The Trust Gap: cosa insegna il caso di una banca digitale a chi gestisce dati sensibili

Il caso non racconta il fallimento di una singola fintech, peraltro di eccellenza, ma mostra un punto cieco comune a tutto il settore finanziario: la distanza tra sapere da dove arriva una richiesta e sapere che quella richiesta è legittima e va eseguita. Planetica chiama questa distanza Trust Gap.

Questo paper ricostruisce l’accaduto sulla base dei soli fatti confermati e propone un metodo per misurare e ridurre il gap: sette controlli, i Trust Gates, e il Trusted Request Resilience Assessment di Planetica, che ne verifica la tenuta in condizioni realistiche.

Per iniziare: un Trust Gap Briefing con il vostro management, per individuare i flussi di richiesta più esposti nella vostra organizzazione. Contatti in chiusura del documento.

1. Il rischio si è spostato dal sistema al processo decisionale

Per anni la sicurezza è stata misurata sul perimetro tecnico: firewall, autenticazione forte, cifratura, gestione delle identità. Sono presidi che funzionano, e per questo gli attacchi più efficaci li aggirano: non forzano il server meglio protetto, cercano una persona autorizzata che, in buona fede, compia l’azione giusta per la richiesta sbagliata. Il risultato è una divulgazione di dati perfettamente autorizzata, ma impropria. La dinamica dell’incidente che ha coinvolto la banca digitale evidenzia con nitidezza questa catena causale:

identità fidata → richiesta plausibile → dipendente autorizzato → divulgazione di dati sensibili

Nessun layer tecnico risulta compromesso o violato. Il punto debole è una domanda che spesso nessuno si pone: accertare che il mittente sia autentico non significa accertare che la richiesta sia legittima.

2. Cosa è successo

Le richieste di ostensione dei dati sono arrivate da una casella PEC del dominio del Ministero dell’Interno, riconducibile alla Prefettura di Reggio Calabria, compromessa e usata da terzi. Come confermato dall’operatore fintech, i sistemi della banca non sono stati violati.

 Secondo la notifica inviata dalla banca digitale ai clienti, i dati consegnati comprendono anagrafiche, recapiti, copie di passaporti e patenti, selfie usati per la verifica dell’identità (KYC), estratti conto con IBAN, registri dei prelievi e storico completo delle transazioni. Le indagini sono in corso: qui sono considerati solo i fatti confermati ufficialmente.

3. Perché ha funzionato: autenticazione non è legittimità

Ogni controllo standard dava esito positivo: il dominio era reale, la casella certificata, la richiesta coerente nella forma. Tre fattori, presenti in molti istituti, hanno fatto il resto.

Un canale autentico usato dalla persona sbagliata. La PEC certifica l’invio e la consegna di un messaggio tra due caselle, non chi materialmente scrive né se abbia l’autorità per chiedere quei dati. E non è un caso isolato: da gennaio a metà giugno 2026 il CERT-AGID ha gestito oltre 650 eventi legati a caselle PEC compromesse o registrate per scopi illecite già nel 2024 l’FBI aveva segnalato l’uso di caselle governative compromesse per richieste di dati fraudolente

La pressione legittima della collaborazione con le autorità. Le banche devono rispondere con tempestività alle autorità, e la Raccomandazione 11 del GAFI (Gruppo d’Azione Finanziaria Internazionale) chiede che i dati conservati siano rapidamente disponibili. È un obbligo fondato, ma rapidità non significa assenza di verifica: molte richieste ordinarie possono attendere qualche ora per una conferma su un canale indipendente. Quando il processo premia la velocità più della verifica, chi si presenta come autorità trova la strada spianata.

La verifica concentrata sul canale, non sulla richiesta. Una volta accettato il mittente, la richiesta tende a diventare un adempimento ordinario, e restano senza risposta domande che il canale non può risolvere: «l’ufficio è competente?», «il perimetro è proporzionato?». Nel caso in esame, secondo il ministro dell’Interno, una richiesta di quel tipo sarebbe spettata a una Procura e non a un ufficio prefettizio.

Nessuno di questi tre fattori costituisce una carenza isolata dell’istituto finanziario coinvolto: sono caratteristiche strutturali dei processi request-to-disclosure di molti intermediari.

4. Un rischio di sistema, non di una singola banca

Più dati un intermediario è tenuto a conservare, più vale una singola divulgazione impropria. Gli obblighi antiriciclaggio e fiscali, il regolamento MiCA, la direttiva DAC8 e la Travel Rule impongono di conservare per anni identità, documenti e transazioni, anche dopo la chiusura del rapporto. Il tema non è quindi solo come proteggere i dati, ma chi può farli uscire, su quale richiesta e con quale verifica. I principi del GDPR di minimizzazione e proporzionalità offrono già il criterio: consegnare solo i dati necessari, con approvazioni rafforzate per documenti d’identità e dati biometrici.

E l’impatto va oltre la privacy: collegare identità, indirizzo di casa e patrimonio in criptovalute espone le persone a rischi fisici. In Francia i casi di sequestro di persona ed estorsione legati alle criptovalute sono stati 77 nel primo semestre 2026, contro 45 in tutto il 2025; CertiK ha verificato 52 wrench attack (aggressioni fisiche per estorcere criptovalute) nel mondo nello stesso periodo e indica tra i fattori di rischio proprio le fughe di dati. Per chi gestisce clienti ad alto patrimonio, una divulgazione impropria è quindi anche un rischio reputazionale, legale e per la sicurezza delle persone.

5. Dalla fiducia alla verifica: i 7 Trust Gates

Nessuna divulgazione di dati sensibili o di informazioni comunque confidenziali dovrebbe basarsi solo sull’affidabilità del canale da cui arriva la richiesta. I Trust Gates trasformano quella fiducia in sette verifiche esplicite sulla richiesta stessa, da attraversare in sequenza prima del rilascio.

Un canale autentico supera per definizione i controlli sul mittente. I gate successivi, in particolare la verifica di competenza e la conferma su un canale indipendente, sono pensati proprio per intercettare richieste che arrivano da un canale autentico ma non sono legittime.

Ogni gate ha un responsabile, un criterio di superamento e una traccia documentale. Così la verifica non dipende dall’intuito del singolo operatore, ma diventa un controllo di processo, dimostrabile anche al regolatore.

Figura 1 · I 7 Trust Gates, dalla richiesta al rilascio

La tabella collega ogni gate a un controllo concreto e a ciò che il caso dell’istituto finanziario suggerisce, limitandosi ai fatti confermati.

Tre domande da porre al vostro team, già da domani

• Le richieste di dati che arrivano via PEC vengono confermate su un recapito reperito autonomamente o rispondendo alla stessa casella?
• Esiste un riferimento aggiornato su quale autorità è competente per quale tipo di richiesta, e chi lo mantiene?
• Chi può rilasciare documenti d’identità e dati biometrici su richiesta di un’autorità, e con quale livello di approvazione?

Se una di queste risposte non è immediata, il Trust Gap probabilmente esiste. Il Trust Gap Briefing di Planetica serve a dare a queste domande una risposta documentata.
 

6. Come lo affronta Planetica: il Trusted Request Resilience Assessment

La domanda che ogni CISO, DPO e Compliance Officer dovrebbe porsi dopo il caso che ha coinvolto la banca digitale non è «abbiamo una procedura?», ma «la nostra procedura resiste a una richiesta falsa che arriva da un canale autentico?». Il Trusted Request Resilience Assessment di Planetica risponde a questa domanda con evidenze, non con assunzioni.

Perché adesso. Il caso dell’operatore finanziario digitale ha reso visibile uno schema che non è isolato: le caselle PEC compromesse si contano a centinaia ogni semestre, e con DORA e NIS2 i regolatori si aspettano controlli dimostrabili sui processi critici, non solo procedure scritte. Meglio scoprire il proprio Trust Gap in un test controllato che in una notifica ai clienti.

Non è un audit documentale: è una verifica di come il processo decisionale si comporta davvero. Si articola in quattro fasi.

1. Discover: ricostruiamo il processo request-to-disclosure reale, non solo quello descritto dalle policy.
2. Challenge: introduciamo scenari controllati e realistici, come una richiesta urgente da un canale istituzionale, una richiesta ampia e riservata di un regolatore o le richieste di auditor, provider KYC e partner.
3. Observe: osserviamo dove la richiesta viene verificata, contestata, scalata o semplicemente accettata.
4. Improve: traduciamo le evidenze in controlli, procedure e priorità di remediation.

Perimetro, persone coinvolte, escalation e condizioni di stop sono concordati prima di ogni test. Il risultato è una cronologia che mostra il punto esatto in cui il comportamento reale si discosta dalla policy.

Cosa riceve il cliente

Un valore per più funzioni. Per la Security riduce il rischio di business process compromise. Per il DPO rende verificabili minimizzazione, proporzionalità e accountability. Per Legal e Compliance rafforza la verifica della competenza dell’autorità richiedente, della base giuridica e dei percorsi di escalation. Per il Risk Management trasforma un rischio trasversale in controlli misurabili con un responsabile definito. L’assessment si integra inoltre con i requisiti di resilienza operativa e di gestione delle terze parti previsti da DORA e NIS2.

Un percorso modulare. Si può partire da un Trust Gap Briefing per il top management, proseguire con l’assessment, poi con un Control Program di remediation, un Decision Lab di formazione ed esercitazioni tabletop, fino a un retest annuale.

Perché Planetica. Il 70% della nostra attività riguarda i Financial Services: banking, paytech, insurance, asset management. Uniamo competenze di Compliance & AML, Enterprise Risk Management, Corporate Resilience (DORA, NIS2), Data Privacy e Audit, e con l’Academy trasformiamo le remediation in comportamenti stabili, anche lavorando sui bias cognitivi che autorità e urgenza attivano. Conosciamo i vincoli normativi delle banche dall’interno: per questo proponiamo controlli che rafforzano la collaborazione con le autorità, invece di rallentarla.

7. Conclusione: una procedura vale quanto regge

Il caso dell’operatore finanziario digitale insegna che la cybersecurity non è solo tecnologia: è anche persone, procedure e decisioni. Una PEC non garantisce l’identità di chi scrive, e l’esistenza di una procedura non ne assicura la tenuta di fronte a un attacco. La sicurezza reale non consiste nel dimostrare che una procedura esiste, ma che regge quando qualcuno prova deliberatamente ad aggirarla. Verificare prima di fidarsi, soprattutto quando una comunicazione autorevole chiede un’azione irreversibile, è oggi una competenza organizzativa misurabile.