> ## 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 del FATF: API de compliment VASP > Travel Rule del FATF amb Didit per a VASP: intercanvi de dades d'ordenant i beneficiari, seguiment i correcció. $0.02 per intercanvi. Didit executa l'intercanvi ordenant-beneficiari del GAFI i del Reglament de transferència de fons de la UE (TFR) per a transferències d'actius virtuals: busca un canal que arribi al VASP de la contrapart, negocia per aquest canal les dades requerides, fa el seguiment de l'intercanvi a través d'un cicle de vida de 13 estats i t'avisa quan l'intercanvi ha conclòs perquè puguis alliberar els fons on-chain. ## Visió general La Travel Rule del GAFI (Recomanació 16), implementada a la UE com a Reglament sobre transferències de fons, obliga un proveïdor de serveis d'actius virtuals emissor (el **VASP ordenant**) a recollir i transmetre la informació de l'ordenant i del beneficiari al proveïdor receptor (el **VASP beneficiari**) abans que una transferència d'actius virtuals es liquidi. A diferència de la majoria de jurisdiccions, el Reglament TFR de la UE s'aplica **sense cap import mínim**: totes les transferències de criptoactius entren en l'àmbit, no només les que superen un llindar de declaració. El producte Travel Rule de Didit és un intercanvi gestionat, no només un camp de dades: * Envies una transferència amb `transaction_category: "travelRule"`. * Didit prova els canals en ordre de prioritat per arribar al VASP contrapart, executa l'intercanvi sobre el primer que hi arriba i, quan l'altra part retorna un nom de beneficiari, el compara amb el que has enviat. * Només quan l'intercanvi arriba a `COMPLETED` has de difondre la transferència a la blockchain. * Després informes el hash de la transacció on-chain a Didit per tancar l'intercanvi com a `FINISHED`. Aquesta versió inclou set canals, provats en estricte ordre de prioritat: el primer que pot arribar a la contrapart guanya. | Prioritat | Canal | Funcionament | | - | - | - | | 1 | `INTERNAL` | S'utilitza quan un altre client de Didit ha demostrat el control de la cartera del beneficiari amb un missatge signat o un ingrés de prova. Didit crea una transferència entrant corresponent a l'aplicació d'aquell client i negocia l'intercanvi íntegrament dins de la plataforma, sense cap crida de xarxa externa. Immediat. | | 2 | `TRP` | Integració nativa amb el Travel Rule Protocol (TRP / OpenVASP) obert. S'utilitza quan la transferència porta una [Travel Address](#travel-addresses), l'entrada de la llibreta d'adreces de la cartera de destinació n'emmagatzema una, o el VASP contrapart es resol al [directori](#directori) amb un endpoint TRP. Porta els actius que apareixen a [Identificadors d'actius TRP](#identificadors-d’actius-trp). Didit intercanvia les dades de l'ordenant i del beneficiari de màquina a màquina, sense cap ronda de correu electrònic. | | 3 | `GTR` | Xarxa Global Travel Rule (GTR). La contrapart es resol mitjançant un `counterparty_gtr_vasp_code` explícit o una entrada del directori que en porti un. Didit llegeix la resposta de la contrapart a partir de la resposta de GTR, o consultant l'estat de la sol·licitud cada 5 minuts mentre la transferència espera. | | 4 | `TRUST` | Xarxa TRUST. La contrapart es resol mitjançant `counterparty_trust_membership_id` o una entrada del directori que en porti un. Només d'enviament: TRUST no retorna res que Didit pugui llegir, de manera que la transferència espera a `AWAITING_COUNTERPARTY` fins que caduca. | | 5 | `VERIFYVASP` | Xarxa VerifyVASP. La contrapart es resol mitjançant `counterparty_verifyvasp_id` o una entrada del directori que en porti un. Didit llegeix la resposta de la contrapart consultant l'estat de la verificació cada 5 minuts. | | 6 | `SYGNA` | Xarxa Sygna Bridge (adquirida per VerifyVASP el 2026, i encara en funcionament per als membres existents). Implementació nativa del protocol Sygna: IVMS101 xifrat amb ECIES i sol·licituds de permís signades. La contrapart es resol mitjançant `counterparty_sygna_vasp_code` o una entrada del directori que en porti un. La resposta d'acceptació o rebuig de la contrapart completa o rebutja la transferència: Didit consulta l'estat de la transferència cada 5 minuts, i també rep la resposta mitjançant el seu callback de Sygna quan l'host públic TRP de Didit estigui en funcionament. | | 7 | `EMAIL` | Alternativa que s'utilitza quan cap protocol ni xarxa arriba a la contrapart i tu n'indiques el contacte de compliment a `counterparty_vasp_email`, o l'entrada del directori de la contrapart té un [contacte de compliment](#contactes). Didit envia a aquest contacte un enllaç de recollida d'un sol ús perquè pugui confirmar o rebutjar l'intercanvi sense un compte de Didit. És la solució principal per al problema de l'arrencada (sunrise): contraparts que encara no són accessibles en cap xarxa. | Els canals de xarxa (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) necessiten una membresia de xarxa per part de l'emissor, i avui aquesta membresia **ha de ser la teva pròpia**. Connecta les credencials de la teva membresia a **Marketplace** de la consola (categoria Travel Rule networks), i les teves transferències viatjaran amb la teva pròpia identitat de xarxa. **Didit no té cap membresia de plataforma per a cap de les quatre xarxes avui, i està fent l'alta com a proveïdor en totes elles.** Fins que es completi aquesta alta, `platform_available` és `false` per a les quatre, el mode `didit` de la configuració (encaminament mitjançant la membresia de plataforma de Didit) no està disponible per a cap xarxa, i `disabled_networks` no té res per desactivar. Una membresia que connectes tu mateix sempre té prioritat sobre una membresia de plataforma. Cap membresia de xarxa s'inclou per defecte, inclosa GTR. Activar Travel Rule no activa GTR, TRUST, VerifyVASP ni Sygna. Consulta [Obtenir la configuració de Travel Rule](https://docs.didit.me/ca/management-api/travel-rule/get-settings.md) per veure els modes efectius de `networks` de la teva aplicació, i [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md) per saber a què arriba cada xarxa avui. Si les quatre informen `unavailable`, cap no pot encaminar un intercanvi: connecta la teva pròpia membresia a **Marketplace**, o utilitza una contrapart accessible per `INTERNAL`, `TRP` o `EMAIL`. En desar una membresia, el codi de participant ha de ser el teu: en desar-la, es respon amb `400` quan el codi és el codi propi de Didit en aquella xarxa, o un codi que ja té la membresia d'una altra aplicació. Una membresia GTR necessita la clau privada ed25519 (en base64), la clau pública de la qual està registrada al portal de GTR: xifra les dades personals que envies i desxifra les que reps. Una membresia VerifyVASP apunta al teu propi Enclave de VerifyVASP: la seva URL és la del teu Enclave, i el seu token és el que el teu Enclave presenta a Didit. Fins i tot amb la teva pròpia membresia, un canal de xarxa només encamina una transferència quan el seu `beneficiary_data` porta l'identificador de la contrapart en aquella xarxa (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` o `counterparty_sygna_vasp_code`), o quan l'entrada de la contrapart al directori el llista en aquella xarxa (vegeu [Rutes](#rutes)). `platform_available` indica si la membresia de plataforma està configurada, no és una comprovació de l'estat de la xarxa en directe. De la mateixa manera, `connected` vol dir que les credencials de la teva membresia estan desades i han superat la validació local; el primer intercanvi real les verifica amb la xarxa. Un mode `didit` o `own` no garanteix que la contrapart sigui accessible ni que el lliurament tingui èxit. Amb la teva pròpia membresia, Didit llegeix la resposta de la contrapart a través de `GTR`, `VERIFYVASP` i `SYGNA` a partir de la resposta de la xarxa o consultant la xarxa cada 5 minuts, cosa que completa o rebutja la transferència. `TRUST` només envia: una transferència enviada per aquesta xarxa roman a `AWAITING_COUNTERPARTY` fins que transcorre `confirmation_timeout_hours`, i després passa a `EXPIRED` i s'aplica el teu `timeout_outcome`. La recepció d'una transferència que un altre VASP t'envia per una xarxa encara no està activada, i cap intercanvi per una xarxa no s'ha completat encara contra una xarxa activa: consulta [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md). Hi ha més xarxes - CODE (l'aliança coreana), TRISA, Notabene i Veriscope - que apareixen a **Marketplace** de la consola com a fitxes de sol·licitud d'accés. Didit encara no té cap integració amb elles, de manera que avui cap transferència no pot encaminar-se per aquestes xarxes. Quan cap de les set vies no pot resoldre una contrapart, Didit fa un pas més de resolució abans de rendir-se: l'atribució mitjançant analítica de blockchain. La cartera de destinació es contrasta amb les dades d'analítica de blockchain; quan la cartera pertany a una plataforma d'intercanvi o custodi conegut, Didit registra el VASP atribuït a la transferència, l'afegeix al [directori](#directori) i torna a executar les vies una vegada amb el nou nom. Consulta [Atribució mitjançant analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain) per al comportament complet i els preus. Una transferència la destinació de la qual està [declarada com a cartera autoallotjada](#carteres-autoallotjades-declarades) omet les set vies - no hi ha cap VASP contrapart amb qui intercanviar - i passa directament a la prova de titularitat de la cartera de l'usuari final. > [!NOTE] > > Didit també opera la part de l'intercanvi orientada a la contrapart: endpoints TRP públics d'identitat i de consulta que altres VASP criden per contactar amb tu, endpoints de callback i el flux de recollida per correu electrònic. > Mai no els crides tu mateix, perquè són infraestructura gestionada, però la pàgina [Interoperabilitat de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-interoperability.md) els documenta tots perquè els VASP de la contrapart es puguin connectar amb tu. > Tu només interactues amb Travel Rule a través dels endpoints `/v3/` descrits en aquesta pàgina. ## Què s'executa quan envies una transferència Les comprovacions s'executen dins de l'única crida `POST /v3/transactions/`. Quan reps la resposta, el cribratge ja s'ha executat, la transferència està emmagatzemada i les regles ja s'han avaluat. L'intercanvi en si comença després de la resposta: Didit tria el canal i contacta la contrapart fora de la teva sol·licitud, de manera que cap xarxa ni cap contrapart no pot alentir ni fer fallar la creació. Cada canvi d'estat posterior arriba com a webhook [`travel_rule.status.updated`](#webhooks) que indica el canal, i l'objecte de transferència que retornen els endpoints de transferència Travel Rule inclou un camp [`delivery`](#lliurament-i-reintents) que mostra si el missatge ha arribat. No hi ha cap flux de treball que calgui consultar; les parts asíncrones són l'intercanvi, la resposta de la contrapart i qualsevol acció de l'usuari final. ```mermaid theme={null} sequenceDiagram autonumber participant You as Your platform participant Didit as Didit API participant CP as Counterparty VASP participant User as Your customer You->>Didit: POST /v3/transactions/ (travelRule) Note over Didit: Validate + bind subject + blocklist check Note over Didit: Device & IP enrichment Note over Didit: Crypto screening (when crypto + monitoring on) Note over Didit: Threshold check -> transfer stored (AWAITING_COUNTERPARTY) Note over Didit: Rules engine (EU TFR bundle + your rules) Didit--)You: transaction.created webhook Didit-->>You: Transaction + travel_rule.status + action_required Note over Didit: After the response: rails in priority order -> analytics attribution Didit->>CP: Exchange over the first reachable rail Didit--)You: travel_rule.status.updated (each status change) User->>Didit: Proves wallet control (when action_required) CP-->>Didit: Confirms beneficiary data Didit--)You: travel_rule.status.updated (COMPLETED) You->>You: Broadcast on-chain You->>Didit: PATCH .../travel-rule/ { payment_txn_id } Didit--)You: travel_rule.status.updated (FINISHED) ``` Pas a pas: 1. **Validació i vinculació del subjecte.** Es valida el payload. Un `transaction_id` ja utilitzat a la teva aplicació es rebutja amb `400`, i quan dues sol·licituds amb el mateix id entren en competència, una d'elles rep `409`. El `subject` es vincula al teu perfil d'usuari o d'empresa mitjançant `vendor_data`, perquè la transferència aparegui en aquest perfil per al monitoratge. Un subjecte o un `vendor_data` de contrapart que estigui a la llista de bloqueig es rebutja amb `400`, i no es crea cap transacció. Les carteres, els comptes bancaris, les IP i els dispositius a la llista de bloqueig es comproven al pas 6 i rebutgen la transacció allà, després que s'hagi executat l'encaminament. 2. **Enriquiment de dispositiu i xarxa.** Les adreces IP de les parts s'enriqueixen amb dades geogràfiques, i qualsevol context de dispositiu (automàtic en [l'enviament des de l'SDK](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md)) es normalitza al graf de dispositius, el mateix graf que alimenten les sessions KYC, de manera que "relacionats per dispositiu" funciona tant en l'alta com en les transaccions. 3. **Cribratge de criptoactius.** Per a transferències cripto amb monitoratge activat, la cartera pertinent (o el hash on-chain) se sotmet a cribratge mitjançant l'analítica de blockchain abans que s'intercanviï res: exposició a sancions, proximitat amb mescladors, fons robats. Consulta [Cribratge de criptomonedes i carteres](https://docs.didit.me/ca/transaction-monitoring/aml-screening.md). 4. **Transferència Travel Rule.** El motor d'intercanvi comprova el llindar i respecta una [declaració de cartera autoallotjada](#carteres-autoallotjades-declarades), i després emmagatzema la transferència: `NOT_APPLICABLE` per sota del teu llindar, `UNCONFIRMED_OWNERSHIP` per a una cartera autoallotjada declarada, `COMPLETED` quan l'altra cartera és la teva cartera verificada, i `AWAITING_COUNTERPARTY` en cas contrari, amb el seu canal encara buit. Cada canvi d'estat posa en cua un esdeveniment `travel_rule.status.updated`, i Didit l'envia després del `transaction.created` (pas 7). 5. **Creació de la verificació de titularitat de la cartera.** Si la transferència necessita una prova de control per part de l'usuari final i `auto_wallet_verification` està activat, es crea una sessió del [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) i es retorna a `action_required`. 6. **Avaluació de regles.** S'executa cada regla activa: el [paquet TFR de la UE](#regles-del-paquet-tfr-de-la-ue) reacciona a l'estat de la transferència establert al pas 4, les teves regles personalitzades veuen la sortida del cribratge del pas 3, i una regla pot retenir la transacció (`IN_REVIEW`), rebutjar-la o exigir una [verificació addicional](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md#accions-requerides-de-l’usuari) (`AWAITING_USER`). 7. **Facturació i notificació.** Una transacció **sortint** es factura en una sola línia: la [línia de Travel Rule](#preus) quan ha iniciat un intercanvi, i Transaction Screening en cas contrari. Una transferència entrant no porta cap de les dues tarifes, i una aplicació sandbox mai no es cobra. La resposta es retorna, i `transaction.created` s'envia a les teves destinacions de webhook, seguit dels esdeveniments `travel_rule.status.updated` del pas 4. 8. **Encaminament, després de la resposta.** Didit recorre els [set canals](#visió-general) per ordre de prioritat; si cap canal no dona resultat, [l'atribució d'analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain) identifica la contrapart i l'encaminament pels canals es torna a executar una vegada. El primer canal accessible porta l'intercanvi: la transferència roman en `AWAITING_COUNTERPARTY` en aquest canal mentre la contrapart respon, es liquida de seguida quan es troba una contrapart `INTERNAL` (`COMPLETED` o `COUNTERPARTY_MISMATCHED_DATA`), o passa a `COUNTERPARTY_VASP_NOT_FOUND` quan cap canal arriba a la contrapart. Cada canvi dispara `travel_rule.status.updated`, i les teves regles s'executen de nou cada vegada que canvien l'estat o el canal. Una transferència que l'encaminament deixa en `COUNTERPARTY_VASP_NOT_FOUND` rep en aquest moment la seva sessió del widget de titularitat de la cartera (quan `auto_wallet_verification` està activat). Llegeix-la de l'`action_required` de la transacció amb [Obtenir transacció](https://docs.didit.me/ca/management-api/transactions/get.md). ### Com cada pas correspon a les teves obligacions | Pas del procés | Obligació que cobreix | | - | - | | Dades de l'ordenant que proporciones a `originator_data` | Informació precisa de l'ordenant (FATF R.16; EU TFR Art. 14). En els canals que transporten dades de persones (`INTERNAL`, `TRP` i els canals de xarxa), Didit transmet la identitat verificada quan el subjecte és un usuari amb una verificació KYC de Didit aprovada (consulta [Dades verificades i procedència](#dades-verificades-i-procedència)), i en cas contrari exactament les `originator_data` que enviïs. | | Intercanvi a través dels canals abans de la liquidació | Informació de l'ordenant i del beneficiari transmesa a la VASP contrapart **abans** que la transferència es liquidi (FATF R.16; EU TFR Art. 14-16) | | Comparació del nom del beneficiari | Verificació que les dades del beneficiari coincideixen amb el destí (obligacions de l'Art. 16 de l'EU TFR del CASP beneficiari) | | Prova de titularitat de la cartera autoallotjada | L'obligació de la TFR de la UE sobre carteres autoallotjades: verificar la titularitat d'una adreça no custodiada en lloc d'intercanviar amb una VASP | | Cribratge de criptoactius + paquet de regles TFR de la UE | Procediments basats en el risc per a transferències amb informació absent o incompleta, i controls d'exposició a sancions | | Pas `COMPLETED` abans de la difusió | Els fons no s'alliberen fins que conclou l'intercanvi: el nucli de la regla | | Tancament `FINISHED` amb el hash on-chain + cronologia | Conservació de registres: cada transferència conserva la seva cronologia de negociació completa per a l'auditoria | > [!NOTE] > > **Nota sobre les proves.** Les aplicacions sandbox no avaluen regles ni facturen, i no envien webhooks `transaction.created` ni `transaction.status.updated`. Les transaccions sandbox es queden `APPROVED` tret que una transferència Travel Rule amb caducitat apliqui el teu `timeout_outcome`, i no es cobra res. > El motor d'intercanvi de Travel Rule també s'executa en aplicacions sandbox quan Travel Rule està activat, amb una sola contrapart: cada intercanvi **sortint** va a [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) pel canal `TEST_VASP`, que respon dins de Didit amb l'escenari que triïs, de manera que la transferència es completa, es rebutja, no coincideix, esdevé inaccessible, caduca o espera la titularitat de la cartera. > Cap missatge de compliment no arriba mai a una VASP contrapart real, i els webhooks `travel_rule.status.updated` s'entreguen amb `environment: sandbox`. > **Entrant**, la VASP de prova pot enviar-te una transferència ([Activar una transferència entrant de Test VASP](https://docs.didit.me/ca/management-api/travel-rule/trigger-test-vasp-inbound.md)), i el registre (`POST /v3/travel-rule/inbound/`) es liquida amb la teva llibreta d'adreces de carteres com en una aplicació en producció: `ON_HOLD`, `UNCONFIRMED_OWNERSHIP`, `COUNTERPARTY_MISMATCHED_DATA`, o `COMPLETED` i després `FINISHED`. > Consulta [Prova Travel Rule en sandbox](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md). ## Cicle de vida Cada transferència té un `status` que pren un dels 13 valors. L'intercanvi comença a `AWAITING_COUNTERPARTY` en el cas habitual, a `NOT_APPLICABLE` quan l'import és inferior al teu `threshold_amount` o quan una sol·licitud de pagament Lightning no indica cap beneficiari (vegeu [Lightning](#lightning)), o a `UNCONFIRMED_OWNERSHIP` quan la destinació s'ha [declarat com a cartera autoallotjada](#carteres-autoallotjades-declarades), i acaba en un dels estats finals: `FINISHED`, `CANCELLED` o `EXPIRED`. La transferència té la seva pròpia màquina d'estats, **separada de** l'estat de revisió de la transacció subjacent. Un estat d'intercanvi mai no canvia per si sol l'estat de la transacció, amb una excepció: una caducitat aplica el teu `timeout_outcome` configurat (o una [política sunrise o de no resposta](#polítiques-sunrise-i-de-contraparts-sense-resposta) quan n'hi hagi una d'aplicable). Les teves regles es tornen a executar en cada transició, de manera que les [regles de TFR de la UE](#regles-del-paquet-tfr-de-la-ue) o qualsevol regla que depengui de `travel_rule_status` poden moure la transacció, per exemple a `IN_REVIEW`. Una transferència que necessita una prova de control de la cartera per part de l'usuari final afegeix un bloc `action_required` a la transacció, però el seu `status` es manté tal com l'han deixat les teves regles. Llegeix l'estat de l'intercanvi des de `travel_rule.status`; llegeix el veredicte permetre / retenir / rebutjar des del propi `status` de la transacció. Cada transició (i cada estat informat passivament) es reflecteix també en els valors personalitzats de la transacció perquè les [regles](https://docs.didit.me/ca/transaction-monitoring/rules.md) puguin basar-se en ells: `custom_values.travel_rule_status` (estat canònic), `custom_values.travel_rule_rail` (la via per la qual s'ha dut a terme l'intercanvi; buida fins que se n'hagi seleccionat una) i `custom_values.travel_rule_regime` (derivat de la `jurisdiction` de la teva [configuració](#configuració): `SG` → `singapore`, `GB` → `uk`, i qualsevol codi de membre de la UE o de l'EEE, com `DE` o `FR`, → `eu`; els codis sense assignar s'escriuen en minúscules, per exemple `US` → `us`. Un `props.travel_rule_regime` que tu mateix envies sempre té prioritat sobre el valor derivat). | Estat | Significat | | - | - | | `AWAITING_COUNTERPARTY` | La transferència espera la contrapart: primer mentre Didit tria la via i envia l'intercanvi, just després de la creació, i després mentre la contrapart respon. El [`delivery`](#lliurament-i-reintents) de la transferència indica si el missatge ha arribat. `TRUST` només envia, de manera que una transferència que utilitza aquesta via es queda aquí fins que caduca. | | `UNCONFIRMED_OWNERSHIP` | La transferència espera una prova de control de la cartera. S'hi arriba quan la cartera de la contrapart s'ha [declarat autoallotjada](#carteres-autoallotjades-declarades) en el moment de l'enviament (sortint o entrant), o quan una transferència entrant es resol en una [entrada de la llibreta d'adreces](#llibreta-d’adreces-de-carteres) la titularitat de la qual encara no està verificada. Avança mitjançant el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) o [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera). | | `ON_HOLD` | Didit només l'estableix en transferències entrants: la cartera de destinació d'un [registre posterior al dipòsit](#registre-posterior-al-dipòsit) o d'una consulta `TRP` entrant no és a la teva [llibreta d'adreces](#llibreta-d’adreces-de-carteres), o una consulta `TRP` entrant espera la teva decisió (l'acceptació automàtica està desactivada, o la resposta automàtica no s'ha pogut lliurar). Resol-lo amb [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera). No canvia per si sol l'estat de la transacció; la [regla de la biblioteca](https://docs.didit.me/ca/transaction-monitoring/rules-library.md) activada explícitament `travel-rule-pending-action` mou aquestes transaccions a `AWAITING_USER`. | | `COMPLETED` | L'intercanvi s'ha completat amb èxit: la contrapart (o, en una transferència entrant, tu) l'ha aprovat, o les comprovacions que Didit fa en aquest camí han passat (coincidència del nom del beneficiari, prova de titularitat de la cartera). Es pot publicar la transferència a la cadena amb seguretat. | | `FINISHED` | L'intercanvi es tanca amb el hash de la seva transacció a la cadena. En una transferència sortint, informes del hash mitjançant [`PATCH .../travel-rule/`](#enviar-una-transferència). En una transferència entrant, Didit l'estableix quan el dipòsit ja s'ha liquidat ([registre posterior al dipòsit](#registre-posterior-al-dipòsit)), quan l'ordenant confirma una transferència `TRP`, o quan la part sortint `INTERNAL` finalitza. | | `CANCELLED` | Cancel·lat manualment amb `action: "cancel"` des de qualsevol estat no final, o cancel·lat per l'ordenant d'una transferència `TRP` entrant. | | `EXPIRED` | Ha transcorregut `confirmation_timeout_hours` mentre estava `AWAITING_COUNTERPARTY`. Un procés de neteja (cada 15 minuts) fa caducar la transferència i aplica el teu `timeout_outcome` configurat a la transacció subjacent: `REJECT` la rebutja, `HOLD` la mou a revisió, `PROCEED` la deixa intacta. La teva [política sunrise o de no resposta](#polítiques-sunrise-i-de-contraparts-sense-resposta) substitueix `timeout_outcome` quan n'hi hagi una d'aplicable. | | `COUNTERPARTY_MISMATCHED_DATA` | El nom del beneficiari no ha satisfet el `name_matching_strictness` configurat respecte de l'altra part: el nom que ha retornat la contrapart, o el `holder_name` de l'entrada corresponent de la llibreta d'adreces. | | `COUNTERPARTY_VASP_NOT_FOUND` | Cap de les set vies (ni el recurs de reserva d'atribució de [l'anàlisi de blockchain](#atribució-mitjançant-analítica-de-blockchain)) no ha pogut resoldre el VASP de la contrapart accessible per a aquesta transferència. Qualsevol entitat atribuïda es registra igualment a la transferència i al directori. En les transferències sortints, Didit crea automàticament una sessió del [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) (quan `auto_wallet_verification` està activat), perquè la transferència es pugui completar igualment com a transferència a cartera autoallotjada. `reason` i `next_actions` indiquen per què i què la fa avançar: vegeu [Per què es bloqueja una transferència](#per-què-una-transferència-està-bloquejada). | | `COUNTERPARTY_VASP_NOT_REACHABLE` | S'ha identificat un VASP de la contrapart però la via seleccionada no ha pogut lliurar: el seu endpoint d'identitat o de consulta `TRP` no és accessible, la identitat que ha informat no coincideix amb `counterparty_vasp_lei` ni amb `counterparty_vasp_name`, una xarxa ha rebutjat el missatge o no l'ha acceptat després de sis intents (vegeu [Lliurament i reintents](#lliurament-i-reintents)), o el proveïdor de correu ha rebutjat el correu de compliment. `reason` distingeix aquests casos i `next_actions` indica què fa avançar la transferència: vegeu [Per què es bloqueja una transferència](#per-què-una-transferència-està-bloquejada). Torna-ho a intentar amb `action: "resend"` quan sigui accessible de nou. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | La contrapart ha rebutjat l'intercanvi: ha denegat la titularitat, ha rebutjat la recollida del correu, o ha fet un rebuig `TRP` o de Sygna. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Una consulta `TRP` entrant no ha identificat el beneficiari ni pel nom ni per l'adreça, de manera que Didit no l'ha pogut associar a la teva llibreta d'adreces. Ni l'endpoint de titularitat ni `resend` accepten una transferència entrant d'aquest tipus: només pots cancel·lar-la, i cancel·lar-la no respon la consulta de la contrapart. Didit no l'estableix mai en una transferència sortint; si tu l'hi registres, `action: "resend"` torna a executar l'encaminament. | | `NOT_APPLICABLE` | La quantitat de la transferència era inferior al `threshold_amount` configurat, una sol·licitud de pagament [Lightning](#lightning) de sortida no indica cap beneficiari (`chain_details.not_applicable_reason` n'explica el motiu), o tu has registrat aquest estat tu mateix amb Travel Rule desactivada (inclosos els valors antics `UNKNOWN` i `EXEMPT`, vegeu més avall). | > [!WARNING] > > **No facis mai la difusió de la transacció abans de `COMPLETED`.** > Alliberar fons on-chain mentre una transferència està en `AWAITING_COUNTERPARTY`, `UNCONFIRMED_OWNERSHIP` o en qualsevol estat de discrepància o rebuig anul·la la finalitat de l'intercanvi. > Condiciona el pas de difusió a `status == "COMPLETED"`, i després crida `PATCH .../travel-rule/` amb el `payment_txn_id` resultant per passar a `FINISHED`. Les transicions d'un cop d'ull (`CANCELLED` també es pot assolir des de qualsevol estat no final amb `action: "cancel"`): ```mermaid theme={null} stateDiagram-v2 [*] --> NOT_APPLICABLE: below threshold [*] --> UNCONFIRMED_OWNERSHIP: self-hosted wallet declared [*] --> AWAITING_COUNTERPARTY: transfer stored, routing queued [*] --> COMPLETED: your own verified wallet [*] --> ON_HOLD: inbound with no matching wallet entry [*] --> NOT_ENOUGH_COUNTERPARTY_DATA: inbound TRP inquiry names no beneficiary AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: INTERNAL rail, verified entry, name mismatch AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_FOUND: no rail resolved AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: delivery failed AWAITING_COUNTERPARTY --> COMPLETED: counterparty confirmed, names match where checked AWAITING_COUNTERPARTY --> COUNTERPARTY_MISMATCHED_DATA: name match failed AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_GENERAL_DECLINE: counterparty declined AWAITING_COUNTERPARTY --> EXPIRED: confirmation timeout AWAITING_COUNTERPARTY --> COUNTERPARTY_VASP_NOT_REACHABLE: TRP inquiry not delivered UNCONFIRMED_OWNERSHIP --> COMPLETED: ownership proven, names match UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_MISMATCHED_DATA: name match failed UNCONFIRMED_OWNERSHIP --> COUNTERPARTY_VASP_GENERAL_DECLINE: ownership denied ON_HOLD --> COMPLETED: you confirm the wallet, names match ON_HOLD --> COUNTERPARTY_MISMATCHED_DATA: you confirm the wallet, name mismatch ON_HOLD --> COUNTERPARTY_VASP_GENERAL_DECLINE: you deny the wallet COUNTERPARTY_MISMATCHED_DATA --> COMPLETED: you approve an inbound TRP inquiry COUNTERPARTY_MISMATCHED_DATA --> COUNTERPARTY_VASP_GENERAL_DECLINE: you decline an inbound TRP inquiry COUNTERPARTY_VASP_NOT_FOUND --> COMPLETED: wallet ownership proven in the widget COUNTERPARTY_VASP_NOT_FOUND --> AWAITING_COUNTERPARTY: action resend COUNTERPARTY_VASP_NOT_REACHABLE --> AWAITING_COUNTERPARTY: action resend COMPLETED --> FINISHED: payment_txn_id reported or deposit already settled FINISHED --> [*] EXPIRED --> [*] ``` ### Lliurament i reintents Didit envia cada missatge que una transferència ha d'enviar fora de la sol·licitud que l'ha originat, i el reintenta fins que l'altra part el rep. L'objecte de transferència que retornen [Finalitza, cancel·la o reenvia](https://docs.didit.me/ca/management-api/travel-rule/update-transfer.md), [Confirma la titularitat](https://docs.didit.me/ca/management-api/travel-rule/confirm-ownership.md) i [registre sunrise](#registre-posterior-al-dipòsit) inclou l'últim missatge a `delivery`, i també ho fa l'objecte `travel_rule` incrustat de la transacció; és `null` quan la transferència mai no ha hagut d'enviar cap missatge. | Camp | Significat | | - | - | | `kind` | `SEND` (el primer missatge a la contrapart), `ANSWER` (la teva acceptació o rebuig, que espera la xarxa que ho ha sol·licitat), `TXID` (el hash on-chain, després que finalitzis la transferència), `CANCEL` (després que la cancel·lis) o `POLL` (una consulta d'estat a una xarxa que n'ofereix una, cada 5 minuts mentre la transferència espera la contrapart). | | `status` | `QUEUED`, `SENDING`, `RETRYING`, `DELIVERED` o `FAILED`. | | `rail` | La via que transporta el missatge; buit fins que Didit n'hagi triat una per a un primer missatge. | | `attempts` | Intents fets fins ara. | | `last_error` | Motiu del darrer intent fallit; buit quan cap no ha fallat. Un motiu breu que indica el pas i el tipus de fallada, per exemple `sygna permission request failed: HTTP 503` o `sygna status query failed: no answer in time`; quan GTR respon amb un error, s'hi inclouen el seu codi d'estat i el seu missatge. Mai no s'hi inclouen els cossos de les respostes. | | `next_attempt_at` | Quan s'executa el següent intent, mentre el missatge està `QUEUED` o `RETRYING`. | | `delivered_at` | Quan l'altra part ha rebut el missatge. | Una fallada de la qual la xarxa encara es pot recuperar (sense resposta a temps, una connexió fallida, HTTP `408`, `429` o `5xx`) es reintenta als 30 segons, 2 minuts, 10 minuts, 30 minuts i 1 hora. Quan un primer missatge falla definitivament (la xarxa l'ha rebutjat, o el sisè intent també ha fallat), la transferència passa a `COUNTERPARTY_VASP_NOT_REACHABLE` amb `last_error` al seu `timeline`, i pots reintentar-la amb `action: "resend"`. Qualsevol altre missatge que falli definitivament es registra al `timeline`. `delivery` mai no substitueix el `status` de la transferència: llegeix l'estat de l'intercanvi des de `status`, i fes servir `delivery` per veure per què una transferència encara està en espera. ### Valors d'estat antics Si ja enviaves `travel_rule_details.status` abans d'aquesta versió, aquests valors continuen funcionant i es converteixen automàticament. També s'accepten les variants en camelCase de qualsevol estat (per exemple `counterpartyVaspNotFound`), tant en l'enviament com en els valors de condició de [regla](https://docs.didit.me/ca/transaction-monitoring/rules.md), i es normalitzen a la forma canònica: | Valor antic | Es converteix en | | - | - | | `UNKNOWN` | `NOT_APPLICABLE` | | `COMPLIANT` | `COMPLETED` | | `PENDING_ACTION` | `ON_HOLD` | | `PENDING_COUNTERPARTY` | `AWAITING_COUNTERPARTY` | | `FAILED` | `CANCELLED` | | `EXEMPT` | `NOT_APPLICABLE` | ## Configuració Configura el perfil del teu VASP i la política de negociació una vegada per aplicació amb `GET`/`PUT /v3/travel-rule/settings/`. ```bash theme={null} curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \ -H "x-api-key: YOUR_API_KEY" ``` ```json theme={null} { "is_enabled": false, "jurisdiction": "EU", "name_matching_strictness": "DEFAULT", "confirmation_timeout_hours": 48, "timeout_outcome": "HOLD", "threshold_amount": "0.00", "inbound_auto_accept": true, "allow_self_declaration": true, "allow_screenshot_proof": true, "auto_wallet_verification": true, "vasp_attribution_enabled": true, "counterparty_screening_enabled": false, "sunrise_policy": "", "sunrise_jurisdictions": ["CO", "KH", "VN"], "non_responsive_policy": "", "legal_name": "", "lei": "", "compliance_email": "", "is_discoverable": true, "travel_address": "", "disabled_networks": [], "networks": { "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false }, "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false }, "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false }, "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false } } } ``` ```bash theme={null} curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "is_enabled": true, "legal_name": "Origin CASP SL", "jurisdiction": "EU", "name_matching_strictness": "DEFAULT", "confirmation_timeout_hours": 48, "timeout_outcome": "HOLD", "is_discoverable": true }' ``` `PUT` és una actualització parcial: envia només els camps que vols canviar. | Camp | Tipus | Descripció | | - | - | - | | `is_enabled` | boolean | Activa el flux de negociació gestionat per a les transaccions `travelRule` sortints d'aquesta aplicació. Requereix un `legal_name` no buit (ja emmagatzemat o inclòs en la mateixa sol·licitud); en cas contrari, la sol·licitud retorna `400`. | | `legal_name` | string | El nom legal del teu VASP. Es mostra a la contrapart a la pàgina de recollida per correu electrònic i es retorna al [directori de VASP](#directori). | | `lei` | string | El teu identificador d'entitat jurídica, que es retorna al directori de VASP. | | `jurisdiction` | string | El codi de la jurisdicció operativa del teu VASP, de fins a 8 caràcters (per defecte `"EU"`). | | `name_matching_strictness` | string | `NONE`, `STRICT`, `CONTAINS`, `DEFAULT` o `FUZZY`: vegeu més avall. | | `confirmation_timeout_hours` | integer | Hores que pot estar una transferència `AWAITING_COUNTERPARTY` abans de caducar automàticament. Mínim `1`, per defecte `48`. | | `timeout_outcome` | string | Què passa amb la transacció subjacent quan caduca una transferència: `HOLD` la mou a revisió, `REJECT` la rebutja, `PROCEED` deixa el seu estat sense canvis. Per defecte `HOLD`. `sunrise_policy` i `non_responsive_policy` tenen prioritat quan n'hi ha una que s'aplica. | | `sunrise_policy` | string | `HOLD`, `REJECT`, `PROCEED` o `""` (per defecte) per seguir `timeout_outcome`: què fa una transferència caducada quan la contrapart és una entrada del directori en una jurisdicció que figura a `sunrise_jurisdictions`. Vegeu [Polítiques de transició i de no resposta](#polítiques-sunrise-i-de-contraparts-sense-resposta). | | `non_responsive_policy` | string | `HOLD`, `REJECT`, `PROCEED` o `""` (per defecte) per seguir `timeout_outcome`: què fa una transferència caducada quan la contrapart és una entrada del directori amb [capacitat de resposta](#capacitat-de-resposta) `UNRESPONSIVE`. `sunrise_policy` s'aplica primer quan s'apliquen totes dues. | | `sunrise_jurisdictions` | string\[] | Només de lectura. Els països que Didit considera en un període de transició de la Travel Rule, actualment `["CO", "KH", "VN"]`. Qualsevol altra jurisdicció segueix `timeout_outcome`. | | `compliance_email` | string | Adreça de correu electrònic de contacte del responsable de compliment del teu VASP. La [xarxa de Didit](#la-xarxa-de-didit) només inclou el teu perfil quan aquesta adreça es confirma mitjançant un enllaç enviat per correu electrònic; canviar-la requereix una nova confirmació. | | `is_discoverable` | boolean | Indica si el teu perfil de VASP pot aparèixer a la [xarxa de Didit](#la-xarxa-de-didit): altres clients de Didit el poden trobar a `GET /v3/travel-rule/vasps/` i arribar-hi per la via INTERNAL. La inclusió té altres condicions; `didit_network` a la configuració indica quines falten. Per defecte `true`. | | `inbound_auto_accept` | boolean | Quan és `true`, una sol·licitud `TRP` entrant la cartera beneficiària de la qual és una entrada verificada a la teva llibreta d'adreces i el nom de la qual coincideix s'aprova automàticament. Quan és `false`, espera a `ON_HOLD` per a la teva decisió. Altres camins d'entrada no llegeixen aquesta configuració. Per defecte `true`. | | `allow_self_declaration` | boolean | Quan és `true`, el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) ofereix l'autodeclaració com a mètode de prova, i pots crear entrades de la [llibreta d'adreces de carteres](#llibreta-d’adreces-de-carteres) amb `self_declared: true`. Per defecte `true`. | | `allow_screenshot_proof` | boolean | Quan és `true`, el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) ofereix la pujada de captures de pantalla com a mètode d'evidència de titularitat. Una captura de pantalla no verifica per si sola la cartera: el teu equip de compliment la revisa i confirma la transferència. És més feble que la signatura criptogràfica; desactiva-la quan la teva política exigeixi una prova amb garanties equivalents a les d'una signatura. Per defecte `true`. | | `auto_wallet_verification` | boolean | Quan és `true`, una transferència sortint que necessita una prova de control de la cartera per part de l'usuari final crea automàticament una sessió del [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) vinculada a la transacció i la mostra al bloc `action_required` de la transacció; els SDK de Didit l'obren automàticament en l'[enviament des del client](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md). Per defecte `true`. | | `counterparty_screening_enabled` | boolean | Cribratge opcional de sancions i de mitjans adversos [de les contraparts VASP](#cribratge-de-contrapart), facturat per cribratge al preu de Cribratge AML d'empreses. Quan és `true`, Didit fa un cribratge de la contrapart a la qual arriba un intercanvi sortint quan aquest comença, reutilitzant un cribratge de menys de 30 dies. Per defecte `false`: no s'analitza ni es factura res. | | `vasp_attribution_enabled` | boolean | Quan és `true`, una transferència sortint que cap via no pot encaminar s'atribueix mitjançant [analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain): la cartera de destinació es resol fins al VASP propietari, l'entitat s'afegeix al directori i les vies s'executen una altra vegada, una sola vegada, amb el nom atribuït. Per defecte `true`. | | `threshold_amount` | string (decimal) | Import mínim de transferència que activa un intercanvi gestionat, en la moneda per defecte de la teva aplicació: Didit el compara amb l'import de la transferència convertit a aquesta moneda (o amb el `amount_in_default_currency` que enviïs), no amb l'import en la moneda pròpia de la transferència. Les transferències per sota d'aquest llindar es resolen directament com a `NOT_APPLICABLE` i mai no es negocien. Si Didit no pot convertir l'import, el llindar no s'aplica i la transferència s'intercanvia. Les aplicacions en sandbox no converteixen imports, de manera que allà el llindar només s'aplica quan envies `amount_in_default_currency`. Per defecte `0.00`, en línia amb el marc sense import mínim de la TFR de la UE, de manera que cada transferència es verifica sigui quina sigui la mida. | | `ownership_validation_mode` | string | `FULL`, `SIMPLIFIED` o `AUTOMATED`: quanta prova cal per validar la titularitat d'una cartera. Vegeu [Modes de validació de titularitat](#modes-de-validació-de-la-titularitat). Per defecte `AUTOMATED`. | | `simplified_validation_threshold` | string (decimal) | En mode `SIMPLIFIED`, una transferència per sota d'aquest import accepta una autodeclaració. Per defecte `0.00`. | | `data_sharing_fields` | object | Els camps que envies sobre els teus propis usuaris, per tipus d'entitat. Vegeu [Compartició de dades](#compartició-de-dades). | | `matching_rules` | object | Amb quin grau d'estrictesa es compara cada camp de les dades de la contrapart, per tipus d'entitat. Vegeu [Coincidència per camp](#coincidència-per-camp). | | `disabled_networks` | string\[] | Vies de xarxa (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) per les quals les teves transferències NO s'han d'encaminar mitjançant la pertinença a la plataforma de Didit. Una xarxa a la qual hagis connectat la teva pròpia pertinença (Marketplace de la consola) no es veu mai afectada per aquesta llista. Didit encara no té cap pertinença a la plataforma, de manera que la llista no té cap efecte d'encaminament avui (una via inclosa informa `mode: off`). Per defecte `[]`. | | `networks` | object | Només de lectura. Estat de cada xarxa, indexat per `gtr` / `trust` / `verifyvasp` / `sygna`: `{rail, mode, platform_available, connected}`, on `mode` és `own` (la teva pertinença connectada), `didit` (la pertinença a la plataforma de Didit, encara no disponible a cap xarxa), `off` (desactivada per tu) o `unavailable`. | | `travel_address` | string | Només de lectura. La Travel Address pròpia del teu VASP: l'endpoint codificat de consulta `TRP` entrant que altres VASP fan servir per contactar amb tu. S'omple quan activis la Travel Rule, per exemple `ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeS5uNDp3dGW3bweBWLKws442chRsyNxmmJnyWc7frxjjSeABVsYR11UuBePkw6E`. | ### Rigor de la coincidència de noms | Valor | Comportament | | - | - | | `NONE` | S'accepta qualsevol nom de beneficiari; no es fa cap comparació. | | `STRICT` | Els conjunts de tokens normalitzats dels dos noms han de ser exactament iguals. | | `CONTAINS` | Totes les paraules d'un nom apareixen a l'altre, per poques que siguin. | | `DEFAULT` | Cada token del nom més curt ha d'aparèixer al nom més llarg (coincidència de subconjunt), i el nom més curt necessita com a mínim dos tokens tret que els dos noms siguin idèntics. | | `FUZZY` | La relació de similitud de les cadenes normalitzades completes ha de ser com a mínim `0.85`. | ### Modes de validació de la titularitat `ownership_validation_mode` decideix quin grau de prova necessita la titularitat d'una cartera abans que una transferència es basi en ella: | Mode | Comportament | | - | - | | `FULL` | Sempre cal una prova: un missatge signat, un dipòsit de prova o una captura de pantalla revisada. La paraula de l'usuari final mai no compta. El widget no ofereix `SELF_DECLARATION`; iniciar-ne una respon `403`, i una entrada de la llibreta d'adreces creada amb `self_declared: true` respon `400`. | | `SIMPLIFIED` | S'accepta una autodeclaració mentre la transferència estigui per sota de `simplified_validation_threshold`; per sobre, cal una prova. Una transferència entrant (una consulta TRP, un missatge de xarxa o un dipòsit que informis) es pondera pel seu import convertit a la moneda predeterminada de la teva aplicació al tipus de canvi actual. Un actiu sense tipus de canvi, i totes les transferències d'una aplicació sandbox, compten com si estiguessin per sobre del llindar. | | `AUTOMATED` | La llibreta d'adreces i les proves anteriors de l'usuari final són suficients per si mateixes, incloses les autodeclaracions mentre `allow_self_declaration` sigui `true`. És el valor per defecte i el que feia cada aplicació abans que existissin els modes. | Una cartera es recorda per a cada usuari final un cop s'ha verificat. En `FULL` i `SIMPLIFIED`, una transferència posterior només la reutilitza quan una prova que el mode accepta per a aquella transferència la recolza. Quan `inbound_auto_accept` no té cap cartera a la llibreta d'adreces per fer coincidir, una cartera de criptomonedes que hagis registrat a les transaccions d'un únic usuari final identifica el titular. Didit afegeix aquesta cartera a la llibreta d'adreces de l'usuari final com la teva autodeclaració, verificada tret que el mode sigui `FULL`. Mai no afegeix una cartera que la llibreta d'adreces ja té registrada amb un altre nom de la mateixa cadena (`eth` i `ethereum`), inclosa una registrada com a pertanyent a un altre VASP. Les comprovacions d'adreces que altres VASP fan abans d'enviar (sobre `GTR`, `Sygna` i `VerifyVASP`) també segueixen el mode: en `FULL`, una cartera que l'usuari final només ha declarat no es reporta com a teva. ### Compartició de dades `data_sharing_fields` tria quins camps envia Didit a la contrapart sobre els teus propis usuaris, per separat per a persones físiques i empreses: ```json theme={null} { "data_sharing_fields": { "individual": ["name", "wallet_address", "address", "date_of_birth"], "company": ["name", "wallet_address", "address"] } } ``` * Les persones físiques poden compartir `name`, `wallet_address`, `address`, `national_id`, `customer_identification`, `date_of_birth` i `place_of_birth`. Les empreses fan servir els cinc primers. * `name` i `wallet_address` sempre s'envien. * Un tipus d'entitat que mai no has triat comparteix tots els camps. Una llista buida també és una elecció: comparteix només el nom i la cartera. * Un `PUT` fusiona per tipus d'entitat, de manera que enviar `individual` no modifica l'elecció `company` emmagatzemada. * Una elecció que no pot complir les obligacions de l'ordenant del teu règim `jurisdiction` (EU TFR o FATF Recommendation 16), inclosa una llista buida, es rebutja amb `400`. Els errors apareixen sota `data_sharing_fields`, indexats per tipus d'entitat. ### Coincidència per camp `matching_rules` estableix el rigor amb què es compara cada camp de les dades de la contrapart amb el que tens: ```json theme={null} { "matching_rules": { "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" }, "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" } } } ``` Cada valor és `NONE`, `STRICT`, `CONTAINS`, `DEFAULT` o `FUZZY`. Per defecte, `name` segueix `name_matching_strictness`, `date_of_birth` i `address` són `NONE`, i `account` és `STRICT`. Un camp omès conserva el seu valor per defecte, i un camp que el tipus d'entitat no compara (una empresa no té `date_of_birth`) es rebutja amb `400`. ### Llindars per jurisdicció `threshold_amount` existeix perquè l'abast de la Travel Rule varia segons el regulador. Didit té per defecte `0.00` (la posició de la UE), de manera que cada transferència s'intercanvia tret que n'augmentis el llindar de manera deliberada: | Règim | Llindar | Notes | | - | - | - | | **UE** - Reglament de transferència de fons (UE) 2023/1113 | **Sense mínim** | Cada transferència de criptomonedes de CASP a CASP és dins de l'abast. La titularitat d'una cartera autoallotjada s'ha de verificar per a les transferències superiors a EUR 1,000. | | **FATF Recommendation 16** (base global) | USD/EUR 1,000 | Per sota d'aquest import, el FATF permet un conjunt de dades reduït (noms i adreces de cartera, sense verificació). | | **Estats Units** - BSA Travel Rule | USD 3,000 | El llindar de transferència de fons de FinCEN de llarga data, aplicat a monedes virtuals convertibles. | | **Regne Unit** | Equivalent a EUR 1,000 | Informació completa per sobre; conjunt de dades reduït per sota (MLRs Part 7A). | | **Singapur** - MAS PSN02 | SGD 1,500 | Requisits reduïts per sota del llindar. | | **Suïssa** - FINMA | Sense mínim | Cal informació per a totes les transferències; s'espera una prova de titularitat per a les carteres autoallotjades. | Estableix `threshold_amount` amb la xifra del teu regulador; les transferències per sota es resolen a `NOT_APPLICABLE` sense intercanviar cap dada d'identitat. Els llindars canvien: confirma la xifra vigent amb el teu assessor de compliment en lloc de tractar aquesta taula com a assessorament legal. ### Model de dades IVMS 101 L'estàndard del sector per a les dades que s'intercanvien sota la Travel Rule és **IVMS 101** (interVASP Messaging Standard). `travel_rule_details.originator_data` i `travel_rule_details.beneficiary_data` són payloads de persona d’estil IVMS 101: Didit els envolta amb el sobre natiu de cada canal. El canal TRP intercanvia blocs `IVMS101` (`ivms101.2023`, informat al camp `ivms_version` de la transferència), el canal Sygna la seva variant IVMS xifrada amb ECIES, i els canals `GTR`, `TRUST` i `VERIFYVASP` els seus propis sobres xifrats. Així, una única estructura de payload arriba a cada contrapart en el format que espera el seu protocol. Didit llegeix aquestes claus de cada payload de persona quan construeix el missatge IVMS 101: `first_name` i `last_name` (o un únic `name` o `full_name`), `date_of_birth`, `place_of_birth`, `residence_country` (o `country`), `vendor_data` (o `customer_identification`), i `wallet_address`. Dues regles pràctiques: * **Escriptura llatina.** IVMS 101 requereix valors en escriptura llatina; translitereu els noms que estan escrits originalment en una altra escriptura. La [coincidència de noms](#rigor-de-la-coincidència-de-noms) de Didit compara conjunts de tokens normalitzats, de manera que les diferències d'ordre i de majúscules i minúscules no fan fallar un intercanvi, però sí que ho faran els sistemes d’escriptura diferents a banda i banda. * **Envieu dades que hàgiu verificat.** Quan el subjecte de `vendor_data` és un usuari amb una verificació KYC de Didit aprovada, Didit transmet la identitat verificada, no els valors que heu escrit: vegeu [Dades verificades i procedència](#dades-verificades-i-procedència). Per a qualsevol altre subjecte, Didit transmet exactament el `originator_data` que envieu, de manera que el construïu a partir de la identitat que vàreu verificar en l'alta, no a partir d'un camp de formulari no verificat. Això és el que exigeix la formulació de la FATF «informació requerida i **precisa de l’ordenant**». Al canal `INTERNAL`, l'aplicació del beneficiari també rep el `subject` que heu enviat (nom, `vendor_data`, data de naixement, país i adreça) com a contrapart de la seva transacció entrant. #### Dades verificades i procedència Quan el subjecte d'una transferència és un dels vostres usuaris, una persona amb una verificació KYC aprovada, Didit construeix aquesta part de l'intercanvi a partir de les dades verificades: * l'ordenant d'una transferència de sortida que creeu amb `POST /v3/transactions/`; * el beneficiari d'una transferència entrant que informeu amb `POST /v3/transactions/`, o amb `POST /v3/travel-rule/inbound/` quan el `holder_vendor_data` de la cartera coincident designa aquell usuari. A `POST /v3/transactions/`, ambdós casos s'apliquen a una transacció amb `transaction_category` igual a `travel_rule` mentre la Travel Rule està activada. Els noms verificats, la data i el lloc de naixement, el número i el tipus de document, l'adreça i el país de residència (a partir d'aquella adreça) tenen prioritat sobre els valors que heu enviat. Un camp que la verificació no conté conserva el vostre valor, i també ho fa una adreça completa que vàreu enviar quan l'adreça verificada no és prou completa per transmetre's. Les `metadata` de la transferència, a l'objecte `travel_rule` incrustat de la transacció, registren d'on prové cada camp i on els vostres valors difereixen: ```json theme={null} { "metadata": { "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" }, "originator_verified_differences": { "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" } } } } ``` `*_provenance` assigna a cada camp `verified` o `caller`, i `*_verified_differences` enumera cada camp on heu enviat un valor diferent del verificat, sense tenir en compte majúscules i minúscules, espais ni codis de país de dues o tres lletres. Mentre les dades d'una transferència entrant estan [emmascarades](#dades-de-la-contrapart-emmascarades), les diferències s'ometen. Didit calcula totes dues claus, de manera que les còpies d'aquestes claus, o de `name_match`, que envieu a `travel_rule_details.metadata` s'ignoren. #### Enviar IVMS 101 directament A més dels objectes plans `originator_data` i `beneficiary_data`, `travel_rule_details` (a `POST /v3/transactions/`) i `POST /v3/travel-rule/inbound/` accepten IVMS 101 genuí: * un bloc `originator` i un bloc `beneficiary`, amb `originatorPersons` o `beneficiaryPersons` que contenen un `naturalPerson` o un `legalPerson`, i `accountNumber`; * els mateixos blocs dins d'un objecte `ivms101` (o `IVMS101`); * una persona IVMS 101, o un bloc complet, com a `originator_data` o `beneficiary_data`. Cada costat accepta una persona: un `naturalPerson`, o un `legalPerson`, que fa que la part sigui una empresa. Un `originator_data` o `beneficiary_data` pla i no buit té preferència sobre un bloc del mateix costat. ```json theme={null} { "travel_rule_details": { "status": "AWAITING_COUNTERPARTY", "beneficiary": { "beneficiaryPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0xBeneficiaryWallet01"] } } } ``` Un bloc mal format retorna un error `400` amb la clau del seu camí, per exemple `{"travel_rule_details": {"originator.originatorPersons": ["must be a non-empty list of originator persons."]}}`. A `POST /v3/travel-rule/inbound/` les mateixes claus estan al nivell superior, sota `ivms101.` quan heu usat l'embolcall. #### Dades obligatòries per règim Mentre la Travel Rule està activada, una transferència de sortida igual o superior al vostre llindar ha de portar el que exigeix el seu règim, o retorna un error `400`. Només es comproven les parts que heu enviat, les dades verificades compten per a l'ordenant, i els errors apareixen sota `travel_rule_details.originator_data` o `travel_rule_details.beneficiary_data`, per exemple `"EU TFR requires the originator name."` o `"FATF Recommendation 16 requires the beneficiary wallet address."`: | Règim | Ordenant | Beneficiari | | - | - | - | | EU TFR (la vostra `jurisdiction` és un estat membre de la UE, Islàndia, Liechtenstein, Noruega, `EU` o `EEA`; `EU` és el valor per defecte) | El nom, més l'adreça, el número oficial de document i el número d'identificació de client junts, o la data i el lloc de naixement. Una empresa no disposa de l’alternativa basada en la data i el lloc de naixement. | Nom i adreça | | FATF Recommendation 16 (qualsevol altra jurisdicció, inclosa una en blanc) | El nom, més una de les opcions següents: l'adreça, el número oficial de document o el número d'identificació de client, o bé la data i el lloc de naixement junts. Una empresa no disposa de l’alternativa basada en la data i el lloc de naixement. | Nom i adreça | Per a l'ordenant, la comprovació llegeix els camps que la vostra aplicació comparteix a [`data_sharing_fields`](#compartició-de-dades), perquè són tots els que un canal envia; el beneficiari es comprova tal com l'heu enviat. Quan la transferència només compleix el règim amb un camp que no compartiu, el `400` anomena el requisit del règim i després els camps que la vostra configuració comparteix. El número oficial de document és `national_id` (o `document_number`), el número d'identificació de client és `customer_identification` (o `vendor_data`), i la data de naixement és `date_of_birth`. Un `beneficiary_data.wallet_address` buit s'omple a partir de `counterparty.payment_method.account_id` abans de la comprovació, i una retirada UTXO la sortida beneficiària de la qual Didit ha inferit de `travel_rule_details.utxo` es considera que la porta. Una transferència Lightning a la qual la Travel Rule no s'aplica no es comprova. ### Travel Addresses Una **Travel Address** és una cadena compacta i codificada que apunta a l'endpoint d'entrada de consultes `TRP` d'un VASP: mai no exposa una URL en brut ni cap adreça de cartera. Quan el Travel Rule està activat, Didit deriva el teu propi `travel_address` (que es retorna com a camp de només lectura a la configuració) perquè el puguis compartir amb altres VASP que et contactin per la via `TRP`. Cadascuna de les teves carteres de la llibreta d'adreces també rep un `receiving_travel_address` propi: una consulta enviada a aquesta adreça indica la cartera concreta, de manera que Didit no ha de trobar-la pel número de compte ni pel nom del titular. L'host públic TRP de Didit encara no respon a altres VASP, de manera que la recepció per `TRP` no està disponible fins que no ho faci: consulta [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md). Quan coneixes la Travel Address d'una contrapart, guarda-la a l'[entrada de la llibreta d'adreces de carteres](#llibreta-d’adreces-de-carteres) de destinació perquè Didit encamini les transferències d'aquell beneficiari directament per `TRP` en lloc de recórrer al correu electrònic. Didit valida les Travel Addresses que guardes en una entrada de la llibreta d'adreces de carteres o que envies a `originating_vasp`: cadascuna ha de començar per `ta` i decodificar-se en una URL de consulta que porti `t=i`, de manera que un marcador com `ta...` retorna `400`. El `beneficiary_data.travel_address` d'una transacció no es valida: si no es decodifica, s'omet el rail `TRP`. La codificació és Base58Check amb prefix `ta`: l'host i la ruta de l'endpoint (que sempre porta el parell de paràmetres de consulta `t=i`) més un checksum de quatre bytes de doble SHA-256, codificat en base58. Una adreça real té aquest aspecte i arriba a unes 100 caràcters: ```text theme={null} ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx ``` Quan Didit valida una Travel Address, un valor que no és una adreça ben formada amb checksum vàlid retorna `400` amb `"Invalid travel address."`. Obté una adreça real de la teva resposta de configuració o de la mateixa contrapart. ## Prova sense credencials de xarxa No necessites cap afiliació a GTR, TRUST, VerifyVASP ni Sygna per provar les rutes que no requereixen afiliació. Igualment necessites una clau d'API de Didit per a l'aplicació que proves. * **Sortint a la sandbox:** envia una transacció `travelRule` des d'una aplicació de sandbox. Després de les comprovacions de llindar i de cartera autoallotjada, el [VASP de prova de Didit](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) la respon dins de Didit amb l'escenari que triïs segons la cartera o el nom del beneficiari: acceptar, rebutjar, discrepància de nom, no disponible, temps d'espera o autoallotjada. Cap xarxa, correu electrònic ni cap altre client de Didit no rep res. * **Entrant a la sandbox:** fes que el VASP de prova t'enviï una transferència amb [Activa la transferència entrant de Travel Rule del VASP de prova](https://docs.didit.me/ca/management-api/travel-rule/trigger-test-vasp-inbound.md), o registra-la tu mateix amb [Registra una transferència entrant de Travel Rule](https://docs.didit.me/ca/management-api/travel-rule/register-inbound.md). Prova una cartera desconeguda, una cartera no verificada, una discrepància de nom del beneficiari i una cartera verificada que coincideixi. Aquestes proves permeten comprovar decisions d'entrada reals sense contactar amb cap xarxa. * **Dues aplicacions en producció controlades:** utilitza el rail `INTERNAL` entre dues de les teves aplicacions en producció (la que rep és localitzable i demostra el control de la cartera de destinació amb un missatge signat o un ingrés de prova), o bé una contrapart TRP controlada, per provar un intercanvi entre dues parts sense credencials d'una xarxa comercial. Les aplicacions en producció poden generar càrrecs i notificacions normals; utilitza identitats i contraparts de prova que controlis. Consulta [Prova Travel Rule a la sandbox](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) per veure tots els escenaris i el resultat exacte de cadascun. Les proves de sandbox o de protocol locals que funcionin no validen les credencials, l'afiliació ni la interoperabilitat en producció d'una xarxa comercial. Per això cal un sandbox de xarxa autoritzat o un intercanvi real controlat amb credencials d'afiliació vàlides. ## Enviar una transferència Inclou la transferència a [`POST /v3/transactions/`](https://docs.didit.me/ca/transaction-monitoring/transactions) establint `transaction_category` a `travelRule` (o `travel_rule`) i adjuntant un objecte `travel_rule_details` (àlies: `travelRule`). El bloc `travel_rule_details` en si és opcional, però en el moment que l'adjuntes, `travel_rule_details.status` és obligatori: un bloc sense aquest camp retorna `400`. Quan Travel Rule està **activat** per a la teva aplicació, Didit ignora el valor `status` que envies i gestiona l'intercanvi per si mateix: 1. Si l'import és inferior al teu `threshold_amount` configurat, la transferència es resol immediatament com a `NOT_APPLICABLE` i no es negocia res. 2. Si el mètode de pagament de la contrapart declara la destinació com a cartera autoallotjada (`payment_method.method_type: "unhosted_wallet"`), no s'intenta cap via: la transferència passa directament a `UNCONFIRMED_OWNERSHIP` i el widget de verificació de titularitat de la cartera es crea automàticament (vegeu [Carteres autoallotjades declarades](#carteres-autoallotjades-declarades)). 3. En cas contrari, les vies s'executen en ordre de prioritat, i la primera que pot arribar a la contrapart porta l'intercanvi: * `INTERNAL`: exactament un altre client de Didit té una prova de missatge signat o de dipòsit de prova per a `beneficiary_data.wallet_address`, feta després que la cartera canviés de titular per última vegada. La teva aplicació mai no compta, i quan el teu usuari final ha triat un membre de la xarxa de Didit al [widget de verificació de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md), només compta la prova d'aquest membre. L'aplicació d'aquest client és en producció (no sandbox), té Travel Rule activat i `is_discoverable` establert, i és el VASP que has indicat en enviar `counterparty_vasp_lei` o `counterparty_vasp_name`. Una cartera que només està autodeclarada, demostrada amb una captura de pantalla, no verificada o només present en una llibreta d'adreces mai no rep res per `INTERNAL`. * `TRP`: l'actiu de la transferència té un mapatge d'Identificador de Token Digital per a la xarxa de la transferència (vegeu [Identificadors d'actius TRP](#identificadors-d’actius-trp)), i el payload inclou `beneficiary_data.travel_address`, l'entrada de la llibreta d'adreces de la destinació n'emmagatzema una, o la contrapart es resol al [directori](#directori) (per `counterparty_vasp_lei` o `counterparty_vasp_name`) amb un endpoint TRP. * `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`: has connectat la teva pròpia membresia per a aquesta xarxa a **Marketplace**, i la contrapart es resol a un identificador de xarxa (camp explícit o entrada del directori: vegeu [Camps de resolució de la contrapart](#camps-de-resolució-de-la-contrapart)). Didit està completant el procés d'incorporació com a proveïdor i encara no té cap membresia de plataforma en aquestes xarxes, de manera que `disabled_networks` avui no canvia aquest pas. * `EMAIL`: s'ha proporcionat `beneficiary_data.counterparty_vasp_email`, o `counterparty_vasp_name` es resol a una entrada del directori amb un correu electrònic de compliment. 4. Si cap via no pot resoldre una contrapart, Didit executa la [cadena de descoberta de contraparts](#descoberta-de-la-contrapart). Amb `vasp_attribution_enabled` activat, això inclou l'[atribució mitjançant analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain): la cartera de destinació es resol al VASP que la posseeix, el nom atribuït s'escriu a `beneficiary_data.counterparty_vasp_name` (quan aquest camp està buit) i al [directori](#directori), i les vies es tornen a executar una vegada, de manera que una cartera atribuïda a un VASP amb una entrada al directori que inclou un endpoint TRP, un identificador de xarxa o un correu electrònic de compliment s'encamina en aquesta segona passada. 5. Si la contrapart encara no es resol, la transferència passa a `COUNTERPARTY_VASP_NOT_FOUND`. En les transferències de sortida, Didit crea automàticament el [widget de verificació de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) (quan `auto_wallet_verification` està activat) perquè la transferència pugui completar-se igualment com a transferència a una cartera autoallotjada, i pots tornar a executar l'encaminament més endavant amb `action: "resend"` quan tinguis millors dades de la contrapart. Els passos 1 i 2 es produeixen dins de la sol·licitud. Els passos 3 a 5 s'executen just després de la resposta: la transferència torna amb l'estat `AWAITING_COUNTERPARTY` amb `protocol: null`, i cada resultat arriba com a webhook [`travel_rule.status.updated`](#webhooks). ### Identificadors d'actius TRP `TRP` identifica l'actiu transferit pel seu Identificador de Token Digital (DTI) d'ISO 24165. Un DTI identifica un token en una única blockchain, de manera que un token multicadena té un DTI per xarxa. Didit envia transferències per `TRP` per a aquests actius: | Actiu | Xarxa | DTI | | - | - | - | | `BTC` | Bitcoin | `4H95J0R2X` | | `ETH` | Ethereum | `X9J9K872S` | | `USDC` | Ethereum | `CK9PW1MFH` | | `USDC` | Celo | `2ZTG3NNVB` | | `USDC` | Base | `CP6817N4B` | | `USDC` | Optimism | `898NNTPZJ` | | `USDC` | Arbitrum One | `4ZSZS1F4F` | | `USDC` | Polygon PoS | `LS71LQK3L` | | `USDC` | Avalanche C-Chain | `45J6XJX7H` | | `USDC` | Solana | `5R3XFPZSM` | | `USDC` | Plume | `N064ZKXDM` | Els identificadors de `USDC` són els que l'emissor del token publica al seu llibre blanc MiCA. Per a un token multicadena, la transferència ha d'indicar la seva xarxa a `transaction_details.crypto_params.crypto_chain` (per exemple `CELO`, `BASE`, `OP`, `ARB` o `POL`). Sense xarxa, o en una xarxa sense mapatge, la transferència no s'envia per `TRP` i Didit prova la resta de vies: primer les xarxes d'interoperabilitat i després el correu electrònic. `USDT` encara no té mapatge. Un token sense mapatge de DTI, com l'stablecoin propi d'una empresa, necessita que el seu emissor registri un DTI davant de l'autoritat de registre ISO 24165, un per token i per blockchain. Quan els DTI existeixin, contacta amb el suport de Didit amb cada DTI, la seva blockchain i els decimals del token, i Didit afegirà el mapatge. Les consultes `TRP` entrants que porten un DTI per cadena mapat es registren amb la moneda del token, l'import en els decimals del token i la xarxa. ### Descoberta de la contrapart Una transferència que porta només una adreça de cartera arriba igualment a la seva contrapart sempre que algú pugui identificar-la. Abans que una transferència de sortida es declari no encaminable, Didit pregunta, en aquest ordre, i s'atura al primer pas que indica un VASP amb una via: | Pas | Què fa | | - | - | | `internal_address_book` | Un altre client de Didit ha demostrat el control de la cartera (una signatura o un dipòsit de prova), de manera que la via `INTERNAL` li lliura. Una entrada de llibreta d'adreces no demostrada mai no compta. | | `wallet_attribution` | L'atribució de la cartera mitjançant l'analítica de blockchain, associada a un VASP del directori amb una via. Un resultat emmagatzemat es reutilitza i es cobra una sola vegada. Requereix `vasp_attribution_enabled`. | | `network_lookup` | Una xarxa de Travel Rule que respon "qui té aquesta adreça", quan la teva aplicació hi té accés. Avui només GTR n'ofereix aquesta funció, i s'executa quan el canal GTR envia. En cas contrari, el pas es registra com a `skipped` amb el motiu. | | `customer_hint` | El nom del VASP, el LEI o la jurisdicció que has enviat a `beneficiary_data`, que es fa coincidir amb un VASP del directori amb una ruta. S'arriba a un `travel_address` o a un correu electrònic de compliment pel seu propi canal. | | `end_user` | Ningú no ha indicat la contrapart, així que es pregunta a l'usuari final. Vegeu més avall. | El camp `discovery` de la transferència enumera cada pas que s'ha executat amb el seu `outcome` (`match`, `miss` o `skipped`), un `reason` llegible per màquines, el `vasp` i el `rail` que ha trobat, i una marca de temps. Un VASP que tu o l'usuari final heu triat té prioritat sobre tots els passos automàtics: la descoberta mai el substitueix per una suposició pròpia. Quan cap pas no indica una contrapart, la transferència passa a `COUNTERPARTY_VASP_NOT_FOUND`, o a `COUNTERPARTY_VASP_NOT_REACHABLE` quan s'ha indicat un VASP però cap de les seves rutes està disponible per a la teva aplicació. Després la transferència porta un `reason` (`awaiting_end_user`, `no_directory_match`, `directory_match_no_route` o `picked_member_without_proven_wallet` quan el membre que ha triat l'usuari final no ha demostrat que és el titular de la cartera) i una llista de `next_actions`: | `action` | Significat | | - | - | | `select_counterparty_vasp` | L'usuari final tria el VASP de destinació al [widget de cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md), o l'indiques tu mateix amb `{"action": "beneficiary_vasp", "beneficiary_vasp": ""}` a l'[endpoint de transferències](#enviar-una-transferència). La transferència s'encamina cap a aquest VASP i es torna a enviar. | | `declare_self_hosted` | L'usuari final declara la cartera com a autoallotjada al mateix widget. | | `add_vasp_hint` | Envia un nom de VASP, un LEI o un `travel_address` a `beneficiary_data`, i després torna a enviar la transferència. | | `update_compliance_email` | Torna a indicar el correu electrònic de compliment de la contrapart quan el primer ha estat rebutjat; consulta [Per què una transferència està bloquejada](#per-què-una-transferència-està-bloquejada). | | `resend` | Torna a executar la descoberta amb el que hagi canviat. | L'enllaç del widget és el valor de `url` de les accions que realitza l'usuari final. Quan hi ha una acció de titularitat de la cartera pendent, el bloc `action_required` de la transacció (tipus `wallet_ownership`) porta el mateix `reason` i els mateixos `next_actions`, de manera que un client que ja segueix `action_required` mostra el selector sense feina addicional. ### Camps de resolució de la contrapart Tot el que Didit sap sobre la contrapart prové de `travel_rule_details.beneficiary_data`. Aquests camps determinen la resolució del canal; tots són opcionals: | Camp | Controla | | - | - | | `wallet_address` | Coincidència a la llibreta d'adreces `INTERNAL`, cerca a la llibreta d'adreces `TRP` i els fluxos de titularitat de la cartera. Si l'omets, Didit utilitza `counterparty.payment_method.account_id`. | | `chain` | Limita les dues cerques a la llibreta d'adreces: una entrada només coincideix quan el seu `chain` és igual a aquest valor (sense distingir majúscules i minúscules) o quan l'entrada no té `chain`. Si l'omets, Didit l'omple a partir de `transaction_details.crypto_params.crypto_chain`, `custom_properties.crypto_chain` o la moneda de la transferència, en majúscules, però només quan aquest valor és una cadena que Didit reconeix (per exemple `ETH`, `BTC`, `SOL`, `TRX`); en cas contrari, la transferència no porta cadena i coincideix amb entrades de qualsevol cadena. Per a una transferència `USDT` o `USDC` sense cadena explícita, Didit l'infereix a partir d'un hash de transacció a `transaction_details.payment_reference_id` (un hash `0x` dona `ETH`). | | `memo` | L'etiqueta de destinació o memo de `wallet_address` en una xarxa amb memo. Forma part de la cartera sempre que es faci coincidir `wallet_address` (consulta [Xarxes amb memo i etiqueta](#xarxes-amb-memo-i-etiqueta)). Àlies: `destinationTag`. | | `travel_address` | Encamina directament per `TRP`: és el senyal més fort que pots enviar. | | `counterparty_vasp_lei` | Cerca al directori per LEI per a `TRP`, `GTR`, `TRUST`, `VERIFYVASP` i `SYGNA`. També es verifica creuadament amb la identitat que informa l'endpoint de TRP: una discrepància, o una identitat sense LEI, avorta l'intercanvi com a `COUNTERPARTY_VASP_NOT_REACHABLE`. | | `counterparty_vasp_name` | Cerca al directori per a `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` i `EMAIL`: el nom exacte, el mateix nom escrit d'una altra manera (`B.V.` per a `BV`, un accent) i després un àlies d'una entrada. Es verifica de manera aproximada amb la identitat de TRP quan hi són tots dos. | | `counterparty_vasp_jurisdiction` | Codi de país ISO 3166 de l'entitat receptora quan el VASP indicat és una marca amb diverses entitats regulades, o quan diverses entrades del directori comparteixen el nom; consulta [Marques i les seves entitats](#marques-i-les-seves-entitats). | | `counterparty_gtr_vasp_code` | Identificador explícit de la xarxa `GTR`: omet el directori. | | `counterparty_trust_membership_id` | Identificador explícit de la xarxa `TRUST`: omet el directori. | | `counterparty_verifyvasp_id` | Identificador explícit de la xarxa `VerifyVASP`: omet el directori. | | `counterparty_sygna_vasp_code` | Codi VASP explícit de `Sygna Bridge`: omet el directori. | | `counterparty_vasp_email` | Contacte de compliment explícit per al canal `EMAIL`: omet el directori. | ### Formes de cadena En una cadena de comptes (cadenes EVM, Solana, Tron) una transferència mou fons d'una adreça a una altra, i Didit llegeix les dues carteres directament de la transacció. Tres altres formes requereixen més informació, i el que Didit ha resolt per a elles apareix a la transferència com a `chain_details` (buit, `{}`, en una cadena de comptes). `chain_details.originator` i `chain_details.beneficiary` porten cadascun el `address`, el seu `memo` i el `source` d'on procedeix, i la coincidència i l'encaminament llegeixen primer les carteres des d'aquí. #### Transferències UTXO Una transacció de Bitcoin, Litecoin, Bitcoin Cash o Dogecoin gasta entrades de qualsevol nombre d'adreces i paga qualsevol nombre de sortides, algunes de les quals retornen el canvi a l'emissor. Envia les entrades i les sortides com a `travel_rule_details.utxo` (imports en la unitat pròpia de la moneda, com a cadenes decimals), i Didit infereix el que no declares: * **Ordenant**: `originator_data.wallet_address` quan l'envies; en cas contrari, l'adreça d'entrada que hi ha aportat més (`source: largest_input`). * **Beneficiari**: la cartera declarada; en cas contrari, l'única sortida que no retorna el pagament a una adreça d'entrada com a canvi (`only_non_change_output`); en cas contrari, la sortida que paga l'import de la transferència (`amount_match`). ```bash theme={null} curl -X POST https://verification.didit.me/v3/transactions/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "transaction_id": "btc-withdrawal-0042", "transaction_category": "travelRule", "transaction_details": { "direction": "outbound", "amount": "0.25", "currency": "BTC", "currency_kind": "crypto" }, "subject": { "vendor_data": "user-042", "full_name": "Ana Diaz" }, "counterparty": { "full_name": "Luis Perez" }, "travel_rule_details": { "status": "AWAITING_COUNTERPARTY", "beneficiary_data": { "name": "Luis Perez", "counterparty_vasp_name": "Destination Exchange" }, "utxo": { "inputs": [ { "address": "bc1qsenderhotwallet01", "amount": "0.30" }, { "address": "bc1qsendercoldwallet02", "amount": "0.05" } ], "outputs": [ { "address": "bc1qbeneficiarydeposit01", "amount": "0.25" }, { "address": "bc1qsenderhotwallet01", "amount": "0.0999" } ] } } }' ``` Aleshores la transferència porta: ```json theme={null} { "chain_details": { "chain": "BTC", "shape": "utxo", "originator": { "address": "bc1qsenderhotwallet01", "memo": "", "source": "largest_input" }, "beneficiary": { "address": "bc1qbeneficiarydeposit01", "memo": "", "source": "only_non_change_output" }, "utxo": { "inputs": [ { "address": "bc1qsenderhotwallet01", "amount": "0.300000000000000000" }, { "address": "bc1qsendercoldwallet02", "amount": "0.050000000000000000" } ], "outputs": [ { "address": "bc1qbeneficiarydeposit01", "amount": "0.250000000000000000" }, { "address": "bc1qsenderhotwallet01", "amount": "0.099900000000000000" } ], "change_output_indexes": [1], "beneficiary_output_index": 0 } } } ``` `chain_details.warnings` marca les incoherències: `declared_originator_not_an_input` (l'ordenant declarat no és una entrada), `declared_beneficiary_not_an_output` (el beneficiari declarat no és una sortida), `beneficiary_output_ambiguous` (no es podia distingir cap sortida única) i `beneficiary_output_amount_differs` (l'import de la sortida del beneficiari és diferent). `utxo` en qualsevol altra cadena és un `400`, i cada llista admet com a màxim 1.000 entrades. Un dipòsit notificat té el mateix objecte `utxo` (vegeu [Registre sunrise posterior al dipòsit](#registre-posterior-al-dipòsit)). #### Xarxes amb memo i etiqueta A XRP, Stellar (XLM), EOS, Cosmos (ATOM) i Hedera (HBAR), una plataforma d'intercanvi rep tots els seus clients en una mateixa adreça compartida i els distingeix per l'etiqueta de destinació o pel memo. Per tant, el memo forma part de la cartera: envia'l com a `payment_method.memo` al participant, o com a `memo` a `originator_data` / `beneficiary_data` (àlies `destinationTag`), i Didit compara l'adreça i el memo conjuntament. * Una entrada de la llibreta d'adreces amb memo només coincideix amb les transferències que indiquen aquell memo. Una entrada sense memo coincideix amb tota l'adreça. Una transferència que no indica cap memo mai arriba a una entrada que en té un: en una adreça compartida, un dipòsit sense la seva etiqueta no és de ningú. * Una X-address de XRP porta la seva etiqueta a dins: Didit la separa en l'adreça clàssica i l'etiqueta (`source: x_address`), de manera que una cartera registrada en qualsevol de les dues formes coincideix amb una transferència en l'altra. * Cada memo d'una adreça compartida és el seu propi mètode de pagament a la transacció. * Què accepta cada xarxa: una destination tag de XRP és un nombre enter de 0 a 4294967295 (s'accepta un número JSON); un memo de Stellar té fins a 28 bytes de text, un id de 64 bits o un hash de 32 bytes en hexadecimal; EOS admet fins a 256 bytes, Cosmos fins a 256 caràcters i Hedera fins a 100 bytes. Un memo en una cadena que no en té (Bitcoin, cadenes EVM, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning) és un `400`. #### Lightning Un pagament Lightning no té cap adreça de beneficiari on-chain: el pagador té una sol·licitud de pagament. En una transferència cripto de bitcoin o Lightning, `payment_method.account_id` pot ser aquesta sol·licitud, i Didit identifica el beneficiari a partir d'ella sense contactar amb cap xarxa: | Què envies | Beneficiari | | - | - | | Factura BOLT11 (`lnbc...`) | El node beneficiari, indicat a la factura o recuperat a partir de la seva signatura. | | Oferta o factura BOLT12 (`lno1...`, `lni1...`) | El node emissor, tret que s'amagui darrere de camins cegats. | | Lightning Address (`name@domain`) | L'adreça en si mateixa. | | Identificador de node | El node en si mateix. | | LNURL (`lnurl1...`, `lnurlp://`) | Cap: indica un servei, no un beneficiari. | El beneficiari es guarda com a compte i com a `chain_details.beneficiary` (`source: invoice_payee`), a la cadena `LIGHTNING`, i el que indica la sol·licitud es guarda a `chain_details.lightning`. Quan la sol·licitud no indica cap beneficiari, una transferència de sortida és `NOT_APPLICABLE`, amb el motiu a `chain_details.not_applicable_reason` i a la seva `timeline`: `LIGHTNING_NO_PAYEE_IDENTIFIER`, `LIGHTNING_BOLT12_BLINDED_PAYEE` o `LIGHTNING_LNURL_NAMES_NO_PAYEE`. Un valor només es llegeix com a Lightning en bitcoin, a `LIGHTNING`, o quan no s'indica cap cadena (una Lightning Address només en bitcoin o `LIGHTNING`): en qualsevol altra cadena és l'adreça pròpia d'aquella cadena. > [!NOTE] > > La via `INTERNAL` només arriba a un altre client de Didit a través d'una cartera que aquest client ha demostrat que controla amb un missatge signat o un dipòsit de prova, i aquestes proves existeixen avui per a Bitcoin, cadenes EVM, Solana i Tron. > A les xarxes amb memo, Lightning, Litecoin, Bitcoin Cash i Dogecoin, una transferència per tant mai arriba a un altre client de Didit per `INTERNAL`. > La coincidència per memo, etiqueta i Lightning continua aplicant-se a la teva pròpia llibreta d'adreces: transferències entrants, dipòsits notificats i consultes `TRP` a les teves carteres. ### Actualitzar la cartera de l'ordenant Sovint una retirada es declara des de la cartera principal del teu client i es difon des de les adreces que tenien les monedes. Registra la cartera de la qual han sortit realment els fons amb `PATCH /v3/transactions/{transaction_id}/travel-rule/`: ```bash theme={null} curl -X PATCH "https://verification.didit.me/v3/transactions/$TRANSACTION_ID/travel-rule/" \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "action": "update_originator_wallet", "wallet_address": "bc1qsendercoldwallet02" }' ``` * Només transferències de sortida, i mai una `CANCELLED` o `EXPIRED` (`409`). * Quan les entrades UTXO de la transferència són conegudes, la cartera n'ha de ser una (en cas contrari, `400`). Envia també `memo` en una xarxa amb memo. * Només canvia el registre: no es torna a enviar res a la contrapart i l'estat es manté. `chain_details.originator` passa a ser la nova cartera amb `source: updated`, la `timeline` registra la cartera anterior i la nova, i la contrapart `INTERNAL` de la transferència s'actualitza de la mateixa manera. ### Atribució mitjançant analítica de blockchain Quan només indiquis una adreça de cartera, Didit encara pot saber qui hi ha a l'altra banda. Si cap via no pot encaminar la transferència, Didit resol la cartera de destinació amb les dades d'atribució d'analítica de blockchain: la mateixa anàlisi que dona suport al [cribratge de transaccions cripto](https://docs.didit.me/ca/transaction-monitoring/aml-screening.md) sap quines carteres pertanyen a quines plataformes d'intercanvi i custodis. L'atribució només s'executa en transferències de sortida que porten alhora una cartera de destinació i un `chain` (vegeu [Camps de resolució de la contrapart](#camps-de-resolució-de-la-contrapart)); sense cadena, s'omet. Quan la cartera s'atribueix a una entitat coneguda, Didit: 1. Registra l'atribució a la transferència: `beneficiary_data.counterparty_vasp_name` s'omple (quan no l'hagis indicat tu), i les metadades de la transferència porten un bloc `vasp_attribution` amb el nom de l'entitat, el tipus d'entitat, el país i `source: "blockchain_analytics"`. 2. Afegeix l'entitat al [directori de VASP](#directori) (o coincideix amb l'entrada existent), perquè l'atribució sigui estable entre transferències. 3. Torna a executar les vies una vegada amb el nom atribuït: una entrada del directori que ja porta un endpoint TRP fa que la transferència s'encamini de seguida, en lloc d'acabar a `COUNTERPARTY_VASP_NOT_FOUND`. La crida d'atribució fa també de cribratge cripto complet: la transacció rep la sortida completa del cribratge (puntuació de risc, categoria de risc de la cartera, instantània de la xarxa), exactament com si s'hagués executat el monitoratge cripto, i `custom_values.aml_screening_trigger` de la transacció es fixa a `travel_rule_attribution`, perquè puguis veure que el cribratge es va executar perquè ho va requerir l'encaminament de Travel Rule. Quan el monitoratge cripto ja ha cribrat la mateixa cartera en aquesta transacció, es reutilitza el resultat emmagatzemat: ni una segona crida d'analítica ni un segon cobrament. L'atribució mai bloqueja la creació de la transacció: si la consulta d'analítica falla o el teu saldo no la cobreix, la transferència simplement continua cap a `COUNTERPARTY_VASP_NOT_FOUND` i no es cobra res per l'intent. Amb `action: "resend"`, una atribució registrada prèviament es reutilitza en lloc de tornar a consultar-la. Desactiva tot el pas amb `vasp_attribution_enabled: false` a la [configuració](#configuració). Consulta [Preus](#preus) per saber com es factura la crida d'atribució. Quan Travel Rule està **desactivada**, `travel_rule_details` (inclòs un `status` que tu proporcionis, de format antic o actual) es registra igualment a la transacció, però de manera passiva: no s'activa cap canal. Fes-ho servir per omplir retroactivament les dades de compliment que ja havies registrat amb el teu propi procés. Una transferència **sortint** passiva no inicia cap intercanvi, de manera que es factura com a Transaction Screening, no a la [línia de Travel Rule](#preus). Amb Travel Rule activada, aquesta sol·licitud s'encamina pel canal `EMAIL`, perquè indica el correu electrònic de compliment de la contrapart i cap canal anterior no pot arribar al beneficiari: ```bash theme={null} curl -X POST https://verification.didit.me/v3/transactions/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "transaction_id": "trv-2026-07-05-001", "transaction_category": "travelRule", "transaction_details": { "direction": "outbound", "action_type": "transfer", "amount": "0.25", "currency": "ETH", "currency_kind": "crypto" }, "subject": { "entity_type": "individual", "vendor_data": "user-042", "full_name": "Jane Doe" }, "travel_rule_details": { "status": "AWAITING_COUNTERPARTY", "originator_data": { "first_name": "Jane", "last_name": "Doe", "date_of_birth": "1990-04-12", "residence_country": "ES", "customer_identification": "user-042", "wallet_address": "0x135908330861442a814796ae99feac507925782a" }, "beneficiary_data": { "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "name": "Ana Diaz", "counterparty_vasp_email": "compliance@bene-casp.example" } } }' ``` La resposta, resumida als camps que importen aquí: ```json theme={null} { "uuid": "22222222-3333-4444-5555-666666666666", "txn_id": "trv-2026-07-05-001", "transaction_type": "travelRule", "direction": "OUTBOUND", "status": "APPROVED", "amount": "0.25", "currency": "ETH", "currency_type": "crypto", "travel_rule": { "uuid": "33333333-4444-5555-6666-777777777777", "status": "AWAITING_COUNTERPARTY", "protocol": null, "required": true, "obligations_count": 0, "originator_data": { "first_name": "Jane", "last_name": "Doe", "date_of_birth": "1990-04-12", "residence_country": "ES", "customer_identification": "user-042", "wallet_address": "0x135908330861442a814796ae99feac507925782a" }, "beneficiary_data": { "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "name": "Ana Diaz", "counterparty_vasp_email": "compliance@bene-casp.example", "chain": "ETH" }, "metadata": { "compliance_email_source": "caller_supplied" } }, "action_required": null } ``` * `originator_data` és el que has enviat, perquè el subjecte de l'exemple no té cap verificació KYC aprovada; per a un usuari verificat, Didit el construeix a partir de les dades verificades (consulta [Dades verificades i procedència](#dades-verificades-i-procedència)). El canal `EMAIL` només mostra al destinatari els camps de l'ordenant que comparteixes a [`data_sharing_fields`](#compartició-de-dades). * `beneficiary_data.chain` és `ETH` perquè la sol·licitud no indicava cap cadena, així que Didit l'ha pres de la moneda. * `status` és `APPROVED` perquè cap regla ha actuat sobre la transacció; les teves pròpies regles poden establir un altre estat. * El contacte de compliment rep l'enllaç de recollida, i la transferència es completa, falla la coincidència de noms o es rebutja quan responen, o caduca si no ho fan (consulta [Recollida per correu electrònic](#recollida-per-correu-electrònic-per-a-contraparts-inaccessibles)). `protocol` continua sent `null` perquè el canal es tria després de la resposta (per exemple `EMAIL` quan has indicat `counterparty_vasp_email`): [Obtén la transacció](https://docs.didit.me/ca/management-api/transactions/get.md) el mostra un cop triat, i cada webhook `travel_rule.status.updated` posterior el porta a `rail`. Si la cartera del beneficiari pertany a un altre client de Didit que n'ha demostrat el control, el canal `INTERNAL` liquida tot l'intercanvi just després de la resposta, i aquest webhook ja informa `COMPLETED` (o `COUNTERPARTY_MISMATCHED_DATA`). Quan el nom no coincideix, la teva transferència és `COUNTERPARTY_MISMATCHED_DATA` i l'altre client no rep res. Sense `counterparty_vasp_email`, i quan ni els canals ni [l'atribució](#atribució-mitjançant-analítica-de-blockchain) no poden arribar al beneficiari, la transferència acaba més tard en `COUNTERPARTY_VASP_NOT_FOUND` amb una acció `wallet_ownership` a la transacció. > [!NOTE] > > El bloc `travel_rule` incrustat de la transacció conté els camps propis de la transferència (`uuid`, `status`, `protocol`, `required`, `obligations_count`, `originator_data`, `beneficiary_data`, `metadata`), el que Didit ha resolt i comparat (`chain_details`, `name_match`, `data_match`, `mismatched_fields`, i els camps d'[emmascarament](#dades-de-la-contrapart-emmascarades) `data_masked` i `data_unmasked`), i els camps que indiquen en quin punt es troba: `direction`, `rail`, `counterparty_vasp`, `delivery`, `discovery`, `reason` i `next_actions` (consulta [Per què una transferència està bloquejada](#per-què-una-transferència-està-bloquejada)). > Cada fila de [`GET /v3/transactions/`](https://docs.didit.me/ca/management-api/transactions/list) porta el mateix bloc, o `null` per a una transacció sense transferència. > Els endpoints dedicats de transferència que hi ha a continuació també retornen aquests camps, més `ivms_version`, `ownership_confirmed`, `deadline_at`, `timeline` i `created_at`, però no `obligations_count` ni `metadata`. Per tancar una transferència **sortint** en estat `COMPLETED` quan ja l'has difós a la cadena: ```bash theme={null} curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}' ``` Això requereix que la transferència sigui una transferència **sortint** en estat `COMPLETED`; en cas contrari, l'API retorna `409`. Si tot va bé, tant la transferència sortint com la seva contrapartida del canal `INTERNAL` passen a `FINISHED`, i el `payment_txn_id` de la transacció es defineix amb el hash que has indicat. Al canal `TRP`, Didit també envia el hash al callback de confirmació de la contrapart. Per cancel·lar una transferència que encara no ha arribat a un estat final, envia `{"action": "cancel"}` al mateix endpoint. La contrapartida del canal `INTERNAL` també es cancel·la, i al canal `TRP`, quan la contrapart ha aprovat la consulta, Didit envia la cancel·lació al seu callback de confirmació. Una transferència ja en `FINISHED`, `CANCELLED` o `EXPIRED` retorna `409`. Una sol·licitud sense `payment_txn_id` ni cap `action` admès retorna `400`. En una transferència que ha passat per `GTR`, `VERIFYVASP` o `SYGNA`, Didit informa del hash on-chain (o de la cancel·lació) a la xarxa després de la resposta, amb els [mateixos reintents](#lliurament-i-reintents); el `delivery` de la resposta mostra aquest missatge. Per reintentar una transferència **sortint** que no ha pogut arribar a la seva contrapart (una que està en `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` o `NOT_ENOUGH_COUNTERPARTY_DATA`), millora primer les dades de la contrapart, per exemple afegint un `travel_address` a l'entrada de la cartera de destinació, un [contacte](#contactes) per a l'entrada de la contrapart al directori, o catalogant el VASP al [directori](#directori). Després envia `{"action": "resend"}` al mateix endpoint. Didit reinicia el termini de confirmació i torna a posar en cua l'escala d'encaminament des del principi, amb les dades emmagatzemades a la transferència: la resposta mostra la transferència de nou en `AWAITING_COUNTERPARTY` (amb `resend queued` al seu `timeline`), i el resultat arriba com a webhook `travel_rule.status.updated`. Un reenviament fet mentre un intent anterior encara està en curs s'envia quan aquest intent finalitza. Qualsevol altre estat, o una transferència d'entrada, retorna `409`. ```bash theme={null} curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"action": "resend"}' ``` Per indicar tu mateix la contrapart quan el [descobriment](#descoberta-de-la-contrapart) no ha pogut fer-ho, envia `{"action": "beneficiary_vasp", "beneficiary_vasp": ""}` (l'`id` de `GET /v3/travel-rule/vasps/`). La transferència s'encamina cap a aquell VASP i es torna a enviar. Només una transferència **sortint** en `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` o `NOT_ENOUGH_COUNTERPARTY_DATA` l'accepta; qualsevol altre estat retorna `409`, i un id desconegut retorna `404`. ### Per què una transferència està bloquejada Una transferència en `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE` indica per què està bloquejada i què la fa avançar, a cada lectura de la seva transacció. El bloc `travel_rule` de [`GET /v3/transactions/{transaction_id}/`](https://docs.didit.me/ca/management-api/transactions/get), del `201` de [`POST /v3/transactions/`](https://docs.didit.me/ca/management-api/transactions/create), i de cada fila de [`GET /v3/transactions/`](https://docs.didit.me/ca/management-api/transactions/list) el porta, i també l'objecte de transferència amb què respon l'[endpoint de transferència](https://docs.didit.me/ca/management-api/travel-rule/update-transfer.md): * `reason` és la causa llegible per màquina, `""` per a qualsevol altre estat. * `next_actions` enumera el que fa avançar la transferència, `[]` per a qualsevol altre estat. * `delivery` és el missatge més recent que la transferència té pendent de lliurar a l'altra part: `kind`, `status` (`QUEUED`, `SENDING`, `RETRYING`, `DELIVERED` o `FAILED`), `rail`, `attempts`, `last_error`, `next_attempt_at` i `delivered_at`, o `null` quan no n'ha tingut cap pendent. * `discovery` és on Didit ha buscat la contrapart, una entrada per cada pas que ha executat: `step`, `outcome` (`match`, `miss` o `skipped`), `reason`, `vasp`, `rail` i `at`. `email_undeliverable` i `delivery_failed` provenen d'un lliurament fallit i només apareixen a `COUNTERPARTY_VASP_NOT_REACHABLE`. Un lliurament fallit decideix primer `reason`, de manera que una contrapart que Didit sí que ha trobat mai no es notifica com una que no ha pogut trobar. Els altres quatre provenen de la traça de descoberta, en tots dos estats. | `reason` | Què ha passat | `next_actions` | | - | - | - | | `email_undeliverable` | El proveïdor de correu ha rebutjat el correu de compliment i no queda cap adreça per provar: quan s'ha enviat, en un recordatori o com a rebot permanent informat més tard. | `update_compliance_email`, després `resend` | | `delivery_failed` | La via que lliurava ha fallat de manera definitiva: una via de xarxa ha rebutjat el missatge o s'ha quedat sense reintents, un host `TRP` d'identitat no ha respost, o el host `TRP` de la contrapart no ha acceptat la consulta. | `resend` | | `awaiting_end_user` | Cap pas de descoberta ha identificat una contrapart a la qual Didit pugui arribar, així que es demana a l'usuari final que l'indiqui. | `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint`, `resend` | | `directory_match_no_route` | Un pas ha identificat una entrada del [directori](#directori), però aquesta entrada no té cap ruta que Didit pugui usar per a tu. | Igual que `awaiting_end_user` | | `picked_member_without_proven_wallet` | L'usuari final ha triat com a contrapart un altre client de Didit, però aquest client no ha demostrat el control de la cartera. | Igual que `awaiting_end_user` | | `no_directory_match` | La traça de descoberta no dona cap altre motiu. | Igual que `awaiting_end_user` | | Acció següent | Què cal fer | | - | - | | `update_compliance_email` | Torna a donar el correu electrònic de compliment de la contrapart, amb `{"action": "update_compliance_email", "compliance_email": "..."}` a l'endpoint de la transferència. | | `resend` | Torna a executar l'encaminament amb `{"action": "resend"}` quan hagi canviat alguna cosa. | | `select_counterparty_vasp` | L'usuari final tria el VASP de destinació al [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md). `url` és l'enllaç del widget mentre la transferència tingui una sessió de widget oberta. | | `declare_self_hosted` | L'usuari final declara la cartera com a autoallotjada al widget, a la mateixa `url`. | | `add_vasp_hint` | Digues a Didit qui és la contrapart, amb un nom de VASP, un LEI o una Travel Address (per exemple, un `travel_address` a l'[entrada de la llibreta d'adreces](#llibreta-d’adreces-de-carteres) de la cartera de destinació), i després reenvia. | Un reenviament fa avançar la transferència, de manera que el seu `reason` s'esborra. L'entrada de la cronologia d'una transició que ha causat un lliurament fallit porta el mateix valor sota `reason`. Si el proveïdor de correu rebutja el correu de compliment de la [transferència d'exemple de dalt](#enviar-una-transferència), el bloc `travel_rule` de la seva transacció diu, abreujat: ```json theme={null} { "uuid": "33333333-4444-5555-6666-777777777777", "status": "COUNTERPARTY_VASP_NOT_REACHABLE", "protocol": "EMAIL", "direction": "OUTBOUND", "rail": "EMAIL", "counterparty_vasp": null, "delivery": { "kind": "SEND", "status": "FAILED", "rail": "EMAIL", "attempts": 1, "last_error": "email undeliverable", "next_attempt_at": null, "delivered_at": null }, "reason": "email_undeliverable", "next_actions": [ { "action": "update_compliance_email" }, { "action": "resend" } ] } ``` Aquí `delivery` concorda amb `reason`, perquè l'enviament en si ha estat rebutjat. Un rebuig en un recordatori, o un rebot informat més tard, deixa `delivery.status` a `DELIVERED`: el primer correu sí que s'ha enviat. Per saber per què una transferència està bloquejada, llegeix `reason`, no `delivery`. Per corregir-ho, torna a donar el correu de compliment de la contrapart i després reenvia: ```bash theme={null} curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}' curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"action": "resend"}' ``` `update_compliance_email` guarda l'adreça com a `beneficiary_data.counterparty_vasp_email` d'aquesta transferència: només pertany a aquesta transferència i no s'afegeix a cap entrada del directori ni a cap llista de contactes. L'estat no canvia, la cronologia afegeix `compliance email updated`, i la transferència manté `reason: email_undeliverable` fins que el reenviament envia la sol·licitud a la nova adreça. Només una transferència de sortida en `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` o `NOT_ENOUGH_COUNTERPARTY_DATA` l'accepta; qualsevol altra transferència respon amb `409`, i un `compliance_email` que falti o tingui un format incorrecte respon amb `400`. ### Carteres autoallotjades declarades Quan el teu client t'indiqui que la destinació és la seva pròpia cartera autoallotjada (no allotjada), declara-la a la transacció en lloc de deixar que l'encaminament descobreixi que no hi ha cap VASP al darrere: estableix el tipus de mètode de pagament de la contrapart a `unhosted_wallet`. ```bash theme={null} curl -X POST https://verification.didit.me/v3/transactions/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "transaction_id": "trv-2026-07-07-002", "transaction_category": "travelRule", "transaction_details": { "direction": "outbound", "action_type": "transfer", "amount": "0.25", "currency": "ETH", "currency_kind": "crypto" }, "subject": { "entity_type": "individual", "vendor_data": "user-042", "full_name": "Jane Doe" }, "counterparty": { "entity_type": "external", "full_name": "Jane Doe", "payment_method": { "method_type": "unhosted_wallet", "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9" } }, "travel_rule_details": { "status": "AWAITING_COUNTERPARTY", "beneficiary_data": { "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9", "name": "Jane Doe" } } }' ``` La declaració salta completament l'encaminament: * No es prova cap via - no hi ha cap VASP de la contrapart amb qui fer l'intercanvi - i la transferència es crea directament en `UNCONFIRMED_OWNERSHIP`. * Quan `auto_wallet_verification` està activat (per defecte), Didit crea automàticament una sessió de [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) vinculada a la transacció i la retorna al bloc `action_required` de la transacció; els SDK l'obren automàticament durant l'[enviament des del client](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md). * Quan el client demostri el control de la cartera, es comprova la coincidència del nom del beneficiari i la transferència avança a `COMPLETED` (o a `COUNTERPARTY_MISMATCHED_DATA` si la coincidència falla). Això és l'obligació del TFR de la UE sobre carteres autoallotjades en forma d'API: verificar la titularitat de la cartera no allotjada en lloc d'intercanviar dades amb un VASP de contrapart. La declaració es llegeix del mètode de pagament del costat **de destinació** d'una transferència de sortida i del costat **d'origen** d'una d'entrada; en tots dos casos, el participant que és la contrapart. Una transferència declarada no allotjada ja segueix el seu camí final sense via, així que `UNCONFIRMED_OWNERSHIP` no és un estat reenviable: completa la prova de titularitat (o cancel·la) en lloc de cridar `action: "resend"`. ## Recepció ### Confirmació de la titularitat de la cartera Una transferència queda a `UNCONFIRMED_OWNERSHIP` en dos casos: * Una transferència entrant es resol en una entrada de la [llibreta d'adreces](#llibreta-d’adreces-de-carteres) la titularitat de la qual encara no està verificada. * La cartera de la contrapart s'ha declarat autoallotjada (`counterparty.payment_method.method_type: "unhosted_wallet"`), en una retirada sortint o en un dipòsit entrant. Consulta [Carteres autoallotjades declarades](#carteres-autoallotjades-declarades). La vostra aplicació confirma o denega la transferència: ```bash theme={null} curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"confirmed": true}' ``` El cos accepta `confirmed` (obligatori, booleà) i un `wallet_address` opcional. L'endpoint accepta una transferència en qualsevol d'aquests estats i retorna `409` amb `{"detail": "Transfer is not awaiting ownership confirmation."}` per a qualsevol altre: * `UNCONFIRMED_OWNERSHIP`, en qualsevol direcció. * `ON_HOLD` en una transferència entrant. * `UNCONFIRMED_OWNERSHIP`, `ON_HOLD` o `COUNTERPARTY_MISMATCHED_DATA` en una transferència entrant `TRP`, perquè un responsable de compliment pugui resoldre una consulta de la contrapart manualment. En una transferència que Didit ha creat per si mateix (via `INTERNAL`, registre sunrise o cartera autoallotjada declarada): * `confirmed: true` marca l'entrada corresponent de la llibreta d'adreces de carteres com a verificada pel que fa a la titularitat, i després executa la coincidència de noms amb el `holder_name` d'aquesta entrada: `COMPLETED` si la supera, `COUNTERPARTY_MISMATCHED_DATA` si no la supera. La contrapart de la via `INTERNAL`, quan n'hi ha una, rep el mateix resultat. Per a una cartera autoallotjada declarada, `confirmed: true` registra que el vostre client ha verificat qui controla la cartera de la contrapart i completa la transferència (`COMPLETED`), en sortida o en entrada. Una transferència entrant el dipòsit de la qual ja s'ha liquidat passa directament a `FINISHED`. * `confirmed: false` posa les dues parts de la transferència a `COUNTERPARTY_VASP_GENERAL_DECLINE`. * L'entrada corresponent es busca a la vostra llibreta d'adreces només per l'adreça de la cartera, sense la cadena. Resoldre una `ON_HOLD` entrant sense entrada corresponent crea l'entrada a partir del `beneficiary_data.wallet_address` de la transferència i la marca com a verificada. Una cartera autoallotjada declarada és l'excepció: la cartera es registra a la vostra llibreta d'adreces com a verificada pel que fa a la titularitat, tal com es descriu més avall. En qualsevol altre cas, una entrada que no existeix retorna `409` amb `{"detail": "wallet address entry no longer available"}`, cosa que també passa quan l'entrada s'ha suprimit. En una transferència `TRP` entrant, la mateixa crida respon a la consulta de la contrapart: * `confirmed: true` necessita una adreça de pagament per retornar, presa del `wallet_address` de la sol·licitud, després de l'entrada coincident i després del `beneficiary_data.wallet_address`. Si cap de les tres existeix, la sol·licitud retorna `400` amb `{"wallet_address": ["wallet_address is required to approve."]}`. Didit crea o verifica l'entrada, envia a la contrapart el callback de resolució de la consulta, estableix `ownership_confirmed` i mou la transferència a `COMPLETED`. * `confirmed: false` envia una resolució de rebuig i mou la transferència a `COUNTERPARTY_VASP_GENERAL_DECLINE`. * Si no es pot accedir a l'endpoint de callback de la contrapart, la sol·licitud retorna `502` i la transferència conserva l'estat actual. En una aprovació, l'entrada de la llibreta d'adreces de la cartera es crea o es marca com a verificada igualment. En una cartera autoallotjada declarada, la cartera que verifiqueu és la de la contrapart: el destí d'una retirada sortint o l'origen (la cartera de l'ordenant) d'un dipòsit entrant. Didit l'afegeix a la llibreta d'adreces de carteres com a verificada pel que fa a la titularitat amb el nom de la contrapart, de manera que la cartera es compara amb el nom de la contrapart (l'ordenant, en un dipòsit). Si la llibreta d'adreces ja conté aquesta cartera amb un altre nom de titular, la transferència passa a `COUNTERPARTY_MISMATCHED_DATA`. Si la transferència no indica cap cartera de la contrapart, passeu `wallet_address` al cos de la sol·licitud. Quan ni la transferència ni la sol·licitud aporten una adreça de cartera, la sol·licitud es rebutja amb `400`. ```json theme={null} {"confirmed": true, "wallet_address": "0xCounterpartyWallet01"} ``` * Una transferència de xarxa que ja s'ha respost a través de la seva xarxa (una transferència VerifyVASP, o una transferència GTR o Sygna Bridge ja decidida) retorna `409` (consulteu [Transferències des d'una xarxa](#transferències-des-d’una-xarxa)). La resposta és l'objecte de transferència més complet descrit més amunt. Una nova transferència `INTERNAL` mai espera aquí: només arriba a un client que ja ha demostrat que controla la cartera. Una transferència `INTERNAL` més antiga que, d'abans d'aquesta regla, encara està pendent manté ocults els detalls de l'emissor fins que demostreu el control de la cartera (un missatge signat o un dipòsit de prova), i confirmar-la retorna `409` fins que ho feu. Rebutjar-la continua funcionant. Quan la contrapart ha respost que la cartera és autoallotjada (avui, el [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) dona aquesta resposta en sandbox), confirmar afegeix la cartera a la vostra llibreta d'adreces amb el nom del beneficiari i executa la coincidència de noms: una coincidència completa la transferència i marca la cartera com a verificada. ### Transferències des d'una xarxa Didit també pot rebre transferències de Travel Rule que una contrapart envia per `GTR`, `VERIFYVASP` o `SYGNA`. La recepció l'activa Didit per a cada xarxa per separat, i **avui encara no n'hi ha cap d'activada**: també requereix que cada xarxa registri els endpoints de Didit, i Didit encara no té cap membresia en aquestes xarxes. Les transferències `TRUST` no es poden rebre. Quan una xarxa està activada, un missatge que lliura es tracta així: * **Encaminament.** El missatge arriba a la vostra aplicació quan indica el codi de participant de la vostra membresia connectada en aquesta xarxa. Un missatge adreçat a la membresia pròpia de Didit només us arriba si sou l'únic client actiu de Didit que ha demostrat el control de la cartera beneficiària. Qualsevol altra cosa es rebutja, de manera que cap client no rep mai la transferència d'un altre client. * **Decisió.** Didit crea la transferència entrant a la vostra aplicació i la decideix com una [consulta TRP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-interoperability.md#endpoints-trp): coincidència de cartera, titularitat, coincidència de noms i `inbound_auto_accept`. * **Una sola vegada.** Les xarxes tornen a enviar un missatge fins que se li respon. Una repetició rep la mateixa resposta que va rebre la primera còpia, i no es crea ni es decideix res dues vegades. * **La vostra revisió, per `GTR` i `SYGNA`.** Una transferència que us espera (`UNCONFIRMED_OWNERSHIP`, `ON_HOLD` o `COUNTERPARTY_MISMATCHED_DATA`) es decideix amb [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera): `confirmed: true` l'aprova (passeu `wallet_address` quan la transferència no n'indica cap) i `confirmed: false` la rebutja. Didit respon a la xarxa després de la resposta, amb els [mateixos reintents](#lliurament-i-reintents). Una transferència que ja s'havia respost retorna `409`. * **Cap resposta posterior per `VERIFYVASP`.** VerifyVASP pren la seva resposta quan la demana, de manera que una transferència que necessitaria la vostra revisió es rebutja de seguida i no es pot decidir més tard (`409`). ### Dades de la contrapart emmascarades Mentre no es confirmi la titularitat de la cartera, les dades personals de la contrapart en una transferència entrant es retornen emmascarades, no pas omeses. Es conserva la primera lletra de cada paraula, i la cartera, la cadena i l'encaminament del VASP continuen sent llegibles. `data_masked` és `true`, i la contrapart del detall de la transacció, de la llista i de l'exportació CSV s'emmascara de la mateixa manera. Un cop confirmada la titularitat apareixen els valors reals, i `data_unmasked` registra l'entrada d'auditoria: ```json theme={null} { "data_masked": false, "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" } } ``` `reason` és `ownership_confirmed`, `wallet_proof`, `address_book_match`, `own_verified_wallet`, `inquiry_approved` (has aprovat una consulta `TRP` o un missatge `GTR` o `Sygna`), `known_payment_method` (la cartera de l'usuari final als teus registres ha respost) o `travel_address` (el Travel Address per cartera ha anomenat la cartera). Una transferència entrant `INTERNAL` porta `data_unmasked` amb `reason: wallet_proof` des del moment en què es crea, perquè només rep dades un destinatari que ha demostrat la cartera. `actor` és el correu electrònic de l'usuari de la consola o l'etiqueta de la clau d'API, i queda en blanc per a una decisió automàtica. L'informe **Registre de transferències de la Travel Rule** (CSV i PDF) emmascara els noms d'una transferència entrant de la mateixa manera fins que es confirmi la titularitat. Els informes que presentes a un regulador, com el XML de goAML i l'informe regulatori en PDF, contenen les dades reals de la contrapart. ### Retroacció de discrepàncies Una transferència `COUNTERPARTY_MISMATCHED_DATA` ara indica els camps que difereixen. `data_match` conté la comparació i `mismatched_fields` enumera els camps. Totes dues inclouen només noms de camp i resultats, mai valors, de manera que continuen sent llegibles mentre les dades estan emmascarades: ```json theme={null} { "status": "COUNTERPARTY_MISMATCHED_DATA", "mismatched_fields": ["date_of_birth"], "data_match": { "matched": false, "mismatched_fields": ["date_of_birth"], "fields": { "name": { "result": "matched", "strictness": "DEFAULT" }, "date_of_birth": { "result": "mismatched", "strictness": "STRICT" }, "address": { "result": "not_compared", "strictness": "NONE" }, "account": { "result": "matched", "strictness": "STRICT" } } } } ``` L'entrada de la cronologia indica els camps, per exemple "la data de naixement del beneficiari no coincideix amb el titular de la cartera". Un rebuig `TRP` després d'una discrepància indica al VASP d'origen quins camps difereixen, per exemple "Les dades del beneficiari no coincideixen amb el titular de la cartera: nom". Allò que l'altre VASP pot saber és limitat intencionadament: mentre el nom sigui incorrecte, el nom és l'únic camp informat (`mismatched_fields: ["name"]`, i tots els altres com a `not_compared`), i un cop el nom coincideix, s'informa de cada camp que difereix. Això s'aplica al costat remitent d'un intercanvi `INTERNAL` i a un rebuig `TRP`. Un nom que falta a tots dos costats apareix com a `not_compared` i no és una discrepància, i un país coincideix pel que designa, de manera que `ES` i `ESP` són iguals. #### Puntuació de coincidència del nom Cada transferència en què s'ha comparat un nom porta `name_match`, i l'entrada de la cronologia que n'ha decidit el resultat porta el mateix objecte al costat del seu `detail`: ```json theme={null} { "name_match": { "score": 90, "matched": false, "method": "sequence_ratio", "strictness": "FUZZY", "compared_with": "wallet_holder", "transfer_name": "Ana Diaz", "compared_name": "Ana Diaz Garcia", "matched_names": ["Ana", "Diaz"], "mismatched_names": ["Garcia"] } } ``` * `score` és la similitud dels dos noms complets, de 0 a 100, i és `0` quan algun dels dos és buit. `matched` és el resultat segons el `strictness`, de manera que poden diferir: `FUZZY` decideix només amb la seva pròpia ràtio de similitud de `0.85`. * `matched_names` són les paraules del nom de la transferència que es troben a l'altre nom; `mismatched_names` són les paraules que un dels dos costats té i l'altre no. * `method` és `none`, `exact_token`, `token_subset`, `token_containment` o `sequence_ratio`, per als modes `NONE`, `STRICT`, `DEFAULT`, `CONTAINS` i `FUZZY`, respectivament. * `compared_with` és `wallet_holder` (el titular registrat per a la cartera) o `counterparty_vasp` (el nom que la contrapart ha indicat a la pàgina de resposta per correu electrònic, o la resposta del Didit Test VASP). * El resultat de la transferència segueix `data_match`, que compara cada camp, de manera que una transferència pot ser `COUNTERPARTY_MISMATCHED_DATA` mentre `name_match.matched` és `true`. * `name_match` és a l'objecte de transferència que retornen els endpoints de la Travel Rule i al `travel_rule` incrustat de la transacció, i és `null` fins que es compara un nom. La llista de transferències i els webhooks no el porten. * Els noms queden ocults mentre les parts estiguin [emmascarades](#dades-de-la-contrapart-emmascarades), i també a la còpia de l'altre client d'un intercanvi `INTERNAL`. ### Missatges i sol·licituds de documents Dos VASP poden resoldre una transferència en disputa dins de Didit en lloc de fer-ho per correu electrònic. `GET` i `POST /v3/transactions/{transaction_id}/travel-rule/messages/` llisten i envien missatges sobre una transferència: ```bash theme={null} curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}' ``` * `kind` és `MESSAGE` (per defecte) o `DOCUMENT_REQUEST`. Una sol·licitud de document necessita almenys una entrada a `requested_documents` (fins a 10); un missatge necessita un `body` (fins a 5000 caràcters) o un fitxer. * `reply_to` indica un missatge anterior de la mateixa transferència. Una resposta de l'altra part que porti un document satisfà la sol·licitud de document a què respon, i `fulfilled_at` s'hi estableix. La teva pròpia resposta no satisfà mai la teva pròpia sol·licitud. * Envia-ho en format multipart amb `files` per adjuntar fins a 5 fitxers de 10 MB cadascun, en PDF, PNG, JPEG o WebP. Didit comprova el contingut de cada fitxer, no només el tipus declarat, i qualsevol altre tipus de fitxer provoca una resposta `400` a `files` ("Adjunta només fitxers PDF, PNG, JPEG o WebP."). * Una transferència admet fins a 100 missatges, dels quals fins a 20 poden portar adjunts (cadascun amb fins a 5 fitxers), comptant tots dos costats; si se supera qualsevol dels dos límits, la sol·licitud respon `400`. Els fitxers adjunts als missatges no compten com a documents propis de la transacció. * Els missatges funcionen per les vies `INTERNAL` i `EMAIL`. A `INTERNAL`, l'altre client de Didit veu el missatge al seu costat del parell. A `EMAIL`, s'envia un correu electrònic a la contrapart i aquesta respon al portal de recollida. Si no es pot enviar el correu electrònic de notificació, el missatge es desa igualment i la sol·licitud respon `201`. * La sol·licitud respon `409` amb un motiu a `detail` per a una transferència per `TRP`, `GTR`, `TRUST`, `VerifyVASP` o `Sygna` (aquests protocols no porten missatges), per a una transferència sense contrapart encara, per a una transferència `INTERNAL` les dades de la qual no han coincidit amb el titular de la cartera (no ha arribat res al destinatari), per a una transferència `INTERNAL` el destinatari de la qual encara no ha demostrat el control de la cartera (en tots dos costats, fins que ho faci), per a una transferència `EMAIL` la contrapart de la qual ja no té adreça de correu electrònic de compliment, i per a una transferència `EMAIL` l'enllaç de recollida de la qual ha caducat o la transferència de la qual està tancada. * Cap webhook s'activa quan la contrapart escriu una resposta. Consulta l'endpoint de missatges. * El correu electrònic que informa la contrapart d'un nou missatge s'envia en anglès. ### Llibreta d'adreces de carteres Registra les carteres que controlis perquè les transferències entrants (per la via `INTERNAL`, les consultes `TRP` entrants i els [registres posteriors al dipòsit](#registre-posterior-al-dipòsit)) es puguin contrastar amb elles, amb `POST`/`GET /v3/travel-rule/wallet-addresses/` i `PATCH`/`DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/`. ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "ETH", "holder_name": "Ana Diaz", "holder_vendor_data": "user-042", "self_declared": true }' ``` | Camp | Tipus | Descripció | | - | - | - | | `address` | string | L'adreça. Única per aplicació, `chain` i `memo` (l'adreça es compara sense distingir majúscules i minúscules): un duplicat retorna `400`. Una adreça X de XRP s'emmagatzema com la seva adreça clàssica i la seva etiqueta. Buida en una entrada [importada pel seu hash](#importar-carteres-en-massa). | | `address_hash` | string | Només lectura. SHA-256 de l'adreça en minúscules, en hexadecimal minúscul. | | `memo` | string | Opcional. L'etiqueta de destinació o memo que forma part de la cartera en una [xarxa amb memo](#xarxes-amb-memo-i-etiqueta); buit quan la cartera s'identifica només per l'adreça completa. Àlies: `destinationTag`. | | `chain` | string | Identificador opcional de la cadena, de fins a 32 caràcters. Usa el mateix token que porten les teves transferències (per exemple `ETH` o `BTC`), o deixa-ho buit perquè coincideixi amb transferències de qualsevol cadena; vegeu la nota següent. Un beneficiari de Lightning (identificador de node o Lightning Address) registrat a bitcoin s'emmagatzema en minúscules a `LIGHTNING`, on es fan coincidir les transferències de [Lightning](#lightning). | | `holder_name` | string | Nom del titular de la cartera, usat per a la coincidència del nom del beneficiari. | | `holder_vendor_data` | string | El teu identificador intern del titular. | | `entity_type` | string | Text lliure de fins a 16 caràcters; per defecte `"individual"`. | | `travel_address` | string | Opcional. La Travel Address de la VASP contrapart per a aquesta cartera, si la coneixes. Permet que Didit encamini les transferències a aquest beneficiari pel canal `TRP` en lloc del correu electrònic. | | `receiving_travel_address` | string | Només lectura. La teva pròpia Travel Address específica d'aquesta cartera. Dona-la a una VASP que envia a aquesta cartera: la seva consulta TRP identifica directament la cartera. Buida per a una cartera registrada com a una altra VASP, mentre Travel Rule està desactivada, i abans de desar el perfil de la teva VASP. Deixa de respondre quan s'elimina la cartera. | | `is_ownership_verified` | boolean | Només lectura. Si s'ha demostrat la titularitat d'aquesta adreça (mitjançant el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) o una autodeclaració). | | `self_declared` | boolean | Només escriptura, només `POST`. Quan és `true`, l'entrada es crea ja verificada mitjançant una prova `SELF_DECLARATION`: les transferències entrants a aquesta adreça salten del tot `UNCONFIRMED_OWNERSHIP` i van directament a la coincidència de noms. Retorna `400` quan `allow_self_declaration` està desactivat a la teva configuració. | `PATCH` accepta `holder_name`, `holder_vendor_data`, `entity_type` i `travel_address`, i retorna només aquests quatre camps. `DELETE` elimina l'entrada (`204`): la seva adreça queda lliure per tornar-la a registrar i deixa de coincidir immediatament amb les noves transferències. > [!NOTE] > > La coincidència no distingeix majúscules i minúscules en l'adreça, inclou el seu `memo` en una xarxa amb memo, i es limita per `chain`. > Quan una transferència porta una cadena, una entrada només coincideix si la seva `chain` és el mateix valor (sense distingir majúscules i minúscules) o està buida. > Els noms de cadena es comparen com a text, no es tradueixen; per tant, una entrada emmagatzemada com a `ethereum` no coincideix amb una transferència la cadena de la qual és `ETH`. > Les transferències sortints prenen la cadena de `beneficiary_data.chain`, després de `transaction_details.crypto_params.crypto_chain`, després de `custom_properties.crypto_chain`, i després de la divisa (per exemple `ETH`, o per a `USDT` i `USDC` la cadena inferida de `payment_reference_id`); només s'estableix quan és una cadena que Didit reconeix. Els registres posteriors al dipòsit prenen la cadena del seu camp `chain`, en minúscules. > Les consultes `TRP` entrants no tenen en compte la cadena: coincideixen per adreça o, quan la consulta no indica cap cartera, pel nom del beneficiari contra les teves entrades verificades. > [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera) també fa coincidir només per adreça. > Quan coincideixen diverses entrades, el canal `INTERNAL` i els registres posteriors al dipòsit prefereixen una entrada amb titularitat verificada i, després, la més antiga; la cerca `TRP` sortint pren l'entrada més antiga que emmagatzema una Travel Address. > Les consultes `TRP` entrants i l'endpoint de titularitat agafen qualsevol de les entrades coincidents; per això, mantén una sola entrada per adreça quan sigui possible. > El canal `INTERNAL` no coincideix amb cap entrada quan hi ha entrades verificades per a l'adreça en més d'una altra aplicació. #### Importar carteres en massa Importa fins a 10.000 carteres en una sola crida amb [`POST /v3/travel-rule/wallet-addresses/import/`](https://docs.didit.me/ca/management-api/travel-rule/import-wallet-addresses), com a JSON (`{"entries": [...]}` o un array simple) o com a fitxer CSV en UTF-8 de com a màxim 5 MB amb una fila de capçalera. Una fila indica una cartera per la seva `address`, per `address_hash` (el SHA-256 de l'adreça en minúscules, 64 caràcters hexadecimals o 44 caràcters base64), o per totes dues, més qualsevol dels camps d'entrada anteriors. Envia només el hash per registrar una cartera sense revelar la seva adreça: coincideix amb les transferències a aquesta adreça com qualsevol altra entrada, i es pot demostrar amb el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md). ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/import/ \ -H "x-api-key: YOUR_API_KEY" \ -F "file=@wallets.csv;type=text/csv" ``` ```text theme={null} address,address_hash,chain,memo,holder_name,holder_vendor_data 0xBeneficiaryWallet01,,ethereum,,Ana Diaz,user-042 ,4f7d2e1c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e,bitcoin,,,user-043 rExchangeSharedAddress01,,XRP,104729,Ana Diaz,user-042 ``` La importació és idempotent i informa de cada fila en l'ordre enviat: `created`, `existing` (la mateixa cartera, cadena i memo ja és al registre i no s'ha modificat), `duplicate` (repeteix una fila anterior, indicada a `duplicate_of_row`) o `failed` amb els seus `errors`. Una fila incorrecta no fa fallar les altres: la resposta és `200` quan cap fila ha fallat i `207` quan n'ha fallat alguna, amb els recomptes a `total`, `created`, `existing`, `duplicate` i `failed`. Una cel·la CSV buida es considera no enviada, i les columnes que la importació no llegeix s'ignoren, de manera que una exportació d'una altra eina s'importa tal qual. A `GET /v3/travel-rule/transfers/`, cada fila porta `originator_memo` i `beneficiary_memo` al costat de les dues carteres. ### Recollida per correu electrònic per a contraparts inaccessibles Quan cap canal de protocol pot arribar a la contrapart, Didit recorre a `EMAIL`: envia un enllaç de recollida d'un sol ús a `beneficiary_data.counterparty_vasp_email` (o a un correu electrònic obtingut a partir de `beneficiary_data.counterparty_vasp_name` mitjançant el registre del directori de VASP). El destinatari no necessita un compte de Didit ni una clau d'API: el token de l'enllaç és l'autenticació. Així es fa l'enviament de la petició: * **Als destinataris correctes.** Un `counterparty_vasp_email` que passes és l'únic destinatari. En cas contrari, Didit escriu com a màxim a tres adreces: els [contactes](#contactes) de la contrapart que no han rebotat (primer els teus i després els de la plataforma; dins de cada grup, primer els que han respost anteriorment), i després el correu de compliment de l'entrada del directori quan queda un espai lliure. Cada adreça rep el seu propi correu. * **En el teu nom.** El correu surt de l'adreça de Didit com a "*el teu nom legal* via Didit", en l'idioma de la jurisdicció de la contrapart (anglès quan no es coneix), i l'enllaç obre la pàgina de resposta en aquest idioma. No reps cap còpia: segueix la cronologia de la transferència. * **Amb recordatoris.** Fins que la contrapart respongui, Didit li envia recordatoris 72, 24 i 6 hores abans del termini, com a mínim 12 hores després de la petició o de l'últim recordatori, i mai després del termini. * **Amb els rebots gestionats.** Un rebot o una queixa de correu brossa marca com a no vàlid el contacte al qual ha arribat, amb el seu motiu, i la cronologia de la transferència ho registra. Un contacte de la plataforma queda llavors no vàlid per a tots els clients de Didit; el contacte de la teva aplicació, només per a la teva aplicació. Quan el servei d'enviament de correu de Didit deixa completament d'enviar a una adreça (després d'un rebot permanent, una queixa de correu brossa o una baixa), tots els contactes d'aquesta adreça es marquen com a no vàlids (`suppressed`), i aquests contactes tornen a ser vàlids quan es reprèn l'enviament a l'adreça. Quan no queda cap adreça on escriure, la transferència passa a `COUNTERPARTY_VASP_NOT_REACHABLE` amb el motiu del servidor de correu receptor a la seva cronologia. Un rebot permanent o una queixa de correu brossa sobre el `counterparty_vasp_email` que vas passar fan això de seguida, perquè és l'únic destinatari; un rebot temporal (`soft_bounce`) en aquest, o en el correu de compliment de l'entrada del directori, deixa la petició oberta per als recordatoris. L'enllaç obre una pàgina allotjada que mostra l'intercanvi pendent i crida aquests dos endpoints públics per al destinatari. Per a la [transferència d'exemple anterior](#enviar-una-transferència), els detalls de recollida són: ```bash theme={null} curl https://verification.didit.me/v3/travel-rule/pickup/{token}/ ``` ```json theme={null} { "reference": "33333333-4444-5555-6666-777777777777", "requested_at": "2026-07-05T10:00:00Z", "originator_vasp_name": "Origin CASP SL", "originator_vasp_lei": "529900EXAMPLEORIG001", "recipient_vasp_name": "Example Counterparty VASP", "language": "es", "amount": "0.250000000000000000", "currency": "ETH", "fiat_amount": "", "fiat_currency": "", "chain": "ETH", "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "status": "AWAITING_COUNTERPARTY", "ivms_version": "ivms101.2023", "deadline_at": "2026-07-07T10:00:00Z", "reminders_sent": 0, "contact": "", "decline_reasons": ["data_mismatch", "not_our_customer", "wallet_not_hosted", "sanctions", "risk_appetite", "jurisdiction", "insufficient_data", "other"], "join_invitation": { "eligible": false, "url": "" }, "originator_data": { "name": "Jane Doe", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" }, "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb" }, "ivms_request": { "originator": { "originatorPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Doe", "secondaryIdentifier": "Jane", "nameIdentifierType": "LEGL" }] } } }], "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"] }, "beneficiary": { "beneficiaryPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }], "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"] } }, "data_masked": false } ``` `reference` és el `uuid` de la transferència. `originator_data` i el `ivms_request` IVMS 101 que se'n construeix només porten els camps de l'ordenant que comparteixes a [`data_sharing_fields`](#compartició-de-dades); el nom i la cartera sempre s'hi inclouen. `fiat_amount` i `fiat_currency` estan buits quan no has enviat cap valor convertit, `contact` repeteix el valor de `?contact=` de l'enllaç, i `decline_reasons` enumera els valors que accepta `decline_reason`. `join_invitation.eligible` és `true` mentre la contrapart tingui una invitació vigent per unir-se a Didit; l'enllaç d'invitació només viatja al correu electrònic. Aquest endpoint retorna l'import emmagatzemat tal qual, amb les 18 xifres decimals completes en lloc de la forma retallada que usa l'objecte de detall de la transacció. ```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 cas d'`accept`, el `beneficiary_name` indicat es compara amb `beneficiary_data.name` de la transferència segons la teva regla de noms: `COMPLETED` si coincideixen, `COUNTERPARTY_MISMATCHED_DATA` en cas contrari. La contrapart pot enviar una resposta IVMS 101 completa com a `ivms_response`; el nom del beneficiari que hi consta té preferència sobre `beneficiary_name`. En cas de `decline`, la transferència passa a `COUNTERPARTY_VASP_GENERAL_DECLINE`. La contrapart pot indicar un `decline_reason` de `decline_reasons`, amb un `decline_detail` (fins a 512 caràcters, obligatori per a `other`), i la cronologia de la transferència el registra, per exemple `counterparty declined: The beneficiary is not our customer`. La resposta és el `{"status": "..."}` resultant, més `decline_reason` després d'un rebuig. Quan la contrapart ha respost, tots dos endpoints retornen `410`. Tots dos endpoints retornen `404` per a un token desconegut i `410` quan la finestra es tanca: o bé la transferència ha sortit de `AWAITING_COUNTERPARTY`, o bé ha passat el termini de confirmació (`confirmation_timeout_hours` després de la creació o de l'últim reenviament). La contrapart llegeix i respon a través de l'enllaç de recollida amb `GET` i `POST /v3/travel-rule/pickup/{token}/messages/`. No necessita cap clau d'API, només accepta adjunts PDF, PNG, JPEG o WebP, i respon `410` quan l'enllaç caduca o la transferència es tanca. Un missatge que has enviat mostra el nom del teu VASP com a `author` i com a `uploaded_by` de l'adjunt, mai la persona ni la clau d'API que hi ha darrere. ### Dipòsits sense correspondència Un dipòsit entrant pot arribar abans que les dades de Travel Rule del VASP d'origen. Aquest dipòsit es manté a `AWAITING_COUNTERPARTY` o `NOT_ENOUGH_COUNTERPARTY_DATA` fins que arriben les dades. Llista els dipòsits que encara esperen amb una clau d'API que tingui el privilegi de transaccions: ```bash theme={null} curl "https://verification.didit.me/v3/travel-rule/unmatched/" \ -H "x-api-key: YOUR_API_KEY" ``` La resposta usa les mateixes files que `GET /v3/travel-rule/transfers/`, limitada als dipòsits entrants que esperen les dades del VASP d'origen. Quan les dades hagin arribat en un missatge rebut separat, emparella el dipòsit i el missatge tu mateix: ```bash theme={null} curl -X POST "https://verification.didit.me/v3/travel-rule/unmatched/{transaction_uuid}/match/" \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"transaction_id": ""}' ``` `{transaction_uuid}` és el dipòsit. `transaction_id` és la transacció del missatge de Travel Rule rebut. La crida retorna `{ "deposit": ..., "message": ... }`. Respon `404` quan alguna de les dues transaccions ja no existeix, i `409` amb `travel_rule_match_conflict` ("This deposit can no longer be matched.") quan qualsevol de les dues parts ja ha canviat d'estat. ### Registre posterior al dipòsit Quan un dipòsit de criptoactius es liquida on-chain **abans** de qualsevol intercanvi de Travel Rule - perquè el VASP emissor era inaccessible, o perquè estàs posant al dia dipòsits històrics - registra'l a posteriori amb `POST /v3/travel-rule/inbound/`. ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "chain": "eth", "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "amount": "500.00", "currency": "USDC", "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" }, "beneficiary_data": { "name": "Ana Diaz" }, "originating_vasp": { "name": "Northwind Digital Assets Ltd", "lei": "5493001KJTIIGC8Y1R12", "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg" } }' ``` `originating_vasp.travel_address` ha de ser una [Travel Address](#travel-addresses) real i amb una suma de verificació vàlida: un valor de marcador de posició retorna `400` amb `"Invalid travel address."`. `originating_vasp.lei` ha d'estar buit o tenir 20 caràcters en format LEI (18 lletres o xifres, seguides de 2 xifres); qualsevol altra cosa retorna `400` amb `"Invalid LEI: expected 20 alphanumeric characters (ISO 17442)."`. Didit només comprova aquest format, no els dígits de control ISO 17442. | Camp | Tipus | Descripció | | - | - | - | | `chain` | string | Xarxa on es va liquidar el dipòsit, de fins a 32 caràcters. Didit la passa a minúscules i l'usa per emparellar-la amb les entrades de la teva [llibreta d'adreces](#llibreta-d’adreces-de-carteres), així que fes servir el mateix token que les teves entrades (`eth` coincideix amb una entrada guardada com a `ETH`). També decideix si el dipòsit es pot sotmetre a cribratge: `bitcoin`/`btc`, `ethereum`/`eth`, `solana`/`sol`, `tron`/`trx`, `polygon`/`matic`, `bsc`/`bnb`, `litecoin`/`ltc`, `ripple`/`xrp`, `bitcoin-cash`/`bch` i `dogecoin`/`doge`. | | `txid` | string | El hash de la transacció on-chain. S'usa per eliminar duplicats: el mateix `txid` + `wallet_address` retorna la transferència existent en lloc de crear-ne una de duplicada. | | `wallet_address` | string | La cartera de destinació on has rebut el dipòsit. Una adreça X de XRP es divideix en la seva adreça clàssica i en l'etiqueta. | | `memo` | string | Opcional. L'etiqueta de destinació o memo del dipòsit en una [xarxa amb memo](#xarxes-amb-memo-i-etiqueta): en una adreça de dipòsit compartida, indica el client al qual pertany el dipòsit. | | `amount` | string (decimal) | Import del dipòsit. | | `currency` | string | Actiu del dipòsit. | | `originator_data` | object | Dades de l'ordenant facilitades pel VASP emissor, si es coneixen, com a objecte pla: Didit llegeix `name` (o `full_name`), `first_name`, `last_name` i `vendor_data`. | | `beneficiary_data` | object | Dades del beneficiari (el teu client), com a objecte pla: Didit compara el seu `name` amb el `holder_name` de l'entrada de la llibreta d'adreces coincident, i hi afegeix `wallet_address` i `chain`. | | `utxo` | object | Opcional, només per a [xarxes UTXO](#transferències-utxo). Les `inputs` i `outputs` de la transacció de dipòsit: la cartera de l'emissor és `originator_data.wallet_address` quan la declares; si no, és l'entrada més gran. | | `originating_vasp` | object | Opcional `{ name, lei, travel_address }` que descriu l'emissor. `lei` ha de coincidir amb el format LEI anterior i `travel_address` ha de ser una Travel Address vàlida, o la sol·licitud retorna `400`. Es manté en aquesta transferència com a `metadata.originating_vasp`; mai no crea ni modifica una entrada de [directori](#com-entren-les-entrades-al-directori) compartit. | Didit crea una transacció `travelRule` entrant (o reutilitza un dipòsit entrant que ja hagis enviat amb el mateix hash i cartera, si encara no té cap transferència Travel Rule) i resol la transferència amb la teva [llibreta d'adreces de carteres](#llibreta-d’adreces-de-carteres), per l'adreça i el memo: * Cap entrada coincident -> `ON_HOLD`. Resol-la amb [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera): `confirmed: true` afegeix la cartera a la teva llibreta d'adreces com a verificada i fa la coincidència de noms; si coincideix, la transferència passa a `COMPLETED` i després a `FINISHED`. * L'entrada existeix però la titularitat no està demostrada -> `UNCONFIRMED_OWNERSHIP`. * El nom del beneficiari no coincideix amb el `holder_name` de l'entrada -> `COUNTERPARTY_MISMATCHED_DATA`. * Entrada verificada i el nom coincideix -> `COMPLETED` i, immediatament, `FINISHED` (el dipòsit ja s'ha liquidat). Amb l'entrada verificada de la llibreta d'adreces registrada a [l'exemple anterior](#llibreta-d’adreces-de-carteres), la resposta és: ```json theme={null} { "transaction_id": "44444444-5555-6666-7777-888888888888", "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e", "created": true, "travel_rule": { "uuid": "55555555-6666-7777-8888-999999999999", "status": "FINISHED", "direction": "INBOUND", "rail": null, "protocol": null, "ivms_version": "ivms101.2023", "required": true, "ownership_confirmed": true, "deadline_at": null, "timeline": [ { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" }, { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" } ], "counterparty_vasp": null, "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" }, "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" }, "created_at": "2026-07-06T10:15:02.087412Z" } } ``` El `txn_id` de la nova transacció és `tr-in-`, seguit dels primers 80 caràcters del `txid` i d'un hash de 12 caràcters del `txid` i de la cartera. `created` és `true` (HTTP `201`) quan aquesta crida ha registrat el dipòsit, i `false` (HTTP `200`) quan el mateix `txid` i `wallet_address` ja estaven registrats; en aquest cas es retorna la transferència existent sense canvis. En la ruta amb entrada verificada, les dues transicions es produeixen abans que l'endpoint respongui, de manera que la resposta síncrona ja mostra l'estat final `FINISHED`; el pas intermedi `COMPLETED` queda registrat igualment a la `timeline` de la transferència. Cada transició dispara un webhook `travel_rule.status.updated` (`COMPLETED` i `FINISHED` en disparen cadascun un). Quan Didit ha creat una transacció nova, envia primer [`transaction.created`](https://docs.didit.me/ca/integration/webhooks#tipus-d’esdeveniments) i després aquests esdeveniments. El registre no té cap tarifa de Travel Rule ni de monitoratge. Quan el monitoratge de criptomonedes està activat i la `chain` és una de les que Didit pot sotmetre a cribratge, un dipòsit nou també se sotmet a un cribratge i es factura una sola vegada a la tarifa de Wallet Verification & Screening. ### Widget de titularitat de la cartera Per treure una transferència de `UNCONFIRMED_OWNERSHIP`, o per verificar prèviament una cartera abans que arribi cap transferència, crea un widget allotjat de titularitat de la cartera amb `POST /v3/travel-rule/widget-session/` i envia el teu client a la `url` retornada. El widget demostra el control de la cartera mitjançant la signatura de missatges (inclosos els comptes de contracte intel·ligent d'EVM, a través d'ERC-1271 i ERC-6492), una prova de Satoshi, una captura de pantalla o una autodeclaració, i després marca com a verificada l'entrada corresponent de la llibreta d'adreces perquè la plataforma d'intercanvi pugui continuar. La captura de pantalla és l'excepció: mai verifica la cartera per si sola, de manera que el teu equip de compliment la revisa i confirma una transferència en `UNCONFIRMED_OWNERSHIP` amb [`POST .../travel-rule/ownership/`](#confirmació-de-la-titularitat-de-la-cartera). Consulta [Widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) per al flux complet, els mètodes de prova i la nota important que el widget s'ha d'obrir en un navegador real, mai dins d'un webview d'un SDK mòbil. ## Directori `GET /v3/travel-rule/vasps/` cerca al directori de VASP: les entrades del directori compartit més els membres de la [xarxa de Didit](#la-xarxa-de-didit). Cada fila indica com pot arribar ara mateix la teva aplicació a aquest VASP. ```bash theme={null} curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \ -H "x-api-key: YOUR_API_KEY" ``` ```json theme={null} { "count": 1, "next": null, "previous": null, "results": [ { "id": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "kind": "directory", "name": "Example Counterparty VASP", "lei": "529900EXAMPLECPTY001", "jurisdiction": "DE", "domains": ["counterparty.example"], "reachable": true, "aliases": [{ "name": "Example Counterparty", "kind": "trading_name" }], "networks": [ { "network": "GTR", "code": "EXAMPLE01", "listed_name": "Example Counterparty VASP", "country": "DE", "verified_at": "2026-10-12T09:30:00Z", "last_seen_at": "2026-10-12T09:30:00Z", "source": "staff" } ], "routes": [ { "rail": "GTR", "status": "unavailable", "reason": "no_membership", "via": "" }, { "rail": "EMAIL", "status": "available", "reason": "", "via": "contact" } ], "umbrella": null, "entities": [], "contacts": [ { "id": "6c1f9b8e-2d4a-4f7e-8b3c-5a9d0e1f2a3b", "email": "travelrule@counterparty.example", "name": "Travel Rule desk", "source": "staff", "scope": "platform", "verified_at": null } ], "dd_status": "NOT_STARTED", "dd_score": 62, "dd_score_breakdown": { "jurisdiction": { "points": 25.0, "max": 25, "reason": "jurisdiction_not_high_risk", "detail": "DEU is not on the high-risk jurisdiction list" }, "verification": { "points": 3.8, "max": 15, "reason": "dd_status_not_started", "detail": "due diligence status NOT_STARTED" }, "protocol": { "points": 6.0, "max": 15, "reason": "email_only", "detail": "reachable over the email fallback only" }, "lei": { "points": 10.0, "max": 10, "reason": "lei_valid", "detail": "valid LEI on record" }, "history": { "points": 5.0, "max": 10, "reason": "no_history", "detail": "no exchange history" }, "essentials": { "points": 7.5, "max": 15, "reason": "no_essential_checks", "detail": "no decided essential check yet" }, "responsiveness": { "points": 5.0, "max": 10, "reason": "responsiveness_unknown", "detail": "0 decided recent requests, too few to judge" } }, "dd_assessed_at": "2026-10-12T09:30:00Z", "dd_score_semantic": "higher_is_safer", "risk_level": "MEDIUM", "responsiveness": { "status": "UNKNOWN", "answered": 0, "total": 0, "computed_at": "2026-10-12T09:30:00Z" }, "essential_checks": {}, "reachable_rails": ["GTR", "EMAIL"], "is_didit_customer": false, "decision": { "decision": "APPROVED", "reason": "Licensed in DE", "decided_by": "", "updated_at": "2026-10-14T10:05:00Z", "inherited_from": null }, "entity_screening": { "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d", "status": "Approved", "total_hits": 0, "score": null, "screened_at": "2026-10-14T09:58:00Z", "fresh": true, "flagged": false }, "questionnaires": [] } ] } ``` `search` coincideix amb un fragment del nom o d'un àlies, amb un LEI exacte o amb un domini (`counterparty.example` o una URL d'aquest domini). Restringeix els resultats amb: | Paràmetre | Efecte | | - | - | | `network` | `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` o `TRISA`: només les entrades que el directori de membres d'aquella xarxa llista en aquest moment. | | `jurisdiction` | Codi de país ISO 3166 de dues o tres lletres. | | `reachable` | `true`: només els VASP als quals la teva aplicació té una ruta disponible. `false`: només les entrades que no pot assolir avui. | | `kind` | `directory` per a les entrades compartides, `didit` per als membres de la xarxa de Didit. | | `risk` | `LOW`, `MEDIUM` o `HIGH`: només les entrades del directori amb aquesta banda de `risk_level`. Consulta [Puntuació i nivell de risc](#puntuació-i-nivell-de-risc). | | `responsiveness` | `RESPONSIVE`, `UNRESPONSIVE` o `UNKNOWN`: només les entrades del directori amb aquest `responsiveness.status`. Consulta [Capacitat de resposta](#capacitat-de-resposta). | Els membres de la xarxa de Didit no reben puntuació, així que `risk` i `responsiveness` només retornen entrades del directori. Els resultats s'ordenen pel nom i es paginen amb `limit` (per defecte `50`) i `offset`. Una xarxa, un codi de país, una banda de risc o un estat de capacitat de resposta desconeguts responen `400` indicant el camp. `GET /v3/travel-rule/vasps/{vasp_id}/` retorna una fila pel seu `id`. El teu propi perfil de VASP mai no apareix als teus propis resultats. `dd_status`, `dd_score`, `dd_score_breakdown`, `dd_assessed_at`, `dd_score_semantic`, `risk_level`, `responsiveness` i `essential_checks` contenen l'avaluació de diligència deguda compartida d'una entrada del directori. `decision`, `entity_screening` i `questionnaires` són els registres propis de la teva aplicació sobre el VASP, i cap altre client no els veu. Consulta [Diligència deguda de la contrapart](#diligència-deguda-sobre-la-contrapart) per saber què significa cadascun, i fes-los servir com a condicions amb els [camps de regla de contrapart](#camps-de-regla-i-preconfiguracions) en lloc de prendre decisions sobre ells directament. Els membres de la xarxa de Didit no reben puntuació: `dd_status` és `COMPLETED`, `dd_score` és `null`, `risk_level` és buit i el desglossament és buit. ### Rutes `routes` enumera les maneres en què la teva aplicació pot lliurar al VASP, en l'ordre en què l'escala d'encaminament les prova, i `reachable` és `true` quan almenys una és `available`: * `TRP` quan l'entrada porta un endpoint TRP que el directori ha verificat. * `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` quan una xarxa llista el VASP amb un codi. La ruta només és `available` quan la teva aplicació pot enviar per aquella xarxa avui (`via: own_membership` per a la teva pròpia membresia connectada, `via: didit_membership` per a la de Didit). En cas contrari és `unavailable` amb `reason: no_membership` o `reason: network_switched_off`, i mai no es mostra com a manera d'arribar al VASP. Les membresies pròpies de Didit a aquestes xarxes encara no estan actives, de manera que avui una ruta de xarxa només està disponible mitjançant una membresia que hagis connectat al Marketplace. * `EMAIL` quan hi ha un contacte de compliment normatiu per a l'entrada. * `INTERNAL` per a un membre de la xarxa de Didit. Una entrada `TRISA` apareix sota `networks` i t'indica qui és el VASP a TRISA, però Didit no té cap canal TRISA, així que mai no és una ruta. Una aplicació sandbox només envia a la [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md), així que no té disponible cap ruta del directori: totes les rutes són `unavailable` amb `reason: sandbox_application`, totes les files tenen `reachable: false`, i `reachable=true` no retorna cap fila. ### Marques i les seves entitats Una marca que opera a través de diverses entitats regulades és una sola fila, les `entities` de la qual són les entitats jurídiques que reben les seves transferències; una fila d'entitat apunta de tornada a la seva marca amb `umbrella`. Una transferència que indica la marca va a una de les seves entitats, triada entre totes: la de la jurisdicció que indica a `beneficiary_data.counterparty_vasp_jurisdiction`, si no, l'entitat que l'[atribució d'anàlisi de blockchain](#atribució-mitjançant-analítica-de-blockchain) vinculi a la cartera de destinació, si no, l'única entitat de la marca quan no s'indica cap jurisdicció. Només llavors aquesta entitat ha de ser accessible; si no ho és, la transferència mai no va a una altra entitat ni a la marca en el seu lloc. Quan cap entitat encaixa (dues hi encaixen igual, o la jurisdicció indicada no és la de cap d'elles), s'usa la ruta pròpia de la marca, i sense ruta la transferència és `COUNTERPARTY_VASP_NOT_FOUND`. L'entitat jurídica que rep les dades de l'ordenant no es determina mai per conjectura, i mai no la decideix el fet que una entitat tingui un contacte. Diverses entrades amb el mateix nom, com les empreses d'un grup que comparteixen un nom comercial, es distingeixen amb la mateixa regla: la de la jurisdicció indicada, si no, la que l'atribució d'anàlisi de blockchain hi vinculi. Quan cap de les dues en tria una, no se'n fa servir cap, i es considera que els detalls no identifiquen cap entrada del directori. ### Contactes `contacts` són les adreces de correu electrònic a les quals escriu la ruta `EMAIL`. Els contactes amb `scope: platform` serveixen a tots els clients de Didit: Didit els gestiona (`source: staff`), o bé una adreça d'un dels dominis propis del VASP ha respost a una sol·licitud mitjançant el seu enllaç de resposta (`source: learned`). Els contactes amb `scope: application` són privats de la teva aplicació: els que afegeixes tu (`source: application`), i una adreça fora dels dominis propis del VASP que ha respost a una de les teves sol·licituds (`source: learned`). Una transferència envia primer el correu al contacte propi de la teva aplicació, després a un contacte de la plataforma que ja hagi respost abans (amb `verified_at` establert), i després als altres. Gestiona els contactes propis de la teva aplicació amb l'API de contactes de contraparts: ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/counterparty-contacts/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"counterparty": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "email": "compliance@counterparty.example", "name": "Compliance desk"}' ``` * `GET /v3/travel-rule/counterparty-contacts/` llista tots els contactes als quals la teva aplicació pot enviar, incloent-hi els contactes de la plataforma i els rebotats, del més nou al més antic, paginada amb `limit` i `offset`. Filtra amb `?counterparty=` i un `id` d'entrada del directori; un valor que no és un UUID respon `400`. * `POST` afegeix un contacte privat (`counterparty`, `email`, `name` opcional) i respon `201`. Afegir una adreça que l'entrada ja té entre els teus propis contactes retorna aquest contacte. Una entrada desconeguda respon `400` (`"No directory entry with this id."`). * `DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/` elimina un dels teus propis contactes (`204`). Els contactes de la plataforma no es poden eliminar i responen `404`. Un contacte que ha rebotat o ha presentat una queixa de correu brossa té `is_invalid: true`, amb `invalid_reason` (`hard_bounce`, `soft_bounce`, `spam_complaint` o `suppressed`), `invalid_detail` i `invalid_at`, i el canal `EMAIL` l'omet. `created_by` està buit en els contactes de la plataforma i en els contactes que ha afegit una clau d'API. ### Com entren les entrades al directori * El registre provisional de MiCA de l'ESMA de prestadors de serveis d'actius criptogràfics, que es llegeix cada setmana: el nom de cada prestador, el seu LEI i l'estat membre d'origen. * El directori públic de TRISA, que es llegeix cada setmana: qui és cada membre, el seu país i la seva inclusió a TRISA. Una inclusió que el directori deixa de mostrar durant tres setmanes s'elimina. * El registre global de LEI completa el LEI, altres noms legals i el país d'una entrada, i troba el LEI d'una entrada pel seu nom legal exacte al seu país. * [Atribució d'analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain) afegeix o associa el VASP que és propietari d'una cartera de destinació, i conserva el nom atribuït com a àlies. * L'equip de Didit gestiona les entrades: identificadors d'encaminament i inclusions a xarxes que ha verificat, contactes de compliment, àlies, marques i les seves entitats, duplicats fusionats i entrades ocultes. Les dades que un client informa sobre una contrapart, com un `originating_vasp` entrant o una Travel Address, es mantenen en la transferència d'aquest client i mai no modifiquen una entrada compartida. Les entrades es fan coincidir primer per LEI i després pel nom exacte o per àlies, i s'enriqueixen en lloc de duplicar-se. ### La xarxa de Didit El teu perfil de VASP és membre de la xarxa de Didit, de manera que altres clients de Didit el troben al directori i al selector de VASP de l'usuari final, només mentre es compleixin totes aquestes condicions: * la teva aplicació està en producció (no en sandbox) i Travel Rule està activada; * `is_discoverable` és `true` i `legal_name` està definit; * `compliance_email` està definit i confirmat: envia la confirmació amb `POST /v3/travel-rule/settings/compliance-email/confirmation/` i obre l'enllaç que t'arriba per correu. Canviar l'adreça requereix una nova confirmació; * Didit no ha marcat l'aplicació com a aplicació de prova, de demostració o interna. El propi canal `INTERNAL` lliura a una cartera de la qual has demostrat la titularitat, tal com es descriu a [Enviament d'una transferència](#enviar-una-transferència): necessita que la teva aplicació estigui en producció, Travel Rule estigui activada i `is_discoverable`, però no la resta de la llista. `GET /v3/travel-rule/settings/` retorna `didit_network`: `listed`, `compliance_email_confirmed`, i a `missing` cada condició que encara no es compleix (`travel_rule_off`, `sandbox_application`, `not_discoverable`, `legal_name_missing`, `compliance_email_missing`, `compliance_email_unconfirmed`, `excluded_by_staff`, `internal_organization`). ### Identificadors d'encaminament L'encaminament de sortida consulta una entrada del directori sempre que la teva transferència anomena la contrapart amb `counterparty_vasp_lei` o `counterparty_vasp_name` (un àlies també funciona). Una entrada porta un identificador per cada xarxa a través de la qual s'hi pot contactar, un endpoint TRP verificat i els seus contactes de compliment, i `routes` indica quines rutes pot utilitzar la teva aplicació. Sempre pots saltar-te el directori en una sola transferència passant els camps explícits que es descriuen a [Camps de resolució de la contrapart](#camps-de-resolució-de-la-contrapart). ## Diligència deguda sobre la contrapart Abans que els fons dels teus clients arribin a un altre VASP, has de saber qui és aquest VASP i si l'acceptes. La diligència deguda sobre una contrapart té dues capes: * **L'avaluació compartida.** Cada entrada del directori porta una puntuació de diligència deguda, el seu nivell de risc, un estat de capacitat de resposta i un informe de comprovacions essencials. Didit els calcula a partir de les dades de la plataforma, de manera que tots els clients veuen els mateixos valors. * **Els teus registres propis.** La teva decisió sobre el VASP, el cribratge de sancions i de mitjans adversos que en fas, i els qüestionaris de diligència deguda que has intercanviat amb ell pertanyen només a la teva aplicació. Cap altre client no els veu mai, i mai no canvien l'entrada compartida. Els teus registres propis funcionen igual per a una entrada del directori que per a un membre de la [xarxa de Didit](#la-xarxa-de-didit): adreça'ls amb el `id` que mostra el [directori](#directori). | Endpoint | Què fa | | - | - | | `GET` / `PUT` / `DELETE /v3/travel-rule/vasps/{vasp_id}/decision/` | Llegeix, defineix o esborra la [teva decisió](#la-teva-decisió-sobre-una-contrapart) sobre la contrapart. | | `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/screening/` | Llegeix el teu [cribratge de contrapart](#cribratge-de-contrapart) més recent, o n'executa un. | | `GET` / `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/` | Llista els teus [qüestionaris de diligència deguda](#qüestionari-de-diligència-deguda) amb la contrapart, o n'envia un. | | `GET /v3/travel-rule/transfers/?counterparty={vasp_id}` | Les teves [transferències amb aquesta contrapart](#transferències-amb-una-contrapart). | ### Puntuació i nivell de risc `dd_score` va de 0 a 100 i **com més alta, més segura**. Cada resultat ho indica a `dd_score_semantic`, que sempre és `higher_is_safer`. `risk_level` és la banda on cau la puntuació: | `risk_level` | `dd_score` | | - | - | | `LOW` | 70 o més | | `MEDIUM` | 40 a 69 | | `HIGH` | Per sota de 40 | La puntuació és la suma de set components. `dd_score_breakdown` mostra cadascun com a `{points, max, reason, detail}`: `max` és el pes del component, `reason` un codi llegible per màquina que pots traduir, i `detail` una explicació d'una línia en anglès. | Component | Pes | Com puntua | Codis de `reason` | | - | - | - | - | | `jurisdiction` | 25 | Complet quan el país de l'entrada no és a la llista per defecte de jurisdiccions d'alt risc (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`), zero quan hi és, i la meitat quan el país és desconegut. | `jurisdiction_not_high_risk`, `jurisdiction_high_risk`, `jurisdiction_unknown` | | `verification` | 15 | Estat de verificació de Didit de l'entrada (`dd_status`): complet per a `COMPLETED`, la meitat per a `IN_PROGRESS`, un quart per a `NOT_STARTED`, zero per a `REJECTED`. | `dd_status_completed`, `dd_status_in_progress`, `dd_status_not_started`, `dd_status_rejected` | | `protocol` | 15 | Complet quan un canal de protocol natiu arriba a l'entrada (un endpoint TRP o el canal `INTERNAL`), el 40 per cent quan només hi arriba el recurs de correu de reserva, i zero sense cap canal accessible. | `native_rail`, `email_only`, `no_rail` | | `lei` | 10 | Complet amb un LEI vàlid registrat, zero sense. | `lei_valid`, `lei_missing` | | `history` | 10 | La proporció d'intercanvis decidits de l'entrada que han reeixit, la meitat sense cap. | `history`, `no_history` | | `essentials` | 15 | La proporció de [comprovacions essencials](#comprovacions-essencials) decidides que passen, la meitat mentre cap no estigui decidida. | `essential_checks`, `no_essential_checks` | | `responsiveness` | 10 | Complet per a `RESPONSIVE`, zero per a `UNRESPONSIVE`, la meitat per a `UNKNOWN`. Vegeu [Capacitat de resposta](#capacitat-de-resposta). | `responsive`, `unresponsive`, `responsiveness_unknown` | Els punts s'arrodoneixen a un decimal i el total a un nombre enter. `history` llegeix les mateixes sol·licituds que [la capacitat de resposta](#capacitat-de-resposta), sense finestra temporal: un intercanvi `COMPLETED` o `FINISHED` és un èxit, i un intercanvi `EXPIRED`, `COUNTERPARTY_MISMATCHED_DATA` o `COUNTERPARTY_VASP_GENERAL_DECLINE` és un fracàs. Una cancel·lació és un acte del remitent i mai no compta. Didit recalcula l'avaluació quan un intercanvi amb l'entrada es completa, finalitza, caduca, presenta una discrepància o és rebutjat, quan actualitza o revisa l'entrada, i per a totes les entrades en l'actualització setmanal del directori. `dd_assessed_at` indica quan es va executar per última vegada. Una entrada encara no avaluada no té `dd_assessed_at`, té un `dd_score` de `0` i un `risk_level` buit, així que llegeix `risk_level` en lloc de la puntuació bruta. Els membres de la xarxa de Didit no reben puntuació: el seu `dd_score` és `null`, el seu `risk_level` és buit i el seu `dd_score_breakdown` és buit. ### Comprovacions essencials `essential_checks` és un informe breu sobre quatre comprovacions que Didit executa a cada entrada del directori, només a partir de fonts verificades de la plataforma, mai de dades que un client hagi informat: | `id` de la comprovació | Es supera quan | | - | - | | `registration` | Un registre oficial inclou el VASP: el registre provisional MiCA de l'UE de prestadors de serveis d'actius criptogràfics, el directori públic de TRISA, o el registre global de LEI amb un LEI emès. | | `licence` | El registre MiCA registra una autorització per al VASP que no ha finalitzat. | | `domain` | El domini de l'entrada coincideix amb el seu endpoint TRP o amb el lloc web que indica el seu registre. | | `lei` | El registre LEI de l'entrada està actiu i emès, i el seu nom legal i el seu país coincideixen amb l'entrada. | Cada comprovació de `checks` indica el seu `status` (`pass`, `fail` o `unknown` quan cap font registrada no permet determinar-la), un `reason` llegible per màquina i un `detail` d'una línia en anglès. `passed`, `failed`, `unknown` i `total` les compten, `level` és `essential`, i `checked_at` indica quan es va construir l'informe. El component `essentials` puntua la proporció de comprovacions decidides que passen, així que una comprovació `unknown` no compta ni a favor ni en contra de l'entrada. L'informe és buit fins que l'actualització setmanal del directori comprova per primera vegada una entrada, i sempre és buit per a un membre de la xarxa de Didit. ### Capacitat de resposta `responsiveness` indica si el VASP respon a les sol·licituds de la Travel Rule: ```json theme={null} { "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" } ``` `total` compta les sol·licituds que els clients de Didit han iniciat cap al VASP en els darrers 90 dies i el resultat de les quals està decidit, i `answered` les que el VASP ha respost: * **Comptades:** les sol·licituds enviades per un canal de xarxa o de protocol, i les sol·licituds enviades per correu a una adreça compartida, que és l'adreça de compliment de l'entrada o un contacte de la plataforma. * **Mai comptades:** una sol·licitud enviada per correu a una adreça que un client ha escrit, o al contacte privat d'un client. Aquest intercanvi es queda a l'historial de transferències del client i mai no etiqueta el VASP per a la resta. * **Respostes:** `COMPLETED`, `FINISHED`, `COUNTERPARTY_VASP_GENERAL_DECLINE` o `COUNTERPARTY_MISMATCHED_DATA`. Un rebuig o una discrepància també és una resposta: el VASP s'ha implicat. * **Sense resposta:** `EXPIRED`. * **Cap de les dues:** qualsevol altre estat. Una sol·licitud `CANCELLED` és un acte del remitent, `COUNTERPARTY_VASP_NOT_REACHABLE` pot ser un fracàs per part del remitent, i una sol·licitud encara en curs encara no s'ha resolt. | `status` | Quan | | - | - | | `UNKNOWN` | Menys de 5 sol·licituds resoltes dins de la finestra, de manera que una sol·licitud caducada no etiqueta mai una VASP. | | `UNRESPONSIVE` | La VASP ha respost a menys del 10 per cent de les seves sol·licituds resoltes. | | `RESPONSIVE` | En qualsevol altre cas. | Els membres de la xarxa de Didit responen dins de Didit i sempre mostren `UNKNOWN` amb comptadors a zero. Actua sobre una contrapart que no respon amb la [política de no resposta](#polítiques-sunrise-i-de-contraparts-sense-resposta) o amb la [configuració predefinida](#camps-de-regla-i-preconfiguracions) `travel-rule-counterparty-unresponsive`. ### La teva decisió sobre una contrapart Registra el veredicte del teu equip de compliment sobre una contrapart amb `PUT /v3/travel-rule/vasps/{vasp_id}/decision/`: ```bash theme={null} curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}' ``` ```json theme={null} { "decision": { "decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction", "decided_by": "", "updated_at": "2026-10-14T10:05:00Z", "inherited_from": null } } ``` | `decision` | Significat | Configuració predefinida que hi actua | | - | - | - | | `APPROVED` | El teu equip ha aprovat la contrapart. | Cap | | `RESTRICTED` | Les transferències cap a ella poden tirar endavant després de revisió. | `travel-rule-counterparty-restricted` les reté per revisar-les. | | `BLOCKED` | El teu equip ha rebutjat la contrapart. | `travel-rule-counterparty-blocked` les denega. | * La decisió és privada per a la teva aplicació: cap altre client no la veu mai, i mai no canvia l'entrada compartida. * Una decisió, per si sola, no canvia res i mai no canvia com s'encamina una transferència. Arriba a les teves transaccions a través del [camp de regla](#camps-de-regla-i-preconfiguracions) `counterparty_dd_status`: instal·la les configuracions predefinides o escriu la teva pròpia regla sobre aquest camp. * Una decisió sobre una marca cobreix cadascuna de les seves [entitats](#marques-i-les-seves-entitats) que no tingui una decisió pròpia, i l'entitat mostra la marca a `inherited_from`. Una decisió sobre l'entitat substitueix la de la marca per a aquesta entitat. * `GET` retorna la decisió aplicable, o `{"decision": null}`. `DELETE` esborra la teva pròpia decisió i retorna la decisió aplicable després: la decisió de la marca per a una entitat o, si no n'hi ha, `null`. Respon `404` quan la teva aplicació no té cap decisió pròpia sobre la contrapart. * `reason` és opcional, de fins a 255 caràcters, i cada `PUT` el substitueix. `decided_by` és l'usuari de la consola que ha pres o modificat per última vegada la decisió, i queda buit quan ho ha fet una clau d'API. ### Cribratge de contrapart El cribratge de contrapart comprova la pròpia VASP contrapart, com a empresa, contra sancions i mitjans adversos. És **opcional i facturable**: activa'l amb `counterparty_screening_enabled` a la teva [configuració](#configuració). Mentre estigui desactivat, no es cribla ni es factura res. ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"refresh": false}' ``` ```json theme={null} { "outcome": "screened", "screening": { "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d", "status": "In Review", "total_hits": 2, "score": 85.0, "screened_at": "2026-10-14T09:58:00Z", "fresh": true, "flagged": true } } ``` * **Facturació.** Cada cribratge nou costa el [preu](https://docs.didit.me/ca/getting-started/pricing.md) de Cribratge AML d'empreses de la teva organització. `GET /v3/travel-rule/vasps/{vasp_id}/screening/` retorna aquest `price`, `fresh_days` i si el cribratge està `enabled`, sense cap cost. Un cribratge de menys de 30 dies és vigent: `POST` el retorna de nou amb `200` i `outcome: reused` i no factura res, tret que enviïs `refresh: true`. Un cribratge nou respon `201` amb `outcome: screened`. Les aplicacions de sandbox mai no es criben ni es facturen. * **Cribratge automàtic.** Amb el cribratge activat, Didit també criba la contrapart a la qual arriba un intercanvi de sortida quan aquest comença, abans que les teves regles avaluïn la transacció, amb la mateixa reutilització i facturació. Una denegació o un error en aquest punt mai no fa fallar la transferència. * **Resultat.** `status` és `Approved` quan no hi ha cap coincidència possible que requereixi atenció, i `In Review` o `Declined` per a una possible coincidència de sancions o de mitjans adversos. `flagged` és `true` mentre un cribratge vigent sigui `In Review` o `Declined`. * **Efecte.** Mentre el teu darrer cribratge d'una contrapart estigui marcat i el cribratge continuï activat, `counterparty_risk_level` és `HIGH` a les teves regles, de manera que la configuració predefinida `travel-rule-counterparty-high-risk`, un cop instal·lada, reté les seves transferències. El `risk_level` compartit del directori no canvia. * **Privacitat.** El cribratge és privat per a la teva aplicació: cap altre client no el veu mai, i mai no canvia l'entrada compartida. El directori mostra el darrer que hagis fet com a `entity_screening`. * **Denegacions.** `409` quan el cribratge està desactivat, per a una aplicació de sandbox, o mentre ja s'està executant un cribratge de la mateixa contrapart. `403` amb `code: insufficient_credits` quan el teu saldo no cobreix el preu. `502` quan el cribratge no es pot completar. Cap d'aquestes respostes no factura res. ### Qüestionari de diligència deguda Demana a una contrapart les seves respostes de diligència deguda amb el qüestionari estàndard de Didit. `POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/` l'envia per correu electrònic a una adreça de compliment registrada per a la contrapart, amb un enllaç d'ús únic a una pàgina de respostes: ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"sent_to": "travelrule@counterparty.example"}' ``` ```json theme={null} { "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f", "status": "SENT", "form_version": "1", "sent_to": "travelrule@counterparty.example", "sent_at": "2026-10-14T10:00:00Z", "expires_at": "2026-11-13T10:00:00Z", "answered_at": null, "valid_until": null, "current": false, "answers": {} } ``` * **On s'envia.** `sent_to` ha de ser una adreça de compliment registrada: per a una entrada del directori, la seva adreça de compliment o un contacte que la teva aplicació veu a `contacts`; per a un membre de la xarxa de Didit, el seu correu de compliment confirmat. Si l'omets, s'usa l'adreça a la qual s'envia un correu de Travel Rule a la contrapart: primer el teu propi contacte, després un contacte de la plataforma i, finalment, l'adreça de compliment de l'entrada. Didit no envia mai el qüestionari a cap altre destinatari, i respon `400` quan la contrapart no té cap adreça de compliment registrada. * **Com es respon.** L'enllaç obre `/v3/travel-rule/questionnaires/{token}/`, una pàgina per a una persona de la contrapart que no necessita compte ni clau d'API. La persona respon a totes les preguntes, de fins a 2.000 caràcters cadascuna (`N/A` quan una no s'aplica), i envia les respostes una sola vegada. Una contrapart també pot enviar `{"answers": {"": ""}}` al mateix enllaç. Un enllaç que s'ha usat, s'ha substituït o ha superat el seu termini mostra una pàgina de caducitat. El correu i la pàgina estan traduïts; les preguntes, en canvi, sempre són en anglès, perquè el seu significat no canviï d'un idioma a un altre. * **Terminis.** La contrapart té 30 dies per respondre (`expires_at`). Les respostes es mantenen vigents durant 365 dies (`valid_until`), i `current` és `true` fins a aquell moment. Un qüestionari sense resposta que ha superat el seu termini, i les respostes que han superat la seva validesa, passen a `EXPIRED`. * **Un sol qüestionari obert per contrapart.** Un nou enviament substitueix el teu qüestionari anterior sense resposta a la mateixa contrapart: passa a `EXPIRED` i el seu enllaç deixa de funcionar. Es pot enviar un correu per minut a una adreça; un enviament més ràpid respon `429`. * **Consulta de les respostes.** `GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/` enumera els teus qüestionaris amb la contrapart, del més recent al més antic, amb `answers` indexades per id de pregunta un cop contestats. El directori els mostra com a `questionnaires`. Són privats per a la teva aplicació. La versió `1` del formulari fa aquestes dotze preguntes: | Identificador de la pregunta | Pregunta | | - | - | | `legal_name` | Nom de l'entitat legal i jurisdicció de constitució. | | `licensing` | Llicències o registres que teniu per a serveis d'actius virtuals: regulador, número de llicència i estat a cada jurisdicció. | | `jurisdictions` | Jurisdiccions on opereu, i aquelles on estigueu exclòs o restringit. | | `aml_program` | Resum del vostre programa AML/CFT: polítiques, procediments i la data de l'última auditoria o revisió independent. | | `compliance_officer` | Nom i rol del vostre responsable de compliment, i com es pot contactar amb aquesta persona. | | `sanctions_screening` | Com cribrareu els clients i les contraparts contra sancions i mitjans adversos: proveïdor o llistes, freqüència i escalat. | | `transaction_monitoring` | Com monitoritzeu les transaccions per detectar activitat sospitosa: eines, llindars i pràctica de notificació. | | `travel_rule` | Com compliu la Travel Rule: protocols i xarxes utilitzats, i el vostre temps de resposta habitual a una sol·licitud. | | `custody` | Acords de custòdia dels actius dels clients: custodi qualificat, assegurança i segregació. | | `ownership` | Titulars reals amb un 25 per cent o més, i qualsevol entitat matriu o paraigua. | | `record_keeping` | Pràctica de conservació de registres i període de conservació per a les dades de la Travel Rule i de les transaccions. | | `data_protection` | Com protegiu les dades personals compartides per al compliment, i on s'emmagatzemen. | ### Transferències amb una contrapart [`GET /v3/travel-rule/transfers/?counterparty={vasp_id}`](https://docs.didit.me/ca/management-api/travel-rule/list-transfers) enumera les transferències de Travel Rule de la vostra aplicació amb una contrapart, de la més recent a la més antiga, pel `id` que mostra el directori: les vostres transferències amb aquella entrada del directori com a contrapart, o els vostres intercanvis `INTERNAL` amb aquell membre de la xarxa de Didit. Un valor que no és un id vàlid respon amb `400`. Cada fila porta `reason` just després de `status`: el [`reason`](#per-què-una-transferència-està-bloquejada) de la mateixa transferència, de manera que la llista permet distingir un correu de compliment rebotat d'una contrapart sense ruta sense obrir cada transferència. ### Polítiques sunrise i de contraparts sense resposta Quan una transferència caduca (si ha passat `confirmation_timeout_hours` mentre estava `AWAITING_COUNTERPARTY`), `timeout_outcome` decideix què passa amb la seva transacció. Hi ha dues configuracions que us permeten tractar de manera diferent dos motius habituals de caducitat: | Configuració | S'aplica quan la contrapart és una entrada del directori que | | - | - | | `sunrise_policy` | Està en una jurisdicció que figura a `sunrise_jurisdictions`: un país que encara no aplica la Travel Rule, de manera que el VASP no està obligat a respondre. | | `non_responsive_policy` | Té `responsiveness.status` `UNRESPONSIVE`. | Totes dues accepten `HOLD`, `REJECT` o `PROCEED`, amb el mateix significat que per a `timeout_outcome`, o una cadena buida per seguir `timeout_outcome`. Totes dues són buides per defecte, de manera que no canvia res fins que n'estableixis una: ```bash theme={null} curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}' ``` La primera d'aquestes que s'aplica decideix el resultat: 1. `sunrise_policy`, quan està definida i la jurisdicció de la contrapart és a `sunrise_jurisdictions`. 2. `non_responsive_policy`, quan està definida i la contrapart és `UNRESPONSIVE`. 3. `timeout_outcome` en tots els altres casos, inclosa una transferència a un membre de la xarxa de Didit o a una contrapart sense entrada al directori. `sunrise_jurisdictions` és de només lectura i actualment és `["CO", "KH", "VN"]`. Només aquests països compten com a en període sunrise: qualsevol altra jurisdicció, i una de buida o desconeguda, segueix `timeout_outcome`, de manera que una contrapart mai no rep la vostra política sunrise per accident. La cronologia de la transferència caducada indica el resultat que s'ha aplicat, per exemple `sunrise_policy=PROCEED (counterparty jurisdiction CO does not enforce the Travel Rule yet)`. Les vostres regles continuen executant-se després de la caducitat, de manera que una regla com `tr_eu_expired_review` del TFR de la UE encara pot enviar la transacció a revisió amb `PROCEED`. ### Camps de regla i preconfiguracions Quatre camps de [regla](https://docs.didit.me/ca/transaction-monitoring/rules.md) contenen el que la vostra aplicació sap sobre la contrapart a la qual ha arribat l'intercanvi de Travel Rule d'una transacció: la seva entrada del directori o, en un intercanvi `INTERNAL`, el client de Didit que l'ha rebut. Cada camp és buit quan l'intercanvi no ha arribat a cap contrapart coneguda. | Camp | Valor | | - | - | | `counterparty_dd_status` | La vostra [decisió](#la-teva-decisió-sobre-una-contrapart): `APPROVED`, `RESTRICTED` o `BLOCKED`, d'una entitat que segueix la de la seva marca. Buit quan no n'heu presa cap. Mai la decisió d'un altre client. | | `counterparty_risk_level` | El `risk_level` de l'entrada (`LOW`, `MEDIUM` o `HIGH`), o `HIGH` mentre el vostre [cribratge](#cribratge-de-contrapart) de la contrapart estigui marcat. Buit per a una entrada encara no avaluada, i per a un membre de la xarxa de Didit tret que el vostre cribratge d'aquest estigui marcat. | | `counterparty_jurisdiction` | El país de la contrapart, des de l'entrada del directori o el perfil del membre de la xarxa de Didit. Els codis ISO-2 i ISO-3 es comparen tots dos, igual que els altres camps de país. | | `counterparty_responsiveness` | El `responsiveness.status` de l'entrada: `RESPONSIVE`, `UNRESPONSIVE` o `UNKNOWN`. Buit per a un membre de la xarxa de Didit. | Cinc preconfiguracions del paquet `travel_rule` actuen sobre aquests camps. Instal·la-les des de **Transactions → Rules → Library** a la Business Console o amb la [API de la biblioteca de regles](https://docs.didit.me/ca/management-api/transactions/rules-install.md): | `library_key` | Activador | Acció per defecte | | - | - | - | | `travel-rule-counterparty-blocked` | `counterparty_dd_status` és `BLOCKED` | +90 de puntuació, `DECLINED` | | `travel-rule-counterparty-restricted` | `counterparty_dd_status` és `RESTRICTED` | +50 de puntuació, `IN_REVIEW` | | `travel-rule-counterparty-high-risk` | `counterparty_risk_level` és `HIGH` | +40 de puntuació, `IN_REVIEW` | | `travel-rule-counterparty-high-risk-jurisdiction` | `counterparty_jurisdiction` és a la llista d'alt risc per defecte (`IRN`, `PRK`, `SYR`, `AFG`, `RUS`, `MMR`) | +60 de puntuació, `IN_REVIEW` | | `travel-rule-counterparty-unresponsive` | `counterparty_responsiveness` és `UNRESPONSIVE` | +30 de puntuació, `IN_REVIEW` | Les cinc només s'apliquen a transaccions de Travel Rule. ## Webhooks Subscriu una destinació a `travel_rule.status.updated` per rebre una notificació a cada transició d'estat de cada transferència de la teva aplicació, de sortida i d'entrada, incloses les etapes de la via `INTERNAL`. L'encaminament s'executa després que la creació de la transacció retorni, de manera que resultats com `COUNTERPARTY_VASP_NOT_FOUND`, `COUNTERPARTY_VASP_NOT_REACHABLE` o un intercanvi `INTERNAL` que es liquida de seguida t'arriben a través d'aquest esdeveniment i no a la resposta de creació. ```json theme={null} { "event_id": "9c0c8b8a-1111-4222-9333-666666666666", "webhook_type": "travel_rule.status.updated", "timestamp": 1774970000, "created_at": 1774970000, "application_id": "11111111-2222-3333-4444-555555555555", "environment": "live", "transaction_id": "22222222-3333-4444-5555-666666666666", "txn_id": "trv-2026-07-05-001", "travel_rule_status": "COMPLETED", "rail": "INTERNAL", "direction": "OUTBOUND" } ``` `rail` està buit fins que se selecciona una via. Per a una transacció, Didit envia `travel_rule.status.updated` després de `transaction.created`: quan Didit crea la transacció (la teva `POST /v3/transactions/`, un registre de sunrise, una consulta `TRP` entrant o l'etapa d'entrada mitjançant la via `INTERNAL`), envia primer `transaction.created`. Cada esdeveniment es lliura i es reintenta de manera independent, així que un `transaction.created` que ha necessitat un reintent pot arribar després d'un esdeveniment d'estat: associa el teu gestor a `transaction_id` i llegeix la transacció quan un esdeveniment d'estat n'anomeni una que encara no has vist. Una transferència enviada via `TRUST` no rep cap esdeveniment `COMPLETED`: TRUST no retorna res que Didit pugui llegir, de manera que, tret que l'enviament falli o la cancel·lis, el seu últim esdeveniment és `EXPIRED`. Via `GTR`, `VERIFYVASP` i `SYGNA`, l'esdeveniment segueix la resposta que Didit llegeix de la xarxa. Les aplicacions de sandbox també envien aquest esdeveniment, amb `"environment": "sandbox"`; una transferència que el [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) ha respost porta `rail: "TEST_VASP"`, `test_vasp: true` i `test_vasp_scenario`. Consulta la [guia de webhooks](https://docs.didit.me/ca/integration/webhooks.md#tipus-d’esdeveniments) per al catàleg complet d'esdeveniments, la verificació de signatures i la política de reintents. ## Preus La tarifa de Travel Rule és **\$0.02 per cada intercanvi de sortida que s'inicia**, que es cobra una sola vegada quan es crea la transacció, independentment de les transicions d'estat per les quals passi l'intercanvi després. Un `resend` mai no el torna a cobrar. * S'aplica a una transacció `travelRule` de sortida en una aplicació amb Travel Rule activat, l'import de la qual és igual o superior al teu `threshold_amount`, de manera que Didit inicia per a ella un intercanvi gestionat. També hi compta una transferència a una cartera autoallotjada o a la cartera verificada del teu propi usuari: la prova de titularitat és el seu intercanvi. * Qualsevol altra transacció de sortida que porti dades de Travel Rule es factura com a Transaction Screening estàndard, que el teu pla inclou fins a la seva [quota mensual de transaccions](https://docs.didit.me/ca/getting-started/pricing.md#monitoratge-de-transaccions-kyt) i que es cobra a \$0.001 a partir d'allà: una transferència per sota del teu llindar, un pagament Lightning al qual Travel Rule no s'aplica, i una transferència registrada de manera passiva mentre Travel Rule està desactivat. Una transacció es factura en una de les dues línies, mai en totes dues. * Les transaccions `travelRule` d'entrada no comporten cap tarifa de Travel Rule ni de monitoratge: l'etapa d'entrada que Didit crea a l'aplicació del beneficiari via la via `INTERNAL`, les consultes `TRP` d'entrada i els [registres posteriors al dipòsit](#registre-posterior-al-dipòsit). * Una aplicació que es va unir a Travel Rule de manera gratuïta no paga cap de les dues tarifes en les transaccions `travelRule` de sortida fins que activa la facturació de sortida amb `POST /v3/travel-rule/workspace/billing/`; la recepció continua essent gratuïta. * A les aplicacions de sandbox no se'ls cobra mai. * La tarifa de Travel Rule figura a $0.02 i Transaction Screening a $0.001 un cop superada la teva quota. Cada transacció es cobra al preu de la línia que factura. * Si el cribratge AML o de carteres cripto també s'executa sobre la mateixa transacció (per exemple, un dipòsit d'entrada amb `currency_kind: "crypto"` i el monitoratge activat), es factura per separat a la tarifa estàndard de Wallet Verification & Screening; no s'inclou dins de la tarifa de Travel Rule. * El [cribratge de contraparts](#cribratge-de-contrapart) és opcional i es factura per separat, al preu de Company AML Screening per cribratge; un cribratge de menys de 30 dies es reutilitza sense cost. Les decisions, els qüestionaris i l'avaluació de diligència deguda del directori no tenen cost. ### Preus de l'atribució L'[atribució d'analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain) necessita una consulta de cartera al proveïdor d'analítica, i sempre obtens el valor complet d'aquesta consulta: * **El monitoratge cripto ja ha cribrat la cartera en aquesta transacció**: es reutilitza el resultat emmagatzemat. Una crida d'analítica, un únic cobrament de Wallet Verification & Screening (el que ja havia fet el monitoratge cripto). L'atribució no hi afegeix res. * **El monitoratge cripto no s'ha executat**: Didit fa la crida d'analítica necessària una sola vegada i en transmet el valor complet: la transacció es cobra la tarifa estàndard de Wallet Verification & Screening (\$0.15 amb l'analítica gestionada per Didit) i rep en resposta la sortida completa del cribratge cripto (puntuació de risc, categoria de risc de la cartera, instantània de la xarxa), no només el nom del VASP. La línia d'ús es marca amb l'activador `travel_rule_attribution` perquè el cobrament sigui explicable. * **Clau d'analítica pròpia**: s'aplica la mateixa tarifa de plataforma que al monitoratge cripto amb la teva pròpia clau (\$0.02 per crida). El teu proveïdor et factura directament la consulta subjacent. * **Les consultes fallides mai no es cobren**, els reenviaments reutilitzen l'atribució registrada sense una nova crida ni cobrament, i les aplicacions de sandbox mai no es cobren. Així, una transferència de sortida que ha necessitat atribució costa \$0.02 (Travel Rule) més un cobrament de Wallet Verification & Screening; i quan els dos productes estan activats, la crida d'analítica i el seu cobrament només es fan una vegada. ## Regles del paquet TFR de la UE El paquet `travel_rule_eu_tfr` inclou quatre regles predefinides, pensades específicament per a les obligacions del TFR de la UE. Com amb qualsevol altre [paquet de regles predefinit](https://docs.didit.me/ca/transaction-monitoring/rules-library.md), activa'l des de la Business Console a **Transactions → Rules → Library**. | Regla (`library_key`) | Activador | Acció | | - | - | - | | `tr_eu_mismatch_hold` | L'estat de la transferència és `COUNTERPARTY_MISMATCHED_DATA` | `+50` a la puntuació, la transacció passa a `IN_REVIEW` | | `tr_eu_unverified_selfhosted_review` | L'estat de la transferència és `UNCONFIRMED_OWNERSHIP` i l'import en la moneda per defecte és com a mínim `1000` | La transacció passa a `IN_REVIEW` | | `tr_eu_vasp_not_found_score` | L'estat de la transferència és `COUNTERPARTY_VASP_NOT_FOUND` | `+25` a la puntuació, etiquetada com a `travel-rule-sunrise` | | `tr_eu_expired_review` | L'estat de la transferència és `EXPIRED` | La transacció passa a `IN_REVIEW` | Aquestes regles s'activen en cada transició rellevant (en crear la transferència, en confirmar la titularitat, quan es rep la resposta de recollida per correu electrònic i des del procés de revisió de caducitats), de manera que una transferència que mai no es resol continua visible per a la revisió de compliment en lloc de liquidar-se sense que ningú se n'adoni. ## Per què això funciona millor en una sola plataforma El compliment de la Travel Rule és un problema d'identitat disfressat de problema de pagaments, i Didit ja té la identitat: * **Dades verificades a l'abast.** El subjecte de cada transferència està vinculat mitjançant `vendor_data` al perfil KYC que Didit va verificar en l'alta (OCR del document, prova de vida, coincidència facial), de manera que pots construir `originator_data` a partir de camps verificats en la mateixa plataforma. Per a un usuari amb una verificació KYC aprovada, Didit transmet la identitat verificada en lloc dels valors que hagis escrit (consulta [Dades verificades i procedència](#dades-verificades-i-procedència)). * **Biometria de verificació addicional per a transferències de risc.** Una [regla](https://docs.didit.me/ca/transaction-monitoring/rules.md) pot retenir qualsevol transferència d'alt valor fins que l'usuari superi una nova comprovació biomètrica contra la cara capturada en l'alta. És la resposta més sòlida possible a la presa de control del compte en el moment de la retirada. Consulta l'[exemple pas a pas](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md#exemple-reverificació-biomètrica-per-a-una-retirada-d’alt-valor). * **Un sol graf de dispositius.** Les transferències enviades des de l'SDK porten la mateixa intel·ligència de dispositiu que les sessions KYC, de manera que «dispositiu nou + import alt + beneficiari per primera vegada» és una única regla, no una unió en un magatzem de dades. * **Cribratge, regles, casos i l'intercanvi en un sol lloc.** El cribratge de carteres que atribueix el VASP de la contrapart és el mateix cribratge que veuen les teves regles i analistes: un sol càrrec, una sola consola i un sol registre d'auditoria. * **Preus publicats.** [\$0.02 per intercanvi de sortida](#preus), sense trams de volum i sense haver de trucar a vendes. ## Preguntes freqüents ### Com funciona l'intercanvi > [accordion] Didit executa l'intercanvi VASP a VASP per si mateix, o només registra les dades de Travel Rule després que una altra xarxa completi l'establiment de connexió? > > Didit executa l'intercanvi per si mateix. > Quan envies una transferència `travelRule`, Didit fa un descobriment de la contrapart en directe, envia les dades de l'ordenant i del beneficiari al VASP receptor per les vies que les transporten, i marca la transferència com a `COMPLETED` només quan la part de la contrapart la confirma: és un establiment de connexió gestionat, no un registre posterior a la liquidació. > Una resposta de la contrapart es processa en totes les vies excepte `TRUST`, que només envia, de manera que una transferència per aquesta via caduca en lloc de completar-se. Per `GTR`, `VERIFYVASP` i `SYGNA`, Didit llegeix la resposta de la xarxa o la consulta cada 5 minuts, i cap intercanvi per aquestes vies no s'ha completat encara contra una xarxa en funcionament; per `TRP`, una resposta que la contrapart no dona de seguida necessita l'amfitrió públic TRP de Didit, que encara no està actiu (vegeu [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md)). > Didit també conserva el registre complet i l'estat de compliment de cada intercanvi (un [cicle de vida](#cicle-de-vida) de 13 estats, [webhooks](#webhooks) i un registre d'auditoria). > Si prefereixes executar Travel Rule amb el teu propi procés, Didit pot registrar en lloc d'això les dades de manera passiva com a únic sistema de registre (vegeu la pregunta sobre el registre passiu). > Hi ha dos modes disponibles: l'intercanvi actiu s'executa quan poses `is_enabled: true` a la [configuració](#configuració) (per defecte és `false`), i fins llavors Didit registra les dades de manera passiva. > [accordion] L'intercanvi és natiu de Didit, o depèn d'un proveïdor d'interoperabilitat extern (Notabene, Sygna, VerifyVASP, TRP)? > > És natiu. Didit executa la seva pròpia implementació del Travel Rule Protocol (TRP), servida a `trp.didit.me` quan aquest amfitrió públic estigui en funcionament (encara no respon, de manera que les contraparts no et poden contactar per TRP avui), i implementa directament els protocols de xarxa del sector: `GTR` (Global Travel Rule), `TRUST`, `VerifyVASP` i `Sygna Bridge` (amb implementació nativa, incloent-hi IVMS 101 xifrat amb ECIES de Sygna i les sol·licituds de permís signades). Didit no és revenedor d'una única capa d'interoperabilitat de tercers. Arribar a una contrapart que és en una xarxa de membres específica necessàriament passa per aquella xarxa (no hi ha un únic canal universal en Travel Rule), però el descobriment, l'establiment de connexió, la verificació i el registre els executa Didit. > Avui cada via de xarxa necessita la teva pròpia membresia, i `TRUST` només envia: vegeu [Visió general](#visió-general). > [accordion] Quines xarxes i protocols de Travel Rule admet Didit? > > Implementats de forma nativa, provats en estricte ordre de prioritat: `INTERNAL` (els dos VASP a Didit), `TRP` (OpenVASP Travel Rule Protocol), `GTR`, `TRUST`, `VerifyVASP`, `Sygna Bridge`, i una alternativa `EMAIL` per a contraparts sense eines. > Les vies de xarxa necessiten avui la teva pròpia membresia, `TRUST` només envia, i la recepció per una xarxa encara no està activada: vegeu [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md). > CODE, TRISA, Notabene i Veriscope apareixen al Marketplace de Didit com a rajoles de sol·licitud d'accés, sense integració encara. > Vegeu [Com encamina Didit un intercanvi](https://docs.didit.me/ca/transaction-monitoring/travel-rule-interoperability.md#com-didit-encamina-un-intercanvi) per a la taula d'encaminament completa, i [Xarxes de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md) per saber què abasta cadascuna avui. > [accordion] Quina xarxa he d'utilitzar, i necessito la meva pròpia membresia? > > `TRP` és la base que recomanem: no necessita cap membresia compartida, compartir la teva [Travel Address](#travel-addresses) permet que qualsevol VASP que parli TRP et contacti, i quan una contrapart només es coneix per l'adreça, l'[atribució amb analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain) l'encamina per TRP només si l'entrada del directori atribuïda ja té un endpoint TRP. > En sortida, Didit envia per aquesta via els actius enumerats a [Identificadors d'actius TRP](#identificadors-d’actius-trp), i una contrapart que no respon de seguida necessita l'amfitrió públic TRP de Didit, que encara no està actiu. > Per a les xarxes de membres, tria segons on operen les teves contraparts: GTR ofereix una àmplia cobertura global, TRUST està orientada a VASP dels EUA, i VerifyVASP (que ara també opera Sygna Bridge) té una bona cobertura a Àsia. > Sí, avui necessites la teva pròpia membresia: Didit no té cap membresia de plataforma en aquestes xarxes encara i s'està donant d'alta com a proveïdor. > Connecta la teva membresia a **Marketplace**; no estàs limitat a una única xarxa. > Recorda que `TRUST` només envia, de manera que una transferència per aquesta via no es completa, i que cap intercanvi per una xarxa no s'ha completat encara contra una xarxa en funcionament. > [accordion] Com troba Didit el VASP de la contrapart quan només tinc una adreça? > > Mitjançant una cadena de resolució: un altre client de Didit que ha demostrat el control de la cartera (la via `INTERNAL`), la teva pròpia [llibreta d'adreces](#llibreta-d’adreces-de-carteres) per a una Travel Address emmagatzemada, després les vies de protocol i de xarxa, i després l'[atribució amb analítica de blockchain](#atribució-mitjançant-analítica-de-blockchain). > Si la transferència porta només una cartera de destinació, Didit la resol amb dades d'analítica de blockchain per atribuir la casa d'intercanvi o el servei de custòdia contrapart i la cataloga al [directori de VASP](#directori). > La transferència només s'encamina automàticament si aquesta entrada del directori ja té una ruta, com un endpoint `TRP`; en cas contrari acaba amb `COUNTERPARTY_VASP_NOT_FOUND` amb el nom de la contrapart registrat, i pots tornar a enviar-la quan existeixi una ruta, per exemple després d'emmagatzemar el `travel_address` de la contrapart a la teva entrada de llibreta d'adreces per a aquella cartera (per als actius enumerats a [Identificadors d'actius TRP](#identificadors-d’actius-trp)). ### Preus i llicències > [accordion] Quant costa Travel Rule, i està inclosa al meu pla de KYC o de verificació? > > Travel Rule és un producte separat, de pagament per ús. > No està inclosa en la verificació d'identitat. > Costa \*\*$0.02 per cada intercanvi de sortida que s'inicia** ([preus publicats](#preus), sense nivells de volum, sense trucada comercial). > Quan l'encaminament necessita una consulta d'analítica de blockchain per identificar el VASP contrapart, aquesta consulta es cobra una vegada a la [tarifa d'atribució](#preus-de-l’atribució): des de $0.15 si és gestionada, o \$0.02 amb una clau de proveïdor existent. > No es torna a cobrar si el monitoratge de criptoactius ja ha fet el cribratge de la mateixa cartera. > Una transferència per sota del teu llindar, o una registrada amb Travel Rule desactivada, es factura com a Transaction Screening; les transferències d'entrada, com els trams que Didit encunya al costat del beneficiari, no es cobren la tarifa de Travel Rule. > [accordion] Em cobraran dues vegades quan Travel Rule i el monitoratge de criptoactius s'executin els dos? > > No. > Una transacció `travelRule` es factura en una sola línia: la tarifa de Travel Rule (\$0.02) quan inicia un intercanvi de sortida, i altrament el Transaction Screening estàndard. La consulta d'analítica de blockchain es cobra una vegada: si el monitoratge de criptoactius ja ha fet el cribratge de la cartera de destinació de la transacció, [l'atribució](#atribució-mitjançant-analítica-de-blockchain) reutilitza aquell resultat emmagatzemat sense cost addicional. > Els trams d'entrada que Didit encunya al costat del beneficiari no es cobren mai la tarifa de Travel Rule. > [accordion] Pot Didit proporcionar documentació o una declaració de capacitats per al meu expedient de llicència VASP o expedient per al regulador? > > Sí. La detecció KYT i el monitoratge de transaccions de Didit, el cribratge AML i de sancions, l'anàlisi de risc de cartera amb analítica de blockchain i les capacitats de Travel Rule estan documentades públicament a docs.didit.me, i pots citar aquestes pàgines en un expedient regulador lliurement. Per a una declaració formal de capacitats del producte adaptada a una presentació concreta (per exemple, una sol·licitud de llicència VASP d'AIFC/AFSA, MiCA o d'una altra), contacta amb l'equip responsable del teu compte a Didit amb el format que exigeixi el teu regulador. ### Operacions i dades > [accordion] Què passa amb les transferències per sota del meu llindar? > > Es resolen immediatament com a `NOT_APPLICABLE`: no es prova cap canal i cap dada d'identitat surt de Didit. > La transacció es factura com a Transaction Screening estàndard, no com a tarifa de Travel Rule. > Didit compara el llindar amb l'import convertit a la moneda per defecte de la teva aplicació. > Si Didit no pot convertir l'import, el llindar no s'aplica i la transferència s'intercanvia. > El TFR de la UE no té mínim, per tant els CASP de la UE haurien de mantenir `threshold_amount` a `0.00`. > [accordion] Què passa si la contrapart mai respon? > > La transferència es queda a `AWAITING_COUNTERPARTY` fins que transcorrin `confirmation_timeout_hours`; llavors un procés automàtic la passa a `EXPIRED` i aplica el teu `timeout_outcome` a la transacció subjacent: `HOLD` per a revisió, `REJECT` per rebutjar-la o `PROCEED` per deixar-la sense canvis. La regla predefinida `tr_eu_expired_review` a més mostra cada expiració als teus analistes. Una contrapart que no rep mai el missatge és diferent: Didit el reintenta i, després del sisè intent fallit, la transferència passa a `COUNTERPARTY_VASP_NOT_REACHABLE` (vegeu [Lliurament i reintents](#lliurament-i-reintents)). > [accordion] La meva contrapart no té cap eina de Travel Rule. Encara puc complir? > > Sí: és el canal `EMAIL`. El seu contacte de compliment rep un enllaç de recollida d'un sol ús i pot confirmar o rebutjar l'intercanvi des d'una pàgina allotjada, sense compte de Didit, sense clau d'API i sense cap integració. Per als dipòsits que ja s'han liquidat abans de ser possible cap intercanvi, utilitza el [registre sunrise posterior al dipòsit](#registre-posterior-al-dipòsit). > [accordion] Com funcionen les retirades a la cartera pròpia de l'usuari? > > Declara la destinació com a autoallotjada (`payment_method.method_type: "unhosted_wallet"`). Didit omet l'encaminament cap a VASP i, en lloc d'això, recull prova que el teu client controla la cartera (signatura de missatges, prova Satoshi, captura de pantalla o autodeclaració) mitjançant el [widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md). Això és l'obligació del TFR de la UE sobre carteres autoallotjades en forma d'API. > [accordion] Les dades personals de la contrapart estan protegides durant l'intercanvi? > > Sí. > Fins que la titularitat de la cartera no es confirmi pel teu costat, les dades personals de la contrapart en una transferència entrant s'emmascaren, tant a l'objecte de la transferència com a la part de contrapart de la transacció (vegeu [Dades de contrapart emmascarades](#dades-de-la-contrapart-emmascarades)). > Les pàgines de recollida per correu només mostren el resum de la transferència (nom del VASP ordenant, import, cartera de destinació), mai els payloads de les persones. > Els intercanvis pels canals s'executen sobre HTTPS, i les xarxes (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) a més xifren el payload IVMS amb la clau pública del VASP receptor. > [accordion] Ja faig un seguiment del compliment de Travel Rule amb el meu propi procés. Puc registrar-ho només? > > Sí. Amb Travel Rule desactivada, qualsevol `travel_rule_details` que enviïs (inclòs un `status` indicat per qui fa la crida, actual o antic) es registra de manera passiva a la transacció: no es dispara cap canal ni es negocia res. Utilitza-ho per omplir dades retroactivament o per executar el teu propi procés mantenint un sol registre de referència. > [accordion] Com ho provo abans de passar a producció? > > Utilitza una aplicació sandbox amb Travel Rule activada. El sandbox omet les regles, la facturació i els webhooks `transaction.created` i `transaction.status.updated`, i cada intercanvi **sortint** va al [Didit Test VASP](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) pel canal `TEST_VASP`, que respon dins de Didit amb l'escenari que triïs: acceptar, rebutjar, discrepància de nom, no accessible, temps d'espera esgotat o autoallotjada. Reps webhooks `travel_rule.status.updated` marcats amb `environment: sandbox`, i cap missatge arriba a una contrapart real. > Per a transferències **entrants**, fes que el VASP de prova t'enviï una transferència amb [Activar una transferència entrant del VASP de prova](https://docs.didit.me/ca/management-api/travel-rule/trigger-test-vasp-inbound.md), o registra'n una amb `POST /v3/travel-rule/inbound/`; ambdues es decideixen segons la llibreta d'adreces de carteres: `ON_HOLD`, `UNCONFIRMED_OWNERSHIP`, `COUNTERPARTY_MISMATCHED_DATA`, o `COMPLETED` i després `FINISHED`. > Per a un intercanvi entre dues parts amb una altra aplicació real, utilitza dues de les teves aplicacions en **producció** pel canal `INTERNAL`: la receptora ha de ser localitzable i demostrar el control de la cartera de destinació amb un missatge signat o un dipòsit de prova. ## Següents passos > [card] [Widget de titularitat de la cartera](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md) > > Demostra que un client controla una cartera mitjançant signatura, prova Satoshi, captura de pantalla o autodeclaració. > [card] [Interoperabilitat](https://docs.didit.me/ca/transaction-monitoring/travel-rule-interoperability.md) > > Els endpoints orientats a la contrapart que altres VASP utilitzen per contactar-te: TRP, callbacks, recollida per correu, sunrise. > [card] [Xarxes](https://docs.didit.me/ca/transaction-monitoring/travel-rule-networks.md) > > A què arriba cada canal i xarxa avui, i què encara requereix una afiliació. > [card] [Prova al sandbox](https://docs.didit.me/ca/transaction-monitoring/travel-rule-sandbox.md) > > Prova tots els resultats amb el Didit Test VASP abans de passar a producció. > [card] [Enviament de transaccions](https://docs.didit.me/ca/transaction-monitoring/transactions.md) > > Com incloure dades de Travel Rule al payload de Create Transaction. > [card] [Biblioteca de regles](https://docs.didit.me/ca/transaction-monitoring/rules-library.md) > > El catàleg complet de regles predefinides, inclòs el paquet de Travel Rule. > [card] [Webhooks](https://docs.didit.me/ca/integration/webhooks.md) > > Subscriu-te a travel\_rule.status.updated i a la resta de famílies d'esdeveniments. > [card] [Guia de la consola](https://docs.didit.me/ca/transaction-monitoring/console.md) > > Consulta de l'estat de Travel Rule a la vista de detall de la transacció. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.