> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Interoperabilità Travel Rule con un VASP di Didit > Come i VASP scambiano dati Travel Rule con i clienti Didit: travel address, endpoint TRP pubblici, callback, email e registrazione sunrise. Questa pagina è destinata all'**altro lato** di uno scambio [Didit Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md): il VASP controparte (o il suo team di ingegneria) che deve inviare dati Travel Rule a un VASP che opera su Didit, o riceverli da esso. Tutta l'infrastruttura documentata qui è pubblica e gestita da Didit. Per interoperare non serve un account Didit, una chiave API né alcun rapporto commerciale con Didit: l'integrazione più completa richiede solo HTTPS e JSON. ## Come Didit instrada un exchange Quando un cliente Didit invia un trasferimento, Didit prova questi canali in rigoroso ordine di priorità e usa il primo che riesce a raggiungerti: | Priorità | Canale | Cosa significa per te | | - | - | - | | 1 | `INTERNAL` | Entrambi i VASP operano su Didit - lo scambio viene regolato all'interno della piattaforma e non viene effettuata alcuna chiamata esterna. | | 2 | `TRP` | Esponi un endpoint Travel Rule Protocol (TRP), oppure il cliente Didit conosce il tuo [Travel Address](#travel-address). Didit chiama il tuo endpoint di richiesta TRP da macchina a macchina, per trasferimenti `BTC`, `ETH` e `USDC` (`USDC` quando il trasferimento indica la rete su cui viaggia). | | 3 | `GTR` | È attiva un'appartenenza Global Travel Rule (GTR) per il mittente e sei raggiungibile tramite un codice VASP GTR. Didit legge la tua risposta dalla risposta di GTR, oppure interrogando lo stato della richiesta. | | 4 | `TRUST` | È attiva un'appartenenza TRUST per il mittente e sei raggiungibile tramite un ID di appartenenza TRUST. Solo invio: vedi l'avviso qui sotto. | | 5 | `VERIFYVASP` | È attiva un'appartenenza VerifyVASP per il mittente e sei raggiungibile tramite un ID VerifyVASP. Didit legge la tua risposta interrogando lo stato della verifica. | | 6 | `SYGNA` | È attiva un'appartenenza Sygna Bridge per il mittente e sei raggiungibile tramite un codice VASP Sygna. Didit parla nativamente il protocollo Sygna (IVMS101 cifrato con ECIES, richieste di autorizzazione firmate) e legge la tua risposta di autorizzazione interrogando lo stato del trasferimento: il suo callback Sygna non è ancora attivo. | | 7 | `EMAIL` | Nessun canale di protocollo è disponibile - il tuo referente per la compliance riceve invece un [link di ritiro via email](#recupero-tramite-email) monouso. | > [!WARNING] > > **Didit non può ricevere una risposta `TRUST` e non accetta ancora trasferimenti inviati verso di sé tramite una rete.** > Su `TRUST`, il trasferimento di un cliente Didit ti raggiunge, ma la tua risposta non può tornare indietro, e il trasferimento scade alla scadenza di conferma del mittente invece di completarsi. > Su `GTR`, `VERIFYVASP` e `SYGNA`, Didit legge la tua risposta dalla rete stessa, dalla sua risposta o interrogando lo stato del trasferimento. La tabella sopra riguarda i trasferimenti che un cliente Didit invia. Quando invii un trasferimento a un cliente Didit, Didit può accettarlo solo come [richiesta di trasferimento](#post-/trp/inquiries//) `TRP`, una volta che l'host TRP pubblico di Didit sarà attivo (per ora non risponde, vedi [endpoint TRP](#endpoint-trp)), oppure, dopo il regolamento, come [registrazione sunrise](#sunrise-trasferimenti-regolati-prima-dello-scambio): oggi nessun canale di rete e nessun canale email consegna un trasferimento in entrata a un cliente Didit. I canali di rete (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) passano attraverso un'appartenenza dal lato del mittente. Oggi questa deve essere l'appartenenza connessa del cliente Didit: Didit non detiene ancora alcuna appartenenza di piattaforma in nessuna di queste reti e sta completando l'onboarding come provider. GTR non è incluso per impostazione predefinita, e lo stesso requisito di appartenenza vale per tutte e quattro le reti. Il mittente deve verificare l'oggetto `networks` in [Get Travel Rule Settings](https://docs.didit.me/it/management-api/travel-rule/get-settings.md): `didit` significa che l'appartenenza di Didit include quell'applicazione come partecipante proprio sulla rete, `own` significa un'appartenenza connessa del cliente, `off` significa che il routing di piattaforma è disabilitato, e `unavailable` significa che per ora nessuno può inviare su quella rete per l'applicazione. Finché Didit non detiene un'appartenenza di piattaforma, nessuna rete riporta `didit`. Attivare la Travel Rule non attiva un'appartenenza di rete. Vedi [reti Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule-networks.md) per sapere a cosa dà accesso oggi ciascuna rete. Se sei su una di queste reti e il cliente Didit ha una propria appartenenza lì, condividi il tuo identificativo di rete con lui: il trasferimento ti raggiunge tramite la rete che già gestisci. Su `SYGNA`, la tua risposta di autorizzazione determina il completamento o il rifiuto del trasferimento: Didit interroga lo stato del trasferimento ogni 5 minuti e registra anche `https://trp.didit.me/sygna/callbacks/permission/{token}/` come callback di ciascuna richiesta di autorizzazione, con un token emesso per quel trasferimento. Quel callback si trova sull'host TRP pubblico di Didit, che non gestisce ancora richieste. Uno `permission_status` di `ACCEPTED` porta il trasferimento del mittente a `COMPLETED`, e `REJECTED` lo porta a `COUNTERPARTY_VASP_GENERAL_DECLINE`, oppure a `COUNTERPARTY_MISMATCHED_DATA` quando `reject_code` è `BVRC007` (il nome del beneficiario non corrisponde). Il callback richiede la tua firma: senza una firma valida risponde `401` con `{"status": "INVALID_SIGNATURE"}`, `404` per un token sconosciuto e di nuovo `200` per una decisione già applicata. Senza appartenenze condivise, il percorso da pianificare è `TRP`: condividi il tuo Travel Address con il cliente Didit e i suoi trasferimenti raggiungono il tuo endpoint TRP. Una risposta fornita nella risposta alla richiesta completa o rifiuta subito il trasferimento; una risposta che invii dopo al callback di Didit richiede l'host TRP pubblico di Didit, che non è ancora attivo. Quando nessuno dei canali riesce a identificarti, Didit esegue un passaggio di risoluzione in più: **attribuzione tramite analisi blockchain**. Il wallet di destinazione viene risolto con i dati di analisi blockchain e, quando risulta attribuito al tuo servizio di exchange o di custodia, Didit registra il tuo nome nella propria directory VASP e riprova i canali con quel nome. Ciò significa che puoi essere identificato anche quando il mittente ha fornito solo un indirizzo. I trasferimenti attribuiti vengono instradati automaticamente verso di te solo quando la tua voce nella directory contiene un percorso: un endpoint `TRP` verificato, una presenza in una rete o un referente per la compliance (vedi [Come entrare nella directory VASP di Didit](#come-entrare-nella-directory-vasp-di-didit)). La catena di risoluzione completa è quindi: un cliente Didit che ha dimostrato il controllo del wallet (`INTERNAL`) e il Travel Address che il mittente ha memorizzato per esso, poi i canali di protocollo e di rete, poi l'analisi blockchain. ## Travel Address Ogni Didit VASP con Travel Rule attiva ha una **Travel Address**: una stringa compatta che inizia con `ta` e codifica l'URL del suo endpoint personale per le richieste di informazioni sui trasferimenti TRP. I clienti di Didit leggono la propria dalle impostazioni Travel Rule e la condividono con le controparti. Quando un cliente di Didit ti fornisce la sua, hai tutto ciò che serve per raggiungerlo tramite TRP. La codifica segue la convenzione TRP per le Travel Address: * Rimuovi il prefisso `ta`. * Decodifica la parte restante con Base58Check (alfabeto Bitcoin, checksum double-SHA256). * I byte decodificati sono l'URL della richiesta di informazioni senza lo schema; aggiungi `https://` all'inizio. * L'URL contiene sempre la coppia di query `t=i` (tipo: inquiry). Una Travel Address Didit decodificata ha una delle due forme: ``` https://trp.didit.me/trp/inquiries/{profile_uuid}/?t=i https://trp.didit.me/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/?t=i ``` `{profile_uuid}` identifica il profilo VASP ospitato: invia le tue richieste di informazioni sui trasferimenti a quell'URL e interroga prima il corrispondente [endpoint di identità](#get-/trp/identity//) per verificare con chi stai comunicando. La seconda forma è una **Travel Address per wallet**: identifica un singolo wallet del cliente Didit (`receiving_travel_address` nella sua rubrica degli indirizzi), quindi la tua richiesta raggiunge quel wallet senza che il cliente debba associarlo tramite numero di conto o nome del titolare. Restituisce `404` una volta che il wallet viene eliminato o risulta assegnato a un altro VASP. ## Endpoint TRP Didit usa la versione `3.2.1` del protocollo TRP all'URL di base `https://trp.didit.me`. Tutti gli endpoint scambiano JSON su HTTPS. > [!WARNING] > > L'host TRP pubblico di Didit non espone ancora questi endpoint. Finché non sarà attivo, una richiesta TRP di trasferimento o di identità indirizzata a un cliente Didit non può essere consegnata; questa sezione descrive il contratto in base al quale l'host risponderà una volta attivo. | Metodo | Percorso | Scopo | | - | - | - | | `GET` | `/identity` | Identità dell'operatore della piattaforma (servita anche su `/trp/identity`). | | `GET` | `/trp/identity/{profile_uuid}/` | Identità di un singolo profilo VASP ospitato. | | `POST` | `/trp/inquiries/{profile_uuid}/` | Invia una richiesta di trasferimento a un VASP ospitato. | | `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | Invia una richiesta di trasferimento per un wallet di un VASP ospitato (un Travel Address per wallet). | | `POST` | `/trp/callbacks/resolution/{token}/` | Risolve una richiesta che **Didit** ti ha inviato (approvazione o rifiuto). | | `POST` | `/trp/callbacks/confirmation/{token}/` | Conferma o annulla un trasferimento che Didit ha approvato per te. | Due intestazioni TRP sono importanti: * `api-version` - la versione del protocollo TRP che utilizzi, ad esempio `3.2.1`. Obbligatoria nelle richieste di trasferimento e in entrambi i callback. * `request-identifier` - il tuo id univoco per la richiesta, restituito nelle intestazioni della risposta. Obbligatorio nelle richieste di trasferimento e in entrambi i callback. Una richiesta agli endpoint di trasferimento o di callback senza entrambe le intestazioni restituisce `400`. Ogni risposta di Didit include `api-version: 3.2.1` e restituisce il tuo `request-identifier`. ### GET /identity Restituisce l'identità dell'operatore della piattaforma. Non sono richieste intestazioni. ```bash theme={null} curl https://trp.didit.me/identity ``` ```json theme={null} { "name": "Didit", "lei": "", "x509": "" } ``` ### GET /trp/identity/{profile_uuid}/ Restituisce l'identità del VASP specifico con cui stai per effettuare lo scambio: usala per verificare nome e LEI prima di inviare dati personali (PII). Didit esegue lo stesso controllo in senso inverso quando avvia lo scambio: se l'identità riportata dal tuo endpoint non corrisponde al LEI o al nome attesi, lo scambio viene interrotto. ```bash theme={null} curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/ ``` ```json theme={null} { "name": "Bene CASP GmbH", "lei": "5493001KJTIIGC8Y1R12", "x509": "" } ``` Restituisce `404` quando il profilo non esiste o quando la sua configurazione Travel Rule è disabilitata. ### POST /trp/inquiries/{profile_uuid}/ Invia una richiesta di trasferimento: tu sei il VASP ordinante, il cliente Didit è il VASP beneficiario. ```bash theme={null} curl -X POST https://trp.didit.me/trp/inquiries/11111111-2222-3333-4444-555555555555/ \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 7f6a1c1e-0a63-4b1f-9f6e-7dcd7c3f1a01" \ -d '{ "asset": { "dti": "X9J9K872S" }, "amount": 250000000000000000, "callback": "https://trp.yourvasp.example/callbacks/inquiry/abc123", "IVMS101": { "originator": { "originatorPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"] }, "beneficiary": { "beneficiaryPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"] } } }' ``` | Campo | Tipo | Descrizione | | - | - | - | | `asset.dti` | string | Obbligatorio. Il Digital Token Identifier (ISO 24165) dell'asset trasferito. Una richiesta senza questo campo restituisce `400`; il campo `asset.slip0044`, presente prima della 3.2.0, non viene letto. | | `amount` | number | Obbligatorio. Importo intero nell'unità più piccola dell'asset (unità base secondo i decimali del DTI). È accettata qualsiasi notazione JSON di un numero intero, inclusa la notazione esponenziale, e anche una stringa di cifre. Una frazione, oppure un importo troppo grande da registrare, restituisce `400`. | | `callback` | string | Obbligatorio. URL pubblico assoluto `http(s)` sul tuo lato a cui Didit invia la risoluzione della richiesta (`https` consigliato). Un nuovo tentativo che ripete lo stesso `callback` viene associato alla richiesta a cui si riferisce. | | `IVMS101` | object | Obbligatorio. Il payload IVMS 101: `originator.originatorPersons` e `beneficiary.beneficiaryPersons` (Didit legge il primo `naturalPerson` di ciascuno; i dati delle persone giuridiche non vengono letti), oltre agli array di wallet `accountNumber`. | Su questo canale gli asset sono identificati tramite DTI, e un DTI identifica un token su una singola blockchain. Didit mappa oggi `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) e `USDC` su nove reti, con altri asset che verranno aggiunti nel tempo. Vedi [identificatori degli asset TRP](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#identificatori-di-asset-trp) per l'elenco completo. Una richiesta il cui DTI non è riconosciuto da Didit viene comunque accettata e presentata al VASP beneficiario con il DTI come codice dell'asset. Una risposta `200` indica che la richiesta è stata accettata per l'elaborazione; `400` indica intestazioni TRP mancanti o un corpo della richiesta non valido; `404` indica che il profilo (o il wallet associato a un indirizzo per wallet) è sconosciuto o disabilitato; `422` indica che la richiesta usa un'estensione TRP: Didit non ne supporta nessuna, quindi un'intestazione `api-extensions` o una chiave `extensions` nel corpo della richiesta vengono rifiutate. Reinviare lo stesso `request-identifier` è idempotente: viene riutilizzata la richiesta originale invece di crearne un duplicato. Didit crea quindi il trasferimento in entrata nell'applicazione del cliente e lo risolve confrontandolo con la rubrica degli indirizzi wallet e con le policy del cliente. Il beneficiario viene associato in base al wallet indicato da un Travel Address per wallet, altrimenti in base al primo indirizzo wallet in `IVMS101.beneficiary.accountNumber`, oppure, in assenza di un indirizzo wallet, in base al nome in `beneficiaryPersons[0].naturalPerson` confrontato con le voci wallet verificate del cliente. La risposta `200` contiene l'esito quando Didit può fornirlo subito: * `{"approved": {"address": "...", "callback": "..."}}` quando la richiesta è stata approvata automaticamente. Didit non invia anche questa approvazione al tuo `callback`. * `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}` quando la richiesta non indica né il beneficiario né un indirizzo wallet, quindi includi sempre entrambi. * `{"version": "3.2.1"}` quando la decisione è in attesa del cliente Didit. La **risoluzione** arriva in seguito come POST al tuo URL `callback`, con uno dei due corpi seguenti. ```json theme={null} { "approved": { "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/" } } ``` ```json theme={null} { "rejected": "Wallet ownership denied by beneficiary VASP" } ``` L'approvazione può essere automatica (quando il VASP beneficiario abilita l'accettazione automatica e il beneficiario corrisponde a una voce wallet verificata sulla blockchain dell'asset) oppure può dipendere da una revisione manuale o da una prova di proprietà del wallet lato beneficiario, quindi considera un possibile ritardo tra richiesta e risoluzione. Una richiesta non corrisponde mai a un wallet che il cliente Didit ha registrato come appartenente a un altro VASP, e il nome del tuo VASP in `originatingVASP` è ciò che il cliente Didit vede come VASP ordinante del trasferimento. Didit non imposta alcuna scadenza per una richiesta che invii, e un cliente Didit che la annulla non ti invia alcun rifiuto, quindi applica un tuo timeout. Dopo aver ricevuto un'approvazione e trasmesso il trasferimento on-chain, chiudi lo scambio inviando un POST all'URL `approved.callback` che ti è stato fornito: ```bash theme={null} curl -X POST "https://trp.didit.me/trp/callbacks/confirmation/{token}/" \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 0b8e2f4a-6c1d-4e9a-8f3b-2d7c5a1e9f60" \ -d '{ "txid": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060" }' ``` Invia `{ "canceled": "reason" }` allo stesso URL se invece annulli il trasferimento. `txid` sposta il trasferimento lato beneficiario in `FINISHED`; `canceled` lo sposta in `CANCELLED`. Entrambi i callback rispondono `204` una volta gestiti, `404` per un token sconosciuto o per un trasferimento che non è più in attesa di quel callback, e `400` per un corpo della richiesta che non contiene nessuno dei due campi del callback. ### Gestione delle richieste inviate da Didit Quando un cliente Didit avvia un trasferimento verso di te tramite TRP, Didit: 1. Recupera `/identity` alla radice dell'host dell'URL della tua richiesta (`https://{your-host}/identity`) e verifica il nome e il LEI dichiarati rispetto a quelli che il cliente si aspetta. Quando il percorso proviene dalla directory di Didit, il tuo `/identity` deve riportare il LEI di quella voce della directory. 2. Invia con POST una richiesta di trasferimento al tuo URL, con la stessa struttura del corpo vista sopra: `asset.dti`, un `amount` in unità base come numero JSON, un `callback` e il payload `IVMS101`. Solo una risposta `2xx` viene considerata consegnata. Una risposta `3xx` viene rifiutata, perché i reindirizzamenti non vengono seguiti, e qualsiasi altra risposta viene registrata nella cronologia del trasferimento del cliente con il codice di stato restituito dal tuo endpoint, per esempio `refused by counterparty (HTTP 403): ...`. Entrambe le chiamate includono le due intestazioni TRP, e Didit non segue i reindirizzamenti HTTP su di esse, quindi esponi direttamente `/identity` e l'URL della richiesta. Se `/identity` non è raggiungibile, non riporta alcun LEI oppure riporta un LEI diverso da quello fornito dal cliente, o riporta un nome che non corrisponde, Didit si ferma prima di inviare la richiesta e il trasferimento passa a `COUNTERPARTY_VASP_NOT_REACHABLE`. Se l'invio POST della richiesta fallisce oppure il tuo endpoint risponde con uno stato `4xx` o `5xx`, anche il trasferimento passa a `COUNTERPARTY_VASP_NOT_REACHABLE`. Il `callback` contenuto in quella richiesta punta all'endpoint di risoluzione di Didit (`/trp/callbacks/resolution/{token}/`). Rispondi inviando con POST gli stessi corpi di risoluzione che usa Didit: `{ "approved": { "address": "...", "callback": "..." } }` per approvare (il tuo `callback` è il punto in cui Didit invierà la conferma on-chain), oppure `{ "rejected": "reason" }` per rifiutare. Invia con la risposta entrambe le intestazioni TRP. Didit risponde con `204` una volta gestita, `404` quando il trasferimento non è più in attesa di una risoluzione, e `400` per un'approvazione senza `address` o il cui `callback` non è un URL `http(s)` pubblico che Didit può chiamare. In caso di approvazione, dal lato Didit lo stato passa a `COMPLETED`. Quando il cliente comunica l'hash on-chain, Didit invia con POST `{ "txid": "..." }` al callback di conferma che hai fornito (oppure `{ "canceled": "reason" }` se il trasferimento viene annullato prima). > [!NOTE] > > I token di callback sono segreti monouso e non indovinabili, generati per ogni trasferimento: tratta gli URL di callback completi come riservati, e tieni presente che una risoluzione viene accettata solo finché il trasferimento è ancora in attesa di una risoluzione. ## Recupero tramite email Se nessun canale del protocollo ti raggiunge e il cliente Didit ha fornito la tua email di compliance, Didit ricorre all'email: il tuo referente per la compliance riceve un messaggio che indica la VASP ordinante, con un link sicuro monouso per il recupero. Non servono un account, una chiave API o un'integrazione: il token del link è l'autenticazione. Aprendo il link viene mostrato lo scambio in sospeso. L'API sottostante, che la pagina ospitata utilizza per te, è pubblica: ```bash theme={null} curl https://verification.didit.me/v3/travel-rule/pickup/{token}/ ``` ```json theme={null} { "originator_vasp_name": "Origin CASP SL", "amount": "0.250000000000000000", "currency": "ETH", "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "status": "AWAITING_COUNTERPARTY" } ``` `amount` è il valore decimale memorizzato così com'è, quindi include tutte le 18 cifre decimali. ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \ -H "Content-Type: application/json" \ -d '{ "decision": "accept", "beneficiary_name": "Ana Diaz" }' ``` `decision` è `accept` o `decline`. In caso di accettazione, indica il nome del beneficiario come risulta nei tuoi registri, così che la parte ordinante possa eseguire il confronto dei nomi, oppure invia la tua risposta IVMS 101 completa come `ivms_response`, nel qual caso prevale il nome del beneficiario contenuto in essa. In caso di rifiuto puoi indicare un `decline_reason` (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` o `other`) e un `decline_detail` di massimo 512 caratteri, obbligatorio per `other`. Un'accettazione senza `beneficiary_name` viene registrata come mancata corrispondenza quando il mittente ha fornito un nome del beneficiario, a meno che il mittente non abbia disattivato il confronto dei nomi. La risposta è il `{"status": "..."}` risultante: `COMPLETED` se i nomi corrispondono, `COUNTERPARTY_MISMATCHED_DATA` se non corrispondono, oppure `COUNTERPARTY_VASP_GENERAL_DECLINE` dopo un rifiuto. Puoi rispondere una sola volta, mentre il trasferimento è in attesa della tua risposta. Dopo che hai risposto, dopo che il trasferimento è stato annullato o dopo la scadenza per la conferma, entrambi gli endpoint restituiscono `410`, e un token sconosciuto restituisce `404`. La richiesta mostra i dati dell'ordinante che il mittente condivide e un `ivms_request` IVMS 101, nella lingua della tua giurisdizione. Ricevi promemoria 72, 24 e 6 ore prima della scadenza finché non hai risposto. ## Sunrise: trasferimenti regolati prima dello scambio Quando un trasferimento raggiunge il wallet di un cliente Didit prima che abbia luogo qualsiasi scambio ai sensi della Travel Rule, perché in quel momento non esisteva un canale condiviso, i dati possono comunque essere consegnati dopo il regolamento. Invia il payload della Travel Rule al cliente Didit (la tua controparte beneficiaria) tramite il tuo canale abituale e chiedigli di registrarlo: il cliente chiama [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/it/transaction-monitoring/travel-rule#registrazione-postuma-del-deposito-sunrise) con la catena del deposito, `txid`, l'indirizzo del wallet, l'importo, la valuta e i tuoi dati dell'ordinante. Includi la tua identità di VASP (nome, LEI e Travel Address) come `originating_vasp` in quel payload, così che il trasferimento del cliente Didit registri chi ha inviato il deposito. I dati restano su quel trasferimento e non creano né modificano mai la tua [voce della directory](#come-entrare-nella-directory-vasp-di-didit). Il LEI deve essere un LEI valido di 20 caratteri e il Travel Address deve essere valido, altrimenti la registrazione viene rifiutata. ## Come entrare nella directory VASP di Didit Didit gestisce una directory VASP che il routing in uscita dei suoi clienti consulta. Le voci provengono da queste fonti: * Il registro interinale MiCA dell'ESMA sui fornitori di servizi per le cripto-attività, consultato ogni settimana: il tuo nome, il tuo LEI e lo Stato membro di origine, se sei iscritto lì. * La directory pubblica TRISA, consultata ogni settimana: chi sei, il tuo paese e la tua iscrizione TRISA. * Il registro globale LEI, che fornisce il tuo LEI, eventuali altri nomi legali e il paese. * L'attribuzione tramite analisi blockchain, quando un wallet di destinazione viene ricondotto al tuo servizio di exchange o di custodia: Didit aggiunge o abbina la tua voce e conserva il nome attribuito come alias. * Il personale di Didit, che cura le voci: identificatori di routing e iscrizioni alle reti che ha verificato, contatti di compliance, alias e marchi con le relative entità. Ciò che un cliente Didit comunica su di te, come un `originating_vasp` in una registrazione sunrise o un Travel Address su un trasferimento, resta su quel trasferimento del cliente e non modifica mai la tua voce. Anche le richieste di informazioni sui trasferimenti che invii a un cliente Didit non creano né aggiornano la tua voce. La tua voce instrada un trasferimento verso di te quando contiene un endpoint `TRP` verificato, un'iscrizione a una rete che il mittente può usare oppure un contatto di compliance per il fallback via email. Un indirizzo di compliance su uno dei tuoi domini che risponde a una richiesta tramite il suo link di risposta diventa un contatto che ogni cliente Didit può usare. Finché la tua voce non contiene un instradamento, un cliente Didit ti raggiunge solo con i campi che trasmette con ogni trasferimento: il tuo Travel Address, il tuo identificatore di rete (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` oppure `counterparty_sygna_vasp_code`) o la tua email di compliance (`counterparty_vasp_email`). Per essere raggiungibile oggi, condividi il tuo Travel Address, il tuo identificatore di rete o la tua email di compliance con i clienti Didit con cui lavori. ## Checklist per i VASP controparte * **Usi già TRP**: condividi il tuo Travel Address e il tuo LEI con il cliente Didit. I suoi trasferimenti `BTC`, `ETH` e `USDC` arrivano come richieste TRP standard al tuo endpoint. Rispondi nella risposta alla richiesta: una risposta successiva richiede l'host TRP pubblico di Didit, che non è ancora attivo. * **Sei su GTR, TRUST o VerifyVASP**: condividi il tuo identificatore di rete. I trasferimenti arrivano su quella rete quando il cliente Didit dispone di una propria iscrizione a tale rete. Didit legge la tua risposta GTR o VerifyVASP dalla rete, ma non quella TRUST, quindi pubblica anche un endpoint TRP quando uno scambio su TRUST deve concludersi. [Reti Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule-networks.md) spiega quando questo cambia. * **Sei su Sygna Bridge**: condividi il tuo codice VASP Sygna. Quando il cliente Didit detiene una propria iscrizione Sygna, la tua risposta di autorizzazione completa o rifiuta il trasferimento una volta che Didit la legge tramite polling. * **Non hai ancora un canale di protocollo**: fornisci al cliente Didit un'email di compliance monitorata. Riceverai i link per prendere in carico le richieste e potrai rispondere dalla pagina ospitata senza alcuna integrazione. * **Un trasferimento è già stato regolato**: invia i dati tramite la [registrazione sunrise](#sunrise-trasferimenti-regolati-prima-dello-scambio), passando dal cliente Didit. * **Vuoi anche inviare trasferimenti verso VASP Didit**: chiedi alla tua controparte il suo Travel Address dalle proprie impostazioni Travel Rule su Didit, poi segui [POST /trp/inquiries](#post-/trp/inquiries//) quando l'host TRP pubblico di Didit sarà attivo. ## Passaggi successivi > [card] [Travel Rule](https://docs.didit.me/it/transaction-monitoring/travel-rule.md) > > Il prodotto per i clienti: ciclo di vita, impostazioni, canali e l'API /v3/. > [card] [Widget per la verifica della proprietà del wallet](https://docs.didit.me/it/transaction-monitoring/wallet-ownership-widget.md) > > Come vengono raccolte le prove di proprietà lato beneficiario quando un wallet è in autocustodia. > [card] [Registrazione sunrise](https://docs.didit.me/it/transaction-monitoring/travel-rule.md#registrazione-postuma-del-deposito-sunrise) > > Registrazione dei dati Travel Rule per i depositi già regolati on-chain. > [card] [Webhook](https://docs.didit.me/it/integration/webhooks.md) > > Come i clienti Didit osservano ogni transizione dello scambio dal proprio lato. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.