> ## 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. # Interoperabilidad Travel Rule: llegar a un VASP de Didit > Cómo los VASP intercambian datos de Travel Rule con un cliente de Didit: travel address, endpoints TRP, callbacks, email y registro sunrise. Esta página es para la **otra parte** de un intercambio de [Travel Rule de Didit](https://docs.didit.me/es/transaction-monitoring/travel-rule.md): la VASP contraparte (o su equipo de ingeniería) que necesita enviar datos de Travel Rule a una VASP que opera con Didit, o recibirlos de ella. Todo lo que se documenta aquí es infraestructura pública operada por Didit. No necesitas una cuenta de Didit, una clave de API ni ninguna relación comercial con Didit para interoperar: la integración más profunda solo requiere HTTPS y JSON. ## Cómo Didit enruta transferencias a un exchange Cuando un cliente de Didit envía una transferencia, Didit prueba estas vías en un orden de prioridad estricto y usa la primera que puede llegar hasta ti: | Prioridad | Vía | Qué significa para ti | | - | - | - | | 1 | `INTERNAL` | Ambos VASP operan en Didit: la transferencia se liquida dentro de la plataforma y no se realiza ninguna llamada externa. | | 2 | `TRP` | Expones un endpoint de Travel Rule Protocol (TRP), o el cliente de Didit conoce tu [travel address](#travel-addresses). Didit invoca tu endpoint de consulta TRP de máquina a máquina, para transferencias de `BTC`, `ETH` y `USDC` (`USDC` cuando la transferencia indica la red por la que se mueve). | | 3 | `GTR` | El remitente tiene activa una membresía de Global Travel Rule (GTR) y eres localizable mediante un código de VASP de GTR. Didit lee tu respuesta a partir de la respuesta de GTR, o consultando periódicamente el estado de la solicitud. | | 4 | `TRUST` | El remitente tiene activa una membresía de TRUST y eres localizable mediante un id de membresía de TRUST. Solo para envío: consulta la advertencia más abajo. | | 5 | `VERIFYVASP` | El remitente tiene activa una membresía de VerifyVASP y eres localizable mediante un id de VerifyVASP. Didit lee tu respuesta consultando periódicamente el estado de la verificación. | | 6 | `SYGNA` | El remitente tiene activa una membresía de Sygna Bridge y eres localizable mediante un código de VASP de Sygna. Didit es compatible de forma nativa con el protocolo de Sygna (IVMS101 cifrado con ECIES, solicitudes de permiso firmadas) y lee tu respuesta de permiso consultando periódicamente el estado de la transferencia: su callback de Sygna todavía no está activo. | | 7 | `EMAIL` | No hay ningún canal de protocolo disponible: tu contacto de cumplimiento recibe en su lugar un [enlace de recogida por correo electrónico](#recogida-por-correo-electrónico) de un solo uso. | > [!WARNING] > > **Didit no puede recibir una respuesta de `TRUST` y todavía no acepta transferencias que se le envíen a través de una red.** > Por `TRUST`, la transferencia de un cliente de Didit te llega, pero tu respuesta no puede volver, y la transferencia expira cuando vence el plazo de confirmación del remitente en lugar de completarse. > Por `GTR`, `VERIFYVASP` y `SYGNA`, Didit lee tu respuesta en la propia red, a partir de su respuesta o consultando periódicamente el estado de la transferencia. La tabla anterior cubre las transferencias que envía un cliente de Didit. Cuando tú envías una transferencia a un cliente de Didit, Didit solo puede recibirla como una [consulta de transferencia](#post-/trp/inquiries//) `TRP`, una vez que el host TRP público de Didit esté activo (todavía no responde; consulta [Endpoints TRP](#endpoints-de-trp)), o, tras la liquidación, como un [registro sunrise](#sunrise-transferencias-liquidadas-antes-del-intercambio): hoy ninguna vía de red ni ningún canal de correo electrónico entrega una transferencia entrante a un cliente de Didit. Las vías de red (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) funcionan mediante una membresía en el lado del remitente. Hoy esa tiene que ser la propia membresía conectada del cliente de Didit: Didit todavía no tiene ninguna membresía de plataforma en ninguna de estas redes y está en proceso de incorporarse como proveedor. GTR no está incluido por defecto, y el mismo requisito de membresía se aplica a las cuatro redes. El remitente debe revisar el objeto `networks` en [Get Travel Rule Settings](https://docs.didit.me/es/management-api/travel-rule/get-settings.md): `didit` significa que la membresía de Didit incluye esa aplicación como su propio participante en la red, `own` significa una membresía conectada del cliente, `off` significa que el enrutamiento de la plataforma está desactivado y `unavailable` significa que todavía no hay nada que pueda enviar por esa red para la aplicación. Hasta que Didit tenga una membresía de plataforma, ninguna red muestra `didit`. Activar Travel Rule no activa ninguna membresía de red. Consulta [Redes de Travel Rule](https://docs.didit.me/es/transaction-monitoring/travel-rule-networks.md) para ver hasta dónde llega cada red hoy. Si estás en una de esas redes y el cliente de Didit tiene allí su propia membresía, compártele tu identificador de red y la transferencia te llegará por la red que ya utilizas. Por `SYGNA`, tu respuesta de permiso completa o rechaza la transferencia: Didit consulta el estado de la transferencia cada 5 minutos y, además, registra `https://trp.didit.me/sygna/callbacks/permission/{token}/` como callback de cada solicitud de permiso, con un token generado para esa transferencia. Ese callback está en el host TRP público de Didit, que todavía no atiende solicitudes. Un `permission_status` con valor `ACCEPTED` cambia el estado de la transferencia del remitente a `COMPLETED`, y un valor `REJECTED` lo cambia a `COUNTERPARTY_VASP_GENERAL_DECLINE`, o a `COUNTERPARTY_MISMATCHED_DATA` cuando el `reject_code` es `BVRC007` (el nombre del beneficiario no coincide). El callback necesita tu firma: responde `401` con `{"status": "INVALID_SIGNATURE"}` si no hay una firma válida, `404` para un token desconocido y `200` de nuevo para una decisión que ya aplicó. Sin ninguna membresía compartida, `TRP` es la vía con la que debes contar: comparte tu travel address con el cliente de Didit y sus transferencias llegarán a tu endpoint TRP. Una respuesta que des en la respuesta a la consulta completa o rechaza la transferencia de inmediato; una respuesta que publiques más tarde en el callback de Didit necesita el host TRP público de Didit, que todavía no está activo. Cuando ninguna de las vías puede identificarte, Didit ejecuta un paso de resolución más: la **atribución mediante análisis de blockchain**. La wallet de destino se coteja con datos de análisis de blockchain y, cuando se atribuye a tu exchange o servicio de custodia, Didit registra tu nombre en su directorio de VASP y vuelve a intentar las vías usando ese nombre. Esto significa que se te puede identificar incluso cuando el remitente no proporcionó nada más que una dirección de wallet. Las transferencias atribuidas se enrutan hacia ti automáticamente solo cuando tu entrada en el directorio incluye una ruta: un endpoint `TRP` verificado, un registro en una red o un contacto de cumplimiento (consulta [Cómo entrar en el directorio de VASP de Didit](#cómo-entrar-en-el-directorio-de-vasp-de-didit)). Por tanto, la cadena de resolución completa es: un cliente de Didit que demostró controlar la wallet (`INTERNAL`), la travel address que el remitente guardó para ella, después las vías de protocolo y de red, y por último el análisis de blockchain. ## Travel Addresses Todo VASP de Didit con la Travel Rule activada tiene una **Travel Address**: una cadena compacta que empieza por `ta` y codifica la URL de su endpoint TRP propio de consulta de transferencias. Los clientes de Didit consultan la suya en la configuración de la Travel Rule y la comparten con sus contrapartes; cuando un cliente de Didit te da la suya, tienes todo lo necesario para comunicarte con él por TRP. La codificación sigue la convención de Travel Address de TRP: * Quita el prefijo `ta`. * Decodifica el resto con Base58Check (alfabeto de Bitcoin, suma de verificación doble SHA-256). * Los bytes decodificados son la URL de consulta sin su esquema; antepón `https://`. * La URL siempre incluye el par de consulta `t=i` (tipo: consulta). Una Travel Address de Didit decodificada tiene una de estas dos formas: ``` 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 de VASP alojado: envía tus consultas de transferencia con POST a esa URL y, antes, consulta el [endpoint de identidad](#get-/trp/identity//) correspondiente para verificar con quién te estás comunicando. La segunda forma es una Travel Address **por wallet**: identifica una wallet concreta del cliente de Didit (`receiving_travel_address` en su libreta de direcciones), de modo que tu consulta llega a esa wallet sin que el cliente tenga que asociarla por número de cuenta o nombre del titular. Responde `404` en cuanto la wallet se elimina o se registra como perteneciente a otro VASP. ## Endpoints de TRP Didit utiliza la versión `3.2.1` de la API de TRP en la URL base `https://trp.didit.me`. Todos los endpoints intercambian JSON sobre HTTPS. > [!WARNING] > > El host público de TRP de Didit todavía no expone estos endpoints. Hasta que lo haga, no se puede entregar una consulta TRP ni una solicitud de identidad a un cliente de Didit; esta sección define el contrato al que se ajustará el host cuando esté activo. | Método | Ruta | Propósito | | - | - | - | | `GET` | `/identity` | Identidad del operador de la plataforma (también disponible en `/trp/identity`). | | `GET` | `/trp/identity/{profile_uuid}/` | Identidad de un perfil de VASP alojado. | | `POST` | `/trp/inquiries/{profile_uuid}/` | Envía una consulta de transferencia a un VASP alojado. | | `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | Envía una consulta de transferencia para una wallet de un VASP alojado (una travel address por wallet). | | `POST` | `/trp/callbacks/resolution/{token}/` | Resuelve una consulta que **Didit** te envió (aprobar o rechazar). | | `POST` | `/trp/callbacks/confirmation/{token}/` | Confirma o cancela una transferencia que Didit aprobó para ti. | Dos encabezados de TRP son importantes: * `api-version`: la versión del protocolo TRP que utilizas, por ejemplo `3.2.1`. Obligatorio en las consultas y en ambos callbacks. * `request-identifier`: tu identificador único de la solicitud, que se devuelve en los encabezados de la respuesta. Obligatorio en las consultas y en ambos callbacks. Una solicitud a los endpoints de consulta o de callback sin ambos encabezados devuelve `400`. Cada respuesta de Didit incluye `api-version: 3.2.1` y devuelve tu `request-identifier`. ### GET /identity Devuelve la identidad del operador de la plataforma. No se requiere ningún encabezado. ```bash theme={null} curl https://trp.didit.me/identity ``` ```json theme={null} { "name": "Didit", "lei": "", "x509": "" } ``` ### GET /trp/identity/{profile_uuid}/ Devuelve la identidad del VASP concreto con el que vas a realizar el intercambio; úsala para verificar el nombre y el LEI antes de enviar datos personales (PII). Didit realiza la misma comprobación a la inversa cuando inicia el intercambio: si la identidad que informa tu endpoint no coincide con el LEI o el nombre esperados, el intercambio se cancela. ```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": "" } ``` Devuelve `404` cuando el perfil no existe o su configuración de Travel Rule está desactivada. ### POST /trp/inquiries/{profile_uuid}/ Envía una consulta de transferencia: tú eres el VASP ordenante y el cliente de Didit es el 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 | Descripción | | - | - | - | | `asset.dti` | string | Obligatorio. El Digital Token Identifier (ISO 24165) del activo que se transfiere. Una consulta sin él responde `400`; el campo `asset.slip0044` anterior a la versión 3.2.0 no se lee. | | `amount` | number | Obligatorio. Importe entero en la unidad mínima del activo (unidades base según los decimales del DTI). Se acepta cualquier notación JSON de un número entero, incluida la forma exponencial, así como una cadena de dígitos. Una fracción, o un importe demasiado grande para registrarlo, responde `400`. | | `callback` | string | Obligatorio. URL `http(s)` pública y absoluta de tu lado donde Didit publica la resolución de la consulta (se recomienda `https`). Un reintento que repite el mismo `callback` se asocia a la consulta que repite. | | `IVMS101` | object | Obligatorio. El payload IVMS 101: `originator.originatorPersons` y `beneficiary.beneficiaryPersons` (Didit lee el primer `naturalPerson` de cada uno; los datos de personas jurídicas no se leen), además de los arrays de wallets `accountNumber`. | En este canal, los activos se identifican por DTI, y un DTI identifica un token en una única blockchain. Actualmente, Didit asigna `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) y `USDC` en nueve redes, y se irán añadiendo más activos con el tiempo. Consulta [Identificadores de activos de TRP](https://docs.didit.me/es/transaction-monitoring/travel-rule.md#identificadores-de-activos-de-trp) para ver la lista completa. Una consulta cuyo DTI Didit no reconoce se acepta igualmente y se muestra al VASP beneficiario con el DTI como código del activo. Una respuesta `200` significa que la consulta se aceptó para su procesamiento; `400` significa que faltan encabezados de TRP o que el cuerpo no es válido, `404` significa que el perfil (o la wallet de una dirección por wallet) es desconocido o está desactivado, y `422` significa que la solicitud utiliza una extensión de TRP: Didit no admite ninguna, por lo que se rechaza un encabezado `api-extensions` o una clave `extensions` en el cuerpo. Reenviar el mismo `request-identifier` es idempotente: se reutiliza la consulta original en lugar de duplicarla. A continuación, Didit crea la transferencia entrante en la aplicación del cliente y la resuelve según la libreta de direcciones de wallets y la política del cliente. Identifica al beneficiario por la wallet que indica una travel address por wallet; si no, por la primera dirección de wallet en `IVMS101.beneficiary.accountNumber`; o, si no hay ninguna, comparando el nombre de `beneficiaryPersons[0].naturalPerson` con las entradas de wallets verificadas del cliente. La respuesta `200` incluye la respuesta cuando Didit puede darla de inmediato: * `{"approved": {"address": "...", "callback": "..."}}` cuando la consulta se aprobó automáticamente. Didit no publica además esa aprobación en tu `callback`. * `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}` cuando la consulta no indica ni el beneficiario ni una dirección de wallet, así que incluye siempre ambos. * `{"version": "3.2.1"}` cuando la decisión queda a la espera del cliente de Didit. En ese caso, la **resolución** llega más tarde como un POST a tu URL de `callback`, con uno de los dos cuerpos siguientes. ```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" } ``` La aprobación puede ser automática (cuando el VASP beneficiario activa la aceptación automática y el beneficiario coincide con una entrada de wallet verificada en la cadena del activo) o producirse tras una revisión manual o una prueba de propiedad de la wallet en el lado del beneficiario, así que ten en cuenta que puede haber un retraso entre la consulta y la resolución. Una consulta nunca coincide con una wallet que el cliente de Didit haya registrado como perteneciente a otro VASP, y el nombre de tu VASP en `originatingVASP` es el nombre que el cliente de Didit ve como el VASP ordenante de la transferencia. Didit no fija ningún plazo para una consulta que envías, y un cliente de Didit que la cancela no te envía ningún rechazo, así que aplica tu propio tiempo de espera. Después de recibir una aprobación y difundir la transferencia on-chain, cierra el intercambio enviando un POST a la URL `approved.callback` que se te proporcionó: ```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" }' ``` Si cancelas la transferencia, envía en su lugar `{ "canceled": "reason" }` a la misma URL. `txid` pasa la transferencia del lado del beneficiario a `FINISHED`; `canceled` la pasa a `CANCELLED`. Ambos callbacks responden `204` una vez procesados, `404` ante un token desconocido o una transferencia que ya no está a la espera de ese callback, y `400` ante un cuerpo que no incluye ninguno de los dos campos del callback. ### Resolver las consultas que te envía Didit Cuando un cliente de Didit origina una transferencia hacia ti mediante TRP, Didit: 1. Obtiene `/identity` en la raíz del host de tu URL de consulta (`https://{your-host}/identity`) y verifica que el nombre y el LEI que devuelves coinciden con lo que espera el cliente. Cuando la ruta procede del directorio de Didit, tu `/identity` debe devolver el LEI de esa entrada del directorio. 2. Envía mediante POST una consulta de transferencia a tu URL de consulta con la misma estructura de cuerpo descrita arriba: `asset.dti`, un `amount` en unidades base como número JSON, un `callback` y el payload `IVMS101`. Solo una respuesta `2xx` cuenta como entregada. Una `3xx` se rechaza, porque no se siguen las redirecciones, y cualquier otra respuesta se registra en la cronología de la transferencia del cliente con tu código de estado, por ejemplo `refused by counterparty (HTTP 403): ...`. Ambas llamadas llevan los dos encabezados de TRP, y Didit no sigue redirecciones HTTP en ellas, así que sirve `/identity` y la URL de consulta directamente. Si `/identity` no es accesible, no devuelve ningún LEI o devuelve un LEI distinto cuando el cliente indicó uno, o devuelve un nombre que no coincide, Didit se detiene antes de enviar la consulta y la transferencia del cliente pasa a `COUNTERPARTY_VASP_NOT_REACHABLE`. Si después el POST de la consulta falla o tu endpoint responde con un estado `4xx` o `5xx`, la transferencia también pasa a `COUNTERPARTY_VASP_NOT_REACHABLE`. El `callback` de esa consulta apunta al endpoint de resolución de Didit (`/trp/callbacks/resolution/{token}/`). Responde enviando mediante POST los mismos cuerpos de resolución que usa Didit: `{ "approved": { "address": "...", "callback": "..." } }` para aprobar (tu `callback` es donde Didit enviará la confirmación on-chain), o `{ "rejected": "reason" }` para rechazar. Envía ambos encabezados de TRP con ella. Didit responde `204` una vez procesada, `404` cuando la transferencia ya no está esperando una resolución y `400` para una aprobación sin `address` o cuyo `callback` no es una URL `http(s)` pública a la que Didit vaya a llamar. Tras la aprobación, el lado de Didit pasa a `COMPLETED`; cuando el cliente informa el hash on-chain, Didit envía mediante POST `{ "txid": "..." }` al callback de confirmación que indicaste (o `{ "canceled": "reason" }` si la transferencia se cancela antes). > [!NOTE] > > Los tokens de callback son secretos destinados a un único fin, imposibles de adivinar y generados para cada transferencia: trata las URL de callback completas como confidenciales y ten en cuenta que una resolución solo se acepta mientras la transferencia sigue a la espera de ella. ## Recogida por correo electrónico Si no te llega ningún canal de protocolo y el cliente de Didit indicó tu correo electrónico de cumplimiento, Didit recurre al correo electrónico: tu contacto de cumplimiento recibe un mensaje que identifica al VASP ordenante con un enlace seguro de recogida de un solo uso. No necesitas cuenta, clave de API ni integración: el token del enlace sirve para autenticarte. Al abrir el enlace se muestra el intercambio pendiente; la API subyacente (que la página alojada invoca por ti) es 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` es el decimal almacenado tal cual, por lo que incluye los 18 decimales completos. ```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` es `accept` o `decline`; al aceptar, indica el nombre del beneficiario tal como figura en tus registros para que la parte ordenante pueda realizar su comparación de nombres, o envía tu respuesta IVMS 101 completa como `ivms_response`, cuyo nombre de beneficiario prevalece entonces. Al rechazar puedes indicar un `decline_reason` (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` u `other`) y un `decline_detail` de hasta 512 caracteres, obligatorio para `other`. Una aceptación sin `beneficiary_name` se registra como discrepancia cuando el remitente indicó un nombre de beneficiario, salvo que el remitente tenga desactivada la comparación de nombres. La respuesta es el `{"status": "..."}` resultante: `COMPLETED` cuando los nombres coinciden, `COUNTERPARTY_MISMATCHED_DATA` cuando no coinciden, o `COUNTERPARTY_VASP_GENERAL_DECLINE` tras un rechazo. Puedes responder una sola vez, mientras la transferencia espera tu respuesta: después de que respondas, después de que se cancele la transferencia o después de que venza su plazo de confirmación, ambos endpoints devuelven `410`, y un token desconocido devuelve `404`. La solicitud muestra los campos del ordenante que comparte el remitente y una `ivms_request` de IVMS 101, en el idioma de tu jurisdicción, y recibes recordatorios 72, 24 y 6 horas antes del plazo mientras no hayas respondido. ## Sunrise: transferencias liquidadas antes del intercambio Cuando una transferencia llega a la wallet de un cliente de Didit antes de que se produzca cualquier intercambio de Travel Rule (porque en ese momento no existía un canal compartido), los datos aún pueden entregarse después de la liquidación. Envía al cliente de Didit (tu contraparte beneficiaria) el payload de Travel Rule por tu canal habitual y pídele que lo registre; debe invocar [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/es/transaction-monitoring/travel-rule#registro-sunrise-posterior-al-depósito) con la cadena del depósito, el `txid`, la dirección de la wallet, el importe, la moneda y tus datos de ordenante. Incluye la identidad de tu VASP (nombre, LEI y travel address) como `originating_vasp` en ese payload, para que la transferencia del cliente de Didit registre quién envió el depósito. Permanece en esa transferencia y nunca crea ni modifica tu [entrada del directorio](#cómo-entrar-en-el-directorio-de-vasp-de-didit). El LEI debe ser un LEI válido de 20 caracteres y la travel address debe ser válida; de lo contrario, el registro se rechaza. ## Cómo entrar en el directorio de VASP de Didit Didit mantiene un directorio de VASP que utiliza el enrutamiento saliente de sus clientes. Las entradas provienen de estas fuentes: * El registro provisional MiCA de la ESMA de proveedores de servicios de criptoactivos, que se lee cada semana: tu nombre, tu LEI y tu Estado miembro de origen si figuras en él. * El directorio público de TRISA, que se lee cada semana: quién eres, tu país y tu ficha en TRISA. * El registro global de LEI, que completa tu LEI, otras denominaciones legales y tu país. * La atribución de analítica blockchain, cuando una wallet de destino se asocia a tu exchange o servicio de custodia: Didit añade tu entrada o la hace coincidir y conserva el nombre atribuido como alias. * El personal de Didit, que revisa y mantiene las entradas: identificadores de enrutamiento y registros en redes que ha verificado, contactos de cumplimiento, alias y marcas con sus entidades. Lo que un cliente de Didit indica sobre ti, como un `originating_vasp` en un registro sunrise o una travel address en una transferencia, queda en la transferencia de ese cliente y nunca modifica tu entrada. Las consultas de transferencia que envías a un cliente de Didit tampoco crean ni actualizan tu entrada. Tu entrada enruta una transferencia hacia ti cuando contiene un endpoint `TRP` verificado, un registro en una red que el remitente puede usar o un contacto de cumplimiento para la alternativa por correo electrónico. Una dirección de cumplimiento en uno de tus propios dominios que responde a una solicitud a través de su enlace de respuesta se convierte en un contacto que cualquier cliente de Didit puede usar. Mientras tu entrada no contenga una ruta, un cliente de Didit solo llega a ti con los campos que envía en cada transferencia: tu travel address, tu identificador de red (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` o `counterparty_sygna_vasp_code`) o tu correo electrónico de cumplimiento (`counterparty_vasp_email`). Para que puedan contactarte hoy, comparte tu travel address, tu identificador de red o tu correo electrónico de cumplimiento con los clientes de Didit con los que trabajas. ## Lista de comprobación para VASP de contraparte * **Ya operas TRP**: comparte tu Travel Address y tu LEI con el cliente de Didit; sus transferencias de `BTC`, `ETH` y `USDC` llegan a tu endpoint como consultas TRP estándar. Responde en la respuesta a la consulta: una respuesta posterior requiere el host TRP público de Didit, que aún no está activo. * **Estás en GTR, TRUST o VerifyVASP**: comparte tu identificador de red; las transferencias llegan por esa red cuando el cliente de Didit tiene su propia membresía en ella. Didit lee tu respuesta de GTR o VerifyVASP desde la red, pero no una de TRUST, así que publica también un endpoint TRP cuando un intercambio por TRUST tenga que concluir. [Redes de Travel Rule](https://docs.didit.me/es/transaction-monitoring/travel-rule-networks.md) indica cuándo cambiará esto. * **Estás en Sygna Bridge**: comparte tu código de VASP de Sygna; cuando el cliente de Didit tiene su propia membresía en Sygna, tu respuesta de permiso completa o rechaza la transferencia una vez que Didit la lee mediante sondeo. * **Aún no tienes un canal de protocolo**: facilita al cliente de Didit una dirección de correo electrónico de cumplimiento que supervises; recibirás enlaces para recoger la información y podrás responder desde la página alojada sin ninguna integración. * **Una transferencia ya se liquidó**: entrega los datos mediante un [registro sunrise](#sunrise-transferencias-liquidadas-antes-del-intercambio) a través del cliente de Didit. * **También quieres originar transferencias hacia VASP de Didit**: pide a tu contraparte su Travel Address, que encontrará en la configuración de Travel Rule de Didit, y sigue [POST /trp/inquiries](#post-/trp/inquiries//) cuando el host TRP público de Didit esté activo. ## Próximos pasos > [card] [Travel Rule](https://docs.didit.me/es/transaction-monitoring/travel-rule.md) > > El producto orientado al cliente: ciclo de vida, configuración, rails y la API /v3/. > [card] [Widget de propiedad de wallet](https://docs.didit.me/es/transaction-monitoring/wallet-ownership-widget.md) > > Cómo se recopilan las pruebas de propiedad del lado del beneficiario cuando se trata de una wallet sin custodia. > [card] [Registro sunrise](https://docs.didit.me/es/transaction-monitoring/travel-rule.md#registro-sunrise-posterior-al-depósito) > > Registro de datos de Travel Rule para depósitos que ya se liquidaron on-chain. > [card] [Webhooks](https://docs.didit.me/es/integration/webhooks.md) > > Cómo los clientes de Didit observan cada cambio de estado del intercambio de su lado. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.