# Come le banche dovrebbero monitorare la consegna degli OTP e le frodi

> Gli indicatori chiave di prestazione (KPI) di cui le banche hanno bisogno sul pannello di controllo, i segnali di frode per i quali è opportuno attivare un avviso e il piano operativo per le modalità di errore dell'OTP che hanno maggiori probabilità di causare perdite economiche.

- URL canonico: https://www.broadnet.me/it/blog/bank-otp-delivery-monitoring-fraud-playbook
- Lingua: it
- Ultimo aggiornamento: 2026-10-20
- Editore: BroadNet (https://www.broadnet.me)

- Pubblicato il: 2026-04-30
- Autore: BroadNet Industry Research

Per una banca, un OTP non è una semplice notifica. È un controllo sui flussi di dati più sensibili dal punto di vista della sicurezza: login, conferma della transazione, aggiunta di un beneficiario, attivazione della carta, associazione del dispositivo. Il costo di un OTP non recapitato è un cliente bloccato; il costo di un OTP recapitato ma intercettato, riutilizzato o esaurito dai controlli automatizzati è una perdita diretta dovuta a frode e un confronto con l'autorità di vigilanza. Le banche necessitano quindi di una prassi operativa OTP più rigorosa rispetto ad altri mittenti A2P: una strumentazione migliore, un sistema di allerta più aggressivo per i modelli di frode e un piano d'azione documentato per le modalità di errore prevedibili. Ecco come si presenta tale prassi.

## I cinque KPI che dovrebbero essere appesi al muro

La maggior parte delle banche misura la consegna degli OTP con un singolo numero, il "tasso di consegna", ma questo dato è quasi sempre errato, perché il tasso di consegna riportato dal fornitore del servizio di messaggistica si riferisce al tasso di successo dell'invio, non al tasso con cui un OTP ha effettivamente raggiunto un cliente che lo ha utilizzato. Cinque parametri, monitorati per canale e per operatore di destinazione, forniscono un quadro più preciso.

1. Tasso di consegna end-to-end: frazione delle richieste OTP in cui l'operatore di destinazione ha restituito un [DLR](https://www.broadnet.me/answers/what-is-dlr) positivo entro la finestra di validità dell'OTP. Questo è il numero reale di consegne, non il tasso di accettazione dell'invio.
2. Latenza p50, p95, p99 — invio al dispositivo mobile, per canale, per operatore di destinazione. Tracciata come serie temporale, non come singolo valore; la condizione di allerta è il degrado rispetto a una linea di base mobile piuttosto che una soglia assoluta.
3. Tasso di tentativi: frazione di richieste OTP che hanno comportato un nuovo invio, attivato dall'utente o dal sistema, entro il periodo di validità. Un tasso di tentativi in aumento è il primo segnale di un deterioramento della consegna primaria; quasi sempre precede il calo esplicito del tasso di consegna.
4. Tasso di rifiuto dell'ID mittente: frazione di invii rifiutati al confine dell'operatore per motivi relativi all'ID mittente. Un valore diverso da zero indica un problema di registrazione; in tal caso, dovrebbe essere segnalato come tolleranza zero.
5. Tasso di completamento OTP: percentuale di richieste OTP in cui l'utente ha inserito correttamente il codice. Questo è l'unico KPI che conta commercialmente; tutto il resto ne è influenzato. Un tasso di consegna del 99% abbinato a un tasso di completamento del 70% indica che il messaggio è arrivato troppo tardi o che l'esperienza utente relativa all'inserimento è difettosa; la consegna senza completamento non è un successo.

## I segnali di frode su cui prestare attenzione

L'infrastruttura OTP rappresenta anche una superficie di attacco per i sistemi OTP. Sono comuni tre categorie di abusi, tutte rilevabili dai dati che la banca già raccoglie.

### 1. Richieste ripetute di OTP per lo stesso MSISDN

Un utente malintenzionato che sonda il flusso OTP su un singolo account, manualmente o tramite uno script, produce una firma caratteristica: molte richieste OTP per un singolo numero di telefono, spesso concentrate in un breve lasso di tempo, a volte con indirizzi IP o stringhe User-Agent diversi nella sessione di origine. L'equivalente legittimo (un utente che non riesce effettivamente a trovare il codice) si ferma a tre o cinque tentativi in pochi minuti; un profilo di attacco ne prevede decine o centinaia. Le soglie di allerta dovrebbero essere rigorose: più di dieci richieste OTP per un singolo numero MSISDN in quindici minuti indicano quasi sempre un attacco o un'integrazione non funzionante, entrambe situazioni che meritano attenzione.

### 2. Anomalie geografiche e comportamentali

Una richiesta di OTP da una sessione originata in un Paese, per un numero di telefono storicamente associato a un altro Paese, non è necessariamente indice di frode (potrebbe trattarsi di un cliente in viaggio), ma è opportuno applicare un livello di autenticazione più approfondito, anziché accettarla passivamente. Se a questo si aggiungono le modifiche all'impronta digitale del dispositivo (nuovo browser, nuovo ID dispositivo, nuova installazione di applicazioni), il segnale di allarme diventa più forte. Il sistema di gestione del rischio della banca dovrebbe già implementare questa funzionalità per l'autorizzazione delle transazioni; estenderla all'emissione di OTP rappresenta un vantaggio immediato.

### 3. Enumerazione limitata e accumulo di credenziali

Un attaccante più sofisticato enumera gli identificativi degli account attraverso il flusso di recupero password, rimanendo deliberatamente al di sotto del limite di richieste OTP per account, ma sondando molti account in parallelo. La firma è un elevato tasso di richieste OTP su molti MSISDN distinti da un intervallo di sorgenti ristretto, spesso con bassi conteggi individuali per MSISDN che sfuggono agli avvisi per account. Il rilevamento richiede l'aggregazione delle origini di sorgente (IP, classe di dispositivo, schema di sessione) piuttosto che per account. Questo è esattamente lo schema degli attacchi di [SMS pumping](https://www.broadnet.me/answers/what-is-sms-pumping) che alcuni attaccanti eseguono contro l'infrastruttura OTP per monetizzare gli sconti per messaggio offerti dai provider; proteggersi da questo tipo di attacco protegge contemporaneamente sia dalle frodi che dall'inflazione dei costi per i provider.

## Il manuale operativo per le modalità di guasto prevedibili

In ogni banca si verificano tre tipologie di incidenti relativi all'OTP (One-Time Password). Disporre di un piano d'azione scritto per ciascuna tipologia di incidente, e non di un manuale improvvisato generato sotto pressione, fa la differenza tra un ripristino in 15 minuti e uno in 4 ore.

### Manuale operativo 1 — degrado del percorso dell'operatore di destinazione

Segnale: la latenza p95 aumenta su uno specifico operatore di destinazione mentre gli altri rimangono stabili, con conseguente calo del tasso di consegna verso tale operatore. Azione: verificare che il degrado sia lato percorso e non interno (l'accettazione dell'invio è ancora al 100%), reindirizzare il traffico OTP per tale operatore al percorso secondario nel motore di routing, notificare il NOC del provider per conferma e stima dei tempi di ripristino. Ripristino: una volta che le metriche del percorso primario tornano ai valori di base per 30 minuti, ripristinare il servizio. Il playbook completo dovrebbe essere composto da dieci righe e testato trimestralmente.

### Manuale operativo 2: picco di rifiuto dell'ID mittente

Segnale: il tasso di rifiuto dell'ID mittente passa da zero a un valore diverso da zero, quasi sempre per un singolo mercato di destinazione. Azione: verificare se la registrazione dell'ID mittente è scaduta o è stata revocata presso l'autorità di regolamentazione del mercato di destinazione (causa più comune), confermare con l'aggregatore locale, utilizzare un ID mittente di backup registrato per il mercato interessato, se disponibile, inoltrare la registrazione. I tempi di ripristino sono gestiti dall'autorità di regolamentazione, non dalla banca; il compito del playbook è quello di limitare l'impatto negativo durante l'attesa.

### Manuale operativo 3: attacco coordinato di pompaggio di OTP

Segnale: il costo per OTP inviato correttamente aumenta bruscamente; il volume di invii a specifici intervalli di numeri (spesso prefissi adiacenti a tariffe premium o prefissi di paesi specifici) subisce un'impennata; il tasso di completamento di tali invii è prossimo allo zero. Azione: abilitare la lista di autorizzazione dei prefissi di destinazione, se non già attiva (questo è il controllo più efficace in assoluto), limitare l'emissione di OTP dai percorsi di origine interessati, contattare il team antifrode del fornitore di servizi di messaggistica. Ripristino: disattivare la lista di autorizzazione una volta cessato l'attacco; per la maggior parte delle banche non è sicuro mantenerla disabilitata in modo permanente. Vedere [HLR Lookup pre-flight](https://www.broadnet.me/products/hlr-lookup) come mitigazione strutturale contro questa classe.

## Scelte architetturali che rendono possibili i playbook

I manuali operativi dipendono soprattutto da decisioni architettoniche prese prima dell'incidente, non da improvvisazioni durante lo stesso. Tre di queste meritano un'attenzione particolare.

- OTP multicanale fin dal primo giorno: come minimo SMS e voce; idealmente SMS, modello di autenticazione WhatsApp e voce con failover automatico documentato. Il failover è un controllo, non un ripiego; dovrebbe essere attivabile per ogni percorso e per ogni categoria senza modifiche al codice.
- Telemetria di consegna e latenza per canale e per operatore: senza di essa, le dashboard di cui sopra rimangono un miraggio. I dati devono provenire dal fornitore di servizi di messaggistica sotto forma di feed DLR strutturati, non come report PDF mensili.
- Inventario documentato degli ID mittente con date di rinnovo: questo registro dovrebbe essere gestito dal team di conformità della banca, non dal fornitore di servizi di messaggistica; le interruzioni causate da una negligenza del fornitore in merito al rinnovo rimangono comunque un problema della banca quando il traffico smette di arrivare.

## Parlare con il fornitore: quali dati dovrebbero essere restituiti?

Un contratto di messaggistica di livello bancario specifica i dati operativi che il fornitore restituisce, non solo il listino prezzi unitario. Aspettatevi, come minimo:

- Webhook DLR in tempo reale che la banca possa autenticare (ad esempio una [firma HMAC-SHA256](https://www.broadnet.me/answers/hmac-sha256-dlr-signing) con segreto condiviso se il provider firma i callback, oppure una allowlist di IP) in modo che la banca possa riconciliare le richieste con la consegna effettiva nel proprio SIEM.
- Report giornalieri su consegne e latenze, suddivisi per operatore di destinazione, ID mittente e percorso, adatti all'integrazione nel sistema di osservabilità della banca.
- Riepiloghi mensili degli incidenti con cronologia, causa principale e misure di mitigazione per qualsiasi incidente lato fornitore che abbia interessato il traffico della banca.
- Contatti diretti per l'escalation presso il NOC e il team antifrode del fornitore, con un accordo sul livello di servizio (SLA) e tempi di risposta predefiniti.

> Il servizio OTP di BroadNet fornisce analisi di consegna, latenza e completamento per canale e per operatore sotto forma di feed strutturati, e lo stesso livello di rilevamento delle frodi che protegge l'operatore è disponibile per i clienti OTP aziendali come sistema di punteggio preliminare per le richieste prima che vengano convertite in invii a pagamento.

## Preparazione alle normative: una dimensione spesso trascurata

Le banche centrali e le autorità di regolamentazione dei servizi finanziari pongono sempre più spesso domande esplicite sull'infrastruttura di erogazione dell'OTP durante le ispezioni: qual è l'SLA, qual è il failover, qual è la tracciabilità delle operazioni, come vengono rilevati e contrastati i modelli di frode. Le banche che riescono a rispondere in cinque minuti attingendo a un dossier operativo preesistente superano l'ispezione senza problemi; quelle che devono improvvisare la risposta nel bel mezzo di un'ispezione non ce la fanno. Gli indicatori chiave di prestazione (KPI) e i manuali operativi sopra menzionati costituiscono gli input di tale dossier; trattateli come artefatti di conformità oltre che operativi.

## Un anti-pattern comune per andare in pensione

Molte banche integrano l'OTP come funzionalità del servizio di autenticazione, anziché come sistema autonomo. Il risultato: l'integrazione della messaggistica è gestita da chi ha originariamente creato il flusso di autenticazione, spesso una persona che nel frattempo ha cambiato team; nessuno presta attenzione alla telemetria di consegna per singolo operatore; il primo segnale di un degrado si manifesta con un picco di richieste di assistenza clienti che il team di supporto non riesce a ricondurre a un problema di messaggistica. La soluzione è strutturale: un responsabile designato per l'infrastruttura OTP con un piccolo team dedicato (o un team partner chiaramente identificato), una revisione trimestrale del dashboard dei KPI e un'esercitazione annuale end-to-end dei playbook sopra descritti, simulando uno scenario di incidente realistico. Tutti i fornitori di servizi di messaggistica di livello bancario istituzionale effettuano revisioni congiunte trimestrali con i propri clienti come parte integrante del rapporto; se il vostro non lo fa, richiedetelo.

## Che aspetto ha il bene, in numeri

Un'infrastruttura OTP bancaria ben gestita, che invia messaggi in un mercato regolamentato del GCC tramite rotte dirette degli operatori, con la catena di fallback e i controlli antifrode descritti in precedenza, dovrebbe raggiungere: un tasso di completamento end-to-end superiore al 99% (non solo la consegna, ma la verifica effettiva del cliente), una latenza p95 inferiore a cinque secondi sul canale primario, un tasso di rifiuto dell'ID mittente pari a zero, un tasso di tentativi inferiore al 3% (al di sopra del quale l'esperienza utente e i costi peggiorano) e un blocco delle richieste OTP correlate a frodi inferiore all'1% del traffico legittimo (i falsi positivi sono importanti: un blocco troppo aggressivo rappresenta di per sé un problema per l'esperienza del cliente). Le banche che si attestano significativamente al di sotto di questi valori hanno una o più delle sette cause di errore descritte nella [guida alla risoluzione dei problemi di consegna OTP](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting) attive in produzione; diagnosticare prima di ottimizzare.

## Letture correlate

- [Perché i messaggi OTP non vengono recapitati e come risolvere i problemi di consegna](https://www.broadnet.me/blog/why-otp-messages-fail-delivery-troubleshooting)
- [In che modo la verifica delle chiamate flash influisce sui ricavi A2P degli operatori](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- [Strategia di messaggistica omnicanale per e-commerce e logistica](https://www.broadnet.me/blog/omnichannel-messaging-ecommerce-logistics-strategy)
- Glossario — [cos'è un OTP](https://www.broadnet.me/answers/what-is-otp), [cos'è l'invio massivo di SMS](https://www.broadnet.me/answers/what-is-sms-pumping), [cos'è un DLR](https://www.broadnet.me/answers/what-is-dlr)
- Pagine prodotto — [Servizio OTP](https://www.broadnet.me/products/otp) e [OTP vocale MyOTP](https://www.broadnet.me/products/myotp)
- Copertura — [Routing conforme a OTP e TDRA negli Emirati Arabi Uniti](https://www.broadnet.me/coverage/uae)