> Avviso: Questo contenuto è destinato esclusivamente a scopi educativi e di riferimento per i software builder. Non costituisce consulenza medica, legale, finanziaria o regolamentare. Consultare un professionista qualificato prima di prendere decisioni basate su questo contenuto.
Usare un Modello Dati KYC Append-Only Event-Sourced
Motivazione: I dati KYC cambiano nel corso del rapporto con il cliente (scadenza dei documenti, variazione dello status PEP, upgrade EDD) e i regolatori possono richiedere di ricostruire lo stato KYC del cliente in qualsiasi punto storico del tempo. I record mutabili non possono soddisfare questo requisito.
Da fare: Modellare il record KYC come un flusso di eventi: ogni azione di verifica, cambio di stato e valutazione del rischio viene accodato come evento immutabile con un timestamp UTC, un ID attore e un tipo di evento. Ricavare lo stato corrente riproducendo gli eventi. Archiviare uno snapshot periodico per le prestazioni delle query.
Da non fare: Aggiornare in-place una singola riga customers per riflettere lo stato KYC corrente. Una singola riga con status=verified non dice nulla su quando è avvenuta la verifica, chi l'ha eseguita o qual era lo stato a una data contestata.
Separare lo Screening delle Sanzioni dalla Latenza del Flusso di Onboarding
Motivazione: Lo screening delle sanzioni (OFAC SDN, EU Consolidated, UN) implica una fuzzy matching su grandi liste. Bloccare la chiamata API di onboarding per la fuzzy matching completa introduce latenza e degrada l'esperienza utente.
Da fare: Eseguire un controllo sincrono rapido di exact-match (ricerca hash del nome) durante l'onboarding per il blocco immediato delle corrispondenze ovvie. Mettere in coda un processo di fuzzy matching completo che si completi in pochi secondi e scriva il risultato, ponendo il conto in stato pending fino a quando il risultato completo non è disponibile. Progettare la macchina a stati KYC in modo che i conti non possano effettuare transazioni fino a quando il risultato completo dello screening non viene superato.
Da non fare: Saltare la fuzzy matching (causa falsi negativi - nomi strutturalmente simili non rilevati) oppure bloccare l'intero onboarding in modo sincrono su una fuzzy match completa su milioni di voci SDN.
Archiviare i Parametri delle Regole AML nel Database, non nel Codice
Motivazione: I compliance officer devono poter regolare le soglie di monitoraggio AML (limite CTR, finestra velocity, periodo di lookback strutturazione) in risposta a variazioni normative o nuove tipologie - senza richiedere un deployment software.
Da fare: Persistere ogni soglia, finestra e condizione della regola in una tabella del database aml_rules. Il motore di regole legge le regole attive all'avvio (o a un intervallo configurabile). Un'admin UI di compliance consente modifiche ai parametri con audit trail completo (chi ha cambiato cosa, quando, valore precedente).
Da non fare: Codificare come costanti nel codice dell'applicazione la soglia CTR di $10.000, la scadenza SAR di 30 giorni o il limite di velocity di 20 transazioni. Anche le soglie normative "stabili" cambiano (es. la soglia della Travel Rule FATF varia per giurisdizione).
Implementare Notifiche Multi-Livello per la Scadenza SAR
Motivazione: Mancate rispetto alla scadenza di 30 giorni per la presentazione SAR costituiscono una violazione della BSA. Una singola notifica inviata a T-30 è insufficiente perché i casi possono bloccarsi nelle code degli analisti.
Da fare: Calcolare la scadenza di presentazione alla creazione del caso e implementare notifiche escalanti: T-10 all'analista assegnato, T-5 all'analista e al supervisore, T-2 ad analista, supervisore e MLRO, con escalation automatica se non vengono intraprese azioni. Archiviare tutti gli eventi di notifica nel log di audit del caso.
Da non fare: Affidarsi agli analisti per tracciare manualmente le scadenze, o inviare una singola email di promemoria al momento della creazione del caso. Entrambi i pattern portano a scadenze mancate in team di compliance con volumi elevati.
Non Esporre Mai l'Esistenza del SAR al Soggetto
Motivazione: Il tipping off di un soggetto SAR è un reato penale ai sensi del 31 U.S.C. § 5318(g)(2). I sistemi software devono garantire che lo status SAR non raggiunga mai il cliente tramite API, email, notifica del conto o interazione di supporto.
Da fare: Implementare un flag tipping_off_guard su tutti i record del caso collegati al SAR. Auditare tutte le risposte API che coinvolgono conti con casi SAR aperti per garantire che nessun metadato SAR venga restituito. Formare il personale di supporto che le restrizioni del conto collegate a un SAR devono essere spiegate solo come "revisione del conto in corso." Registrare tutti gli accessi ai dati del caso SAR con l'identità dell'attore.
Da non fare: Restituire messaggi di errore come "Il tuo conto è stato segnalato per attività sospetta" o "È stato presentato un SAR." Non inviare email automatiche di restrizione del conto che coincidano con la presentazione SAR.
Usare Timestamp UTC Lato Server per Tutti gli Eventi Transazionali
Motivazione: Le regole di transaction monitoring dipendono dalla tempistica precisa degli eventi (finestre velocity, aggregazione CTR per giorno lavorativo). I timestamp forniti dal client non sono affidabili e possono essere manipolati per eludere le regole.
Da fare: Assegnare tutti i timestamp delle transazioni lato server al momento della ricezione dell'API. Usare UTC ovunque. Archiviare i timestamp come TIMESTAMPTZ in PostgreSQL. Conservare il timestamp inviato dal client in un campo separato client_submitted_at per la riconciliazione ma non usarlo mai per la valutazione delle regole.
Da non fare: Accettare il timestamp del client come tempo autorevole dell'evento, o archiviare i timestamp come stringhe di ora locale senza informazioni sul fuso orario.
Implementare un Meccanismo di Retention Hold per i Record AML
Motivazione: Il GDPR Art. 17 concede ai clienti UE un diritto alla cancellazione, ma la BSA e le AMLD UE impongono la conservazione quinquennale dei record KYC e delle transazioni. Queste obbligazioni sono in conflitto e devono essere risolte nel software.
Da fare: Implementare un flag compliance_hold sui record clienti e transazioni. Porre un hold all'inizio del periodo di conservazione normativa. Le richieste di cancellazione GDPR attivano un soft-delete che imposta un timestamp deletion_requested_at, ma il hold impedisce la cancellazione definitiva. Un processo pianificato rimuove il hold solo quando retention_expires_at è trascorso, poi esegue la cancellazione in sospeso.
Da non fare: Cancellare i record KYC in risposta a richieste GDPR senza controllare i retention hold attivi. Analogamente, conservare i dati a tempo indeterminato senza implementare il ciclo di cancellazione quinquennale.
Implementare il Dynamic Linking per i Pagamenti Autenticati con SCA
Motivazione: Senza il dynamic linking, un attacco man-in-the-middle può intercettare un codice SCA valido e riprodurlo con un importo del pagamento o un beneficiario diverso. Il RTS PSD2 richiede esplicitamente il dynamic linking. (RTS PSD2 Art. 5, EUR-Lex 2018/389)
Da fare: Includere l'importo del pagamento (in unità minori) e l'IBAN del beneficiario nei dati della challenge prima di calcolare il codice SCA (challenge FIDO2 o seed TOTP). Verificare lato server che il codice restituito sia stato calcolato su una challenge che corrisponde ai dettagli del pagamento nella submission.
Da non fare: Usare un OTP statico o una SCA legata alla sessione che non sia collegata allo specifico importo del pagamento e al beneficiario.
Registrare Ogni Concessione e Revoca del Consenso nell'Open Banking
Motivazione: La PSD2 richiede che il consenso sia esplicito, granulare, limitato nel tempo e revocabile. In caso di disputa, il registro del consenso è l'unica prova che un TPP fosse autorizzato ad accedere a un conto.
Da fare: Registrare ogni evento di consenso (concessione, accesso, rinnovo, revoca) con: ID consenso, identificatore TPP, scope, ID cliente, timestamp, indirizzo IP e l'access token/i emessi. Fornire un'interfaccia di gestione del consenso rivolta al cliente che elenchi i consensi attivi e consenta la revoca immediata.
Da non fare: Gestire il consenso solo nei sistemi del TPP senza mantenere un registro indipendente lato ASPSP (banca). Una banca non può dimostrare la conformità alla PSD2 se non ha record di consenso.
Validare il Formato IBAN Prima dell'Archiviazione o dell'Elaborazione
Motivazione: Gli IBAN malformati causano rifiuti di pagamento, falsi alert AML positivi e problemi di qualità dei dati. La validazione al momento dell'inserimento è meno costosa della correzione downstream.
Da fare: Implementare la validazione IBAN MOD-97 (ISO 13616) come funzione utility chiamata ad ogni invio del modulo di pagamento e ai confini API dove vengono ricevuti gli IBAN. Restituire un errore di validazione chiaro con il motivo specifico del fallimento (codice paese non valido, cifra di controllo fallita, lunghezza BBAN errata). Archiviare solo gli IBAN validati.
Da non fare: Accettare gli IBAN senza validazione strutturale, affidandosi all'elaborazione del pagamento downstream per rifiutare le voci non valide. I rifiuti downstream arrivano troppo tardi per essere utilizzabili nella sessione utente.
Implementare lo Screening delle Sanzioni Parametrizzato con Documentata Taratura dei Falsi Positivi
Motivazione: Una fuzzy matching eccessivamente aggressiva produce grandi volumi di alert di sanzioni falsi positivi, sopraffacendo gli analisti di compliance e degradando l'efficacia delle corrispondenze genuine.
Da fare: Documentare l'algoritmo di fuzzy matching e la soglia utilizzati (es. distanza di Levenshtein ≤ 2, Jaro-Winkler > 0.85, corrispondenza fonetica Soundex). Registrare il punteggio di corrispondenza su ogni risultato di screening. Tracciare le disposizioni di falsi positivi degli analisti nel tempo e usarle per calibrare la soglia. Implementare una "whitelist" per i nomi noti come falsi positivi (es. nomi comuni identici alle voci SDN) con rivalidazione obbligatoria alla scadenza della whitelist.
Da non fare: Usare solo exact-match screening (alto tasso di falsi negativi) o usare soglie fuzzy molto basse senza la capacità degli analisti di processare il volume di alert risultante.
Implementare il Risk Scoring AML come Modello Multi-Fattore e Versionato
Motivazione: Gli esaminatori normativi si aspettano che gli istituti finanziari dimostrino un approccio basato sul rischio con criteri di scoring documentati e verificabili. Un singolo flag di rischio o un tier manuale è insufficiente.
Da fare: Progettare un modello di risk scoring che combini fattori ponderati: tipo di cliente (individuo/azienda), rischio di giurisdizione, rischio di prodotto, rischio del comportamento transazionale, status PEP/sanzioni e media avversi. Archiviare ogni valore del fattore, il suo peso e il punteggio composito in una tabella risk_assessments con un campo model_version. Quando il modello viene rivisto, ri-calcolare il punteggio di tutti i clienti e archiviare sia la vecchia che la nuova valutazione.
Da non fare: Assegnare tier di rischio manualmente o basandosi su un singolo fattore (es. "tutti i clienti aziendali sono ad alto rischio"). I modelli a singolo fattore non superano il test di approccio basato sul rischio del FATF.