Financial Crime

screening delle sanzioni

Governare un agente di valutazione delle corrispondenze nello screening delle sanzioni

13 min · Updated 2026-06-02

Answer

Si governa un agente di valutazione delle corrispondenze in materia di sanzioni intercettando le sue tre azioni consequenziali: archiviare una corrispondenza come falso positivo, con conseguente rilascio di un pagamento sospeso o completamento dell'onboarding; confermare una corrispondenza effettiva, bloccando e congelando; oppure inoltrare una corrispondenza approssimativa ambigua. Un checkpoint di policy viene eseguito prima dell'azione e chiude il gate in caso di errore sul rilascio, non sul blocco. L'archiviazione è l'azione irreversibile soggetta a responsabilità oggettiva: un rilascio errato a una parte bloccata viola l'IEEPA indipendentemente dalla buona fede. Per questo ogni archiviazione resta sospesa per impostazione predefinita e viene inoltrata a un responsabile delle sanzioni nominato in un controllo maker-checker, mentre il percorso di blocco/congelamento rimane rapido. La forza vincolante deriva dal diritto in materia di sanzioni — 50 Percent Rule dell'OFAC, responsabilità oggettiva dell'IEEPA, congelamento dei beni ai sensi del Reg. (EU) 269/2014 e standard UN/FATF «freeze without delay» — mentre l'EU AI Act aggiunge disciplina di supervisione umana e di logging, senza una classificazione automatica ad alto rischio ai sensi dell'Allegato III.

KLA is the independent runtime governance and assurance layer forthis Process. KLA governs the agent you already built, whether it was built in-house or on a commercial agent framework: it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.

The Process

The job & where the agent takes high-stakes action

Un motore di screening di nomi e pagamenti confronta controparti, ordinanti e beneficiari — inclusi i dati FinCEN Travel-Rule per trasferimenti di $3,000 o più — con l'elenco OFAC SDN/consolidated e l'elenco consolidato delle sanzioni finanziarie EU; genera una corrispondenza quando un match esatto o approssimativo supera la soglia. Un analista delle sanzioni di norma valuta ogni corrispondenza: esamina il nome, i dati della parte e la voce dell'elenco, quindi ne decide l'esito. L'agente automatizza questo lavoro e compie tre azioni consequenziali: (1) archivia una corrispondenza come falso positivo, rilasciando un pagamento sospeso o completando un onboarding e mettendo fondi o servizi a disposizione della controparte; (2) conferma una corrispondenza effettiva, bloccando o rifiutando il pagamento e congelando fondi o conto; oppure (3) inoltra una corrispondenza approssimativa ambigua a un responsabile delle sanzioni nominato. L'asimmetria fra queste azioni è decisiva: l'archiviazione rende disponibili fondi, attività che il Reg. (EU) 269/2014 Art. 2(2) e lo standard UN/FATF sul congelamento dei beni vietano nei confronti di una parte designata, mentre il blocco conserva lo status quo. Un «no list hit» non equivale a un'archiviazione: la 50 Percent Rule dell'OFAC stabilisce che un'entità posseduta complessivamente al 50% o più, direttamente o indirettamente, da persone bloccate è a sua volta bloccata anche se non compare nell'elenco SDN; lo screening basato solo sul nome ha quindi un difetto strutturale di rilevazione.

Stakes

Why it's high-stakes

La responsabilità per le sanzioni è oggettiva, non basata sulla negligenza. Ai sensi dell'IEEPA (50 U.S.C. § 1705), una sanzione civile «può essere imposta a chiunque commetta un atto illecito» senza un requisito di conoscenza o intenzione; lo scienter («willfully») compare solo nella sottosezione penale. Se l'agente archivia una corrispondenza che era effettiva e il pagamento sospeso viene rilasciato a una parte bloccata, la violazione è completa indipendentemente dalla buona fede dell'agente o dalla plausibilità della sua motivazione. Il massimo legale adeguato all'inflazione è il maggiore tra $377,700 e il doppio del valore della transazione sottostante, per violazione; un file di pagamenti può contenere migliaia di transazioni. La disciplina EU è altrettanto categorica: il Reg. (EU) 269/2014 Art. 2 impone di congelare tutti i fondi e le risorse economiche controllati da persone designate e di non renderli disponibili, direttamente o indirettamente, a loro vantaggio. Anche l'errore opposto ha conseguenze: confermare erroneamente un falso positivo blocca un pagamento legittimo, congela un cliente legittimo e, su larga scala, genera de-risking ed esclusione finanziaria di intere nazionalità o regioni; è un danno di condotta vigilata e di equità, pur senza responsabilità oggettiva. Poiché lo screening delle sanzioni non è elencato nell'Allegato III dell'EU AI Act, l'istituzione non dispone di una filiera ad alto rischio con marcatura CE e valutazione di conformità che protegga queste decisioni; l'onere della governance ricade sui controlli propri del deployer in materia di sanzioni e rischio di modello.

What goes wrong

Failure modes specific to this agent

Archiviazione per «no SDN hit» quando la controparte è un'entità bloccata derivata (punto cieco della 50 Percent Rule)

L'agente valuta una corrispondenza — o una mancata corrispondenza nello screening — confrontando il nome della controparte con l'elenco SDN/consolidated pubblicato, non trova una voce esatta e archivia la corrispondenza, rilasciando il pagamento. Tuttavia, la 50 Percent Rule dell'OFAC rende bloccata anche un'entità posseduta complessivamente al 50% o più, direttamente o indirettamente, da una o più persone bloccate, pur se non è nominata nell'elenco SDN. L'agente ragiona sull'elenco che può confrontare e, per impostazione predefinita, non ricostruisce la catena della titolarità effettiva. Un pagamento a una società schermo posseduta al 60%, tramite due entità intermedie, da un oligarca designato risulta quindi come un «no hit» pulito e viene rilasciato: una violazione soggetta a responsabilità oggettiva.

Why it's hard to catch: La logica dell'agente è localmente corretta («nome non presente nell'elenco → nessuna corrispondenza»), quindi superano tutti i test unitari che verificano il confronto con l'elenco e la motivazione prodotta («controparte non presente nell'OFAC SDN o nell'elenco consolidato EU alla data di <version>») è vera e verificabile in audit. Il difetto è un'assenza — uno screening mai effettuato dall'agente — non una risposta errata. Emerge solo sovrapponendo i dati di titolarità, che le fixture di test, basate quasi sempre su un solo nome e un elenco, raramente includono. La precisione aggregata appare ottima proprio perché queste entità sono invisibili allo screening basato sui nomi.

Archiviazione eccessiva di match approssimativi che si traduce in de-risking di una coorte

Per ridurre l'elevatissimo tasso di falsi positivi dello screening dei nomi, l'agente viene configurato — o apprende — per archiviare in modo aggressivo i match approssimativi: varianti di traslitterazione, cognomi comuni, corrispondenze parziali della data di nascita. Considerata isolatamente, ogni archiviazione sembra ragionevole. Tuttavia, la stessa configurazione che archivia varianti benigne di nomi slavi o arabi aumenta anche il tasso di archiviazione delle corrispondenze effettive che usano quelle convenzioni di denominazione; l'errore speculare, la sovraconferma prudenziale, blocca e congela silenziosamente clienti legittimi concentrati in particolari nazionalità o corridoi. L'istituzione finisce per far passare corrispondenze effettive in una coorte o per escludere una coorte intera dalla banca tramite de-risking: due difetti di qualità della valutazione invisibili nella vista per singola corrispondenza.

Why it's hard to catch: La revisione per singola corrispondenza non rileva nulla: ogni archiviazione e ogni blocco sono difendibili sui rispettivi fatti. Il danno è una proprietà distributiva — un tasso differenziale di archiviazione/conferma fra coorti, per nazionalità, famiglia di traslitterazione o corridoio di pagamento — che emerge solo aggregando e confrontando gli esiti fra gruppi; il QA caso per caso e i test di accordo sulle etichette non lo mostrano. Poiché la metrica dominante, la riduzione dei falsi positivi, migliora quanto più l'agente archivia, sia il de-risking sia il rischio di far passare corrispondenze effettive appaiono come «guadagni di efficienza» nella dashboard.

Rilascio del pagamento mentre la corrispondenza è ancora in valutazione (violazione del requisito «without delay»)

L'agente, o l'orchestrazione circostante, tratta la valutazione come consultiva e lascia che il pagamento prosegua verso il regolamento, oppure rimuove la sospensione non appena formula un giudizio provvisorio di «probabile falso positivo», prima di una decisione umana o di policy definitiva. Lo standard UN/FATF applicato dagli Stati impone di congelare «without delay» e di garantire che nulla sia reso disponibile a beneficio di una parte designata; un pagamento regolato durante la valutazione vanifica il congelamento anche se l'agente in seguito conclude che si trattava di una corrispondenza effettiva. L'impostazione predefinita pericolosa è «lasciare fluire il pagamento salvo ordine di fermarlo», l'esatto contrario di quanto richiede il diritto in materia di sanzioni.

Why it's hard to catch: Dal punto di vista funzionale l'agente sembra operare correttamente: le corrispondenze vengono valutate, i pagamenti ricevono per lo più l'esito corretto e nei test il fattore temporale conta raramente, perché i pagamenti di prova non si muovono davvero. Il difetto è una proprietà di tempo e ordinamento — il rilascio avviene prima che la valutazione sia definitiva — che si manifesta solo con concorrenza e latenza di produzione e produce una traccia di audit apparentemente corretta: l'agente ha valutato la corrispondenza, ma dopo l'uscita del denaro. I test funzionali standard verificano la decisione, non che nessun valore si sia mosso mentre la decisione era in attesa.

Versione dell'elenco obsoleta: valutazione rispetto all'elenco consolidato di ieri

L'agente archivia o conferma una corrispondenza ragionando su una fotografia dell'elenco delle sanzioni apparentemente corretta ma non aggiornata: una designazione aggiunta quella mattina all'elenco consolidato EU o all'OFAC SDN non compare nella versione su cui l'agente ha eseguito il match; una parte appena designata viene così archiviata e il pagamento rilasciato. L'elenco consolidato EU «riflette i testi ufficialmente adottati pubblicati nella Gazzetta ufficiale» ed è aggiornato quando necessario; l'OFAC aggiorna continuamente l'elenco SDN. Valutare una corrispondenza rispetto a una versione obsoleta significa dare una risposta «corretta» rispetto al riferimento sbagliato.

Why it's hard to catch: L'agente produce una motivazione pulita che cita l'elenco («non presente nell'elenco consolidato») e l'unico elemento errato è la versione dell'elenco incorporata nello screening, che nessun controllo di qualità per decisione ispeziona. La motivazione è internamente coerente e l'elenco citato è reale, solo non aggiornato. Ripetere la decisione rispetto all'elenco corrente rileverebbe il problema, ma la maggior parte dei test usa una fixture congelata; l'obsolescenza viene quindi esclusa proprio nel punto in cui colpisce in produzione. La finestra di danno è stretta, fra una designazione e la successiva sincronizzazione dell'elenco, e facile da non rilevare nel campionamento.

How KLA governs it

Runtime controls, mapped to each decision point

KLA evaluates each consequential action with a policy gate that runs before the action executes: a Decision Request to POST /v1/decisions.evaluate: resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.

Decision point	Intercept (before action)	Policy checks → reason codes	Human routing (maker-checker)	Evidence captured
Archiviare una corrispondenza come falso positivo (rilascia un pagamento sospeso / completa un onboarding — rende disponibili fondi o servizi)	Un checkpoint KLA SDK avvolge la chiamata allo strumento clear_hit / release_payment dell'agente (Govern in Place). Il checkpoint invia un Decision Request tramite POST /v1/decisions.evaluate con la parte corrispondente, le voci candidate dell'elenco, il punteggio di match, gli esiti risolti della titolarità effettiva e la versione dell'elenco PRIMA che venga scritto il rilascio. I deployer che operano tramite il proxy gestito sottopongono lo stesso passaggio all'Executions API. È l'azione su cui il gate chiude in caso di errore: se la policy non può essere valutata, l'archiviazione non procede e il pagamento resta sospeso.	require_approval per ogni archiviazione di una corrispondenza sopra la fascia di punteggio configurata, oppure per qualsiasi match nell'elenco delle sanzioni quando la policy dell'istituzione prescrive il principio dei quattro occhi per i rilasci; l'agente non rilascia mai unilateralmente — reasonCode SANC_CLEAR_HUMAN_SIGNOFF block quando all'archiviazione non è allegata una risoluzione della titolarità effettiva / 50%-Rule: un'archiviazione per «no SDN hit» senza screening della titolarità non costituisce diligenza sufficiente — reasonCode SANC_CLEAR_NO_OWNERSHIP_RESOLUTION block quando la versione dell'elenco impressa sullo screening è precedente alla versione corrente pubblicata dell'elenco OFAC SDN / EU consolidato — reasonCode SANC_CLEAR_STALE_LIST_VERSION block quando l'archiviazione punta a un percorso di rilascio diverso dall'endpoint di regolamento approvato che conserva la sospensione, impedendo il «rilascio mentre è in attesa» — reasonCode SANC_RELEASE_PATH_UNAPPROVED warn, registrato senza sospensione, solo per archiviazioni dimostrabilmente a basso punteggio, con titolarità risolta e rispetto all'elenco corrente, così che l'avviso e il reason code raggiungano comunque il Lineage Record	Un esito require_approval apre un'escalation in Decision Desk, inoltrata dalla policy a un responsabile delle sanzioni nominato o a un revisore della conformità OFAC-EU (maker-checker: l'agente propone e il responsabile verifica). Il responsabile vede la parte corrispondente, le voci candidate e i punteggi dell'elenco, gli esiti di titolarità, la versione dell'elenco, l'archiviazione proposta e la relativa motivazione, i reason code attivanti e un link al Lineage Record; quindi approva o nega il rilascio, oppure lo inoltra a un MLRO o responsabile sanzioni senior. Il rilascio viene eseguito solo dopo l'approvazione.	Decision Request (action=clear_hit/release_payment + parte corrispondente + voci candidate dell'elenco + punteggio del match + esiti di titolarità + versione dell'elenco) esito della policy + reasonCodes + remediation ID dell'escalation, verdetto di approvazione/negazione e timestamp del responsabile delle sanzioni nominato hash del Release attivo che ha prodotto la valutazione artefatto della versione esatta dell'elenco delle sanzioni usata per lo screening Lineage Record a sola aggiunta con prova Merkle
Confermare una corrispondenza effettiva (blocca/rifiuta il pagamento e congela fondi o conto)	Un checkpoint KLA SDK avvolge la chiamata allo strumento confirm_match / freeze dell'agente. Il Decision Request a POST /v1/decisions.evaluate include la parte corrispondente, la voce dell'elenco, il punteggio e l'azione di congelamento proposta prima che blocco/congelamento vengano confermati. Poiché il congelamento è la direzione sicura in caso di errore ai sensi del diritto in materia di sanzioni, questo percorso può procedere rapidamente; resta comunque registrato e può essere invertito solo tramite revisione, rendendo il sovrablocco osservabile anziché silenzioso.	allow affinché il blocco/congelamento proceda senza sospensione, nella direzione sicura, ma registra SEMPRE la conferma con il relativo reason code affinché ogni congelamento sia attribuibile — reasonCode SANC_CONFIRM_FREEZE_RECORDED warn + reason code quando la conferma dipende da un match approssimativo a basso punteggio: il congelamento resta, ma il caso viene segnalato per una revisione umana tempestiva al fine di evitare de-risking ingiustificato — reasonCode SANC_CONFIRM_LOW_SCORE_REVIEW require_approval prima di ogni successiva inversione/sblocco di un conto già congelato: invertire un congelamento costituisce di per sé un rilascio e deve ereditare il gate maker-checker del percorso di archiviazione — reasonCode SANC_UNFREEZE_HUMAN_SIGNOFF	Una conferma/congelamento procede e non apre per impostazione predefinita un'escalation bloccante, ma una conferma a basso punteggio genera un elemento di revisione indirizzato dall'Assurance a un responsabile delle sanzioni nominato, così da correggere tempestivamente un congelamento ingiusto. Ogni sblocco viene inoltrato a un responsabile nominato come escalation di classe rilascio. I tassi di sovraconferma per coorte emergono come Assurance Alerts (vedere il controllo trasversale).	Decision Request (action=confirm_match/freeze + parte corrispondente + voce dell'elenco + punteggio) esito della policy + reasonCodes, inclusa ogni segnalazione di revisione per basso punteggio azione di congelamento e relativo endpoint di destinazione governato ogni successiva escalation di sblocco e il verdetto del responsabile nominato Lineage Record che collega screening -> decisione -> congelamento -> eventuale inversione, con prova Merkle
Inoltrare un match approssimativo ambiguo a un responsabile delle sanzioni	Un checkpoint KLA SDK avvolge la chiamata allo strumento escalate_hit dell'agente. Il Decision Request a POST /v1/decisions.evaluate include il punteggio di match, i dati mancanti o di bassa qualità — per esempio campi incompleti dell'ordinante o del beneficiario ai sensi della Travel Rule — e le voci candidate dell'elenco prima che l'escalation sia inoltrata. Quando non riesce a risolvere una corrispondenza, l'impostazione sicura dell'agente è inoltrarla, non archiviarla.	require_approval, con inoltro a un responsabile nominato, quando il punteggio di match rientra nella fascia ambigua configurata o sussiste ambiguità di traslitterazione o identificatore parziale — reasonCode SANC_FUZZY_AMBIGUOUS_ESCALATE require_approval quando mancano o sono di bassa qualità i dati obbligatori della Travel Rule — nome/indirizzo dell'ordinante, beneficiario e istituzione ricevente per trasferimenti di $3,000+ — poiché dati di pagamento incompleti generano strutturalmente match approssimativi non risolvibili e impongono l'escalation anziché l'archiviazione — reasonCode SANC_INSUFFICIENT_TRAVEL_RULE_DATA block per ogni tentativo di convertire direttamente un match ambiguo irrisolto in un'archiviazione senza la firma di un responsabile, chiudendo la scorciatoia «inoltrare e poi archiviare silenziosamente» — reasonCode SANC_AMBIGUOUS_AUTOCLEAR_BLOCKED	Un esito require_approval apre un'escalation in Decision Desk, indirizzata a un responsabile delle sanzioni nominato con l'intero pacchetto di contesto: punteggio, voci candidate, lacune nei dati e versione dell'elenco. Il responsabile archivia, conferma o richiede altri dati; esito e identità vengono registrati. La sospensione sul pagamento sottostante persiste per tutta la durata della valutazione («without delay» / gate chiuso in caso di errore sul rilascio).	Decision Request (action=escalate_hit + punteggio + indicatori di lacune nei dati + voci candidate + versione dell'elenco) esito require_approval + reason codes esito del responsabile nominato (clear/confirm/request-more) e timestamp prova che il pagamento sottostante è rimasto sospeso durante la valutazione Lineage Record sigillato
Controllo trasversale: rendere l'esecuzione riproducibile, monitorare il de-risking e mantenere le evidenze verificabili in modo indipendente	Ogni checkpoint precedente passa attraverso la stessa pipeline Evidence-by-Default: ogni Decision Request, decisione di policy, chiamata a strumento e verdetto umano viene acquisito automaticamente mentre avviene, senza un passaggio di logging separato nel codice dell'agente. Gli esiti di archiviazione/conferma alimentano inoltre il monitoraggio per coorti in Assurance Center.	impostazione predefinita chiusa in caso di errore, con direzione sicura definita per azione: un clear/release che non può essere valutato non procede e il pagamento resta sospeso; il congelamento è nella direzione fail-safe e procede con registrazione ogni esito diverso da allow deve riportare reasonCodes + remediation, applicati al lint della policy e al momento della pubblicazione Assurance Center monitora i tassi di archiviazione e conferma/congelamento in coorti definite — nazionalità, famiglia di traslitterazione, corridoio di pagamento e regione. Un tasso materialmente diverso fra coorti genera un Assurance Alert con il dettaglio della coorte, facendo emergere i pattern sia di corrispondenze effettive rilasciate sia di de-risking che la vista per singola corrispondenza nasconde	non applicabile al substrato delle evidenze; gli Assurance Alerts vengono inoltrati al team di controllo responsabile delle sanzioni/dei reati finanziari, con un link a Lineage Explorer per ispezionare le tracce alla base di una disparità.	logging automatico degli eventi per l'intera vita dell'agente, senza strumentazione manuale Lineage Record per valutazione, verificabile tramite GET /v1/lineage/{id}/verify con ricalcolo della radice Merkle, senza fiducia in KLA Assurance Alerts con tassi di archiviazione/conferma per coorte come evidenza continuativa di equità e de-risking Sealed Evidence Bundle esportabile e Control Pack per il programma sanzioni conservazione dei log generati automaticamente almeno per il minimo di sei mesi

Least-privilege execution & data boundaries

Archiviare una corrispondenza come falso positivo (rilascia un pagamento sospeso / completa un onboarding — rende disponibili fondi o servizi): clear_hit / release_payment è vincolato nel Release immutabile dell'agente al Tool Catalog; l'agente non può autoassegnarsi uno strumento di regolamento o di completamento dell'onboarding non incluso nel Release. Data Boundaries mantiene i dati relativi a parti sanzionate, pagamenti e titolarità nel sistema e nella regione approvati e fissa lo screening a un artefatto dell'elenco versionato e con timestamp, affinché il riferimento usato dall'agente sia quello governato.
Confermare una corrispondenza effettiva (blocca/rifiuta il pagamento e congela fondi o conto): confirm_match / freeze è vincolato solo all'endpoint governato di blocco del pagamento/congelamento del conto. L'agente non dispone di un binding verso un canale rivolto al cliente che possa rivelare la motivazione del congelamento, soggetta a riservatezza sanzionatoria, né verso uno strumento di sblocco unilaterale: gli sblocchi passano dal gate di rilascio.
Inoltrare un match approssimativo ambiguo a un responsabile delle sanzioni: escalate_hit è vincolato alla sola lettura e all'inoltro; non può né rilasciare né congelare. Il pacchetto di contesto viene assemblato nel Data Boundary affinché i dati della parte e del match candidato non transitino mai in un sistema non approvato.
Controllo trasversale: rendere l'esecuzione riproducibile, monitorare il de-risking e mantenere le evidenze verificabili in modo indipendente: l'agente opera in un unico Release immutabile; qualsiasi modifica a modello, istruzioni, parametri o binding degli strumenti produce un nuovo Release con hash. Diventa quindi verificabile quale configurazione fosse in esecuzione, rispetto a quale versione dell'elenco e alla data dell'archiviazione.

Mapped to regulation

Regulatory mapping

Framework	Article / section	Obligation (plain language)	How a KLA runtime control satisfies it	Source
US OFAC — 50 Percent Rule	Updated Guidance on Entities Owned by Persons Whose Property and Interests in Property Are Blocked (13 Aug 2014) e FAQ 401	Un'entità posseduta complessivamente al 50% o più, direttamente o indirettamente, da una o più persone bloccate è a sua volta bloccata anche se NON è nominata nell'elenco SDN; «indirettamente» copre la titolarità tramite entità intermedie possedute al 50%+. Uno screening basato sul solo nome che restituisce «no list hit» non dimostra quindi, da solo, che una controparte possa essere archiviata.	Il blocco sul percorso di archiviazione quando non è allegata una risoluzione della titolarità effettiva / 50%-Rule (runtime_controls[0], SANC_CLEAR_NO_OWNERSHIP_RESOLUTION) impedisce all'agente di rilasciare un pagamento sulla base di un «no SDN hit». L'archiviazione non può procedere finché non è allegato uno screening della titolarità e, sopra la fascia di punteggio, un responsabile delle sanzioni nominato non ratifica.	Source
US IEEPA — responsabilità civile oggettiva	50 U.S.C. § 1705(a)-(c); 31 CFR Part 501 App. A (massimo della sanzione civile)	Una sanzione civile «può essere imposta a chiunque commetta un atto illecito» senza un requisito di conoscenza o intenzione; lo scienter («willfully») compare solo nella sottosezione penale. Il massimo legale adeguato all'inflazione è il maggiore tra $377,700 e il doppio del valore della transazione sottostante, per violazione. Un rilascio errato a una parte bloccata costituisce una violazione completa indipendentemente dalla buona fede.	Poiché la responsabilità per un'archiviazione errata è oggettiva, il gate chiude in caso di errore sull'azione clear/release (runtime_controls[0], runtime_controls[3]): ogni archiviazione in ambito resta sospesa per impostazione predefinita e viene inoltrata a un responsabile nominato. Nessun valore viene quindi rilasciato a una parte potenzialmente bloccata sulla sola parola dell'agente. L'asimmetria è codificata nella direzione della policy: il rilascio si sospende, il congelamento procede.	Source
Misure restrittive EU — Reg. (EU) 269/2014	Art. 2(1)-(2) — congelamento dei beni e divieto di «mettere a disposizione»	Tutti i fondi e le risorse economiche di proprietà, detenuti o controllati da persone designate devono essere congelati e nessun fondo o risorsa economica può essere messo a loro disposizione, direttamente o indirettamente, o a loro vantaggio. «Controllati» e «indirettamente» rendono l'obbligo più ampio della corrispondenza letterale di un nome.	Il gate del percorso di archiviazione (runtime_controls[0]) tratta un'archiviazione come un atto di «messa a disposizione» e la mantiene sospesa fino alla risoluzione della titolarità e alla firma del responsabile. Il percorso di conferma/congelamento (runtime_controls[1]) esegue il blocco nella direzione fail-safe. Insieme impediscono all'agente di rendere disponibili fondi a una parte controllata o indirettamente posseduta, lasciando procedere i congelamenti effettivi.	Source
Misure restrittive EU — elenco consolidato (DG FISMA)	Elenco consolidato delle sanzioni EU (riflette i testi della Gazzetta ufficiale ed è aggiornato quando necessario)	L'elenco consolidato delle sanzioni finanziarie EU è il riferimento operativo per lo screening e riflette i testi ufficialmente adottati pubblicati nella Gazzetta ufficiale; viene aggiornato quando necessario. La valutazione deve essere eseguita rispetto alla versione corrente dell'elenco.	Il blocco per versione dell'elenco obsoleta (runtime_controls[0], SANC_CLEAR_STALE_LIST_VERSION) rifiuta un'archiviazione se lo screening è stato eseguito rispetto a un elenco precedente alla versione corrente pubblicata. Le evidenze fissano l'artefatto della versione esatta dell'elenco nel Lineage Record (runtime_controls[0], runtime_controls[3]).	Source
FATF R.6 (tramite lo standard UN Security Council di congelamento dei beni)	UN SC «Assets Freeze: Explanation of Terms» — «freeze without delay»	I fondi e i beni delle persone designate, compresi quelli posseduti o controllati direttamente o indirettamente, devono essere congelati «without delay» e nulla può essere reso disponibile a loro vantaggio. «Without delay» è un controllo temporale sul momento in cui il valore può muoversi.	L'impostazione fail-closed-on-release, il blocco del percorso di rilascio non approvato (runtime_controls[0], SANC_RELEASE_PATH_UNAPPROVED) e la sospensione che persiste durante l'escalation (runtime_controls[2]) assicurano che il pagamento rimanga congelato per tutta la valutazione: nessun valore si muove mentre una corrispondenza è in attesa, soddisfacendo lo standard «freeze without delay».	Source
FATF R.16 (via FinCEN Travel Rule)	31 CFR § 1010.410(e) — fondi soggetti alla «Travel Rule» ($3,000+)	Per trasferimenti di $3,000 o più, le informazioni sull'ordinante e sul beneficiario/istituzione ricevente devono accompagnare il pagamento ed essere conservate. Sono i dati rispetto ai quali l'agente valuta la corrispondenza; dati Travel Rule mancanti o di bassa qualità generano match approssimativi non risolvibili.	La regola di escalation per dati Travel Rule insufficienti (runtime_controls[2], SANC_INSUFFICIENT_TRAVEL_RULE_DATA) inoltra una corrispondenza con dati mancanti o di bassa qualità dell'ordinante/beneficiario a un responsabile nominato anziché consentire all'agente di archiviarla sulla base di un record di pagamento incompleto. Trasforma una lacuna strutturale nei dati in un'escalation, non in un'archiviazione silenziosa.	Source
EU AI Act — Regolamento (EU) 2024/1689	Allegato III (nota di classificazione: le sanzioni non sono enumerate)	L'Allegato III elenca gli ambiti ad alto rischio; lo screening delle sanzioni e la valutazione del congelamento dei beni non vi figurano. Un agente di valutazione delle corrispondenze in materia di sanzioni non è quindi automaticamente un sistema di IA ad alto rischio. Il regime dominante è il diritto sanzionatorio a responsabilità oggettiva; l'EU AI Act si applica come disciplina di supervisione e logging e quando il deployer rientra altrimenti nel suo ambito.	È una mappatura dell'ambito, non un controllo: chiarisce al deployer che qui il regime di conformità ad alto rischio non è l'obbligo portante. I controlli a runtime soddisfano anzitutto il diritto in materia di sanzioni e la relativa asimmetria, con gate chiuso sul rilascio, adottando volontariamente in aggiunta le disposizioni dell'EU AI Act sulla supervisione e sul logging.	Source
EU AI Act — Regolamento (EU) 2024/1689	Articolo 14(4)(b),(d),(e) — Supervisione umana	Le persone in vista devono rimanere consapevoli del bias di automazione, essere in grado di decidere di non utilizzare / ignorare / sovrascrivere / invertire l'output del sistema, e di essere in grado di intervenire o interrompere il sistema in uno stato sicuro.	Il pagamento richiesto_approvazione su un chiaro + Decision Desk override/re-route (runtime_controls[0], runtime_controls[2]) è l'analogo diretto disregard/override/reverse; i risultati del blocco (no-proprietà, stale-list, non approvato-release-path) sono Codici di ragione presentati al bias contro automazione ufficiale su un plausibile-ma-rong chiaro.	Source
EU AI Act — Regolamento (EU) 2024/1689	Articolo 12(1)-(2) — Registrazione (registrazione automatica)	I sistemi di IA ad alto rischio devono consentire tecnicamente il logging automatico degli eventi durante l'intero ciclo di vita del sistema, con un livello di tracciabilità appropriato allo scopo previsto.	Evidence-by-Default acquisisce automaticamente ogni Decision Request, decisione di policy, chiamata a strumento e verdetto umano (runtime_controls[3]) e li sigilla — inclusa la versione esatta dell'elenco rispetto al quale è stato eseguito lo screening — in un Lineage Record a sola aggiunta con prova Merkle. Soddisfa come proprietà incorporata il requisito di logging automatico e tracciabilità dell'Art. 12, anche quando questo vincola strettamente solo nell'ambito ad alto rischio.	Source
EU AI Act — Regolamento (EU) 2024/1689	Art. 26(6) — conservazione dei log	I deployer devono conservare, sotto il proprio controllo, i log generati automaticamente almeno per sei mesi, salvo che altre norme dell'Unione o nazionali impongano un periodo più lungo.	La pipeline Evidence-by-Default conserva i Lineage Record generati automaticamente ben oltre il minimo di sei mesi (runtime_controls[3]); sono esportabili come Sealed Evidence Bundle o Control Pack per il programma sanzioni. Le norme di registrazione su sanzioni e AML richiedono in genere una conservazione più lunga, supportata dallo stesso ledger.	Source

Prove the control held

Audit-evidence checklist

Per ogni clear/release: Decision Request, risoluzione allegata della titolarità effettiva / 50%-Rule, esito della policy + reasonCodes, verdetto di approvazione del responsabile delle sanzioni nominato e timestamp, tutti sigillati nel Lineage Record — prova che nessun valore è stato rilasciato sulla sola parola dell'agente (IEEPA; 50 Percent Rule dell'OFAC; Reg. (EU) 269/2014 Art. 2(2)).
L'artefatto esatto e datato della versione dell'elenco delle sanzioni usato per ogni screening, fissato nel Lineage Record: diventa provabile, senza ricostruzione, a quale versione dell'elenco OFAC SDN / EU consolidato si sia affidata l'archiviazione (elenco consolidato EU; blocco per versione obsoleta).
Per ogni confirm/freeze: Decision Request, punteggio del match, azione di congelamento e relativo endpoint di destinazione governato, nonché ogni segnalazione di revisione per basso punteggio — prova che il blocco è attribuibile e che i blocchi errati sono contrassegnati per revisione tempestiva (UN/FATF «freeze without delay»; controllo del de-risking).
Prova che il pagamento sottostante è rimasto sospeso per tutta la durata di ogni escalation/valutazione: nessun valore si è mosso mentre una corrispondenza era in attesa, il controllo temporale «without delay».
Ogni unfreeze/inversione acquisito come escalation di classe rilascio con l'approvazione del responsabile nominato, poiché invertire un congelamento è di per sé un atto di «messa a disposizione» e eredita il gate maker-checker del percorso di archiviazione.
Tassi per coorte di archiviazione e conferma/congelamento in Assurance Center — per nazionalità, famiglia di traslitterazione, corridoio di pagamento e regione — e ogni Assurance Alert sulle disparità: evidenza continuativa che l'archiviazione eccessiva, con corrispondenze effettive rilasciate, e il sovrablocco, con de-risking/esclusione finanziaria, sono monitorati attivamente.
Hash del Release attivo, inclusi modello, istruzioni, parametri e binding degli strumenti, apposto su ogni Lineage Record, per rispondere alla domanda su quale configurazione esatta abbia prodotto quella valutazione.
Verifica indipendente: ogni Lineage Record è verificabile tramite GET /v1/lineage/{id}/verify ricalcolando la radice Merkle rispetto alla radice ImmuDB pubblicata, senza fiducia in KLA; è esportabile come Sealed Evidence Bundle o Control Pack per il programma sanzioni, con log conservati oltre l'Art. 26(6) dell'EU AI Act.

A concrete intercept

Reference scenario: Un agente tenta di archiviare un pagamento «no SDN hit» a una società schermo — e un responsabile delle sanzioni nominato mantiene la sospensione

1
L'agente di valutazione delle corrispondenze esamina il pagamento PAY-55218, un trasferimento di $480,000 a «Meridian Trade Holdings Ltd», dopo che il motore di screening ha rilevato un match approssimativo a basso punteggio. Confronta il nome con gli elenchi OFAC SDN e EU consolidato, non trova una voce esatta e si prepara ad archiviare il match come falso positivo, rilasciando così il pagamento sospeso, con la motivazione «counterparty not present on OFAC SDN or EU consolidated list».
2
Prima che il rilascio venga scritto, il checkpoint KLA SDK che avvolge clear_hit / release_payment invia un Decision Request a POST /v1/decisions.evaluate con: match_score=0.61, list_version=OFAC-SDN-2026-06-01, beneficial_ownership_resolution=absent, release_path=settlement-prod.
3
La policy soddisfa due regole: SANC_CLEAR_NO_OWNERSHIP_RESOLUTION, poiché non è allegata alcuna risoluzione 50%-Rule / di titolarità, restituisce block; SANC_CLEAR_HUMAN_SIGNOFF, poiché sta per essere archiviato un match nell'elenco sanzioni, restituisce require_approval. Per precedenza vince l'unico block: l'archiviazione non procede, il pagamento resta sospeso e l'agente riceve un diniego strutturato con reason codes e remediation («attach beneficial-ownership resolution; route to sanctions officer»).
4
La policy inoltra un'escalation in Decision Desk al responsabile delle sanzioni nominato che presidia questo corridoio. Il responsabile vede la parte, le voci candidate dell'elenco, match_score, la risoluzione di titolarità assente, la versione dell'elenco, l'archiviazione proposta dall'agente con la relativa motivazione, entrambi i reason code e un link al Lineage Record.
5
Il responsabile ricostruisce la catena di titolarità e rileva che Meridian è posseduta al 60%, indirettamente tramite due intermediari, da una persona designata: un'entità bloccata derivata ai sensi della 50 Percent Rule dell'OFAC, che non compare mai nell'elenco SDN. Nega il rilascio e conferma il match; il congelamento procede. L'override dell'Art. 14(4)(d) e il controllo maker-checker vengono esercitati sull'unica azione soggetta a responsabilità oggettiva.
6
Ogni passaggio — Decision Request, esiti block + require_approval, reason codes, artefatto della versione dell'elenco fissato, identità e verdetto del responsabile e hash del Release attivo — è sigillato in un Lineage Record a sola aggiunta con prova Merkle, verificabile in seguito tramite GET /v1/lineage/{id}/verify ed esportabile in un Control Pack per il programma sanzioni, senza richiedere fiducia in KLA.

What most teams get wrong

The non-obvious insight

Per un agente di valutazione delle corrispondenze in materia di sanzioni, il gate di policy deve chiudere in caso di errore sull'azione CLEAR, cioè il rilascio, e non sul blocco: è l'inverso di come sono configurati la maggior parte dei gate di approvazione. I due errori non sono simmetrici. L'archiviazione di una corrispondenza effettiva rilascia valore a una parte bloccata e, ai sensi dell'IEEPA (50 U.S.C. § 1705), costituisce una violazione soggetta a responsabilità oggettiva senza difesa di buona fede; il massimo adeguato all'inflazione è il maggiore tra $377,700 e il doppio del valore della transazione, per violazione. Confermare erroneamente un falso positivo sospende invece un pagamento legittimo, danno recuperabile e senza responsabilità oggettiva. L'azione pericolosa e irreversibile è quindi il rilascio; un «no SDN hit» non basta neppure a giustificarlo, perché la 50 Percent Rule dell'OFAC rende bloccata un'entità posseduta al 50%+ da persone bloccate, direttamente o indirettamente, pur senza che compaia nell'elenco. Il gate mantiene pertanto sospesa per impostazione predefinita ogni archiviazione in ambito e lascia procedere rapidamente il congelamento.

Why it matters: Molti team progettano gate di approvazione che negano l'azione in caso di errore, scelta ragionevole quando l'azione stessa è rischiosa. Qui l'azione rischiosa è il rilascio; un progetto ingenuo che tratta la valutazione come consultiva e lascia proseguire il pagamento salvo ordine di fermarlo fallisce aperto proprio sull'azione soggetta a responsabilità oggettiva e vanifica lo standard «freeze without delay» lasciando muovere valore mentre una corrispondenza è in attesa. La stessa configurazione di archiviazione eccessiva che riduce i falsi positivi può inoltre escludere silenziosamente dalla banca intere nazionalità o corridoi sul lato speculare; è un danno di equità invisibile per singola corrispondenza, ma visibile nei tassi di archiviazione/conferma per coorte. La direzione fail-closed corretta — il rilascio si sospende, il congelamento procede, lo sblocco eredita il gate di rilascio — e il monitoraggio della distribuzione per coorte costituiscono il disegno del controllo.

Un'archiviazione errata in materia di sanzioni è particolarmente implacabile: ai sensi dell'IEEPA (50 U.S.C. § 1705), la responsabilità civile ricade su «any person who commits an unlawful act» senza un requisito di conoscenza o intenzione. Rilasciare un pagamento sospeso a una parte bloccata è quindi una violazione completa anche se l'agente ha agito in perfetta buona fede, esposta al massimo legale del maggiore tra $377,700 e il doppio del valore della transazione per violazione. Per questo l'azione di clear di un agente di valutazione, e non la sua azione block, deve restare fail-closed dietro un responsabile nominato. (source)

Q&A

Frequently asked questions

Un agente di valutazione delle corrispondenze nello screening delle sanzioni è un sistema di IA ad alto rischio ai sensi dell'EU AI Act?

Con ogni probabilità no, sulla base dell'Allegato III. Lo screening delle sanzioni e la valutazione del congelamento dei beni non sono elencati nell'Allegato III dell'EU AI Act, quindi l'agente non è automaticamente un sistema di IA ad alto rischio. Il regime dominante è il diritto sanzionatorio a responsabilità oggettiva: 50 Percent Rule dell'OFAC e IEEPA (50 U.S.C. § 1705), congelamento dei beni e divieto di «messa a disposizione» del Reg. (EU) 269/2014 e standard UN/FATF «freeze without delay». L'EU AI Act rimane utile come disciplina di supervisione umana e logging (Art. 12, 14, 26) e quando il deployer rientra altrimenti nel suo ambito. Verificate la classificazione rispetto al vostro deployment e chiedete consulenza: «non ad alto rischio ai sensi dell'Allegato III» non significa «governance leggera», perché la responsabilità sanzionatoria è oggettiva.

Perché il gate chiude in caso di errore su un'archiviazione ma lascia procedere un congelamento?

Perché i due errori non sono simmetrici. Archiviare una corrispondenza effettiva rilascia valore a una parte bloccata e costituisce, ai sensi dell'IEEPA, una violazione soggetta a responsabilità oggettiva, senza difesa di buona fede e con un massimo legale pari al maggiore tra $377,700 e il doppio del valore della transazione per violazione: un'azione irreversibile e costosa. Confermare erroneamente un falso positivo sospende soltanto un pagamento legittimo, effetto recuperabile. L'azione pericolosa è quindi il rilascio: ogni clear in ambito resta sospeso per impostazione predefinita ed è inoltrato a un responsabile delle sanzioni nominato (require_approval), mentre il congelamento procede nella direzione fail-safe ed è registrato. Uno sblocco eredita il gate del percorso di clear perché invertire un congelamento è di per sé un atto di «messa a disposizione».

Se la controparte non è nell'elenco SDN, perché l'agente non può semplicemente archiviarla?

Perché «no list hit» non equivale a «clear». La 50 Percent Rule dell'OFAC rende bloccata qualsiasi entità posseduta complessivamente al 50% o più, direttamente o indirettamente, da una o più persone bloccate, anche se non compare nell'elenco SDN; «indirettamente» include la titolarità attraverso entità intermedie possedute al 50%+. Lo screening basato sul solo nome non rileva strutturalmente queste entità bloccate derivate. Il gate di clear blocca quindi ogni archiviazione priva della risoluzione della titolarità effettiva / 50%-Rule (SANC_CLEAR_NO_OWNERSHIP_RESOLUTION): l'agente deve ricostruire la catena di titolarità e, sopra la fascia di punteggio, un responsabile nominato deve ratificarla prima che proceda il rilascio.

In che modo la governance impedisce all'agente di fare de-risking di intere nazionalità o corridoi?

La revisione per singola corrispondenza non può rilevare il de-risking: ogni clear e ogni block sembrano difendibili presi isolatamente. Il danno è distributivo; Assurance Center di KLA monitora quindi i tassi di clear e conferma/congelamento dell'agente nelle coorti definite, per nazionalità, famiglia di traslitterazione, corridoio di pagamento e regione. Se una coorte viene confermata/congelata o archiviata a un tasso materialmente diverso, la disparità diventa un Assurance Alert con il dettaglio della coorte e un link a Lineage Explorer. Il sovrablocco, esclusione finanziaria, e l'archiviazione eccessiva, corrispondenze effettive rilasciate, passano così dall'«efficienza» invisibile della dashboard a evidenza di equità stabile e verificabile; il flag di revisione delle conferme a basso punteggio intercetta tempestivamente i singoli congelamenti ingiusti.

Come si garantisce che un pagamento non venga regolato mentre una corrispondenza è ancora in valutazione?

L'impostazione fail-closed-on-release è il meccanismo: un clear/release che non può essere valutato integralmente non procede e il pagamento resta sospeso. Il block sul percorso di rilascio (SANC_RELEASE_PATH_UNAPPROVED) impedisce all'agente di instradare valore attraverso un percorso diverso dall'endpoint di regolamento approvato che conserva la sospensione; durante un'escalation, la sospensione persiste per l'intera valutazione. Ogni Lineage Record dimostra che il pagamento è rimasto sospeso: la forma operativa dello standard UN/FATF «freeze without delay», che un progetto ingenuo che lascia proseguire il pagamento salvo ordine di fermarlo vanificherebbe.

KLA costruisce, esegue o gestisce l'agente di screening delle sanzioni?

No. Il cliente costruisce e possiede l'agente di valutazione delle corrispondenze in materia di sanzioni — LangGraph, CrewAI, Agentforce, Microsoft Copilot o sviluppo interno — e possiede il programma sanzioni. KLA è il livello indipendente di governance e assurance a runtime che governa l'agente nel suo contesto: intercetta ogni azione consequenziale prima che venga eseguita, applica policy-as-code con i quattro esiti (allow / warn / require_approval / block) e una direzione fail-closed sul rilascio, inoltra clear e unfreeze ad alta criticità ad approvatori umani nominati in Decision Desk e sigilla un lineage di esecuzione firmato e mappato al diritto sanzionatorio. KLA non archivia mai una corrispondenza, non rilascia mai un pagamento e non decide: gli esseri umani mantengono il veto su require_approval.

Related blueprints & guides

Primary sources

Govern this Process without re-platforming the agent

KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.

Book a demo Read the governance guide