Travel Rule del FATF: API de compliment VASP

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, l’entrada de la llibreta d’adreces de la cartera de destinació n’emmagatzema una, o el VASP contrapart es resol al directori amb un endpoint TRP. Porta els actius que apareixen a 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. 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 per veure els modes efectius de networks de la teva aplicació, i Xarxes de Travel Rule 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). 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. 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 i torna a executar les vies una vegada amb el nou nom. Consulta 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 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.

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 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 que indica el canal, i l’objecte de transferència que retornen els endpoints de transferència Travel Rule inclou un camp delivery 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. Pas a pas:

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.
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) 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.
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.
Transferència Travel Rule. El motor d’intercanvi comprova el llindar i respecta una declaració de cartera autoallotjada, 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).
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 i es retorna a action_required.
Avaluació de regles. S’executa cada regla activa: el 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 (AWAITING_USER).
Facturació i notificació. Una transacció sortint es factura en una sola línia: la línia de Travel Rule 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.
Encaminament, després de la resposta. Didit recorre els set canals per ordre de prioritat; si cap canal no dona resultat, l’atribució d’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ó.

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), 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

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 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), 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.

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), o a UNCONFIRMED_OWNERSHIP quan la destinació s’ha declarat com a cartera autoallotjada, 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 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 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 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ó: 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` 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 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 la titularitat de la qual encara no està verificada. Avança mitjançant el widget de titularitat de la cartera o `POST .../travel-rule/ownership/`.
`ON_HOLD`	Didit només l’estableix en transferències entrants: la cartera de destinació d’un registre posterior al dipòsit o d’una consulta `TRP` entrant no és a la teva llibreta d’adreces, 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/`. No canvia per si sol l’estat de la transacció; la regla de la biblioteca 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/`. En una transferència entrant, Didit l’estableix quan el dipòsit ja s’ha liquidat (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 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) 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 (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.
`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), 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. 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 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).

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"):

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, Confirma la titularitat i registre sunrise 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, 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/.

curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "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 }
  }
}

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.
`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.
`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 `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 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: 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 ofereix l’autodeclaració com a mètode de prova, i pots crear entrades de la 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 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 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. Per defecte `true`.
`counterparty_screening_enabled`	boolean	Cribratge opcional de sancions i de mitjans adversos de les contraparts VASP, 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: 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. 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.
`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.
`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:

{
  "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:

{
  "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 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. 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:

{
  "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, 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.

{
  "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, 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. Quan coneixes la Travel Address d’una contrapart, guarda-la a l’entrada de la 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:

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 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, o registra-la tu mateix amb Registra una transferència entrant de Travel Rule. 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 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/ 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:

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.
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).
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, 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), 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 (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). 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.
Si cap via no pot resoldre una contrapart, Didit executa la cadena de descoberta de contraparts. Amb vasp_attribution_enabled activat, això inclou l’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, 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.
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 (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.

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, o l’indiques tu mateix amb `{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"}` a l’endpoint de transferències. 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.
`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). À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.
`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).

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:

{
  "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).

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.

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/:

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 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); sense cadena, s’omet. Quan la cartera s’atribueix a una entitat coneguda, Didit:

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".
Afegeix l’entitat al directori de VASP (o coincideix amb l’entrada existent), perquè l’atribució sigui estable entre transferències.
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ó. Consulta 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. 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:

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í:

{
  "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). El canal EMAIL només mostra al destinatari els camps de l’ordenant que comparteixes a data_sharing_fields.
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).

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ó 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ó 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ó.

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 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). Cada fila de GET /v3/transactions/ 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:

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; 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 per a l’entrada de la contrapart al directori, o catalogant el VASP al 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.

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 no ha pogut fer-ho, envia {"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"} (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}/, del 201 de POST /v3/transactions/, i de cada fila de GET /v3/transactions/ el porta, i també l’objecte de transferència amb què respon l’endpoint de transferència:

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, 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. `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 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, el bloc travel_rule de la seva transacció diu, abreujat:

{
  "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:

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.

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 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.
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 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.

La vostra aplicació confirma o denega la transferència:

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.

{"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).

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 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: 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/: 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. 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:

{
  "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:

{
  "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:

{
  "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, 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:

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) es puguin contrastar amb elles, amb POST/GET /v3/travel-rule/wallet-addresses/ i PATCH/DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/.

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.
`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; 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.
`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 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.

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/ 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/, 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.

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"

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 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, els detalls de recollida són:

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "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; 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ó.

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:

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:

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": "<uuid of the received message transaction>"}'

{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/.

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 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, 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: 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. 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 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, per l’adreça i el memo:

Cap entrada coincident -> ON_HOLD. Resol-la amb POST .../travel-rule/ownership/: 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, la resposta és:

{
  "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 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. 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/. Consulta Widget de titularitat de la cartera 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. Cada fila indica com pot arribar ara mateix la teva aplicació a aquest VASP.

curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \
  -H "x-api-key: YOUR_API_KEY"

{
  "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.
`responsiveness`	`RESPONSIVE`, `UNRESPONSIVE` o `UNKNOWN`: només les entrades del directori amb aquest `responsiveness.status`. Consulta 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 per saber què significa cadascun, i fes-los servir com a condicions amb els camps de regla de contrapart 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, 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 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:

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 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: 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.

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: adreça’ls amb el id que mostra el directori.

Endpoint	Què fa
`GET` / `PUT` / `DELETE /v3/travel-rule/vasps/{vasp_id}/decision/`	Llegeix, defineix o esborra la teva decisió sobre la contrapart.
`GET` / `POST /v3/travel-rule/vasps/{vasp_id}/screening/`	Llegeix el teu 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 amb la contrapart, o n’envia un.
`GET /v3/travel-rule/transfers/?counterparty={vasp_id}`	Les teves transferències amb aquesta 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 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.	`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, 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:

{ "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 o amb la configuració predefinida 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/:

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"}'

{
  "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 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 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ó. Mentre estigui desactivat, no es cribla ni es factura res.

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}'

{
  "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 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:

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"}'

{
  "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": {"<question id>": "<answer>"}} 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} 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 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:

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:

sunrise_policy, quan està definida i la jurisdicció de la contrapart és a sunrise_jurisdictions.
non_responsive_policy, quan està definida i la contrapart és UNRESPONSIVE.
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 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ó: `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 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:

`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ó.

{
  "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 ha respost porta rail: "TEST_VASP", test_vasp: true i test_vasp_scenario. Consulta la guia de webhooks 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 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.
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 é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 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, 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).
Biometria de verificació addicional per a transferències de risc. Una regla 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.
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, sense trams de volum i sense haver de trucar a vendes.

Preguntes freqüents

Com funciona l’intercanvi

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). Didit també conserva el registre complet i l’estat de compliment de cada intercanvi (un cicle de vida de 13 estats, 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ó (per defecte és false), i fins llavors Didit registra les dades de manera passiva.

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.

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. 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 per a la taula d’encaminament completa, i Xarxes de Travel Rule per saber què abasta cadascuna avui.

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 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 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, 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.

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 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. 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. 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).

Preus i llicències

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.

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ó 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.

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

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.

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).

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.

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. Això és l’obligació del TFR de la UE sobre carteres autoallotjades en forma d’API.

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). 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.

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.

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 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, 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

Widget de titularitat de la cartera

Demostra que un client controla una cartera mitjançant signatura, prova Satoshi, captura de pantalla o autodeclaració.

Interoperabilitat

Els endpoints orientats a la contrapart que altres VASP utilitzen per contactar-te: TRP, callbacks, recollida per correu, sunrise.

Xarxes

A què arriba cada canal i xarxa avui, i què encara requereix una afiliació.

Prova al sandbox

Prova tots els resultats amb el Didit Test VASP abans de passar a producció.

Enviament de transaccions

Com incloure dades de Travel Rule al payload de Create Transaction.

Biblioteca de regles

El catàleg complet de regles predefinides, inclòs el paquet de Travel Rule.

Webhooks

Subscriu-te a travel_rule.status.updated i a la resta de famílies d’esdeveniments.

Guia de la consola

Consulta de l’estat de Travel Rule a la vista de detall de la transacció.

Darrera modificació el 7 de novembre del 2026

​Visió general

​Què s’executa quan envies una transferència

​Com cada pas correspon a les teves obligacions

​Cicle de vida

​Lliurament i reintents

​Valors d’estat antics

​Configuració

​Rigor de la coincidència de noms

​Modes de validació de la titularitat

​Compartició de dades

​Coincidència per camp

​Llindars per jurisdicció

​Model de dades IVMS 101

​Dades verificades i procedència

​Enviar IVMS 101 directament

​Dades obligatòries per règim

​Travel Addresses

​Prova sense credencials de xarxa

​Enviar una transferència

​Identificadors d’actius TRP

​Descoberta de la contrapart

​Camps de resolució de la contrapart

​Formes de cadena

​Transferències UTXO

​Xarxes amb memo i etiqueta

​Lightning

​Actualitzar la cartera de l’ordenant

​Atribució mitjançant analítica de blockchain

​Per què una transferència està bloquejada

​Carteres autoallotjades declarades

​Recepció

​Confirmació de la titularitat de la cartera

​Transferències des d’una xarxa

​Dades de la contrapart emmascarades

​Retroacció de discrepàncies

​Puntuació de coincidència del nom

​Missatges i sol·licituds de documents

​Llibreta d’adreces de carteres

​Importar carteres en massa

​Recollida per correu electrònic per a contraparts inaccessibles

​Dipòsits sense correspondència

​Registre posterior al dipòsit

​Widget de titularitat de la cartera

​Directori

​Rutes

​Marques i les seves entitats

​Contactes

​Com entren les entrades al directori

​La xarxa de Didit

​Identificadors d’encaminament

​Diligència deguda sobre la contrapart

​Puntuació i nivell de risc

​Comprovacions essencials

​Capacitat de resposta

​La teva decisió sobre una contrapart

​Cribratge de contrapart

​Qüestionari de diligència deguda

​Transferències amb una contrapart

​Polítiques sunrise i de contraparts sense resposta

​Camps de regla i preconfiguracions

​Webhooks

​Preus

​Preus de l’atribució

​Regles del paquet TFR de la UE

​Per què això funciona millor en una sola plataforma

​Preguntes freqüents

​Com funciona l’intercanvi

​Preus i llicències

​Operacions i dades

​Següents passos

Widget de titularitat de la cartera

Interoperabilitat

Xarxes

Prova al sandbox

Enviament de transaccions

Biblioteca de regles

Webhooks

Guia de la consola

Visió general

Què s’executa quan envies una transferència

Com cada pas correspon a les teves obligacions

Cicle de vida

Lliurament i reintents

Valors d’estat antics

Configuració

Rigor de la coincidència de noms

Modes de validació de la titularitat

Compartició de dades

Coincidència per camp

Llindars per jurisdicció

Model de dades IVMS 101

Dades verificades i procedència

Enviar IVMS 101 directament

Dades obligatòries per règim

Travel Addresses

Prova sense credencials de xarxa

Enviar una transferència

Identificadors d’actius TRP

Descoberta de la contrapart

Camps de resolució de la contrapart

Formes de cadena

Transferències UTXO

Xarxes amb memo i etiqueta

Lightning

Actualitzar la cartera de l’ordenant

Atribució mitjançant analítica de blockchain

Per què una transferència està bloquejada

Carteres autoallotjades declarades

Recepció

Confirmació de la titularitat de la cartera

Transferències des d’una xarxa

Dades de la contrapart emmascarades

Retroacció de discrepàncies

Puntuació de coincidència del nom

Missatges i sol·licituds de documents

Llibreta d’adreces de carteres

Importar carteres en massa

Recollida per correu electrònic per a contraparts inaccessibles

Dipòsits sense correspondència

Registre posterior al dipòsit

Widget de titularitat de la cartera

Directori

Rutes

Marques i les seves entitats

Contactes

Com entren les entrades al directori

La xarxa de Didit

Identificadors d’encaminament

Diligència deguda sobre la contrapart

Puntuació i nivell de risc

Comprovacions essencials

Capacitat de resposta

La teva decisió sobre una contrapart

Cribratge de contrapart

Qüestionari de diligència deguda

Transferències amb una contrapart

Polítiques sunrise i de contraparts sense resposta

Camps de regla i preconfiguracions

Webhooks

Preus

Preus de l’atribució

Regles del paquet TFR de la UE

Per què això funciona millor en una sola plataforma

Preguntes freqüents

Com funciona l’intercanvi

Preus i llicències

Operacions i dades

Següents passos