Il 12 settembre Revolut ha confermato di aver comunicato dati personali di alcuni clienti a un terzo non autorizzato. Nessun sistema è stato violato, nessun malware è stato usato, nessun attaccante è entrato nell'infrastruttura. I dati sono usciti dalla porta principale, consegnati da personale che riteneva in buona fede di stare rispondendo a una richiesta legittima di un'autorità pubblica.

È il motivo per cui questo incidente merita più attenzione di molte violazioni tecnicamente più sofisticate.

I fatti

Secondo la comunicazione inviata ai clienti coinvolti, che ha iniziato a circolare l'11 settembre ed è stata visionata da TechCrunch, Revolut ha ricevuto una richiesta di informazioni che sembrava provenire da una legittima agenzia governativa. La richiesta arrivava da un account di posta non autorizzato ma operante all'interno del dominio ufficiale dell'agenzia. Nelle parole dell'azienda, «poiché la comunicazione presentava credenziali di autenticazione del dominio valide, è stata evasa nella ragionevole convinzione che fosse una richiesta autentica».

Tradotto: SPF, DKIM e DMARC hanno dato esito positivo, perché il messaggio partiva davvero da quel dominio. L'attaccante aveva creato una casella all'interno dell'infrastruttura dell'agenzia, oppure ne aveva compromessa una esistente. Non si è trattato di spoofing nel senso classico del termine, e questa è la differenza che rende il caso interessante: i controlli anti-spoofing non potevano rilevare nulla, perché non c'era nulla da rilevare.

I dati consegnati, secondo la notifica, sono l'insieme completo di ciò che un istituto regolamentato è obbligato a raccogliere per l'adeguata verifica della clientela:

  • identità: nome completo, data di nascita, professione;
  • contatti: indirizzo postale, email, numero di telefono;
  • documenti e verifica: copia del documento d'identità (passaporto e/o patente) e immagine di verifica facciale, ossia il selfie fornito in fase di onboarding (Revolut precisa che non sono stati coinvolti dati biometrici di telemetria facciale);
  • dati finanziari: estratti conto con IBAN, stato e data di apertura del rapporto, riferimento del wallet, registro dei prelievi e cronologia completa delle transazioni, incluse quelle in Bitcoin.

Revolut ha scoperto la frode solo dopo, contattando autonomamente l'agenzia per verificare la richiesta: l'ente ha confermato di non averla mai inoltrata. L'azienda dichiara di aver bloccato l'indirizzo, allertato l'agenzia, informato le autorità di polizia e segnalato l'incidente ai regolatori finanziari. Afferma inoltre che i fondi dei clienti non sono stati toccati.

Due elementi restano opachi. Revolut non ha reso noto il numero di clienti coinvolti — parla genericamente di un numero limitato — né quale agenzia e quale Paese siano coinvolti. La seconda reticenza è la più problematica: senza il nome della casella, nessun altro operatore regolamentato può cercare nei propri registri delle richieste di autorità se ha ricevuto messaggi dalla stessa origine. Il ricercatore ZachXBT, che ha diffuso la notifica, ritiene che l'operazione fosse mirata a clienti con patrimoni elevati.

Se quella lettura è corretta, non siamo davanti a un furto di massa ma a un'operazione chirurgica: costruire profili completi di persone facoltose incrociando documento d'identità, selfie, IBAN e movimenti in criptovaluta riconducibili all'identità reale. È esattamente il materiale che serve per SIM swap, frodi di identità, sostituzione di persona in banca e — nel caso di detentori noti di criptovalute — per estorsioni che possono assumere forme molto concrete.

Cosa significa per le aziende italiane

La tentazione è archiviarlo come un problema di una fintech estera. Sarebbe un errore, per tre ragioni.

La prima: la richiesta dell'autorità è un vettore di attacco sottovalutato in Italia. Studi professionali, banche, assicurazioni, società di recupero crediti, telco, provider e pubbliche amministrazioni ricevono con regolarità richieste di dati da Autorità giudiziaria, Guardia di Finanza, Agenzia delle Entrate, forze di polizia. Il canale è spesso la PEC, a volte la posta ordinaria, in molti casi un modulo firmato in PDF. E il riflesso condizionato dell'organizzazione, davanti a una carta intestata, è eseguire. Chiedere una verifica a un magistrato o a un ufficiale è percepito come un atto scortese, o addirittura rischioso. Quella percezione è precisamente ciò su cui un attaccante costruisce l'operazione.

Va detto con onestà che il caso Revolut, in Italia, sarebbe stato più difficile ma non impossibile: la PEC fornisce una catena di custodia più forte della semplice posta elettronica, e il domicilio digitale degli enti è verificabile su IPA e INI-PEC. Ma la PEC non è il canale unico, molte richieste arrivano ancora via email ordinaria da caselle istituzionali, e soprattutto una casella PEC compromessa resta una casella PEC valida a tutti gli effetti. Il controllo crittografico e il controllo di legittimità sono due cose diverse: qui è fallito il secondo.

La seconda: sul piano GDPR questo è un data breach a tutti gli effetti. Non serve un'intrusione informatica perché scatti l'articolo 33. La divulgazione non autorizzata di dati personali a un terzo è una violazione anche quando è compiuta materialmente da un dipendente in buona fede — anzi, il Regolamento distingue esplicitamente tra distruzione, perdita, modifica, divulgazione non autorizzata e accesso. Trattandosi di documenti d'identità, immagini del volto e dati finanziari completi, il rischio elevato per i diritti degli interessati è difficilmente contestabile, e con esso l'obbligo di comunicazione agli interessati ex articolo 34. Revolut ha notificato i clienti, ed è la scelta corretta.

Il punto che riguarda i titolari italiani è a monte: evadere una richiesta illegittima significa aver trattato dati senza una base giuridica valida. L'articolo 6, paragrafo 1, lettera c) del GDPR copre l'obbligo legale, ma solo se l'obbligo esiste davvero. Se la richiesta è falsa, l'obbligo non esiste, e la comunicazione è un trattamento illecito imputabile al titolare. Il fatto di essere stati ingannati non sposta la responsabilità: sposta semmai la valutazione di adeguatezza delle misure organizzative previste dall'articolo 32, che è esattamente il terreno su cui il Garante costruisce le sanzioni.

La terza: per banche, assicurazioni e intermediari c'è anche DORA. Il Regolamento (UE) 2022/2554 è pienamente applicabile dal gennaio 2025 e impone di classificare e segnalare gli incidenti ICT rilevanti alle autorità competenti. Un incidente di questo tipo — che non compromette sistemi ma produce divulgazione di dati di clientela per un difetto di processo — rientra nel perimetro: DORA guarda all'impatto, non alla tecnica dell'attaccante. Le entità NIS2 hanno un obbligo analogo verso ACN e CSIRT Italia, con la notifica di preallerta entro 24 ore. Chi ha impostato le proprie procedure di incident response assumendo che «incidente» significhi «qualcuno è entrato nei sistemi» ha una lacuna da colmare.

C'è infine un aspetto che merita di essere detto chiaramente, perché tocca un dibattito aperto. Il modello KYC concentra in un unico archivio, presso ogni singolo operatore, il set completo di documenti identificativi di ciascun cliente. Ogni fintech, ogni exchange, ogni intermediario custodisce la stessa copia dello stesso passaporto. La sicurezza di quel documento non è quella del custode migliore, ma quella del peggiore fra tutti quelli a cui il cliente lo ha consegnato — e nel caso Revolut, quella del suo processo di risposta alle richieste delle autorità. È una fragilità strutturale della normativa antiriciclaggio, non un difetto di un singolo operatore, e il portafoglio di identità digitale europeo previsto da eIDAS 2 nasce anche per ridurla. Nel frattempo, il rischio resta interamente sul cliente.

Cosa fare subito

  • Definire una procedura scritta per le richieste delle autorità, con verifica indipendente obbligatoria per le richieste che comportano la comunicazione di documenti d'identità, dati finanziari o categorie particolari di dati. La verifica deve avvenire su un canale diverso da quello della richiesta e con un recapito reperito autonomamente (IPA, INI-PEC, centralino ufficiale), mai con i contatti indicati nella richiesta stessa.
  • Richiamare fuori banda ogni richiesta anomala: importo o ampiezza del dato inusuali, urgenza dichiarata, riferimenti normativi generici, richiesta di inviare i dati a un indirizzo diverso da quello mittente. Sono gli stessi segnali del BEC, applicati a un contesto in cui nessuno li cerca.
  • Registrare ogni richiesta ricevuta ed evasa in un registro dedicato, con protocollo, base giuridica invocata, dati comunicati ed esito della verifica. Serve per l'accountability e serve, il giorno in cui emerge un caso come questo, per capire in mezz'ora se si è stati colpiti.
  • Formare chi materialmente risponde — compliance, legale, back office, segreterie — non sul GDPR in astratto ma su questo scenario specifico, e dare esplicita copertura organizzativa a chi decide di verificare prima di rispondere. Finché chiedere conferma è visto come un rischio personale, nessuno lo farà.
  • Trattare l'account takeover di caselle istituzionali come ipotesi realistica nella propria threat modeling: l'autenticazione del dominio prova la provenienza, non la legittimità. MFA resistente al phishing e monitoraggio degli invii anomali sulle proprie caselle valgono anche in senso inverso, per non diventare il dominio da cui parte la prossima richiesta falsa.
  • Estendere la definizione di incidente nelle procedure DORA/NIS2 alla divulgazione non autorizzata per errore di processo, e verificare che il flusso di escalation porti alla notifica nei termini previsti.
  • Per i clienti Revolut: attivare tutte le notifiche di sicurezza disponibili, diffidare di qualunque contatto che faccia leva su dettagli personali verificabili (sono proprio quelli finiti in mano all'attaccante), e considerare che documento d'identità e selfie compromessi restano utilizzabili per anni — un aggiornamento del documento, dove possibile, è l'unica mitigazione reale.