Wallet non custoditi e trasferimenti self-hosted

Un trasferimento da o verso un wallet self-hosted non coinvolge un secondo VASP che possa ricevere dati, eseguire controlli o rispondere a domande. L'unica parte obbligata nella transazione è il cliente della società, quindi tutto ciò che la Travel Rule normalmente ripartirebbe tra due provider ricade su uno solo. Le autorità di vigilanza si aspettano sempre più spesso che le società dimostrino di adottare un approccio deliberato e documentato a questi trasferimenti, anziché ignorarli o vietarli del tutto.

Perché i trasferimenti verso e da wallet self-hosted sono importanti

Un wallet non custodito (wallet self-hosted) è controllato dall'utente tramite le proprie chiavi, senza alcun fornitore di servizi intermediario. I trasferimenti tra questi wallet sono peer-to-peer (P2P) e restano fuori dal perimetro AML/CFT finché il valore non entra in contatto con un VASP o un istituto finanziario. È in quel punto di entrata o uscita che si applicano i controlli della società.

Il FATF ha più volte indicato i trasferimenti P2P tramite wallet non custoditi come un rischio prioritario nei suoi rapporti mirati e aggiornamenti annuali, osservando che nessun soggetto obbligato vede questi trasferimenti o li segnala.

La maggior parte dei trasferimenti self-hosted è legittima: i clienti spostano asset in cold storage, usano la DeFi o ricevono pagamenti da privati. Il compito è distinguere questi trasferimenti da quelli che spostano valore per conto di terzi o di soggetti illeciti.

Cosa si aspetta il FATF

Le persone che usano i propri wallet non sono soggetti obbligati, quindi non c'è nessuno a cui inviare un messaggio Travel Rule. Le linee guida del FATF sugli asset virtuali non vietano questi trasferimenti. Si aspettano invece che i VASP:

• ottengano dal proprio cliente le informazioni richieste sull'ordinante e sul beneficiario e le conservino;
• controllino i nomi rispetto agli elenchi delle sanzioni e applichino gli obblighi di congelamento e divieto previsti dalla R.16;
• utilizzino le informazioni per il monitoraggio delle transazioni e la segnalazione di operazioni sospette;
• applichino controlli basati sul rischio e proporzionati a esso, come un monitoraggio rafforzato, limiti o restrizioni ai trasferimenti verso indirizzi valutati dalla società.

I paesi possono aggiungere requisiti. Alcuni regimi, per esempio, richiedono alle società di verificare che il cliente possieda o controlli un indirizzo self-hosted oltre una determinata soglia, mentre altri lasciano il metodo alla valutazione del rischio della società. La lezione Come i regimi nazionali attuano lo standard mostra come mappare queste differenze.

Un approccio basato sul rischio

Una policy efficace assegna un punteggio a ciascun trasferimento self-hosted sulla base di alcuni fattori e definisce i controlli in funzione del risultato:

I controlli vengono quindi intensificati in base al rischio: registrare e monitorare; richiedere una prova di proprietà; chiedere i dati della terza parte e lo scopo del trasferimento; applicare un limite inferiore o sospendere l'operazione per una revisione; oppure rifiutare. La policy deve indicare chi può approvare le eccezioni e quali prove sono necessarie per ogni passaggio. L'esposizione rilevata dall'analisi è trattata in modo approfondito nella lezione Controlli su wallet e transazioni.

Dimostrare la proprietà dell'indirizzo

I metodi più efficaci dimostrano il controllo della chiave privata, non soltanto la conoscenza dell'indirizzo:

• Messaggio firmato. Il cliente firma, con la chiave associata all'indirizzo, un testo di verifica scelto dalla società che include un valore casuale e una data; la società verifica la firma. Esistono specifiche aperte per questo scopo: BIP-322 per Bitcoin, EIP-191 ed EIP-712 per gli account di tipo Ethereum ed EIP-1271 per i wallet di smart contract, che convalidano le firme tramite il proprio codice.
• Test satoshi. Il cliente invia alla società un piccolo importo, definito dalla società, dall'indirizzo. Dimostra il controllo dell'indirizzo in quel momento, al costo di una commissione e di un breve ritardo.
• Microtrasferimento inverso. La società invia un piccolo importo non tondo all'indirizzo e chiede al cliente di indicarlo. Questo dimostra solo che il cliente può visualizzare l'indirizzo, cosa che chiunque può fare su un block explorer, quindi è un metodo debole.
• Screenshot o dichiarazione. Uno screenshot di un'app wallet o una dichiarazione firmata sono facili da falsificare e non dimostrano nulla sul controllo della chiave. Vanno trattati solo come informazioni di supporto nei casi a basso rischio.

Ogni metodo dimostra il controllo in un dato momento. Le chiavi possono essere condivise, vendute o compromesse, quindi le verifiche della proprietà integrano il monitoraggio anziché sostituirlo. I wallet multisignature richiedono particolare attenzione: una firma può dimostrare che il cliente detiene una chiave, ma non che controlli il wallet.

Un indirizzo verificato dovrebbe essere accompagnato da una registrazione delle prove che un revisore possa controllare nuovamente:

{
  "customer_id": "C-20418",
  "address": "bc1q…4h8s",
  "chain": "bitcoin",
  "method": "signed_message_bip322",
  "challenge": "Alpha Exchange ownership check C-20418 2026-10-14 nonce 7f3e91",
  "signature": "AkcwRAIg…Qe1",
  "verified_at": "2026-10-14T09:42:17Z",
  "verified_by": "system",
  "result": "pass",
  "analytics_check": { "risk_category": "none_detected", "checked_at": "2026-10-14T09:42:20Z" },
  "review_due": "2027-10-14"
}

La registrazione conserva il testo esatto della verifica e la firma, così che il controllo possa essere ripetuto, insieme all'esito dell'analisi effettuata in quel momento e a una data per la revisione. Il nonce e la data inclusi nel testo di verifica impediscono al cliente di riutilizzare una firma creata per un'altra società o per un controllo precedente.

Quando raccogliere i dati dell'ordinante e del beneficiario

I dati provengono dal cliente della società; le informazioni da richiedere dipendono dalla direzione del trasferimento e da chi controlla l'altro wallet:

I trasferimenti in entrata da terze parti meritano attenzione, perché un cliente che riceve valore da molti wallet self-hosted non correlati potrebbe agire da prestanome per il riciclaggio di denaro o gestire un'attività non registrata. I dati raccolti dalla società sono affidabili solo quanto lo è la risposta del cliente, quindi vanno confrontati con quanto emerge dalla blockchain: un «wallet proprio» che riceve fondi da decine di sconosciuti non si comporta come tale.

Errori comuni

Le revisioni dei controlli sui wallet self-hosted rilevano spesso le stesse debolezze:

• Screenshot accettati come prova per trasferimenti di valore elevato o ad alto rischio, perché i metodi più efficaci sembravano scomodi.
• Verificare una volta e fidarsi per sempre. Un indirizzo verificato anni prima è ancora considerato verificato, benché il suo comportamento sia cambiato completamente.
• Nessun dato sulle terze parti. Il modulo di prelievo richiede solo un indirizzo, quindi la società non può dire chi ha ricevuto i fondi.
• Controlli scollegati dal monitoraggio. Gli esiti delle verifiche della proprietà e i rapporti dichiarati sono conservati in un sistema e non raggiungono mai le regole di monitoraggio che potrebbero utilizzarli.
• Trattamento incoerente. Team diversi applicano soglie o metodi diversi a trasferimenti simili e nessuno sa spiegare il motivo.

È facile verificare ciascuna di queste debolezze: selezionare un campione di indirizzi verificati, ripetere il controllo usando la registrazione delle prove e confrontare il rapporto dichiarato con l'andamento on-chain.

Caso svolto

Un cliente con una storia di due anni e un punteggio di rischio standard riceve ETH del valore di 9.500 USD da un indirizzo self-hosted mai visto prima. L'analisi non rileva esposizione illecita. Il cliente dichiara che si tratta del proprio wallet.

1. In base alla policy, un primo trasferimento da un nuovo indirizzo self-hosted che supera il livello interno di revisione comporta una verifica della proprietà.
2. La società invia un testo di verifica e il cliente restituisce una firma EIP-191 valida. L'indirizzo viene verificato e registrato.
3. I fondi vengono accreditati e l'indirizzo viene aggiunto all'elenco degli indirizzi verificati del cliente, con una data per la revisione.

Un mese dopo, lo stesso indirizzo invia cinque trasferimenti in una settimana e l'analisi mostra che riceve fondi da diversi wallet creati di recente e finanziati da un cluster di truffe noto. La precedente prova della proprietà non chiude la questione: l'analista apre un alert, chiede al cliente informazioni sull'origine dei fondi e valuta una segnalazione di operazione sospetta.

Focus sull'esame: perché i wallet non custoditi non possono ricevere messaggi Travel Rule e cosa si aspetta invece il FATF (raccogliere le informazioni dal proprio cliente, conservarle, effettuare controlli, monitorare e applicare controlli basati sul rischio); il fatto che il FATF non vieti questi trasferimenti; i fattori di rischio e i controlli graduati per i trasferimenti self-hosted; i quattro metodi per verificare la proprietà e quali dimostrano il controllo della chiave (messaggio firmato, test satoshi), quali la visibilità (microtrasferimento inverso) e quali non dimostrano nulla (screenshot); le avvertenze su EIP-1271 e wallet multisignature; la raccolta dei dati per trasferimenti tra wallet propri e di terze parti; il fatto che la prova della proprietà è una verifica valida in un dato momento e non sostituisce il monitoraggio.