Progettare il reporting normativo AML su larga scala

Perché il reporting AML è il problema di dati più difficile in una banca

A prima vista, il reporting normativo AML sembra un problema di dati. Un’autorità di vigilanza, FINTRAC in Canada o FinCEN negli Stati Uniti, richiede di segnalare determinati schemi di transazione: trasferimenti elettronici di fondi sopra una soglia (EFTR), operazioni in contanti sopra una soglia (CTR), comportamenti sospetti (STR) e transazioni insolite (UTR). Si prendono i dati, si formattano e si inviano.

In pratica, la difficoltà è che l’autorità vuole il quadro completo dei collegamenti: chi ha originato i fondi, chi li ha ricevuti, chi controlla il conto, qual è il livello KYC delle parti, quale tratta valutaria è passata da quale intermediario, quali segnali di sicurezza informatica si sono attivati durante la sessione. Questo contesto è distribuito tra centinaia di sistemi sorgente — core banking retail, mercati dei capitali, credito commerciale, bonifici, cambi, tesoreria, hub clienti, sistemi di identità — ciascuno con il proprio schema, la propria frequenza di aggiornamento e i propri responsabili.

Il 2° pacchetto normativo FINTRAC lo ha reso esplicito: circa 30 casi d’uso distinti, ciascuno dei quali collega la transazione finanziaria ai dati valutari, di clienti/conti e di sicurezza informatica, nelle aree private banking, retail, mercati dei capitali e commerciale. Dal punto di vista architetturale, non è un progetto di reporting. È una piattaforma di integrazione enterprise.

L’architettura di riferimento, dall’inizio alla fine

Le piattaforme che abbiamo progettato per banche di primo livello condividono una struttura comune: cinque livelli logici, ciascuno scalabile e verificabile in modo indipendente:

• Acquisizione dalle sorgenti. Acquisizione delle modifiche ai dati da core banking, Workday HR, hub clienti, motori valutari e segnali di sicurezza informatica. Alcuni sistemi pubblicano eventi; i sistemi legacy espongono estrazioni batch che integriamo in un caricatore con validazione dello schema.
• Dorsale di streaming. Flussi di eventi in stile Kafka che trasportano transazioni finanziarie, aggiornamenti KYC, riscontri nelle liste di sanzioni ed eventi del ciclo di vita dei conti. I topic sono partizionati per cliente o conto per preservare l’ordine per entità.
• Collegamento e arricchimento. I processi di elaborazione dei flussi uniscono l’evento di transazione ai dati anagrafici dei clienti, alle gerarchie dei conti, alle tratte valutarie, ai profili KYC e ai comportamenti storici. Il risultato è un record segnalabile, completamente collegato e conforme alla struttura richiesta dall’autorità.
• Rilevamento e regole. Actimize ospita gli scenari di rilevamento AML per STR/UTR; regole di soglia deterministiche e dati di riferimento governano EFTR/CTR. Il risultato è un flusso di segnalazioni candidate con le relative evidenze.
• Invio e tracciabilità. Un servizio di invio formatta i payload EFTR/STR/CTR/UTR secondo gli schemi FINTRAC, li firma e li trasmette tramite il canale sicuro. Ogni record contiene un ID di tracciabilità che risale agli eventi sorgente.

La piattaforma si basa su Azure — AKS per i servizi containerizzati, PostgreSQL per l’archivio delle segnalazioni normative, Azure Storage per gli eventi grezzi e Azure Monitor / Sentinel per sicurezza e osservabilità. Nelle implementazioni presso le cinque maggiori banche canadesi abbiamo potenziato Actimize su AKS con PostgreSQL, specificamente per le funzionalità CTR su larga scala.

Perché lo streaming di eventi invece dei batch notturni

Storicamente, il reporting AML era un processo batch notturno. Funzionava quando gli obblighi di segnalazione si misuravano in giorni. Oggi le aspettative di FINTRAC, e francamente la stessa propensione al rischio della banca, si avvicinano molto di più al tempo quasi reale. Le segnalazioni EFTR devono essere attivate in modo affidabile indipendentemente da quando viene regolato il bonifico sottostante. Le STR traggono vantaggio dal collegamento dei segnali comportamentali in tempo reale alla transazione.

Lo streaming di eventi offre tre cose che il batch non può offrire. Primo, acquisizione con gestione della contropressione: una sorgente lenta non blocca la pipeline normativa. Secondo, rielaborazione: quando una regola cambia, possiamo rielaborare l’intervallo interessato senza intervenire sui sistemi sorgente. Terzo, ordinamento per entità: partizionando per cliente o conto, garantiamo che una modifica a una transazione venga elaborata dopo l’originale, anche quando transitano diecimila eventi al secondo.

In termini di costi, AKS offre capacità di calcolo elastica che scala con i volumi: i picchi di fine mese, fine anno e volatilità valutaria non richiedono capacità allocata permanentemente.

La modellazione delle minacce come elemento architetturale fondamentale

Il reporting AML opera in un ambiente ostile. I malintenzionati cercano attivamente di restare sotto le soglie, frazionare le transazioni o contaminare i dati KYC. Una buona piattaforma AML non è solo conforme: tiene conto degli attacchi.

Ogni architettura che realizziamo in questo ambito include un modello esplicito delle minacce: STRIDE su ogni confine tra componenti, classificazione dei dati in ogni archivio e identità con privilegi minimi per le chiamate tra servizi. I segreti risiedono in Azure Key Vault; le identità dei servizi usano identità gestite, non credenziali statiche. I payload sensibili, come documenti KYC e dati personali dei clienti, sono crittografati con chiavi envelope associate alla linea di business.

Per le segnalazioni normative, ogni payload è firmato e la chiave di firma è protetta da hardware. Questo significa che una segnalazione manomessa o reinviata può essere rilevata sia da FINTRAC sia dalla nostra pipeline di audit.

KYC e onboarding delle imprese di servizi monetari

Il reporting AML è a valle del KYC. Se il KYC è errato, lo sono anche le segnalazioni. Uno degli interventi tattici più interessanti a cui abbiamo lavorato è il flusso di onboarding per le imprese di servizi monetari (MSB), una categoria di clienti effettivamente ad alto rischio, per la quale i requisiti di adeguata verifica KYC sono rilevanti.

Il modello architetturale: una pipeline di screening che raccoglie registrazioni MSB, liste di sanzioni e dati sulla titolarità effettiva in un grafo di arricchimento dei clienti; un’interfaccia tattica di gestione dei casi per il team di indagini AML; e una traccia di audit che collega ogni decisione di onboarding alle evidenze su cui si basa. La soluzione tattica permette di guadagnare tempo mentre l’hub clienti strategico si allinea, ma produce output della stessa struttura, così la piattaforma strategica eredita i dati senza rilavorazioni.

Le lezioni apprese realizzando questa soluzione in due banche di primo livello

• Trattare lo schema dell’autorità come un contratto. Progettare in funzione di esso fin dal primo giorno. Non lasciare che le strutture dati interne si propaghino nel livello di invio.
• Il vero lavoro è creare i collegamenti. Le regole EFTR/STR sono la parte semplice. Collegare correttamente 30 casi d’uso di dati su clienti, conti, cambi e sicurezza informatica assorbe l’80% del lavoro di ingegneria.
• La tracciabilità è indispensabile. Quando un’autorità mette in discussione una segnalazione, occorre mostrare ogni evento che vi ha contribuito in pochi minuti, non giorni.
• L’approvazione dell’Architecture Review Board non è una formalità. Usatela come stimolo al rigore. Le revisioni che abbiamo affrontato hanno individuato problemi di residenza dei dati e gestione delle chiavi che sarebbero stati molto costosi da correggere in seguito.
• Nativo cloud ≠ esclusivamente cloud. Alcuni sistemi a monte resteranno on-premise per anni. L’architettura deve affrontare realisticamente l’integrazione ibrida.

Serve una soluzione simile alla tua banca o fintech?

SEYSO ha progettato piattaforme AML e di reporting normativo per diverse banche canadesi e statunitensi di primo livello, coprendo gli obblighi LCTR, EFTR, STR, UTR, CTR, KYC e CFT. Se stai modernizzando la tecnologia contro la criminalità finanziaria, migrando Actimize o definendo un nuovo programma normativo, parliamone. Tu porta gli obblighi normativi e la complessità dei sistemi sorgente; noi porteremo l’architettura.