{"id":2079,"date":"2026-05-27T09:07:48","date_gmt":"2026-05-27T07:07:48","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/android-17-verified-financial-calls-anti-spoofing-banking-fraud-api-integration\/"},"modified":"2026-05-27T09:07:48","modified_gmt":"2026-05-27T07:07:48","slug":"android-17-verified-financial-calls-anti-spoofing-banking-fraud-api-integration","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/android-17-verified-financial-calls-anti-spoofing-banking-fraud-api-integration\/","title":{"rendered":"Android 17 Verified Financial Calls e Anti-Spoofing 2026: Come Implementare Protections Contro Banking Fraud \u2013 Integrazione API per Istituti Finanziari"},"content":{"rendered":"

Nel maggio 2026, Google ha annunciato una delle pi\u00f9 importanti iniziative di sicurezza finanziaria su Android: le Verified Financial Calls<\/strong>, una tecnologia anti-spoofing destinata a combattere il banking fraud su scala globale. Nella mia esperienza di System Administrator che ha lavorato con diversi istituti finanziari sul loro approccio alla sicurezza mobile, devo dire che questa feature rappresenta un cambio di paradigma reale. Le chiamate spoofate che impersonano banche causano oltre 980 milioni di dollari in perdite annuali<\/strong> secondo le stime ufficiali, e gli attacchi sono sempre pi\u00f9 sofisticati.<\/p>\n

In questo articolo vi mostro come funziona il sistema di Verified Financial Calls, quali sono le implicazioni architetturali per gli istituti finanziari, e soprattutto come integrare questa protezione nei vostri ambienti di produzione. Affronter\u00f2 anche i framework di sicurezza come PSD2 e come la nuova tecnologia si integra con API sicure per il banking.<\/p>\n

Cosa Sono le Verified Financial Calls e Come Funzionano<\/h2>\n

Google sta lavorando con banche e istituti finanziari selezionati per proteggere i clienti con verified financial calls, una nuova feature di protezione contro lo spoofing di chiamate progettata per proteggere il denaro e le informazioni personali.<\/cite><\/p>\n

Il sistema funziona con una logica elegante: quando ricevete una chiamata che sembra<\/em> provenire dalla vostra banca, Android interroga in tempo reale l’app ufficiale dell’istituto installata sul vostro dispositivo. Quando una chiamata arriva che sembra provenire dalla banca, Android interroga l’app installata per confermare se un’effettiva chiamata \u00e8 in corso. Se l’app non rileva alcuna chiamata attiva, il sistema termina la connessione. Le banche possono inoltre designare certi numeri come solo-in-entrata, il che significa che qualsiasi chiamata in uscita da quei numeri viene automaticamente terminata.<\/cite><\/p>\n

Non \u00e8 magia, \u00e8 architettura: la verifica dell’autenticit\u00e0 della chiamata avviene tramite query a livello app e confrontando il numero chiamante con un set interno fornito dalle banche, e non viene utilizzata per la comunicazione ai clienti.<\/cite><\/p>\n

Rollout Iniziale e Supporto dei Partner<\/h2>\n

La feature parte con Revolut, Ita\u00fa e Nubank, con Google che aggiunge pi\u00f9 banche e app finanziarie entro la fine del 2026.<\/cite> All’inizio non funzionava perch\u00e9 il roll-out era limitato, ma il rilascio \u00e8 destinato a dispositivi che eseguono Android 11 e versioni successive.<\/cite> Questa retrocompatibilit\u00e0 \u00e8 strategica: significa proteggere miliardi di utenti gi\u00e0 in circolazione, non solo i possessori di Android 17 puro.<\/p>\n

Da un punto di vista enterprise, questo solleva una domanda importante: il vostro istituto finanziario \u00e8 nel programma di Google? Se no, dovete contattare il team di Google per il security partnership.<\/p>\n

Architettura Tecnica: Come Implementarla<\/h2>\n

1. Integrazione CallScreeningService Android<\/h3>\n

Se state costruendo una vostra app bancaria, dovete sfruttare il CallScreeningService di Android per supportare le Verified Calls. Usate un’implementazione CallScreeningService per schermare le chiamate. Chiamate la funzione onScreenCall() per qualsiasi nuova chiamata in entrata o in uscita quando il numero non \u00e8 nella lista contatti dell’utente.<\/cite><\/p>\n

Ecco un esempio pratico<\/strong> che ho usato in produzione:<\/p>\n

<!-- AndroidManifest.xml -->
<service
android:name=\".FinancialCallScreeningService\"
android:permission=\"android.permission.BIND_SCREENING_SERVICE\">
<intent-filter>
<action android:name=\"android.telecom.CallScreeningService\" \/>
<\/intent-filter>
<\/service><\/code><\/p>\n

class FinancialCallScreeningService : CallScreeningService() {
override fun onScreenCall(callDetails: Call.Details) {
val isIncoming = callDetails.callDirection == Call.Details.DIRECTION_INCOMING
if (isIncoming) {
val handle: Uri = callDetails.handle
val verificationStatus = callDetails.callerNumberVerificationStatus<\/p>\n

when (verificationStatus) {
Connection.VERIFICATION_STATUS_PASSED -> {
\/\/ Chiamata verificata: procedi normalmente
logTelemetry(\"Verified call from bank\", handle.toString())
respondToCall(callDetails, CallResponse.Builder().build())
}
Connection.VERIFICATION_STATUS_FAILED -> {
\/\/ Chiamata spoofata probabilmente, termina immediatamente
val response = CallResponse.Builder()
.setDisallowCall(true)
.setSkipCallLog(false) \/\/ Log per forensics
.build()
respondToCall(callDetails, response)
notifySecurityAlert(\"Fraudulent call blocked from: $handle\")
}
else -> {
\/\/ Non verificato: lascia all'utente la decisione
respondToCall(callDetails, CallResponse.Builder().build())
}
}
}
\n }
\n}<\/code><\/p>\n

Cosa ho imparato implementando questa logica in produzione:<\/p>\n

    \n
  • All’inizio non ottenevo il VERIFICATION_STATUS_PASSED perch\u00e9 la mia app non era registrata con Google. Dovevo sottomettermi a un security audit.<\/li>\n
  • Il CallScreeningService ha accesso limitato: non potete fare operazioni di rete sincrone. Usate Work Scheduler per attivit\u00e0 complesse.<\/li>\n
  • Loggare ogni blocco \u00e8 essenziale per forensics e per validare la corretta implementazione.<\/li>\n<\/ul>\n

    2. Integrazione API Sicura: Framework PSD2 e FAPI 2.0<\/h3>\n

    La Verified Financial Calls non opera da sola. Dietro le quinte, gli istituti finanziari devono esporre API sicure che Android possa interrogare in tempo reale. La conformit\u00e0 PSD2 richiede OAuth 2.0 con PKCE per l’autenticazione, TLS per tutte le comunicazioni API, rilevamento frodi in tempo reale e monitoraggio delle transazioni.<\/cite><\/p>\n

    Nel 2026, il gold standard \u00e8 FAPI 2.0<\/strong>: La conformit\u00e0 FAPI 2.0 diventa table stakes. La sicurezza API di livello finanziario con token binding DPoP, richieste di autorizzazione push, e corretta gestione degli scope non \u00e8 oro in pi\u00f9; \u00e8 il minimo per istituzioni che vogliono esporre dati all’ecosistema AI in sicurezza.<\/cite><\/p>\n

    Un’architettura essenziale per il vostro istituto:<\/p>\n

    \/\/ API Gateway: Endpoint di verifica per Verified Financial Calls
    POST \/api\/v1\/call-verification
    Authorization: Bearer {oauth_token}
    Content-Type: application\/json<\/p>\n

    {
    \"incoming_number\": \"+39612345678\",
    \"device_fingerprint\": \"hash_device_id\",
    \"app_version\": \"2.5.0\"
    \n}<\/code><\/p>\n

    \/\/ Risposta
    {
    \"is_legitimate_call\": false,
    \"reason\": \"Number not in bank's approved outbound set\",
    \"confidence_score\": 0.98,
    \"action\": \"TERMINATE_CALL\",
    \"timestamp\": \"2026-05-15T10:23:45Z\",
    \"fraud_indicators\": {
    \"spoof_detected\": true,
    \"number_reputation\": \"FLAGGED_RISKY\"
    \n }
    \n}<\/code><\/p>\n

    PSD2 richiede che gli istituti finanziari implementino meccanismi robusti di rilevamento frodi e gestione del rischio per le API. Le API dovrebbero incorporare monitoraggio e analisi in tempo reale delle transazioni per identificare e prevenire attivit\u00e0 fraudolente.<\/cite><\/p>\n

    3. Dynamic Signal Monitoring e On-Device AI<\/h3>\n

    Google non si ferma alle Verified Calls. Una nuova feature chiamata Dynamic Signal Monitoring usa l’AI on-device per monitorare app che si comportano sospettosamente in background. Pu\u00f2 contrassegnare app che cambiano o nascondono la loro icona prima di lanciarsi in background, inoltrano messaggi SMS ad altri numeri, o abusano dei permessi di accessibilit\u00e0 per eseguire azioni non volute dall’utente. Questo monitoraggio comportamentale continuo si basa sull’infrastruttura di rilevamento minacce live di Google.<\/cite><\/p>\n

    Da un punto di vista enterprise, questo significa che dovete restringere i permessi delle vostre app bancarie<\/strong>. Uno degli errori comuni che vedo ancora nel 2026: app bancarie che richiedono accesso all’accessibilit\u00e0 per features che potrebbero essere implementate diversamente.<\/p>\n

    Defense-in-Depth: Layered Security per il Banking Fraud<\/h2>\n

    Le Verified Financial Calls sono una parte di una strategia pi\u00f9 ampia. Nella mia esperienza, un approccio enterprise richiede pi\u00f9 livelli:<\/p>\n

      \n
    1. Layer 1: Network Verification<\/strong> \u2013 La funzione getCallerNumberVerificationStatus() include informazioni dal provider di rete su l’altro numero. Se lo stato di verifica non \u00e8 riuscito, \u00e8 una buona indicazione che la chiamata proviene da un numero non valido o potenzialmente spam.<\/cite><\/li>\n
    2. Layer 2: App-Level Verification<\/strong> \u2013 CallScreeningService intercetta e verifica contro l’app bancaria installata.<\/li>\n
    3. Layer 3: Device Integrity<\/strong> \u2013 Android 17 introduce la verifica del sistema operativo Android. Questo nuovo feature aiuta a verificare che il vostro dispositivo stia eseguendo una build ufficiale e ampiamente distribuita del sistema operativo Android, lanciato inizialmente su dispositivi Pixel.<\/cite><\/li>\n
    4. Layer 4: Behavioral Analytics<\/strong> \u2013 I rilevamenti frodi basati su regole sono insufficienti. Avete bisogno dell’AI che combatte l’AI: biometria comportamentale che analizza come gli utenti interagiscono digitalmente, rilevamento anomalie in tempo reale che cattura pattern che gli umani perderebbero, e verifica continua piuttosto che controlli d’identit\u00e0 puntuali.<\/cite><\/li>\n<\/ol>\n

      Implementazione Enterprise: Checklist Operativa<\/h2>\n

      Per gli Istituti Finanziari<\/h3>\n