Lo stack tecnologico per la conformità

Nessuna attività legata alle criptovalute può gestire il proprio programma manualmente: i trasferimenti si regolano in pochi minuti, i clienti si registrano da remoto e le prove si trovano su registri pubblici e nei sistemi dei partner. Lo stack tecnologico è quindi il quadro dei controlli nella pratica e le sue debolezze diventano carenze di conformità. Questa lezione illustra i componenti, come sceglierli e integrarli senza favorire alcun fornitore e come mantenere sotto controllo i relativi dati e modelli.

I componenti fondamentali

Uno stack tipico ha sei componenti. Alcune imprese ne acquistano ciascuno, altre combinano strumenti acquistati e soluzioni sviluppate internamente.

Le regole di monitoraggio delle transazioni vengono generalmente eseguite sulla piattaforma dati o all'interno dello strumento di analisi o di gestione dei casi; ovunque vengano eseguite, dipendono dagli stessi dati. Il rapporto della FATF Opportunities and Challenges of New Technologies for AML/CFT (luglio 2021) e la sua Guidance on Digital Identity (marzo 2020) descrivono i vantaggi e le condizioni necessarie: governance, spiegabilità e supervisione umana.

Sviluppare, acquistare o combinare

Poche imprese sviluppano tutto o acquistano tutto. La scelta dipende da alcune domande:

Un approccio comune consiste nell'acquistare la verifica dell'identità, i dati degli elenchi, l'attribuzione analitica e la connettività Travel Rule, e nello sviluppare la piattaforma dati, gli scenari di monitoraggio che si basano sui dati propri dell'impresa e la logica decisionale che combina tutti i segnali. Tutto ciò che viene sviluppato internamente richiede la stessa documentazione, gli stessi test e gli stessi controlli delle modifiche previsti per uno strumento di un fornitore.

Selezione degli strumenti

La selezione dovrebbe partire dalla valutazione del rischio e dal quadro dei controlli, non da una dimostrazione. Elenca i controlli che lo strumento deve eseguire, quindi assegna un punteggio ai candidati in base a criteri quali:

• copertura: le catene, i token e i bridge supportati o che si prevede di supportare; le fonti degli elenchi; i paesi e i tipi di documenti;
• accuratezza: tassi di falsi positivi e falsi negativi misurati sui dati propri;
• spiegabilità: se ogni punteggio o corrispondenza è accompagnato dalla motivazione e dalla fonte sottostante;
• latenza e disponibilità: tempi di risposta compatibili con i controlli pre-transazione e livelli di servizio;
• configurabilità: soglie, regole e flussi di lavoro modificabili nell'ambito dei propri controlli delle modifiche;
• tracciabilità di audit: cronologia completa di dati di input, versioni, decisioni e azioni degli utenti;
• sicurezza e protezione dei dati: rapporti di assurance indipendenti, certificazioni come ISO/IEC 27001, ubicazione dei dati, cifratura;
• uscita: esportazione di tutti i dati e della cronologia in un formato utilizzabile in caso di cessazione del rapporto.

Una prova di concetto basata sui propri dati costituisce la prova più solida. Fornisci a uno strumento di screening voci note degli elenchi con varianti ortografiche e verifica quali riesce a trovare. Sottoponi gli stessi 500 indirizzi a due fonti di analisi, includendo i tuoi depositi di prova, e misura i punti di disaccordo; i disaccordi sono comuni e indicano dove è necessaria una seconda fonte o una revisione manuale (per sapere perché l'attribuzione varia, consulta la lezione IDFE-BA Valutare la qualità dei cluster).

Due diligence sui fornitori e contratti

Uno strumento che esegue un controllo per conto dell'impresa costituisce un accordo con terze parti e si applicano le regole della lezione Creare la funzione di conformità: la responsabilità rimane all'impresa. La due diligence riguarda la proprietà e la solidità finanziaria del fornitore, la sua sicurezza e resilienza, il rispetto da parte sua delle norme in materia di sanzioni e protezione dei dati, i suoi subappaltatori e la provenienza dei dati. Per i dati di analisi e screening, chiedi come vengono reperite le etichette e le voci degli elenchi, con quale frequenza vengono aggiornate e come vengono corretti gli errori.

Il contratto dovrebbe prevedere diritti di audit e di accesso alle informazioni, livelli di servizio con rimedi, notifica delle modifiche sostanziali ai modelli o alle fonti dei dati, notifica delle violazioni, proprietà e restituzione dei dati e un piano di uscita collaudato. Anche la concentrazione è importante: se un'interruzione blocca contemporaneamente la registrazione dei clienti, lo screening e il monitoraggio, occorre predisporre una soluzione alternativa.

Integrazione e percorso decisionale

La posizione di un controllo nel processo determina se previene o si limita a rilevare un problema. Lo screening dei wallet e i controlli Travel Rule pre-transazione devono essere eseguiti prima che un prelievo venga firmato e trasmesso; una volta che un trasferimento è on-chain, non può essere revocato. Ogni controllo preventivo necessita di una modalità di errore definita: fail closed (bloccare la transazione quando lo strumento non è disponibile) per i controlli ad alto rischio, oppure fail open, con revisione successiva, solo quando la valutazione del rischio lo consente. Altre regole di integrazione: un unico identificativo cliente condiviso da ogni sistema, orologi sincronizzati in UTC e nuovi tentativi che non generino mai avvisi o messaggi duplicati. Le modifiche allo stack, da una nuova catena all'aggiornamento di un modello del fornitore, devono essere sottoposte a test in un ambiente non di produzione e all'approvazione della funzione di conformità prima del rilascio, perché un'integrazione interrotta può disattivare un controllo senza che nessuno se ne accorga.

Ogni decisione automatizzata dovrebbe lasciare una registrazione che si spieghi da sé:

{
  "event": "withdrawal_decision",
  "withdrawal_id": "WD-2026-0918-00417",
  "customer_id": "C-88213",
  "asset": "USDC", "amount": "12500.00", "destination": "0xA1b2…9F",
  "screening": { "list_match": false, "list_version": "2026-09-18T06:00Z" },
  "analytics": { "entity_type": "VASP", "risk_score": 22,
                 "source": "provider-1", "label_date": "2026-09-02" },
  "travel_rule": { "required": true, "protocol": "TRP",
                   "status": "ACCEPTED", "payload_hash": "e91c…40ab" },
  "decision": "RELEASE", "rule_set": "WD-POLICY v4.2",
  "decided_at": "2026-09-18T10:42:07Z"
}

La registrazione conserva i dati di input e le relative versioni, non solo l'esito: quale versione dell'elenco è stata usata per lo screening, quale fonte di analisi ha classificato la destinazione e quando, se il messaggio Travel Rule è stato accettato e quale insieme di regole ha determinato la decisione. In questo modo, un investigatore o un esaminatore può ricostruire mesi dopo perché il trasferimento è stato autorizzato, anche se gli elenchi, le etichette e le regole sono cambiati. L'hash dimostra quale messaggio è stato inviato senza copiare dati personali in ogni registro.

Piattaforma dati e tracciabilità della provenienza

Il monitoraggio, le informazioni gestionali e le segnalazioni alle autorità sono affidabili solo quanto i dati su cui si basano. La tracciabilità della provenienza dei dati documenta da dove proviene ogni dato e ogni trasformazione effettuata lungo il percorso. I Principles for effective risk data aggregation and risk reporting del Comitato di Basilea (BCBS 239, gennaio 2013), redatti per le grandi banche, stabiliscono aspettative adeguate a qualsiasi piattaforma dati per la conformità: accuratezza, completezza, tempestività e adattabilità, nell'ambito di una governance chiara.

I controlli pratici comprendono:

• riconciliazioni di completezza, per esempio il confronto giornaliero tra il numero di prelievi nel registro, il numero sottoposto a screening e il numero monitorato;
• monitoraggio dei flussi di dati, con avvisi quando una fonte si interrompe o il suo volume diminuisce bruscamente;
• un dizionario dei dati e responsabili per ogni campo critico;
• accesso basato sui ruoli, registrazione di chi ha visualizzato o modificato i dati e conservazione per almeno cinque anni;
• archiviazione a prova di manomissione per decisioni e prove.

Uno scenario di monitoraggio che per tre mesi non ha rilevato in modo silenzioso una nuova catena è un rilievo tipico; la riconciliazione è il controllo che avrebbe permesso di individuarlo.

Rischio dei modelli

Molti componenti dello stack sono modelli: algoritmi di corrispondenza approssimativa, punteggi di rischio dei clienti, punteggi di rischio analitici e classificazione degli avvisi mediante apprendimento automatico. Ognuno può essere errato, diventare obsoleto o essere utilizzato in modo improprio. Mantieni un inventario dei modelli con responsabile, finalità, dati di input, versione e data dell'ultima convalida; convalidali prima dell'uso e periodicamente; e controlla ogni modifica. Quando un investigatore non concorda con un'etichetta o un punteggio del fornitore, la deroga dovrebbe essere registrata con la relativa motivazione e le prove, segnalata al fornitore e conteggiata: un tasso di deroghe in aumento è un primo segnale che un modello non è più adatto alla tua attività. I modelli dei fornitori restano modelli di cui sei responsabile: devi disporre di documentazione e risultati dei test sufficienti per spiegare i loro risultati a un'autorità di vigilanza. Quadri come il NIST AI Risk Management Framework (AI RMF 1.0, gennaio 2023) e la norma ISO/IEC 42001:2023 sui sistemi di gestione dell'IA aiutano a strutturare la governance. I metodi di calibrazione e convalida sono trattati nella lezione Calibrazione, metriche e governance dei modelli.

Focus sull'esame: i sei componenti dello stack e la carenza tipica di ciascuno; i criteri di selezione (copertura, accuratezza, spiegabilità, latenza, configurabilità, tracciabilità di audit, sicurezza, uscita) e la verifica con una prova di concetto sui propri dati; la due diligence sui fornitori e le condizioni contrattuali, con la responsabilità che rimane all'impresa; perché i controlli pre-transazione devono essere eseguiti prima della trasmissione e la differenza tra fail closed e fail open; i contenuti di una registrazione decisionale che si spiega da sé; la tracciabilità della provenienza dei dati, le riconciliazioni di completezza e i principi BCBS 239; l'inventario e la convalida dei modelli, compresi quelli dei fornitori.