Vai al contenuto principale
Uno scambio Travel Rule raggiunge la VASP controparte su un solo canale. Tre canali non richiedono l’adesione di nessuno: INTERNAL tra due clienti Didit, il Travel Rule Protocol aperto (TRP) e EMAIL. I quattro canali di rete (GTR, TRUST, VERIFYVASP, SYGNA) richiedono un’adesione a quella rete dal lato del mittente. Questa pagina descrive cosa fa oggi ciascun canale, così sai dove le tue controparti sono raggiungibili prima di fare affidamento su un percorso.
Didit non dispone ancora di un’adesione attiva a nessuna rete Travel Rule. Un canale di rete funziona oggi solo con un’adesione che colleghi tu stesso nel Marketplace della console. Nessuno scambio raggiunge una controparte su GTR, TRUST, VerifyVASP o Sygna Bridge tramite l’adesione di Didit, e questa pagina cambierà il giorno in cui ciò accadrà.

Stato in breve

“Funziona” significa che Didit invia lo scambio e legge la risposta. “Implementato, non ancora verificato in produzione” significa che Didit invia lo scambio e legge la risposta della rete, ma nessuno scambio su quella rete si è ancora completato con una rete in produzione. Nessuna delle due indicazioni significa che una data controparte è raggiungibile: questo dipende dalla controparte, e i routes di ciascuna VASP nella directory indicano quali canali la tua applicazione può usare per essa oggi. EMAIL trasporta solo le tue richieste in uscita: la pagina di risposta è il punto in cui una controparte risponde a una di esse, e nessuna VASP può inviarti un trasferimento via email. Prima di fare affidamento su GTR, VerifyVASP, Sygna Bridge o TRUST, collega la tua adesione ed esegui un primo scambio con una controparte che conosci.

Canali che non richiedono adesione

INTERNAL

Entrambe le VASP operano su Didit, quindi lo scambio si regola all’interno della piattaforma senza alcuna chiamata in uscita. Il destinatario deve essere un cliente Didit attivo con Travel Rule abilitato, che ha dimostrato il controllo del wallet di destinazione con un messaggio firmato o un deposito di prova. Un wallet solo dichiarato, dimostrato esclusivamente tramite una schermata o non verificato, non riceve nulla. Vedi Invio di un trasferimento.

TRP

Didit supporta nativamente il Travel Rule Protocol. Un trasferimento passa su TRP quando contiene il Travel Address della controparte, quando la voce della rubrica del wallet di destinazione ne memorizza uno, oppure quando la controparte si risolve nella directory con un endpoint TRP che la directory ha verificato. Ogni scambio TRP che non si conclude in una singola chiamata richiede l’host TRP pubblico di Didit, quello a cui puntano i Travel Address:
  • Invio. Una controparte che risponde subito alla tua richiesta, nella sua risposta, completa o rifiuta il trasferimento. Una controparte che risponde più tardi pubblica la sua risposta sull’host TRP di Didit, quindi quello scambio non può completarsi finché l’host non è attivo: il trasferimento resta in attesa e scade alla scadenza prevista. Didit invia la richiesta una sola volta e non la ripete. Quando l’host TRP della controparte non è raggiungibile o rifiuta la richiesta, il trasferimento diventa immediatamente COUNTERPARTY_VASP_NOT_REACHABLE e puoi riprovarlo con action: "resend".
  • Ricezione. Le altre VASP ti raggiungono al tuo Travel Address su quell’host, quindi nessuna controparte può inviarti una richiesta TRP finché l’host non sarà attivo.
L’host TRP pubblico di Didit non espone ancora questi endpoint. Interoperabilità Travel Rule documenta gli endpoint che le controparti chiameranno quando l’host sarà attivo.

EMAIL

Quando nessun protocollo raggiunge la controparte, Didit invia ai suoi indirizzi di compliance un link monouso a una pagina ospitata, dove accettano o rifiutano. Non serve alcun account né alcuna integrazione dalla loro parte. Vedi Ritiro via email.

Infrastrutture di rete

Con una propria affiliazione

Collega la tua affiliazione nel Marketplace della console (categoria Travel Rule networks). I tuoi trasferimenti viaggeranno poi con la tua identità di rete, e un’affiliazione collegata ha sempre la precedenza su quella di Didit. GTR, TRUST e VerifyVASP accettano anche, in modo facoltativo, un certificato client per mutual TLS, la relativa chiave client e un bundle CA (PEM), per un’affiliazione che usa mutual TLS o una CA privata.
  • Didit invia in background e riprova con una rete che non risponde, o che risponde con un errore temporaneo (nessuna risposta in tempo, connessione non riuscita, HTTP 408, 429 o 5xx): dopo 30 secondi, poi dopo 2, 10, 30 e 60 minuti. Dopo il sesto tentativo fallito il trasferimento passa a COUNTERPARTY_VASP_NOT_REACHABLE. Un rifiuto, come un’altra risposta 4xx o un reindirizzamento, non viene ritentato: il trasferimento passa subito a COUNTERPARTY_VASP_NOT_REACHABLE.
  • Un trasferimento la cui risposta non arriva mai resta in AWAITING_COUNTERPARTY finché non trascorrono confirmation_timeout_hours, poi scade e applica il tuo timeout_outcome.
  • La ricezione di un trasferimento che un altro VASP ti invia tramite GTR, VerifyVASP o Sygna Bridge non è ancora attiva: Didit la attiva rete per rete, e fino ad allora queste reti non possono consegnarti un trasferimento.
  • Il salvataggio di un’affiliazione restituisce 400 quando il suo codice partecipante è il codice di Didit su quella rete, oppure un codice già in uso da un’altra applicazione.
  • Le richieste di rete trasmettono le tue credenziali solo all’host di quella rete e non seguono mai un reindirizzamento. Il pacchetto dati TRUST va al beneficiario senza la tua chiave API, il tuo ID membro o il tuo certificato client.

Tramite l’affiliazione di Didit

Una volta che Didit detiene un’affiliazione a una rete, un cliente che non ne ha una può raggiungere la rete come proprio partecipante tramite l’affiliazione di Didit, con il codice partecipante che la rete gli assegna: i messaggi in uscita indicano il tuo codice, mai quello di Didit. Questa modalità è offerta solo per GTR e Sygna Bridge. TRUST ammette i membri un VASP alla volta e un Enclave VerifyVASP serve un solo VASP, quindi per entrambe si accede solo con una propria affiliazione. L’adesione richiede tre passaggi: rispondere al questionario di due diligence di Didit sulla rete, far approvare il questionario da Didit, quindi richiedere l’accesso alla rete. Didit ti registra presso la rete, e il tuo partecipante diventa attivo una volta che la rete gli assegna un codice. Questo flusso non è ancora aperto. Finché non lo sarà, il salvataggio o l’invio del questionario e la richiesta di accesso a una rete restituiscono 403 con code: travel_rule_platform_networks_disabled, e GET /v3/travel-rule/networks/ riporta platform_networks_enabled: false.

Lettura dello stato della tua applicazione

GET /v3/travel-rule/settings/ e GET /v3/travel-rule/networks/ restituiscono networks, indicizzato per gtr, trust, verifyvasp e sygna. Ogni voce indica cosa la rete può fare oggi per la tua applicazione: mode riassume lo stato come own, didit, off o unavailable. Viene verificata per prima la tua adesione, poi disabled_networks, quindi l’adesione di Didit. Oggi una rete risulta own_membership una volta collegata la tua adesione. Altrimenti GTR e Sygna Bridge risultano didit_onboarding (unavailable con sandbox_application su un’applicazione sandbox), mentre TRUST e VerifyVASP risultano unavailable con own_membership_only, anche in sandbox. Un’applicazione sandbox non invia mai su una rete, nemmeno con la tua adesione collegata e in stato own_membership: i suoi trasferimenti vanno al Didit Test VASP. connected significa che la tua adesione salvata ha superato la validazione locale, non che uno scambio sia andato a buon fine. Il primo scambio in produzione lo verifica presso la rete.

Cosa cambia quando una rete va in produzione

Questa pagina, lo stato networks e tutti i percorsi della directory cambiano insieme. Nella tua integrazione non cambia nulla: un trasferimento inizia a passare dalla rete non appena la tua applicazione ha un’adesione su di essa, secondo l’ordine dei canali descritto in Come Didit instrada uno scambio. Per richiedere una rete che Didit non raggiunge ancora, usa il riquadro Richiedi accesso nel Marketplace. Ogni richiesta mostra il proprio stato (Aperta, Contattata, In corso, Attiva o Rifiutata) con l’ultima nota di Didit. Quando Didit cambia lo stato o la nota, invia un’email al membro del team che ha fatto la richiesta, finché fa ancora parte della tua organizzazione. Una richiesta fatta con una chiave API non genera alcuna email, quindi segui l’avanzamento nel Marketplace.

Prossimi passi

Travel Rule

Il ciclo di vita dello scambio, le impostazioni, i canali e l’API /v3/.

Test in sandbox

Testa ogni esito con il Didit Test VASP prima di andare in produzione.

Interoperabilità

Gli endpoint che i VASP delle controparti usano per raggiungerti.

Directory

Trova un VASP e i percorsi che la tua applicazione può usare per raggiungerlo.
Ultima modifica il 7 novembre 2026