> ## 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. # Travel Rule: interoperabilitat amb un VASP de Didit > Com un VASP intercanvia dades de la Travel Rule amb un client de Didit: travel addresses, endpoints TRP, callbacks i registre sunrise. Aquesta pàgina és per a **l'altra part** d'un intercanvi de la [Travel Rule de Didit](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md): el VASP contrapart (o el seu equip d'enginyeria) que necessita enviar dades de la Travel Rule a un VASP que s'executa a Didit, o rebre'n dades des d'aquest. Tot el que es documenta aquí és infraestructura pública operada per Didit. No necessites un compte de Didit, una clau d'API ni cap relació comercial amb Didit per interoperar: la integració més profunda només requereix HTTPS i JSON. ## Com Didit encamina un intercanvi Quan un client de Didit envia una transferència, Didit prova aquests canals en un ordre de prioritat estricte i utilitza el primer que pugui arribar a tu: | Prioritat | Canal | Què significa per a tu | | - | - | - | | 1 | `INTERNAL` | Tots dos VASP funcionen a Didit: l'intercanvi es liquida dins de la plataforma i no es fa cap crida externa. | | 2 | `TRP` | Exposes un endpoint del Travel Rule Protocol (TRP), o el client de Didit coneix la teva [Travel Address](#travel-addresses). Didit crida el teu endpoint de consulta TRP de màquina a màquina, per a transferències de `BTC`, `ETH` i `USDC` (`USDC` quan la transferència indica la xarxa per la qual es mou). | | 3 | `GTR` | Hi ha una membresia activa de Global Travel Rule (GTR) per a l'ordenant i ets adreçable mitjançant un codi de VASP de GTR. Didit llegeix la teva resposta des de la resposta de GTR, o consultant l'estat de la sol·licitud. | | 4 | `TRUST` | Hi ha una membresia activa de TRUST per a l'ordenant i ets adreçable mitjançant un identificador de membresia de TRUST. Només per a enviaments: consulta l'advertència següent. | | 5 | `VERIFYVASP` | Hi ha una membresia activa de VerifyVASP per a l'ordenant i ets adreçable mitjançant un id de VerifyVASP. Didit llegeix la teva resposta consultant l'estat de la verificació. | | 6 | `SYGNA` | Hi ha una membresia activa de Sygna Bridge per a l'ordenant i ets adreçable mitjançant un codi de VASP de Sygna. Didit utilitza el protocol Sygna de forma nativa (IVMS101 xifrat amb ECIES, sol·licituds de permís signades) i llegeix la teva resposta de permís consultant l'estat de la transferència: el seu callback de Sygna encara no està activat. | | 7 | `EMAIL` | No hi ha cap canal de protocol disponible: el teu contacte de compliment rep un [enllaç d'un sol ús per recollir la transferència per correu electrònic](#recollida-per-correu-electrònic). | > [!WARNING] > > **Didit no pot rebre una resposta de `TRUST` i encara no accepta transferències que s'hi enviïn per la xarxa.** > Per `TRUST`, una transferència d'un client de Didit et arriba, però la teva resposta no pot tornar, i la transferència caduca quan arriba la data límit de confirmació de l'ordenant en lloc de completar-se. > Per `GTR`, `VERIFYVASP` i `SYGNA`, Didit llegeix la teva resposta de la mateixa xarxa, mitjançant la resposta de la xarxa o consultant l'estat de la transferència. La taula anterior cobreix les transferències que envia un client de Didit. Quan tu envies una transferència a un client de Didit, Didit només la pot acceptar com a `TRP` [consulta de transferència](#post-/trp/inquiries//), quan l'host públic TRP de Didit estigui activat (encara no respon, consulta [endpoints TRP](#endpoints-trp)), o, després de la liquidació, com a [registre sunrise](#sunrise-transferències-liquidades-abans-de-l’intercanvi): avui cap canal de xarxa ni cap canal de correu no lliura una transferència entrant a un client de Didit. Els canals de xarxa (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) funcionen amb una membresia del costat de l'ordenant. Avui això ha de ser la membresia connectada pròpia del client de Didit: Didit no té cap membresia de plataforma en cap d'aquestes xarxes encara i està en procés d'alta com a proveïdor. GTR no s'inclou per defecte, i el mateix requisit de membresia s'aplica a les quatre xarxes. L'ordenant hauria de revisar l'objecte `networks` a [Obtenir la configuració de Travel Rule](https://docs.didit.me/ca/management-api/travel-rule/get-settings.md): `didit` vol dir que la membresia de Didit té aquesta aplicació com a participant propi a la xarxa, `own` vol dir una membresia de client connectada, `off` vol dir que l'encaminament de la plataforma està desactivat, i `unavailable` vol dir que res pot enviar per aquesta xarxa per a l'aplicació de moment. Mentre Didit no tingui una membresia de plataforma, cap xarxa informa `didit`. Activar Travel Rule no activa una membresia de xarxa. Consulta [xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md) per saber a què dona accés cada xarxa avui. Si ets en una d'aquestes xarxes i el client de Didit té la seva pròpia membresia, comparteix el teu identificador de xarxa amb ell i la transferència t'arribarà per la xarxa que ja fas servir. Per `SYGNA`, la teva resposta de permís completa o rebutja la transferència: Didit consulta l'estat de la transferència cada 5 minuts, i també registra `https://trp.didit.me/sygna/callbacks/permission/{token}/` com a callback de cada sol·licitud de permís, amb un token generat per a aquesta transferència. Aquest callback està a l'host públic TRP de Didit, que encara no atén sol·licituds. Un `permission_status` de `ACCEPTED` passa la transferència de l'ordenant a `COMPLETED`, i `REJECTED` la passa a `COUNTERPARTY_VASP_GENERAL_DECLINE`, o a `COUNTERPARTY_MISMATCHED_DATA` quan el `reject_code` és `BVRC007` (el nom del beneficiari no coincideix). El callback necessita la teva signatura: respon `401` amb `{"status": "INVALID_SIGNATURE"}` sense una signatura vàlida, `404` per a un token desconegut, i `200` de nou per a una decisió que ja s'ha aplicat. Sense cap membresia compartida, `TRP` és el camí a planificar: comparteix la teva Travel Address amb el client de Didit, i les seves transferències arribaran al teu endpoint TRP. Una resposta que donis en la teva resposta a la consulta completa o rebutja la transferència de seguida; una resposta que enviïs més tard al callback de Didit necessita l'host públic TRP de Didit, que encara no està activat. Quan cap dels canals et pot identificar, Didit fa un pas de resolució més: **atribució mitjançant analítica de blockchain**. La cartera de destinació es resol mitjançant les dades d'analítica de blockchain i, quan s'atribueix al teu servei d'intercanvi o de custòdia, Didit registra el teu nom al seu directori de VASP i torna a provar els canals amb aquest identificador. Això vol dir que pots ser identificat fins i tot quan l'ordenant només va proporcionar una adreça. Les transferències atribuïdes t'arriben automàticament només quan la teva entrada del directori té un encaminament: un endpoint `TRP` verificat, un registre en una xarxa, o un contacte de compliment (consulta [Entrar al directori de VASP de Didit](#com-entrar-al-directori-de-vasp-de-didit)). La cadena de resolució completa és, doncs: un client de Didit que ha demostrat el control de la cartera (`INTERNAL`) i la Travel Address que l'ordenant hi va guardar, després els canals de protocol i de xarxa, i després l'analítica de blockchain. ## Travel addresses Tot VASP de Didit amb Travel Rule activat té una **Travel Address**: una cadena compacta que comença per `ta` i codifica la URL del seu endpoint personal de consulta de transferències TRP. Els clients de Didit la llegeixen a la seva configuració de Travel Rule i la comparteixen amb les contraparts. Quan un client de Didit us facilita la seva, teniu tot el necessari per contactar-lo per TRP. La codificació segueix la convenció de Travel Address de TRP: * Elimina el prefix `ta`. * Descodifica el resultat en Base58Check (alfabet de Bitcoin, suma de verificació de doble SHA-256). * Els bytes descodificats són la URL de consulta sense l'esquema; afegeix-hi `https://` al davant. * La URL sempre inclou el parell de consulta `t=i` (tipus: consulta). Una Travel Address de Didit descodificada té una de les dues formes: ``` 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 el perfil allotjat del VASP. Envia les teves consultes de transferència mitjançant POST a aquesta URL i consulta primer l'[endpoint d'identitat](#get-/trp/identity//) corresponent per verificar amb qui estàs parlant. La segona forma és una **Travel Address per cartera**: indica una cartera concreta del client de Didit (`receiving_travel_address` a la seva llibreta d'adreces), de manera que la teva consulta arriba a aquella cartera sense que el client l'hagi de fer coincidir pel número de compte o pel nom del titular. Respon `404` quan la cartera s'ha eliminat o quan consta com a pertanyent a un altre VASP. ## Endpoints TRP Didit utilitza la versió `3.2.1` del protocol TRP a l'URL base `https://trp.didit.me`. Tots els endpoints intercanvien JSON sobre HTTPS. > [!WARNING] > > El servidor públic de TRP de Didit encara no ofereix aquests endpoints. Mentre no ho faci, no es pot lliurar cap consulta ni sol·licitud d'identitat TRP a un client de Didit; aquesta secció és el contracte segons el qual respondrà el servidor quan estigui disponible. | Mètode | Ruta | Finalitat | | - | - | - | | `GET` | `/identity` | Identitat de l'operador de la plataforma (també servida a `/trp/identity`). | | `GET` | `/trp/identity/{profile_uuid}/` | Identitat d'un perfil de VASP allotjat. | | `POST` | `/trp/inquiries/{profile_uuid}/` | Envia una consulta de transferència a un VASP allotjat. | | `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | Envia una consulta de transferència per a una cartera concreta d'un VASP allotjat (una Travel Address per cartera). | | `POST` | `/trp/callbacks/resolution/{token}/` | Resol una consulta que **Didit** t'ha enviat (aprovar o rebutjar). | | `POST` | `/trp/callbacks/confirmation/{token}/` | Confirma o cancel·la una transferència que Didit ha aprovat per a tu. | Hi ha dues capçaleres TRP importants: * `api-version` - la versió del protocol TRP que parles, per exemple `3.2.1`. És obligatòria en les consultes i en els dos callbacks. * `request-identifier` - el teu identificador únic de la sol·licitud, que es torna a enviar a les capçaleres de la resposta. És obligatòria en les consultes i en els dos callbacks. Una sol·licitud als endpoints de consulta o de callback sense les dues capçaleres retorna `400`. Cada resposta de Didit inclou `api-version: 3.2.1` i torna a enviar el teu `request-identifier`. ### GET /identity Retorna la identitat de l'operador de la plataforma. No cal cap capçalera. ```bash theme={null} curl https://trp.didit.me/identity ``` ```json theme={null} { "name": "Didit", "lei": "", "x509": "" } ``` ### GET /trp/identity/{profile_uuid}/ Retorna la identitat del VASP concret amb què estàs a punt d'intercanviar - utilitza-la per verificar el nom i el LEI abans d'enviar dades personals identificables (PII). Didit fa la mateixa comprovació en sentit invers quan inicia l'intercanvi: si la identitat que informa el teu endpoint no coincideix amb el LEI o el nom esperats, l'intercanvi s'avorta. ```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": "" } ``` Retorna `404` quan el perfil no existeix o quan la seva configuració de Travel Rule està desactivada. ### POST /trp/inquiries/{profile_uuid}/ Envia una consulta de transferència: tu ets el VASP ordenant, i el client de Didit és el VASP beneficiari. ```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"] } } }' ``` | Camp | Tipus | Descripció | | - | - | - | | `asset.dti` | string | Obligatori. L'identificador de token digital (DTI, ISO 24165) de l'actiu que es transfereix. Una consulta sense aquest camp respon `400`; el camp `asset.slip0044` anterior a la 3.2.0 no es llegeix. | | `amount` | number | Obligatori. Import enter en la unitat més petita de l'actiu (unitats base segons els decimals del DTI). S'accepta qualsevol notació JSON d'un nombre enter, inclosa la forma amb exponent, i també una cadena de dígits. Una fracció, o un import massa gran per registrar-se, respon `400`. | | `callback` | string | Obligatori. URL absoluta pública `http(s)` del teu costat on Didit envia la resolució de la consulta (es recomana `https`). Un reintent que repeteix el mateix `callback` s'associa a la consulta que repeteix. | | `IVMS101` | object | Obligatori. La càrrega útil IVMS 101: `originator.originatorPersons` i `beneficiary.beneficiaryPersons` (Didit llegeix el primer `naturalPerson` de cadascun; les dades de persona jurídica no es llegeixen), juntament amb les matrius de carteres `accountNumber`. | En aquest canal els actius s'identifiquen pel DTI, i un DTI identifica un token en una única blockchain. Didit mapeja avui `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) i `USDC` en nou xarxes, i se'n podran afegir més amb el temps. Consulta [identificadors d'actius TRP](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md#identificadors-d’actius-trp) per a la llista completa. Una consulta amb un DTI que Didit no reconeix s'accepta igualment i es mostra al VASP beneficiari amb el DTI com a codi d'actiu. Una resposta `200` indica que la consulta s'ha acceptat per al seu processament; `400` vol dir que falten les capçaleres TRP o el cos no és vàlid; `404` vol dir que el perfil (o la cartera d'una Travel Address per cartera) és desconeguda o està desactivada; i `422` vol dir que la sol·licitud utilitza una extensió TRP: Didit no en suporta cap, de manera que es rebutja una capçalera `api-extensions` o una clau `extensions` al cos. Tornar a enviar el mateix `request-identifier` és idempotent: es reutilitza la consulta original en lloc de duplicar-la. Després, Didit crea la transferència entrant a l'aplicació del client i la resol segons la llibreta d'adreces de carteres i la política del client. Identifica el beneficiari per la cartera que especifica una Travel Address per cartera; si no, per la primera adreça de cartera de `IVMS101.beneficiary.accountNumber`; o, si no n'hi ha cap, pel nom de `beneficiaryPersons[0].naturalPerson` comparat amb les entrades de cartera verificades del client. La resposta `200` porta la resposta quan Didit la pot donar de seguida: * `{"approved": {"address": "...", "callback": "..."}}` quan la consulta s'ha aprovat automàticament. Didit no envia aquesta aprovació també al teu `callback`. * `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}` quan la consulta no indica ni el beneficiari ni una adreça de cartera; per això inclou sempre les dues coses. * `{"version": "3.2.1"}` quan la decisió està pendent del client de Didit. La **resolució** arribarà més tard com a POST a la teva URL de `callback`, amb un dels dos cossos següents. ```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'aprovació pot ser automàtica - quan el VASP beneficiari activa l'acceptació automàtica i el beneficiari coincideix amb una entrada de cartera verificada a la cadena de l'actiu - o pot dependre d'una revisió manual o d'una prova de titularitat de la cartera per part del beneficiari, així que compta amb un retard entre la consulta i la resolució. Una consulta mai coincideix amb una cartera que el client de Didit hagi registrat com a pertanyent a un altre VASP, i el nom del teu VASP que consta a `originatingVASP` és el que el client de Didit veu com a VASP ordenant de la transferència. Didit no fixa cap termini per a les consultes que envies, i un client de Didit que cancel·la una consulta no t'envia cap rebuig, així que aplica el teu propi temps d'espera. Després de rebre una aprovació i difondre la transferència on-chain, tanca l'intercanvi fent un POST a la URL `approved.callback` que se't va donar: ```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" }' ``` Envia `{ "canceled": "reason" }` a la mateixa URL en cas que avortis la transferència. `txid` passa la transferència del costat del beneficiari a `FINISHED`; `canceled` la passa a `CANCELLED`. Els dos callbacks responen `204` quan s'han processat, `404` per a un token desconegut o una transferència que ja no espera aquest callback, i `400` per a un cos que no porta cap dels dos camps del callback. ### Resolució de les consultes que Didit t'envia Quan un client de Didit inicia una transferència cap a tu per TRP, Didit: 1. Obté `/identity` a l'arrel de l'amfitrió de la URL de consulta (`https://{your-host}/identity`) i verifica el nom i el LEI informats respecte al que espera el client. Quan la ruta prové del directori de Didit, el teu `/identity` ha d'informar del LEI d'aquella entrada del directori. 2. Envia un POST d'una consulta de transferència a la teva URL de consulta, amb la mateixa estructura del cos que l'anterior: `asset.dti`, un `amount` en unitats base com a número JSON, un `callback` i el payload `IVMS101`. Només una resposta `2xx` es considera lliurada. Una `3xx` es rebutja, perquè els redireccionaments no se segueixen, i qualsevol altra resposta es registra a la línia de temps de la transferència del client amb el codi d'estat que has retornat, per exemple `refused by counterparty (HTTP 403): ...`. Totes dues crides porten les dues capçaleres TRP, i Didit no segueix els redireccionaments HTTP en aquestes crides, així que serveix `/identity` i la URL de consulta directament. Si `/identity` no és accessible, no informa d'un LEI o n'informa un de diferent quan el client n'ha subministrat un, o informa d'un nom que no coincideix, Didit s'atura abans d'enviar la consulta i la transferència del client passa a `COUNTERPARTY_VASP_NOT_REACHABLE`. Si després el POST de la consulta falla o el teu endpoint la respon amb un estat `4xx` o `5xx`, la transferència també passa a `COUNTERPARTY_VASP_NOT_REACHABLE`. El `callback` d'aquella consulta apunta a l'endpoint de resolució de Didit (`/trp/callbacks/resolution/{token}/`). Respon fent un POST amb els mateixos cossos de resolució que fa servir Didit: `{ "approved": { "address": "...", "callback": "..." } }` per aprovar (el teu `callback` és on Didit publicarà la confirmació on-chain), o `{ "rejected": "reason" }` per rebutjar. Envia-hi les dues capçaleres TRP. Didit respon amb `204` un cop gestionada la sol·licitud, `404` quan la transferència ja no espera cap resolució, i `400` per a una aprovació sense `address` o quan el `callback` no és una URL `http(s)` pública que Didit pugui cridar. En aprovar, la part de Didit passa a `COMPLETED`. Quan el client informa del hash on-chain, Didit fa un POST de `{ "txid": "..." }` al callback de confirmació que has indicat (o de `{ "canceled": "reason" }` si la transferència es cancel·la abans). > [!NOTE] > > Els tokens de callback són secrets amb una única finalitat, no endevinables, generats per a cada transferència: tracta les URL completes de callback com a confidencials, i tingues en compte que una resolució només s'accepta mentre la transferència encara n'espera una. ## Recollida per correu electrònic Si no t'arriba cap canal de protocol i el client de Didit ha subministrat el teu correu de compliment, Didit recorre al correu electrònic: el teu contacte de compliment rep un missatge que identifica la VASP ordenant amb un enllaç segur de recollida d'un sol ús. No cal cap compte, clau d'API ni integració: el token de l'enllaç és l'autenticació. En obrir l'enllaç es mostra l'intercanvi pendent. L'API que hi ha a sota (que la pàgina allotjada gestiona en nom teu) és pública: ```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` és el decimal emmagatzemat tal qual, de manera que porta les 18 xifres decimals completes. ```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` és `accept` o `decline`. En acceptar, indica el nom del beneficiari tal com consta als teus registres, perquè la part ordenant pugui fer la seva comparació de noms, o envia la teva resposta IVMS 101 completa com a `ivms_response`, i aleshores prevaldrà el nom del beneficiari que hi consta. En rebutjar, pots indicar un `decline_reason` (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` o `other`) i un `decline_detail` de fins a 512 caràcters, obligatori per a `other`. Una acceptació sense `beneficiary_name` es registra com a discrepància quan el remitent ha subministrat un nom de beneficiari, tret que el remitent hagi desactivat la comparació de noms. La resposta és el `{"status": "..."}` resultant: `COMPLETED` quan els noms coincideixen, `COUNTERPARTY_MISMATCHED_DATA` quan no coincideixen, o `COUNTERPARTY_VASP_GENERAL_DECLINE` després d'un rebuig. Només pots respondre una vegada, mentre la transferència espera la teva resposta: després de respondre, després que la transferència es cancel·li, o després del seu termini de confirmació, tots dos endpoints retornen `410`, i un token desconegut retorna `404`. La sol·licitud mostra els camps de l'ordenant que comparteix el remitent i un `ivms_request` IVMS 101, en l'idioma de la teva jurisdicció, i se't recorda 72, 24 i 6 hores abans del termini mentre no hagis respost. ## Sunrise: transferències liquidades abans de l'intercanvi Quan una transferència arriba a la cartera d'un client de Didit abans que hagi tingut lloc cap intercanvi de Travel Rule, perquè en aquell moment no existia cap via compartida, les dades es poden lliurar igualment després de la liquidació. Envia el payload de la Travel Rule al client de Didit (la teva contrapart beneficiària) pel teu canal habitual i demana-li que la registri. El client crida [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/ca/transaction-monitoring/travel-rule#registre-posterior-al-dipòsit) amb la cadena del dipòsit, el `txid`, l'adreça de la cartera, l'import, la moneda i les teves dades de l'ordenant. Inclou la identitat de la teva VASP (nom, LEI i Travel Address) com a `originating_vasp` en aquest payload, perquè el registre de la transferència del client de Didit indiqui qui ha enviat el dipòsit. Queda associat a aquella transferència i mai no crea ni modifica la teva [entrada al directori](#com-entrar-al-directori-de-vasp-de-didit). El LEI ha de ser un LEI vàlid de 20 caràcters, i la Travel Address ha de ser-ne una de vàlida, o el registre es rebutja. ## Com entrar al directori de VASP de Didit Didit manté un directori de VASP que consulta l'encaminament de transferències sortints dels seus clients. Les entrades provenen d'aquestes fonts: * El registre provisional MiCA de l'ESMA de proveïdors de serveis de criptoactius, consultat cada setmana: el teu nom, el LEI i l'estat membre d'origen, si hi figures. * El directori públic de TRISA, consultat cada setmana: qui ets, el teu país i la teva inscripció a TRISA. * El registre global de LEI, que omple el teu LEI, altres noms legals i el país. * L'atribució d'analítica de blockchain, quan una adreça de cartera de destinació es resol cap al teu servei d'intercanvi o de custòdia: Didit afegeix o relaciona la teva entrada i conserva el nom atribuït com a àlies. * El personal de Didit, que gestiona les entrades: identificadors d'encaminament i inscripcions de xarxa verificats, contactes de compliment, àlies, i marques amb les seves entitats. Qualsevol cosa que un client de Didit informi sobre tu, com ara un `originating_vasp` en un registre sunrise o una adreça de viatge en una transferència, es queda en la transferència d'aquest client i mai no canvia la teva entrada. Les consultes de transferència que tu enviïs a un client de Didit tampoc no creen ni actualitzen la teva entrada. La teva entrada encamina una transferència cap a tu quan porta un endpoint `TRP` verificat, una inscripció de xarxa que el remitent pot utilitzar, o un contacte de compliment per a l'alternativa del correu electrònic. Una adreça de compliment d'un dels teus propis dominis que respon a una sol·licitud mitjançant el seu enllaç de resposta esdevé un contacte que qualsevol client de Didit pot utilitzar. Mentre la teva entrada no porti cap ruta, un client de Didit només pot contactar amb tu mitjançant els camps que transmet a cada transferència: la teva adreça de viatge, el teu identificador de xarxa (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` o `counterparty_sygna_vasp_code`), o el teu correu de compliment (`counterparty_vasp_email`). Per ser accessible avui, comparteix la teva adreça de viatge, el teu identificador de xarxa o el teu correu de compliment amb els clients de Didit amb qui treballes. ## Llista de verificació per a VASP contrapart * **Ja utilitzes TRP**: comparteix la teva adreça de viatge i el teu LEI amb el client de Didit; les seves transferències de `BTC`, `ETH` i `USDC` arriben com a consultes TRP estàndard al teu endpoint. Respon a la consulta: una resposta posterior requereix l'amfitrió públic de TRP de Didit, que encara no està disponible. * **Ets a GTR, TRUST o VerifyVASP**: comparteix el teu identificador de xarxa; les transferències arriben per aquesta xarxa quan el client de Didit té la seva pròpia membresia allà. Didit llegeix la teva resposta de GTR o VerifyVASP des de la xarxa, però no la de TRUST; per tant, publica també un endpoint TRP quan s'hagi de completar un intercanvi mitjançant TRUST. [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md) expliquen quan això canvia. * **Ets a Sygna Bridge**: comparteix el teu codi VASP de Sygna; quan el client de Didit té la seva pròpia membresia de Sygna, la teva resposta de permís fa que la transferència es completi o es rebutgi un cop Didit la llegeix mitjançant sondeig. * **Encara no tens cap canal de protocol**: dona al client de Didit un correu de compliment supervisat; rebràs enllaços per recollir les consultes i podràs respondre des de la pàgina allotjada sense cap integració. * **Una transferència ja s'ha liquidat**: lliura les dades mitjançant el [registre sunrise](#sunrise-transferències-liquidades-abans-de-l’intercanvi) a través del client de Didit. * **També vols originar transferències cap a VASP de Didit**: demana a la teva contrapart la seva adreça de viatge des de la configuració de Travel Rule de Didit, i després segueix [POST /trp/inquiries](#post-/trp/inquiries//) quan l'amfitrió públic de TRP de Didit estigui en funcionament. ## Següents passos > [card] [Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md) > > El producte per als clients: cicle de vida, configuració, vies i l'API /v3/. > [card] [Giny de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) > > Com es recullen les proves de titularitat de la part beneficiària quan una cartera és autoallotjada. > [card] [Registre sunrise](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md#registre-posterior-al-dipòsit) > > Registre de dades de la Travel Rule per a dipòsits que ja s'han liquidat on-chain. > [card] [Webhooks](https://docs.didit.me/ca/integration/webhooks.md) > > Com els clients de Didit observen cada transició de l'intercanvi al seu costat. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.