Collaborare con i fornitori di servizi

Il tracciamento on-chain di solito termina presso un servizio: un exchange, un custode, un emittente di stablecoin, un elaboratore di pagamenti. Da lì, le prove che identificano le persone e mostrano dove è andato il valore si trovano nei sistemi del fornitore stesso. Per ottenerle è necessario rivolgersi al fornitore giusto, al momento giusto, chiedendo esattamente i documenti necessari, e poi leggere la risposta con lo stesso scetticismo riservato a qualsiasi altra fonte.

Quali dati possono detenere i fornitori

Fornitori diversi vedono parti diverse di una transazione. Sapere chi detiene cosa permette di evitare richieste inutili e fonti trascurate.

La soglia legale di solito cresce con la sensibilità dei dati: i dati degli abbonati sono più facili da ottenere dei dati sul traffico, che a loro volta sono più facili da ottenere dei contenuti. La lezione Autorizzazione legale e cooperazione internazionale tratta gli strumenti disponibili.

Prima la conservazione

I fornitori conservano i registri per periodi limitati e alcuni eliminano quelli degli account chiusi. Una richiesta di conservazione chiede al fornitore di congelare una copia di specifici documenti fino all'arrivo di un ordine di produzione. È economica, rapida e spesso l'unico modo per impedire che i dati scompaiano mentre si prepara la richiesta formale.

Inviare la richiesta di conservazione non appena viene identificato un account, senza aspettare che l'ordine di produzione sia pronto. Chiedere al fornitore di confermare per iscritto cosa è stato conservato e fino a quando, e annotare la data di scadenza. Se occorre anche bloccare i fondi, oltre a conservare i documenti, inviare una richiesta volontaria di congelamento separata, citando le prove che i fondi sono proventi di reato; i fornitori decidono se congelarli in base ai propri termini di servizio e obblighi legali.

Redigere una richiesta precisa

I fornitori eseguono ricerche nei propri sistemi utilizzando identificativi. Le richieste vaghe causano ritardi, risposte parziali o rifiuti. Una buona richiesta ha tre componenti.

• Identificativi: ogni indirizzo con la relativa blockchain e asset, ogni txid con timestamp e importo, ID degli account, indirizzi email o nomi utente, se noti.
• Periodo: inizio e fine in UTC, sufficientemente ampio da includere l'apertura dell'account e le attività successive.
• Campi: i documenti specifici richiesti, anziché «tutte le informazioni».

RICHIESTA DI CONSERVAZIONE  rif. CF-2026-0147/P-01  inviata 2026-03-04 11:02 UTC
A: Exchange K, team di risposta alle forze dell'ordine
Base giuridica: [ordine o potere, con riferimento]   Riservatezza richiesta: sì
Identificativi:
  - Indirizzo di deposito TQx7…4mPa (rete Tron, USDT TRC-20)
  - Txid in entrata 7b2f…d9e0, 2026-03-04 07:13:52 UTC, 9,800.00 USDT
Periodo: dal 2026-02-01 00:00 UTC alla data della risposta
Conservare, per ogni account collegato a questi identificativi:
  - Documento e dati KYC; registrazione e registri degli accessi IP con porte
  - Identificativi di dispositivi e sessioni; conti bancari e carte collegati
  - Libro mastro interno: depositi, operazioni, trasferimenti interni, prelievi
  - Indirizzi di prelievo e txid; dati Travel Rule inviati o ricevuti
  - Comunicazioni con il titolare dell'account
Contatto: [nome, ruolo, telefono ed email ufficiali]

La richiesta indica la rete oltre all'indirizzo, perché lo stesso formato di indirizzo può esistere su più blockchain, e include il txid in entrata affinché il fornitore possa individuare l'account anche se l'indirizzo è stato riassegnato. Richiede i registri IP con le porte di origine, di cui il fornitore Internet potrebbe aver bisogno per gli indirizzi condivisi. Richiede tutti gli account collegati, poiché spesso una stessa persona ne detiene diversi. Indica esplicitamente la richiesta di riservatezza e fornisce un contatto ufficiale, così che il fornitore possa verificare chi ha inoltrato la richiesta.

Tra gli errori comuni figurano indirizzi errati o troncati, orari locali senza fuso orario, nomi delle blockchain mancanti e richieste di «tutte le transazioni» che restituiscono un riepilogo invece del libro mastro interno.

Portali, verifica ed emergenze

Molti grandi fornitori gestiscono portali per le forze dell'ordine o caselle email dedicate e pubblicano le linee guida sui dati necessari. Utilizzare il canale indicato è più rapido che rivolgersi agli indirizzi di assistenza generale e crea una traccia verificabile. I fornitori verificano che la richiesta provenga da un'autorità autentica; i criminali si sono spacciati per agenti di polizia usando richieste di emergenza contraffatte, quindi è normale che vengano effettuati controlli. Inviare le richieste da account ufficiali.

La maggior parte dei fornitori ha una procedura di divulgazione di emergenza per i rischi imminenti per la vita o i danni gravi, e il Secondo Protocollo addizionale introduce ordini diretti per i dati degli abbonati e un canale di emergenza tra gli Stati, nei casi in cui si applica. Nella maggior parte degli altri casi, prima di produrre i documenti è necessario un ordine o una richiesta formale.

Riservatezza e rischio di allertare il soggetto

Alcuni fornitori notificano ai clienti le richieste delle forze dell'ordine, a meno che ciò non sia vietato, e un account congelato segnala al titolare che è successo qualcosa. Chiedere la riservatezza in ogni richiesta, citare qualsiasi base giuridica a sostegno e chiedere al fornitore di comunicare se non è in grado di ottemperare. Pianificare i congelamenti e le richieste in modo che il soggetto non venga allertato prima del sequestro dei dispositivi o della conservazione di altri account. I fornitori hanno propri obblighi di non allertare i clienti in merito alle segnalazioni che presentano, trattati nella lezione IDFE-CC Obblighi di segnalazione delle transazioni sospette.

Esaminare criticamente la risposta

I dati restituiti da un fornitore sono una fonte da verificare, non una conclusione.

• Autenticarli. Registrare come sono arrivati, calcolare l'hash di ogni file al momento della ricezione e conservare ogni certificato o dichiarazione del responsabile della custodia dei documenti del fornitore. La lezione Account di exchange e cloud come prove tratta l'autenticazione in modo approfondito.
• Verificare i fusi orari e le unità. Le esportazioni mescolano ora locale e UTC e gli importi possono essere arrotondati o riportati al netto delle commissioni.
• Verificare la completezza. Confrontare il numero di righe e gli intervalli di date con quanto richiesto; annotare cosa manca e chiedere chiarimenti.
• Considerare l'identità come un'affermazione. I dati KYC possono appartenere a un prestanome, a una persona di cui è stata rubata l'identità o a un titolare di un account acquistato. Un indirizzo IP può appartenere a una VPN o a un nodo di uscita Tor.
• Riconciliare con la blockchain. Ogni deposito e prelievo on-chain riportato nella risposta dovrebbe corrispondere a una transazione effettiva.

-- Prelievi del fornitore senza trasferimenti on-chain corrispondenti
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount, w.completed_utc
FROM provider_withdrawals AS w
LEFT JOIN chain_transfers AS c
  ON  c.txid = w.txid
  AND c.to_address = w.to_address
  AND c.amount = w.amount
WHERE c.txid IS NULL;   -- le righe senza corrispondenza richiedono una spiegazione

La query associa i prelievi elencati dal fornitore ai trasferimenti decodificati dai dati del nodo dell'esaminatore, utilizzando txid, destinatario e importo. Le righe senza corrispondenza richiedono una spiegazione. Tra le ragioni comuni vi sono i trasferimenti interni a un altro cliente, che non hanno alcun txid, gli importi registrati al lordo della commissione di rete o un prelievo effettuato su una blockchain diversa da quella esaminata. Gli importi devono essere espressi nelle stesse unità su entrambi i lati; per poter effettuare il confronto, alcuni motori richiedono un tipo decimale esplicito o una piccola tolleranza. Una discrepanza senza spiegazione è di per sé un elemento emerso e dovrebbe essere sottoposta al fornitore.

Un esempio di risposta

Tre settimane dopo, Exchange K risponde all'ordine di produzione relativo al caso CF-2026-0147. L'esaminatore confronta la risposta con le domande indicate nella dichiarazione dell'ambito.

1. KYC. L'account è stato aperto otto giorni prima del primo pagamento della vittima da uno studente ventenne residente in un altro Paese. L'identità potrebbe essere autentica e comunque non appartenere alla persona che gestisce la truffa: il profilo è compatibile con quello di un prestanome reclutato. Registrato come «titolare registrato dell'account», non come «sospettato».
2. Registri IP. La registrazione è avvenuta da un indirizzo residenziale nel Paese del titolare; quasi tutti gli accessi successivi provengono da indirizzi compresi in un intervallo commerciale di hosting. Ciò suggerisce l'uso di una VPN o un operatore remoto e costituisce una nuova pista per una richiesta alla società di hosting.
3. Libro mastro. Gli 9.800 USDT sono stati congelati dopo la richiesta di conservazione, ma 31.200 USDT provenienti da pagamenti precedenti erano già usciti tramite quattro prelievi. Tre corrispondono a trasferimenti on-chain verso nuovi indirizzi; il quarto era un trasferimento interno a un altro account di Exchange K, invisibile on-chain.
4. Prossimi passaggi. Nel piano vengono inseriti una seconda richiesta per l'account destinatario, un nuovo tracciamento a partire dai tre indirizzi di prelievo e una richiesta al fornitore di hosting.

La risposta ha chiarito una questione e ne ha aperte altre tre. È normale, e il fascicolo del caso dovrebbe documentare ogni nuova pista e la relativa provenienza.

Focus sull'esame: quali documenti possono detenere exchange, custodi, emittenti di stablecoin, fornitori di hosting, operatori di telecomunicazioni e altri fornitori, e quali sono i loro limiti; dare la precedenza alla conservazione e confermarne la scadenza; inviare richieste volontarie di congelamento separate; i tre componenti di una richiesta precisa (identificativi con blockchain e timestamp, periodo in UTC, campi specifici); portali per le forze dell'ordine, verifica del richiedente e procedure di emergenza; richiedere la riservatezza ed evitare di allertare il soggetto; autenticare i dati restituiti, verificare i fusi orari e la completezza, considerare i dati KYC e IP come affermazioni; riconciliare i documenti del fornitore con i dati on-chain; ricavare nuove piste da una risposta.