API Travel Rule GAFI : conformité VASP

​

Vue d’ensemble

• Vous soumettez un transfert avec transaction_category: "travelRule".
• Didit essaie les canaux dans l’ordre de priorité pour atteindre le VASP de la contrepartie, exécute l’échange sur le premier qui l’atteint et, lorsque l’autre partie renvoie un nom de bénéficiaire, le compare à celui que vous avez envoyé.
• Ce n’est qu’une fois que l’échange atteint COMPLETED que vous devez diffuser le transfert on-chain.
• Vous renvoyez ensuite le hash de la transaction on-chain à Didit pour clôturer l’échange avec le statut FINISHED.

​

Ce qui s’exécute lors de l’envoi d’un transfert

1. Validation et rattachement du sujet. La charge utile est validée. Un transaction_id déjà utilisé dans votre application est rejeté avec 400, et lorsque deux requêtes portant le même identifiant arrivent en même temps, l’une d’elles reçoit 409. Le subject est rattaché à votre profil utilisateur ou entreprise via vendor_data, de sorte que le transfert apparaît sur ce profil pour la surveillance. Un sujet ou un vendor_data de contrepartie figurant sur une liste de blocage est rejeté avec 400, et aucune transaction n’est créée. Les portefeuilles, comptes bancaires, adresses IP et appareils figurant sur une liste de blocage sont vérifiés à l’étape 6 et refusent la transaction à ce stade, après l’exécution du routage.
2. Enrichissement de l’appareil et du réseau. Les adresses IP des parties sont enrichies de données de géolocalisation, et tout contexte d’appareil (automatique lors d’une soumission via le SDK) est normalisé dans le graphe des appareils. C’est le même graphe qu’alimentent les sessions KYC, de sorte que le critère « lié par appareil » fonctionne à travers l’onboarding et les transactions.
3. Filtrage crypto. Pour les transferts crypto avec la surveillance activée, le portefeuille concerné (ou le hash on-chain) est filtré auprès des outils d’analyse blockchain avant tout échange : exposition aux sanctions, proximité avec un mixeur, fonds volés. Voir Filtrage crypto et des portefeuilles.
4. Transfert Travel Rule. Le moteur d’échange vérifie le seuil et tient compte d’une déclaration de portefeuille auto-hébergé, puis enregistre le transfert : NOT_APPLICABLE sous votre seuil, UNCONFIRMED_OWNERSHIP pour un portefeuille auto-hébergé déclaré, COMPLETED lorsque l’autre portefeuille est votre portefeuille vérifié, et AWAITING_COUNTERPARTY dans les autres cas, avec un rail encore vide. Chaque changement de statut met en file d’attente un événement travel_rule.status.updated, et Didit l’envoie après le transaction.created de la transaction (étape 7).
5. Création de la session de preuve de propriété du portefeuille. Si le transfert exige une preuve de contrôle par l’utilisateur final et que auto_wallet_verification est activé, une session du widget de preuve de propriété du portefeuille est créée et renvoyée dans action_required.
6. Évaluation des règles. Toutes les règles actives s’exécutent : le ensemble EU TFR réagit au statut du transfert défini à l’étape 4, vos règles personnalisées tiennent compte du résultat du filtrage de l’étape 3, et une règle peut bloquer la transaction (IN_REVIEW), la refuser ou exiger une vérification renforcée (AWAITING_USER).
7. Facturation et notification. Une transaction sortante est facturée sur une seule ligne : la ligne Travel Rule lorsqu’elle lance un échange, et Transaction Screening dans le cas contraire. Un transfert entrant ne génère aucun de ces frais, et une application sandbox n’est jamais facturée. La réponse est renvoyée, transaction.created est envoyé à vos destinations de webhook, suivi des événements travel_rule.status.updated de l’étape 4.
8. Routage, après la réponse. Didit parcourt les sept rails par ordre de priorité. Si aucun ne permet de résoudre la contrepartie, l’attribution par analyse blockchain identifie la contrepartie et les rails sont relancés une fois. Le premier rail accessible achemine l’échange : le transfert reste AWAITING_COUNTERPARTY sur ce rail tant que la contrepartie ne répond pas, est réglé immédiatement lorsqu’une contrepartie INTERNAL correspondante est trouvée (COMPLETED ou COUNTERPARTY_MISMATCHED_DATA), ou passe à COUNTERPARTY_VASP_NOT_FOUND lorsqu’aucun rail n’atteint la contrepartie. Chaque changement déclenche travel_rule.status.updated, et vos règles sont à nouveau évaluées dès que le statut ou le rail change. Un transfert que le routage laisse en COUNTERPARTY_VASP_NOT_FOUND reçoit à ce moment sa session de widget de preuve de propriété du portefeuille (lorsque auto_wallet_verification est activé). Vous la lisez dans action_required de la transaction avec Get transaction.

​

Comment chaque étape correspond à vos obligations

​

Cycle de vie

​

Livraison et nouvelles tentatives

​

Valeurs de statut héritées

​

Configuration

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

​

Rigueur de la correspondance des noms

​

Modes de validation de la propriété

​

Partage de données

{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}

• Les personnes physiques peuvent partager name, wallet_address, address, national_id, customer_identification, date_of_birth et place_of_birth. Les entreprises utilisent les cinq premiers.
• name et wallet_address sont toujours envoyés.
• Un type d’entité que vous n’avez jamais choisi partage tous les champs. Une liste vide est elle aussi un choix : elle ne partage que le nom et le portefeuille.
• Un PUT fusionne par type d’entité : l’envoi de individual laisse le choix enregistré pour company inchangé.
• Un choix qui ne peut pas satisfaire les obligations applicables au donneur d’ordre dans le régime de votre jurisdiction (règlement UE sur les transferts de fonds ou Recommandation 16 du GAFI), y compris une liste vide, est refusé avec 400. Les erreurs figurent sous data_sharing_fields, indexées par type d’entité.

​

Correspondance par champ

{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}

​

Seuils par juridiction

​

Modèle de données IVMS 101

• Écriture latine. IVMS 101 exige des valeurs en système d’écriture latin ; translittérez les noms qui sont écrits nativement dans un autre système d’écriture. La correspondance des noms de Didit compare des ensembles de jetons normalisés : les différences d’ordre et de casse ne font donc pas échouer un échange, mais des systèmes d’écriture différents des deux côtés le feront.
• Envoyez les données que vous avez vérifiées. Lorsque la personne concernée par vendor_data est un utilisateur disposant d’une vérification KYC Didit approuvée, Didit transmet l’identité vérifiée, et non les valeurs que vous avez saisies : voir Données vérifiées et provenance. Pour toute autre personne, Didit transmet exactement le originator_data que vous envoyez. Construisez-le donc à partir de l’identité que vous avez vérifiée lors de l’onboarding, et non à partir d’un champ de formulaire non vérifié. C’est ce qu’exige la formulation de la FATF : « informations requises et exactes sur le donneur d’ordre ». Sur le canal INTERNAL, l’application du bénéficiaire reçoit aussi le subject que vous avez envoyé (nom, vendor_data, date de naissance, pays et adresse) en tant que contrepartie de sa transaction entrante.

​

Données vérifiées et provenance

• le donneur d’ordre d’un transfert sortant que vous créez avec POST /v3/transactions/ ;
• le bénéficiaire d’un transfert entrant que vous signalez avec POST /v3/transactions/, ou avec POST /v3/travel-rule/inbound/ lorsque le holder_vendor_data du portefeuille correspondant désigne cet utilisateur.

{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}

​

Envoyer directement de l’IVMS 101

• un bloc originator et un bloc beneficiary, avec originatorPersons ou beneficiaryPersons contenant un naturalPerson ou un legalPerson, ainsi que accountNumber ;
• les mêmes blocs à l’intérieur d’un objet ivms101 (ou IVMS101) ;
• une personne IVMS 101, ou un bloc complet, en tant que originator_data ou beneficiary_data.

{
  "travel_rule_details": {
    "status": "AWAITING_COUNTERPARTY",
    "beneficiary": {
      "beneficiaryPersons": [
        {
          "naturalPerson": {
            "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] }
          }
        }
      ],
      "accountNumber": ["0xBeneficiaryWallet01"]
    }
  }
}

​

Données requises par régime

​

Travel Addresses

ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx

​

Tester sans identifiants réseau

• Sandbox sortant : soumettez une transaction travelRule depuis une application sandbox. Après les contrôles de seuil et de portefeuille auto-hébergé, le Didit Test VASP y répond au sein de Didit avec le scénario que vous choisissez selon le portefeuille ou le nom du bénéficiaire : acceptation, refus, nom non concordant, injoignable, expiration du délai ou auto-hébergé. Aucun réseau, aucun e-mail ni aucun autre client de Didit ne reçoit quoi que ce soit.
• Sandbox entrant : faites envoyer un transfert par le test VASP avec Trigger Test VASP Inbound Transfer, ou enregistrez-en un vous-même avec Register Inbound Travel Rule Transfer. Testez un portefeuille inconnu, un portefeuille non vérifié, une non-concordance de nom de bénéficiaire et un portefeuille vérifié correspondant. Ces scénarios permettent de tester de véritables décisions entrantes sans contacter de réseau.
• Deux applications en production contrôlées : utilisez le canal INTERNAL entre deux de vos applications en production (l’application destinataire est détectable et prouve la maîtrise du portefeuille de destination au moyen d’un message signé ou d’un dépôt de test), ou une contrepartie TRP que vous contrôlez, pour tester un échange entre deux parties sans identifiants commerciaux de réseau. Les applications en production peuvent entraîner des frais et des notifications normaux ; utilisez des identités de test et des contreparties que vous contrôlez.

​

Envoyer un transfert

1. Si le montant est inférieur au threshold_amount configuré, le transfert passe immédiatement à NOT_APPLICABLE et aucune négociation n’a lieu.
2. Si le moyen de paiement de la contrepartie déclare la destination comme portefeuille auto-hébergé (payment_method.method_type: "unhosted_wallet"), aucun canal n’est essayé : le transfert passe directement à UNCONFIRMED_OWNERSHIP et le widget de propriété du portefeuille est généré automatiquement (voir Portefeuilles auto-hébergés déclarés).
3. Sinon, les canaux sont essayés dans l’ordre de priorité, et le premier capable d’atteindre la contrepartie prend en charge l’échange :
   • INTERNAL : exactement un autre client Didit détient une preuve par message signé ou par dépôt test pour beneficiary_data.wallet_address, établie après le dernier changement de titulaire du portefeuille. Votre propre application ne compte jamais, et lorsque votre utilisateur final a choisi un membre du réseau Didit dans le widget de propriété du portefeuille, seule la preuve de ce membre compte. L’application de ce client est en production (et non en sandbox), a Travel Rule activé et is_discoverable défini, et correspond au VASP que vous avez indiqué lors de l’envoi de counterparty_vasp_lei ou counterparty_vasp_name. Un portefeuille seulement déclaré, prouvé par une capture d’écran, non vérifié ou simplement répertorié dans un carnet d’adresses ne reçoit jamais rien par INTERNAL.
   • TRP : l’actif du transfert dispose d’une correspondance Digital Token Identifier pour le réseau du transfert (voir Identifiants d’actifs TRP), et la charge utile contient beneficiary_data.travel_address, l’entrée du carnet d’adresses de la destination en contient une, ou la contrepartie se résout dans l’annuaire (par counterparty_vasp_lei ou counterparty_vasp_name) avec un point de terminaison TRP.
   • GTR, TRUST, VERIFYVASP, SYGNA : vous avez connecté votre propre adhésion à ce réseau dans Marketplace, et la contrepartie se résout en identifiant de réseau (champ explicite ou entrée de l’annuaire, voir Champs de résolution de la contrepartie). Didit ne détient aucune adhésion de plateforme sur ces réseaux pour l’instant (il est en cours d’onboarding en tant que prestataire), donc disabled_networks ne modifie pas cette étape aujourd’hui.
   • EMAIL : beneficiary_data.counterparty_vasp_email a été fourni, ou counterparty_vasp_name se résout en une entrée de l’annuaire avec un e-mail de conformité.
4. Si aucun canal ne parvient à résoudre une contrepartie, Didit exécute la chaîne de découverte de la contrepartie. Lorsque vasp_attribution_enabled est activé, cette chaîne comprend l’attribution par analyse de blockchain : le portefeuille de destination est rattaché à son VASP propriétaire, le nom attribué est inscrit dans beneficiary_data.counterparty_vasp_name (si le champ est vide) et dans l’annuaire, puis les canaux sont relancés une fois. Ainsi, un portefeuille attribué à un VASP dont l’entrée de l’annuaire comporte un point de terminaison TRP, un identifiant de réseau ou un e-mail de conformité est acheminé lors de ce second passage.
5. Si la contrepartie reste non résolue, le transfert passe à COUNTERPARTY_VASP_NOT_FOUND. Pour les transferts sortants, Didit génère automatiquement le widget de propriété du portefeuille (lorsque auto_wallet_verification est activé) afin que le transfert puisse tout de même aboutir comme transfert vers un portefeuille auto-hébergé, et vous pouvez relancer le routage plus tard avec action: "resend" une fois que vous disposez de meilleures données sur la contrepartie.

​

Identifiants d’actifs TRP

​

Découverte de la contrepartie

​

Champs de résolution de la contrepartie

​

Formes de chaîne

​

Transferts UTXO

• Donneur d’ordre : originator_data.wallet_address lorsque vous l’envoyez, sinon l’adresse d’entrée ayant apporté le montant le plus élevé (source: largest_input).
• Bénéficiaire : le portefeuille déclaré, sinon l’unique sortie qui ne renvoie pas de monnaie à une adresse d’entrée (only_non_change_output), sinon la sortie correspondant au montant du transfert (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" }
        ]
      }
    }
  }'

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

​

Réseaux à mémo et à tag

• Une entrée du carnet d’adresses avec un mémo ne correspond qu’aux transferts qui mentionnent ce mémo. Une entrée sans mémo correspond à l’ensemble de l’adresse. Un transfert qui ne mentionne aucun mémo n’atteint jamais une entrée qui en a un : sur une adresse partagée, un dépôt sans son tag n’appartient à personne.
• Une X-address XRP contient son tag : Didit la découpe en adresse classique et en tag (source: x_address), si bien qu’un portefeuille enregistré sous l’une ou l’autre forme correspond à un transfert exprimé sous l’autre forme.
• Chaque mémo sur une adresse partagée constitue son propre moyen de paiement sur la transaction.
• Formats acceptés par réseau : un tag de destination XRP est un nombre entier de 0 à 4294967295 (un nombre JSON est accepté) ; un mémo Stellar comporte jusqu’à 28 octets de texte, un identifiant sur 64 bits ou un hash de 32 octets en hexadécimal ; EOS accepte jusqu’à 256 octets, Cosmos jusqu’à 256 caractères, Hedera jusqu’à 100 octets. Un mémo sur une chaîne qui n’en a pas (Bitcoin, chaînes EVM, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning) renvoie une erreur 400.

​

Lightning

​

Mise à jour du portefeuille donneur d’ordre

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

• Transferts sortants uniquement, et jamais un transfert CANCELLED ou EXPIRED (409).
• Lorsque les entrées UTXO du transfert sont connues, le portefeuille doit en faire partie (sinon 400). Envoyez aussi memo sur un réseau à mémo.
• Seul l’enregistrement est modifié : rien n’est envoyé à nouveau à la contrepartie et le statut reste inchangé. chain_details.originator devient le nouveau portefeuille avec source: updated, la timeline enregistre l’ancien et le nouveau portefeuille, et la contrepartie INTERNAL du transfert est mise à jour de la même manière.

​

Attribution par analyse de la blockchain

1. Enregistre l’attribution sur le transfert : beneficiary_data.counterparty_vasp_name est renseigné (si vous ne l’avez pas fourni), et les métadonnées du transfert contiennent un bloc vasp_attribution avec le nom de l’entité, son type, son pays et source: "blockchain_analytics".
2. Ajoute l’entité à l’annuaire VASP (ou rapproche l’entrée existante), afin que l’attribution reste stable d’un transfert à l’autre.
3. Relance une fois les canaux avec le nom attribué : une entrée d’annuaire qui comporte déjà un endpoint TRP permet d’acheminer immédiatement le transfert, au lieu de le faire aboutir à COUNTERPARTY_VASP_NOT_FOUND.

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

{
  "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 correspond à ce que vous avez envoyé, car le sujet de l’exemple n’a pas de vérification KYC approuvée ; pour un utilisateur vérifié, Didit le construit à partir des données vérifiées (voir Données vérifiées et provenance). Le rail EMAIL n’affiche au destinataire que les champs du donneur d’ordre que vous partagez dans data_sharing_fields.
• beneficiary_data.chain vaut ETH car la requête n’indiquait aucune chaîne ; Didit l’a déduite de la devise.
• status vaut APPROVED car aucune règle n’a agi sur la transaction ; vos propres règles peuvent lui attribuer un autre statut.
• Le contact de conformité reçoit le lien de récupération, et le transfert se termine, échoue au contrôle de correspondance du nom ou est refusé lorsque le contact répond, ou expire s’il ne répond pas (voir Récupération par e-mail).

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

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

​

Pourquoi un transfert est bloqué

• reason est la cause lisible par la machine, "" pour tout autre statut.
• next_actions liste les actions qui font avancer le transfert, [] pour tout autre statut.
• delivery est le message le plus récent que le transfert doit envoyer à l’autre partie : kind, status (QUEUED, SENDING, RETRYING, DELIVERED ou FAILED), rail, attempts, last_error, next_attempt_at et delivered_at, ou null lorsqu’il n’en doit aucun.
• discovery indique où Didit a cherché la contrepartie, avec une entrée par étape exécutée : step, outcome (match, miss ou skipped), reason, vasp, rail et at.

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

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

​

Portefeuilles auto-hébergés déclarés

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

• Aucun rail n’est essayé, car il n’existe aucun VASP de contrepartie avec lequel échanger, et le transfert est créé directement dans UNCONFIRMED_OWNERSHIP.
• Lorsque auto_wallet_verification est activé (valeur par défaut), Didit génère automatiquement une session de widget de vérification de la propriété du portefeuille liée à la transaction et la renvoie dans le bloc action_required de la transaction ; les SDK la lancent automatiquement lors de la soumission côté client.
• Dès que le client prouve le contrôle du portefeuille, le transfert effectue la vérification de correspondance du nom du bénéficiaire et passe à COMPLETED (ou à COUNTERPARTY_MISMATCHED_DATA si la correspondance échoue).

​

Réception

​

Confirmation de la propriété du portefeuille

• Un transfert entrant correspond à une entrée du carnet d’adresses dont la propriété n’est pas encore vérifiée.
• Le portefeuille de la contrepartie a été déclaré auto-hébergé (counterparty.payment_method.method_type: "unhosted_wallet"), pour un retrait sortant ou un dépôt entrant. Voir Portefeuilles auto-hébergés déclarés.

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

• UNCONFIRMED_OWNERSHIP, dans les deux sens.
• ON_HOLD sur un transfert entrant.
• UNCONFIRMED_OWNERSHIP, ON_HOLD ou COUNTERPARTY_MISMATCHED_DATA sur un transfert entrant TRP, afin qu’un responsable de la conformité puisse traiter manuellement une demande de la contrepartie.

• confirmed: true marque l’entrée correspondante du carnet d’adresses de portefeuilles comme propriété vérifiée, puis lance la correspondance de nom avec le holder_name de cette entrée : COMPLETED si elle réussit, COUNTERPARTY_MISMATCHED_DATA sinon. La contrepartie sur le rail INTERNAL, lorsqu’elle existe, reçoit le même résultat. Pour un portefeuille auto-hébergé déclaré, confirmed: true enregistre que votre client a vérifié qui contrôle le portefeuille de la contrepartie et termine le transfert (COMPLETED), en sortie comme en entrée. Un transfert entrant dont le dépôt a déjà été réglé passe directement à FINISHED.
• confirmed: false fait passer les deux côtés du transfert à COUNTERPARTY_VASP_GENERAL_DECLINE.
• L’entrée correspondante est recherchée dans votre propre carnet d’adresses uniquement par adresse de portefeuille, sans tenir compte de la chaîne. Résoudre un ON_HOLD entrant sans entrée correspondante crée l’entrée à partir de beneficiary_data.wallet_address du transfert et la marque comme vérifiée. Un portefeuille auto-hébergé déclaré fait exception : il est enregistré dans votre carnet d’adresses comme propriété vérifiée, comme décrit ci-dessous. Dans tous les autres cas, une entrée absente renvoie 409 avec {"detail": "wallet address entry no longer available"}, ce qui est aussi la réponse pour une entrée supprimée.

• confirmed: true nécessite une adresse de paiement à renvoyer, prise dans le wallet_address de la requête, puis dans l’entrée correspondante, puis dans beneficiary_data.wallet_address. Si aucune des trois n’est disponible, la requête renvoie 400 avec {"wallet_address": ["wallet_address is required to approve."]}. Didit crée ou vérifie l’entrée, envoie à la contrepartie le rappel de résolution de la demande, définit ownership_confirmed et fait passer le transfert à COMPLETED.
• confirmed: false envoie une résolution de refus et fait passer le transfert à COUNTERPARTY_VASP_GENERAL_DECLINE.
• Si l’endpoint de rappel de la contrepartie est injoignable, la requête renvoie 502 et le transfert conserve son statut actuel. En cas d’approbation, l’entrée du carnet d’adresses du portefeuille est tout de même créée ou marquée comme vérifiée.

{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}

• Un transfert par réseau déjà traité sur son réseau (transfert VerifyVASP, ou transfert GTR ou Sygna Bridge déjà tranché) renvoie 409 (voir Transferts depuis un réseau).

​

Transferts depuis un réseau

• Routage. Le message vous parvient lorsqu’il désigne le code de participant de votre propre adhésion connectée sur ce réseau. Un message adressé à l’adhésion propre de Didit ne vous parvient que si vous êtes l’unique client Didit actif ayant prouvé le contrôle du portefeuille bénéficiaire. Tout autre message est refusé, afin qu’aucun client ne reçoive jamais le transfert d’un autre client.
• Décision. Didit crée le transfert entrant sur votre application et le décide comme une demande TRP : correspondance du portefeuille, propriété, correspondance des noms et inbound_auto_accept.
• Une seule fois. Les réseaux renvoient un message tant qu’il n’a pas reçu de réponse. Une répétition reçoit la réponse de la première copie, et rien n’est créé ni décidé deux fois.
• Votre examen, sur GTR et SYGNA. Un transfert qui attend votre décision (UNCONFIRMED_OWNERSHIP, ON_HOLD ou COUNTERPARTY_MISMATCHED_DATA) se décide avec POST .../travel-rule/ownership/ : confirmed: true l’approuve (transmettez wallet_address lorsque le transfert n’en désigne aucun) et confirmed: false le refuse. Didit répond au réseau après la réponse, avec les mêmes nouvelles tentatives. Un transfert déjà traité renvoie 409.
• Pas de réponse ultérieure sur VERIFYVASP. VerifyVASP obtient sa réponse au moment où il la demande : un transfert qui nécessiterait votre examen est refusé immédiatement et ne peut plus être décidé ensuite (409).

​

Données de la contrepartie masquées

{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}

​

Retour sur les écarts

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

​

Score de correspondance du nom

{
  "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 est la similarité des deux noms complets, de 0 à 100, et vaut 0 lorsque l’un des deux est vide. matched est le résultat au niveau strictness, de sorte que les deux peuvent diverger : FUZZY tranche sur son propre ratio de similarité de 0.85.
• matched_names sont les mots du nom du virement retrouvés dans l’autre nom ; mismatched_names sont les mots que l’un des deux côtés possède et que l’autre n’a pas.
• method vaut none, exact_token, token_subset, token_containment ou sequence_ratio, pour NONE, STRICT, DEFAULT, CONTAINS et FUZZY.
• compared_with vaut wallet_holder (le titulaire enregistré pour le portefeuille) ou counterparty_vasp (le nom donné par la contrepartie sur la page de réponse par e-mail, ou la réponse du Didit Test VASP).
• L’issue du virement suit data_match, qui compare chaque champ. Un virement peut donc être COUNTERPARTY_MISMATCHED_DATA alors que name_match.matched vaut true.
• name_match figure dans l’objet virement renvoyé par les endpoints Travel Rule et dans travel_rule intégré à la transaction, et vaut null tant qu’aucun nom n’a été comparé. La liste des virements et les webhooks ne le contiennent pas.
• Les noms sont masqués tant que les parties sont masquées, et sur la copie de l’autre client d’un échange INTERNAL.

​

Messages et demandes de documents

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 vaut MESSAGE (par défaut) ou DOCUMENT_REQUEST. Une demande de document exige au moins une entrée dans requested_documents (jusqu’à 10) ; un message exige un body (jusqu’à 5000 caractères) ou un fichier.
• reply_to désigne un message antérieur du même virement. Une réponse de l’autre côté qui contient un document satisfait la demande de document à laquelle elle répond, et fulfilled_at y est renseigné. Votre propre réponse ne satisfait jamais votre propre demande.
• Envoyez en multipart avec files pour joindre jusqu’à 5 fichiers de 10 Mo chacun, au format PDF, PNG, JPEG ou WebP. Didit vérifie le contenu de chaque fichier, et pas seulement son type déclaré. Tout autre fichier renvoie 400 sur files (« Joignez uniquement des fichiers PDF, PNG, JPEG ou WebP. »).
• Un virement peut contenir jusqu’à 100 messages, dont jusqu’à 20 peuvent porter des pièces jointes (chacune avec jusqu’à 5 fichiers), en comptant les deux côtés. Au-delà de l’une ou l’autre limite, la requête renvoie 400. Les pièces jointes des messages ne comptent pas dans les documents propres à la transaction.
• Les messages fonctionnent sur les canaux INTERNAL et EMAIL. Sur INTERNAL, l’autre client Didit voit le message de son côté de la paire. Sur EMAIL, la contrepartie reçoit un e-mail et répond dans le portail de retrait. Si cet e-mail de notification ne peut pas être envoyé, le message est tout de même enregistré et la requête renvoie 201.
• La requête renvoie 409, avec une raison dans detail, pour un virement sur TRP, GTR, TRUST, VerifyVASP ou Sygna (ces protocoles ne transportent pas de messages), un virement sans contrepartie pour l’instant, un virement INTERNAL dont les données ne correspondaient pas au titulaire du portefeuille (rien n’a atteint le destinataire), un virement INTERNAL dont le destinataire n’a pas encore prouvé le contrôle du portefeuille (des deux côtés, tant qu’il ne l’a pas fait), un virement EMAIL dont la contrepartie n’a plus d’adresse e-mail de conformité, et un virement EMAIL dont le lien de retrait a expiré ou dont le virement est clos.
• Aucun webhook n’est déclenché lorsque la contrepartie répond. Consultez l’endpoint des messages.
• L’e-mail qui informe la contrepartie d’un nouveau message est envoyé en anglais.

​

Carnet d’adresses de portefeuilles

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

​

Import en masse de portefeuilles

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

​

Récupération par e-mail pour les contreparties injoignables

• Aux bonnes adresses. Une counterparty_vasp_email que vous transmettez est le seul destinataire. Sinon, Didit écrit à trois adresses au maximum : les contacts de la contrepartie qui n’ont pas rebondi (les vôtres d’abord, puis ceux de la plateforme, en donnant la priorité à ceux qui ont déjà répondu), puis l’e-mail de conformité de l’entrée de l’annuaire lorsqu’un emplacement reste libre. Chaque adresse reçoit son propre e-mail.
• En votre nom. L’e-mail provient de l’adresse de Didit sous le nom « votre nom légal via Didit », dans la langue de la juridiction de la contrepartie (l’anglais lorsqu’elle n’est pas connue), et le lien ouvre la page de réponse dans cette langue. Vous ne recevez aucune copie : suivez la chronologie du transfert.
• Avec des relances. Tant que la contrepartie n’a pas répondu, Didit la relance 72, 24 et 6 heures avant l’échéance, au moins 12 heures après la demande ou la dernière relance, et jamais après l’échéance.
• Avec la gestion des rebonds. Un rebond ou une plainte pour spam marque le contact atteint comme invalide, avec sa raison, et la chronologie du transfert le consigne. Un contact de la plateforme est alors invalide pour tous les clients de Didit ; le contact propre à votre application ne l’est que pour votre application. Lorsque l’envoi d’e-mails de Didit cesse totalement pour une adresse (après un rebond permanent, une plainte pour spam ou un désabonnement), chaque contact à cette adresse est marqué invalide (suppressed), et ces contacts redeviennent valides dès que l’envoi vers l’adresse reprend. Lorsqu’il ne reste aucune adresse à laquelle écrire, le transfert passe à COUNTERPARTY_VASP_NOT_REACHABLE, avec la raison du serveur de messagerie destinataire dans sa chronologie. Un rebond permanent ou une plainte pour spam sur la counterparty_vasp_email que vous avez transmise produit cet effet immédiatement, car c’est le seul destinataire ; un rebond temporaire (soft_bounce) sur cette adresse, ou sur l’e-mail de conformité de l’entrée de l’annuaire, laisse la demande ouverte pour les relances.

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
}

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

​

Dépôts non rapprochés

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

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

​

Enregistrement a posteriori (sunrise)

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

• Aucune entrée correspondante -> ON_HOLD. Résolvez-la avec POST .../travel-rule/ownership/ : confirmed: true ajoute le portefeuille à votre carnet d’adresses comme vérifié et lance la correspondance du nom ; en cas de correspondance, le transfert passe à COMPLETED, puis à FINISHED.
• L’entrée existe mais la propriété n’est pas prouvée -> UNCONFIRMED_OWNERSHIP.
• Le nom du bénéficiaire ne correspond pas au holder_name de l’entrée -> COUNTERPARTY_MISMATCHED_DATA.
• Entrée vérifiée et nom correspondant -> COMPLETED, puis immédiatement FINISHED (le dépôt a déjà été réglé).

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

​

Widget de propriété du portefeuille

​

Annuaire

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": []
    }
  ]
}

​

Routes

• TRP lorsque l’entrée comporte un point de terminaison TRP vérifié par l’annuaire.
• GTR, TRUST, VERIFYVASP, SYGNA lorsqu’un réseau répertorie le VASP sous un code. La route n’est available que si votre application peut envoyer via ce réseau aujourd’hui (via: own_membership pour votre propre adhésion connectée, via: didit_membership pour celle de Didit). Sinon, elle est unavailable avec reason: no_membership ou reason: network_switched_off, et n’est jamais présentée comme un moyen d’atteindre le VASP. Les adhésions de Didit aux réseaux ne sont pas encore opérationnelles : aujourd’hui, une route réseau n’est donc disponible que via une adhésion que vous avez connectée dans la Marketplace.
• EMAIL lorsqu’il existe un contact de conformité pour l’entrée.
• INTERNAL pour un membre du réseau Didit.

​

Marques et leurs entités

​

Contacts

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/ liste chaque contact auquel votre application peut écrire, y compris les contacts de plateforme et ceux qui ont rebondi, du plus récent au plus ancien, paginés avec limit et offset. Filtrez avec ?counterparty= et l’id d’une entrée de l’annuaire ; une valeur qui n’est pas un UUID renvoie 400.
• POST ajoute un contact privé (counterparty, email, name facultatif) et renvoie 201. Ajouter une adresse que l’entrée possède déjà parmi vos propres contacts renvoie ce contact. Une entrée inconnue renvoie 400 ("No directory entry with this id.").
• DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/ supprime l’un de vos propres contacts (204). Les contacts de plateforme ne peuvent pas être supprimés et renvoient 404.

​

Comment les entrées sont ajoutées à l’annuaire

• Le registre intérimaire MiCA de l’ESMA des prestataires de services sur crypto-actifs, consulté chaque semaine : le nom de chaque prestataire, son LEI et son État membre d’origine.
• L’annuaire public TRISA, consulté chaque semaine : qui est chaque membre, son pays et son inscription TRISA. Toute inscription que l’annuaire n’affiche plus pendant trois semaines est supprimée.
• Le registre mondial LEI complète le LEI, les autres raisons sociales et le pays d’une entrée, et retrouve le LEI d’une entrée à partir de sa raison sociale exacte dans son pays.
• Attribution par analyse blockchain ajoute ou associe le VASP qui possède un portefeuille de destination, et conserve le nom attribué comme alias.
• L’équipe Didit organise les entrées : identifiants de routage et inscriptions sur les réseaux qu’elle a vérifiés, contacts de conformité, alias, marques et leurs entités, doublons fusionnés et entrées masquées.

​

Le réseau Didit

• votre application est en production (et non en sandbox) et la Travel Rule est activée ;
• is_discoverable vaut true et legal_name est renseigné ;
• compliance_email est renseigné et confirmé : envoyez la confirmation avec POST /v3/travel-rule/settings/compliance-email/confirmation/ et ouvrez le lien reçu par e-mail. Modifier l’adresse nécessite une nouvelle confirmation ;
• Didit n’a pas marqué l’application comme une application de test, de démonstration ou interne.

​

Identifiants de routage

​

Diligence raisonnable sur la contrepartie

• L’évaluation partagée. Chaque entrée de l’annuaire porte un score de diligence raisonnable, son niveau de risque, un statut de réactivité et un rapport de contrôles essentiels. Didit les calcule à partir des données propres à la plateforme, de sorte que tous les clients voient les mêmes valeurs.
• Vos propres dossiers. Votre décision concernant le VASP, le filtrage des sanctions et de la presse négative le concernant, ainsi que les questionnaires de diligence raisonnable échangés avec lui, appartiennent uniquement à votre application. Aucun autre client ne les voit, et ils ne modifient jamais l’entrée partagée.

​

Score et niveau de risque

​

Contrôles essentiels

​

Réactivité

{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }

• Comptabilisées : les requêtes envoyées par un canal réseau ou protocolaire, ainsi que les requêtes envoyées par e-mail à une adresse partagée, c’est-à-dire l’adresse de conformité de l’entrée ou un contact de la plateforme.
• Jamais comptabilisées : une requête envoyée par e-mail à une adresse saisie par un client, ou à un contact privé d’un client. Cet échange reste dans l’historique de transferts du client et ne qualifie jamais le VASP aux yeux des autres.
• Répondues : COMPLETED, FINISHED, COUNTERPARTY_VASP_GENERAL_DECLINE ou COUNTERPARTY_MISMATCHED_DATA. Un refus ou une discordance constitue une réponse : le VASP a répondu.
• Sans réponse : EXPIRED.
• Ni l’un ni l’autre : tous les autres statuts. Une requête CANCELLED relève de l’initiative de l’expéditeur, COUNTERPARTY_VASP_NOT_REACHABLE peut être un échec du côté de l’expéditeur, et une requête encore en cours n’est pas encore décidée.

​

Votre décision sur une contrepartie

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

• La décision est privée pour votre application : aucun autre client ne la voit, et elle ne modifie jamais l’entrée partagée.
• Une décision ne change rien à elle seule et ne modifie jamais l’acheminement d’un transfert. Elle s’applique à vos transactions par l’intermédiaire du champ de règle counterparty_dd_status : installez les préréglages, ou écrivez votre propre règle sur ce champ.
• Une décision sur une marque couvre chacune de ses entités qui n’a pas de décision propre, et l’entité affiche la marque dans inherited_from. Une décision sur l’entité remplace celle de la marque pour cette entité.
• GET renvoie la décision applicable, ou {"decision": null}. DELETE supprime votre propre décision et renvoie celle qui s’applique ensuite : la décision de la marque pour une entité, sinon null. Il répond 404 lorsque votre application n’a aucune décision propre sur la contrepartie.
• reason est facultatif, limité à 255 caractères, et chaque PUT le remplace. decided_by est l’utilisateur de la console qui a pris ou modifié en dernier la décision, et il est vide lorsqu’une clé API l’a fait.

​

Filtrage de la contrepartie

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

• Facturation. Chaque nouveau filtrage coûte le prix du Filtrage AML pour entreprises de votre organisation. GET /v3/travel-rule/vasps/{vasp_id}/screening/ renvoie ce price, fresh_days et si le filtrage est enabled, sans frais. Un filtrage datant de moins de 30 jours est considéré comme récent : POST le renvoie à nouveau avec 200 et outcome: reused sans rien facturer, sauf si vous envoyez refresh: true. Un nouveau filtrage répond 201 avec outcome: screened. Les applications sandbox ne sont jamais filtrées ni facturées.
• Filtrage automatique. Lorsque le filtrage est activé, Didit filtre aussi la contrepartie vers laquelle est effectué un échange sortant dès le début de celui-ci, avant que vos règles n’évaluent la transaction, avec la même réutilisation et la même facturation. Un refus ou un échec à cette étape ne fait jamais échouer le transfert.
• Résultat. status vaut Approved lorsqu’aucune correspondance possible ne demande d’attention, et In Review ou Declined pour une correspondance possible avec des sanctions ou de la presse négative. flagged vaut true tant qu’un filtrage récent est In Review ou Declined.
• Effet. Tant que votre dernier filtrage de la contrepartie est signalé et que le filtrage reste activé, counterparty_risk_level vaut HIGH dans vos règles, de sorte que le préréglage travel-rule-counterparty-high-risk, une fois installé, met en attente ses transferts. Le risk_level partagé du répertoire ne change pas.
• Confidentialité. Le filtrage est privé pour votre application : aucun autre client ne le voit, et il ne modifie jamais l’entrée partagée. Le répertoire affiche votre dernier filtrage sous entity_screening.
• Refus. 409 lorsque le filtrage est désactivé, pour une application sandbox, ou lorsqu’un filtrage de la même contrepartie est déjà en cours. 403 avec code: insufficient_credits lorsque votre solde ne couvre pas le prix. 502 lorsque le filtrage n’a pas pu être terminé. Aucun de ces cas ne facture quoi que ce soit.

​

Questionnaire de diligence raisonnable

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

• Destinataire. sent_to doit être une adresse de conformité enregistrée : pour une entrée du répertoire, son adresse de conformité ou un contact que votre application voit dans contacts ; pour un membre du réseau Didit, son e-mail de conformité confirmé. Omettez-le pour utiliser l’adresse à laquelle est envoyé un e-mail Travel Rule à la contrepartie : d’abord votre propre contact, puis un contact de la plateforme, puis l’adresse de conformité de l’entrée. Didit n’envoie jamais le questionnaire ailleurs, et répond 400 lorsque la contrepartie n’a aucune adresse de conformité enregistrée.
• Réponses. Le lien ouvre /v3/travel-rule/questionnaires/{token}/, une page destinée à une personne de la contrepartie, qui ne nécessite ni compte ni clé API. Elle répond à chaque question, jusqu’à 2 000 caractères chacune (N/A lorsqu’une question ne s’applique pas), et soumet une seule fois. Une contrepartie peut aussi envoyer {"answers": {"<question id>": "<answer>"}} au même lien. Un lien déjà utilisé, remplacé ou dépassant sa date limite affiche une page d’expiration à la place. L’e-mail et la page sont traduits ; les questions elles-mêmes restent en anglais, afin que leur sens ne change jamais d’une langue à l’autre.
• Délais. La contrepartie dispose de 30 jours pour répondre (expires_at). Les réponses restent valables pendant 365 jours (valid_until), et current vaut true jusque-là. Un questionnaire resté sans réponse après sa date limite, et des réponses au-delà de leur validité, passent à EXPIRED.
• Un seul questionnaire ouvert par contrepartie. Un nouvel envoi remplace votre questionnaire précédent resté sans réponse pour la même contrepartie : il passe à EXPIRED et son lien cesse de fonctionner. Un seul e-mail par minute peut être envoyé à une adresse ; un envoi plus rapide répond 429.
• Lecture des réponses. GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/ liste vos questionnaires avec la contrepartie, du plus récent au plus ancien, avec answers indexées par identifiant de question une fois répondues. Le répertoire les affiche sous questionnaires. Elles sont privées pour votre application.

​

Transferts avec une seule contrepartie

​

Politiques de période de transition et d’absence de réponse

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

1. sunrise_policy, lorsqu’elle est définie et que la juridiction de la contrepartie figure dans sunrise_jurisdictions.
2. non_responsive_policy, lorsqu’elle est définie et que la contrepartie est UNRESPONSIVE.
3. timeout_outcome dans tous les autres cas, y compris pour un transfert vers un membre du réseau Didit ou vers une contrepartie sans entrée d’annuaire.

​

Champs de règle et préréglages

​

Webhooks

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

​

Tarifs

• Ils s’appliquent à une transaction travelRule sortante sur une application où Travel Rule est activé, dont le montant est égal ou supérieur à votre threshold_amount, de sorte que Didit lance pour elle un échange géré. Un transfert vers un portefeuille auto-hébergé, ou vers le portefeuille vérifié de votre utilisateur, compte aussi : la preuve de propriété constitue son échange.
• Toute autre transaction sortante qui contient des données Travel Rule est facturée comme Transaction Screening standard, inclus dans votre forfait jusqu’à son quota mensuel de transactions, puis à $0.001 au-delà. Sont concernés : un transfert sous votre seuil, un paiement Lightning auquel la Travel Rule ne s’applique pas, et un transfert enregistré passivement lorsque Travel Rule est désactivé. Une transaction est facturée sur l’une des deux lignes, jamais sur les deux.
• Les transactions travelRule entrantes ne donnent lieu à aucuns frais Travel Rule ni de surveillance : c’est le cas du tronçon entrant que Didit crée sur l’application du bénéficiaire via le rail INTERNAL, des demandes TRP entrantes et des enregistrements après dépôt.
• Une application qui a rejoint Travel Rule gratuitement ne paie aucun des deux frais sur les transactions travelRule sortantes tant qu’elle n’active pas la facturation sortante avec POST /v3/travel-rule/workspace/billing/. La réception reste gratuite.
• Les applications sandbox ne sont jamais facturées.
• Les frais Travel Rule sont affichés à $0.02, et Transaction Screening à $0.001 au-delà de votre quota. Chaque transaction est facturée au prix de la ligne qu’elle utilise.
• Si le filtrage crypto AML/portefeuille s’exécute aussi sur la même transaction (par exemple un dépôt entrant avec currency_kind: "crypto" et la surveillance activée), il est facturé séparément au tarif standard Wallet Verification & Screening. Il n’est pas inclus dans les frais Travel Rule.
• Le filtrage de la contrepartie est optionnel et facturé séparément, au prix Company AML Screening par filtrage. Un filtrage de moins de 30 jours est réutilisé sans frais. Les décisions, les questionnaires et l’évaluation de vigilance de l’annuaire ne coûtent rien.

​

Tarifs de l’attribution

• La surveillance crypto a déjà filtré le portefeuille de cette transaction : le résultat enregistré est réutilisé. Un appel d’analyse, une seule facturation Wallet Verification & Screening (celle déjà effectuée par la surveillance crypto). L’attribution n’ajoute rien.
• La surveillance crypto n’a pas été exécutée : Didit effectue une seule fois l’appel d’analyse requis et transmet sa valeur complète. La transaction est facturée au tarif standard Wallet Verification & Screening ($0.15 avec l’analyse gérée par Didit) et reçoit en retour l’intégralité du résultat du filtrage crypto (score de risque, catégorie de risque du portefeuille, instantané du réseau), et pas seulement le nom du VASP. La ligne de consommation porte le déclencheur travel_rule_attribution, afin que la facturation soit explicable.
• Votre propre clé d’analyse : les mêmes frais de plateforme que pour la surveillance crypto avec votre propre clé s’appliquent ici ($0.02 par appel). Votre fournisseur vous facture directement la recherche sous-jacente.
• Les recherches en échec ne sont jamais facturées. Les renvois réutilisent l’attribution enregistrée, sans nouvel appel ni nouvelle facturation, et les applications sandbox ne sont jamais facturées.

​

Ensemble de règles EU TFR

​

Pourquoi cela fonctionne mieux sur une seule plateforme

• Données vérifiées à portée de main. La personne concernée par chaque transfert est reliée par vendor_data au profil KYC que Didit a vérifié lors de l’onboarding (OCR du document, détection du vivant, correspondance faciale). Vous pouvez donc construire originator_data à partir de champs vérifiés, sur la même plateforme. Pour un utilisateur dont la vérification KYC est approuvée, Didit transmet l’identité vérifiée et non les valeurs que vous avez saisies (voir Données vérifiées et provenance).
• Biométrie renforcée pour les transferts à risque. Une règle peut mettre en attente tout transfert de montant élevé jusqu’à ce que l’utilisateur réussisse une revérification biométrique par rapport au visage capturé lors de l’onboarding. C’est la meilleure réponse possible à la prise de contrôle de compte au moment du retrait. Voir l’exemple détaillé.
• Un seul graphe d’appareils. Les transferts soumis via le SDK portent la même analyse de l’appareil que les sessions KYC. Ainsi, « nouvel appareil + montant élevé + bénéficiaire pour la première fois » constitue une seule règle, et non une jointure dans un entrepôt de données.
• Filtrage, règles, dossiers et échange au même endroit. Le filtrage des portefeuilles qui identifie le VASP de la contrepartie est le même filtrage que vos règles et vos analystes consultent : une seule facturation, une seule console, un seul journal d’audit.
• Tarifs publiés. $0.02 par échange sortant, sans paliers de volume, sans appel commercial.

​

FAQ

​

Comment fonctionne l’échange

​

Tarifs et licences

​

Opérations et données

​

Prochaines étapes