Come costruire un flusso di screening delle liste di sanzioni: dalle corrispondenze sui nomi a una revisione tracciabile per l'audit

Scaricare una lista di sanzioni ed eseguire ricerche per somiglianza dei nomi non equivale ad avere un prodotto di screening per la compliance. Nell'operatività reale emergono subito omonimi, alias, traslitterazioni, gerarchie societarie, campi identificativi mancanti, aggiornamenti delle liste e arretrati di falsi positivi; durante le interruzioni del sistema, i team devono anche decidere quali flussi sospendere, quali possono passare alla revisione umana e come recuperare lo screening una volta ripristinato il servizio.

Una discussione su r/ComplianceOps a proposito di un'interruzione di un servizio di screening descriveva uno scenario in cui, dopo l'indisponibilità di un fornitore, le transazioni venivano messe in coda in massa, i team scaricavano temporaneamente le liste ufficiali e le regole di gestione manuale non erano state definite in anticipo. Il post e le risposte non sono stati verificati in modo indipendente e non rappresentano le pratiche generali degli istituti finanziari; sollevano però una domanda sensata per la progettazione del prodotto: un prodotto di screening fornisce risultati di ricerca o un flusso decisionale tracciabile sia in condizioni normali sia in modalità degradata?

La lista ufficiale è una fonte, non un giudizio definitivo

Il servizio OFAC Sanctions List Service offre punti di accesso come SDN, Non-SDN consolidated, dataset personalizzati e file delta storici, rendendo disponibili i dati delle liste in formati scaricabili. Il livello di acquisizione deve conservare le liste di origine, gli identificativi dei record, le date di pubblicazione, gli orari di download, i digest dei file e le versioni del parser. Solo così i sistemi potranno indicare in seguito quale versione della lista è stata usata in un determinato screening.

La stessa entità può avere nomi principali, alias deboli, indirizzi, nazionalità, date di nascita, numeri identificativi o identificativi di navi e aeromobili. I prodotti non devono comprimere questi campi in un'unica lunga stringa per poi generare un punteggio opaco. Il livello di normalizzazione deve mantenere i tipi di campo e i valori grezzi della fonte, generando al contempo rappresentazioni normalizzate per la ricerca; qualsiasi trascrizione, rimozione della punteggiatura o traslitterazione deve essere spiegabile.

Le voci delle liste non coprono l'intero ambito della compliance. Le indicazioni dell'OFAC sulla 50 Percent Rule precisano che anche alcune entità non presenti in lista possono essere considerate bloccate se uno o più soggetti sanzionati ne detengono complessivamente una partecipazione pari o superiore al 50 per cento. Lo screening dei soli nomi delle controparti non può sostituire le verifiche sugli assetti proprietari. I prodotti devono separare le corrispondenze dirette nelle liste dalle verifiche delle catene proprietarie e non devono usare ricerche per nome prive di dati sulle partecipazioni per trarre conclusioni su queste ultime.

I punteggi di somiglianza servono solo a individuare i candidati

La FAQ 246 dell'OFAC spiega che Sanctions List Search applica la logica fuzzy solo al campo del nome e usa la corrispondenza dei caratteri per gli altri campi. In altre parole, i punteggi sui nomi sono segnali per individuare candidati, non probabilità di rischio calcolate su più campi.

I prodotti possono usare nomi, alias e traslitterazioni per ampliare il recall, poi ricorrere a date di nascita, indirizzi, nazionalità, giurisdizioni di costituzione, documenti di identità o tipi di entità per aiutare gli analisti a distinguere. Le discrepanze tra i campi, però, hanno un peso che dipende dalla qualità dei dati: un anno di nascita mancante non equivale a una mancata corrispondenza; indirizzi diversi possono riflettere semplicemente sedi passate; un conflitto tra entità persona fisica e società è in genere un segnale di esclusione più forte. L'interfaccia deve mostrare i campi a confronto affiancati invece di un unico punteggio di [87].

Consigliamo di mantenere almeno quattro categorie di risultati:

• In attesa di revisione: il nome o l'alias soddisfa i criteri di individuazione, ma i campi secondari non bastano.
• Candidato escludibile: gli analisti lo escludono sulla base di differenze evidenti nei campi, registrando motivazione e periodo di validità.
• Escalation: i campi chiave corrispondono oppure i rapporti di proprietà richiedono la valutazione del compliance officer.
• Nessun risultato disponibile: la query è incompleta, i dati della lista sono scaduti o gli input sono insufficienti, quindi non è possibile mostrare lo stato “superato”.

La chiusura automatica dei falsi positivi richiede particolare cautela. Un'entità esclusa in precedenza come omonimo non resta escludibile con una nuova versione della lista, un indirizzo aggiornato o un nuovo documento di identità. Le eccezioni di corrispondenza ben progettate devono essere legate agli identificativi dell'oggetto, ai campi a supporto, alle liste applicabili e alle condizioni di scadenza.

La qualità degli input determina la qualità dello screening

Se i sistemi a monte trasmettono solo il nome del beneficiario troncato, nessuna complessità nel backend può recuperare l'identità mancante. Le API di screening dovrebbero restituire indicazioni sulla qualità dell'input: paese mancante, tipo di entità sconosciuto, nome forse troncato per limiti di lunghezza del campo, suffisso societario rimosso o formato dell'identificativo non interpretabile. Le aziende possono così richiedere dati integrativi invece di abbassare di continuo le soglie.

Persone fisiche, società, navi e aeromobili usano modelli di campi distinti. Costringere tutti gli oggetti in [name + country] priva di significato i numeri di registrazione delle società, le date di nascita delle persone e i numeri IMO delle navi. Le interfacce unificate possono condividere un wrapper comune, ma ogni tipo di oggetto deve mantenere i propri campi identificativi forti.

Occorre anche applicare limiti a tutela della privacy. I campi identificativi necessari allo screening non giustificano la conservazione indefinita dei dati dei clienti. Documenti di identità originali, campi estratti, richieste di screening e conclusioni delle analisi richiedono controlli di accesso basati sui ruoli e periodi di conservazione distinti. Le linee guida di questo sito sulla progettazione di un'API unificata per i dati possono aiutare a definire i confini tra le evidenze delle fonti e le azioni di business, ma non sostituiscono le valutazioni sulla giurisdizione e sulle finalità consentite.

Il monitoraggio continuo non è un avviso che si ripete ogni giorno

Dopo ogni aggiornamento delle liste, i sistemi devono individuare i record aggiunti, modificati ed eliminati e poi sottoporre a nuovo screening solo gli oggetti potenzialmente interessati. Senza identificativi stabili dei record di origine e diff tra versioni, i sistemi rischiano di scambiare semplici modifiche di formattazione dei nomi per nuove corrispondenze, o di non rilevare alias o campi identificativi appena aggiunti.

Gli eventi di monitoraggio continuo dovrebbero includere versioni delle liste, campi modificati, numero di oggetti interessati, batch di nuovo screening e stati di elaborazione. Quando lo stesso cliente compare in più rapporti commerciali, la risoluzione delle entità deve evitare la creazione di casi duplicati, mentre le azioni restano indipendenti per ciascun rapporto: onboarding, pagamenti e attivazione dei fornitori possono avere responsabili e tempistiche diversi.

Non interpretare automaticamente la rimozione da una lista come un via libera a riprendere tutte le attività. Congelamenti, rifiuti o decisioni già sottoposte a escalation possono richiedere la revisione del compliance officer secondo le norme applicabili. Le variazioni dei dati si limitano ad attivare delle attività; i sistemi non devono spingersi fino a emettere conclusioni legali.

La gestione del degrado va progettata prima che si verifichino incidenti

Errori di download delle liste, errori di parsing, timeout del servizio di screening e interruzioni del sistema di gestione dei casi sono quattro modalità di guasto distinte. I prodotti devono mostrare la versione corrente delle liste e le metriche di aggiornamento, impedire che cache scadute vengano spacciate per controlli appena completati e conservare le chiavi di idempotenza per le richieste recuperabili, così da non creare casi duplicati quando il servizio torna disponibile.

Le regole per il funzionamento in modalità degradata dovrebbero essere approvate in anticipo dai responsabili delle aree business e compliance, stabilendo per esempio quali flussi si sospendono automaticamente, quali consentono solo il salvataggio in bozza, quando scatta l'instradamento manuale e in quale ordine di priorità smaltire le attività arretrate di nuovo screening. Durante un incidente, i team tecnici non devono decidere sul momento se sbloccare fondi o attivare clienti. L'OFAC Compliance Commitments Framework indica valutazione del rischio, controlli interni, test e audit e formazione come componenti fondamentali di un programma di compliance; i prodotti di screening dovrebbero fornire prove a supporto di questi controlli organizzativi, non pretendere di sostituirli.

Dopo il ripristino occorre generare un elenco di screening di recupero che copra gli oggetti e le transazioni nella finestra dell'interruzione, le versioni delle liste usate in quel momento, l'eventuale variazione dei risultati del nuovo screening e chi ha esaminato le discrepanze. Le linee guida di questo sito sugli errori delle API e sull'auto-riparazione possono aiutare a progettare nuovi tentativi, percorsi di degrado e code di eccezioni, ma le regole effettive di sblocco devono essere definite da personale autorizzato.

La validazione dell'MVP si concentra sui cicli di analisi, non sull'azzeramento dei falsi positivi

Le prime versioni possono coprire un solo tipo di oggetto, un solo punto di ingresso del business e un insieme definito di liste ufficiali. Crea set di test con campioni storici autorizzati, registrando il recall delle corrispondenze reali, il numero di candidati irrilevanti, il tempo di revisione per caso, le omissioni negli input e la latenza degli aggiornamenti delle liste. Evita un'unica metrica aggregata di accuratezza che nasconda i costi diversi di falsi negativi e falsi positivi.

I test di accettazione dovrebbero selezionare casualmente un campione di casi chiusi per verificare che un secondo analista possa ricostruire le decisioni con gli stessi input, le stesse versioni delle liste e le stesse motivazioni. I team dovrebbero anche simulare un aggiornamento delle liste e un'interruzione del servizio per verificare che i risultati obsoleti non vengano riutilizzati in silenzio, che gli arretrati vengano conservati e che lo screening di recupero vada a buon fine dopo il ripristino.

Questo articolo tratta la trasformazione delle liste di sanzioni in prodotto e i relativi controlli di ingegneria, non costituisce consulenza legale o di compliance e non implica che [EveryInfra] abbia rilasciato un servizio di screening delle sanzioni. L'output più importante di un sistema di screening delle sanzioni non è un'etichetta “superato”, ma un processo decisionale ben delimitato che gestisce l'incertezza, consente la revisione da parte di personale autorizzato e resta ricostruibile anche a distanza di anni.