Passer au contenu principal
Un échange Travel Rule atteint le VASP de la contrepartie via un seul canal. Trois canaux ne nécessitent aucune adhésion : INTERNAL entre deux clients Didit, le protocole ouvert Travel Rule Protocol (TRP) et EMAIL. Les quatre canaux de réseau (GTR, TRUST, VERIFYVASP, SYGNA) exigent une adhésion à ce réseau du côté émetteur. Cette page indique ce que fait chacun de ces canaux aujourd’hui, afin que vous sachiez où vos contreparties sont joignables avant de dépendre d’une route.
Didit ne détient pas encore d’adhésion active à un réseau Travel Rule. Un canal de réseau ne fonctionne aujourd’hui qu’avec une adhésion que vous connectez vous-même dans le Marketplace de la console. Rien n’atteint une contrepartie sur GTR, TRUST, VerifyVASP ou Sygna Bridge par l’intermédiaire de l’adhésion propre de Didit, et cette page changera le jour où ce sera le cas.

​
Statut en un coup d’œil

« Fonctionne » signifie que Didit envoie l’échange et lit la réponse. « Implémenté, pas encore éprouvé en production » signifie que Didit envoie l’échange et lit la réponse du réseau, mais qu’aucun échange sur ce réseau n’a encore abouti sur un réseau en production. Aucune de ces mentions ne signifie qu’une contrepartie donnée est joignable : cela dépend de la contrepartie, et les routes de chaque VASP dans l’annuaire indiquent quels canaux votre application peut utiliser pour elle aujourd’hui. EMAIL ne transporte que vos demandes sortantes : la page de réponse est l’endroit où une contrepartie répond à l’une d’elles, et aucun VASP ne peut vous envoyer un transfert par e-mail. Avant de vous appuyer sur GTR, VerifyVASP, Sygna Bridge ou TRUST, connectez votre adhésion et effectuez un premier échange avec une contrepartie que vous connaissez.

​
Canaux sans adhésion

​
INTERNAL

Les deux VASP fonctionnent sur Didit, donc l’échange est réglé au sein de la plateforme, sans appel sortant. Le destinataire doit être un client Didit actif, avec la Travel Rule activée, qui a prouvé le contrôle du portefeuille de destination par un message signé ou un dépôt de test. Un portefeuille déclaré sans preuve, présenté uniquement par capture d’écran ou non vérifié, ne reçoit rien. Voir Envoi d’un transfert.

​
TRP

Didit prend nativement en charge le protocole Travel Rule Protocol. Un transfert passe par TRP lorsqu’il comporte la Travel Address de la contrepartie, lorsque l’entrée du carnet d’adresses du portefeuille de destination en contient une, ou lorsque la contrepartie est trouvée dans l’annuaire avec un endpoint TRP que l’annuaire a vérifié. Tout échange TRP qui ne se termine pas en un seul appel nécessite l’hôte TRP public de Didit, celui vers lequel pointent les Travel Address :
  • Envoi. Une contrepartie qui répond à votre demande immédiatement, dans sa réponse, termine ou refuse le transfert. Une contrepartie qui répond plus tard publie sa réponse sur l’hôte TRP de Didit ; cet échange ne peut donc pas aboutir tant que l’hôte n’est pas en service : le transfert attend et expire à son échéance. Didit envoie la demande une seule fois et ne réessaie pas : lorsque l’hôte TRP de la contrepartie est injoignable ou refuse la demande, le transfert passe immédiatement au statut COUNTERPARTY_VASP_NOT_REACHABLE, et vous pouvez le réessayer avec action: "resend".
  • Réception. D’autres VASP vous joignent via votre Travel Address sur cet hôte ; aucune contrepartie ne peut donc vous envoyer une demande TRP tant que celui-ci n’est pas en service.
L’hôte TRP public de Didit n’expose pas encore ces endpoints. Interopérabilité Travel Rule documente les endpoints que les contreparties appellent une fois qu’il le fera.

​
EMAIL

Lorsqu’aucun protocole n’atteint la contrepartie, Didit envoie aux adresses de conformité de celle-ci un lien à usage unique vers une page hébergée, où la contrepartie accepte ou refuse. Aucun compte ni aucune intégration n’est nécessaire de leur côté. Voir Récupération par e-mail.

​
Canaux réseau

​
Avec votre propre adhésion

Connectez votre propre adhésion dans le Marketplace de la console (catégorie Travel Rule networks). Vos transferts transitent alors sous votre propre identité de réseau, et une adhésion connectée prime toujours sur celle de Didit. GTR, TRUST et VerifyVASP acceptent aussi, en option, un certificat client TLS mutuel, une clé client et un bundle d’autorités de certification (PEM), pour une adhésion qui utilise le TLS mutuel ou une autorité de certification privée.
  • Didit envoie en arrière-plan et réessaie lorsqu’un réseau ne répond pas, ou répond par une erreur temporaire (pas de réponse à temps, connexion échouée, HTTP 408, 429 ou 5xx) : après 30 secondes, puis après 2, 10, 30 et 60 minutes. Après la sixième tentative échouée, le transfert passe à COUNTERPARTY_VASP_NOT_REACHABLE. Un refus, comme une autre réponse 4xx ou une redirection, n’est pas réessayé : le transfert passe immédiatement à COUNTERPARTY_VASP_NOT_REACHABLE.
  • Un transfert dont la réponse n’arrive jamais reste en AWAITING_COUNTERPARTY jusqu’à ce que confirmation_timeout_hours soit écoulé, puis expire et applique votre timeout_outcome.
  • La réception d’un transfert qu’un autre VASP vous envoie via GTR, VerifyVASP ou Sygna Bridge n’est pas encore activée : Didit l’active réseau par réseau, et jusqu’à cette activation, ces réseaux ne peuvent pas vous livrer de transfert.
  • L’enregistrement d’une adhésion renvoie 400 lorsque son code de participant est le code propre de Didit sur ce réseau, ou un code déjà détenu par une autre application.
  • Les requêtes réseau ne transmettent vos identifiants qu’à l’hôte propre de ce réseau et ne suivent jamais une redirection. Le paquet de données TRUST est envoyé au bénéficiaire sans votre clé API, votre identifiant de membre ni votre certificat client.

​
Via l’adhésion de Didit

Une fois que Didit détient une adhésion à un réseau, un client qui n’en a pas peut atteindre ce réseau en tant que votre propre participant, via l’adhésion de Didit, avec le code de participant que lui attribue le réseau : les messages sortants mentionnent votre code, jamais celui de Didit. Cette option n’est proposée que pour GTR et Sygna Bridge. TRUST admet les membres un VASP à la fois, et une Enclave VerifyVASP ne sert qu’un seul VASP : ces deux réseaux ne sont donc accessibles qu’avec votre propre adhésion. L’adhésion comporte trois étapes : répondre au questionnaire de diligence raisonnable du réseau de Didit, faire approuver ce questionnaire par Didit, puis demander l’accès au réseau. Didit vous enregistre auprès du réseau, et votre participant devient actif dès que le réseau lui attribue un code. Ce parcours n’est pas encore ouvert. Tant qu’il ne l’est pas, l’enregistrement ou la soumission du questionnaire et la demande d’accès à un réseau renvoient 403 avec code: travel_rule_platform_networks_disabled, et GET /v3/travel-rule/networks/ indique platform_networks_enabled: false.

​
Lire le statut de votre application

GET /v3/travel-rule/settings/ et GET /v3/travel-rule/networks/ renvoient networks, indexé par gtr, trust, verifyvasp et sygna. Chaque entrée indique ce que le réseau peut faire pour votre application aujourd’hui : mode résume l’état sous la forme own, didit, off ou unavailable. Votre propre adhésion est vérifiée en premier, puis disabled_networks, puis l’adhésion de Didit. Aujourd’hui, un réseau affiche own_membership dès que vous connectez votre propre adhésion. Sinon, GTR et Sygna Bridge affichent didit_onboarding (unavailable avec sandbox_application sur une application sandbox), et TRUST et VerifyVASP affichent unavailable avec own_membership_only, y compris en sandbox. Une application sandbox n’envoie jamais de transfert sur un réseau, même avec votre propre adhésion connectée et l’état own_membership : ses transferts sont dirigés vers le Didit Test VASP. connected signifie que votre adhésion enregistrée a passé la validation locale, et non qu’un échange a réussi. Le premier échange en production le confirme auprès du réseau.

​
Ce qui change lorsqu’un réseau passe en production

Cette page, le statut networks et toutes les routes de l’annuaire changent ensemble. Rien ne change dans votre intégration : un transfert commence à être acheminé via le réseau dès que votre application dispose d’une adhésion à celui-ci, selon l’ordre des rails décrit dans Comment Didit achemine un échange. Pour demander l’accès à un réseau que Didit n’atteint pas encore, utilisez sa vignette Demander l’accès dans la Marketplace. Chaque demande affiche son statut (Ouverte, Contactée, En cours, En production ou Refusée) accompagné de la dernière note de Didit. Lorsque Didit modifie le statut ou la note, il envoie un e-mail au coéquipier qui a fait la demande, tant que celui-ci fait partie de votre organisation. Une demande faite avec une clé API ne donne lieu à aucun e-mail : suivez-la dans la Marketplace.

​
Étapes suivantes

Travel Rule

Le cycle de vie des échanges, les paramètres, les rails et l’API /v3/.

Tester en sandbox

Testez chaque résultat avec le Didit Test VASP avant la mise en production.

Interopérabilité

Les endpoints que les VASP des contreparties utilisent pour vous joindre.

Annuaire

Trouvez un VASP et les routes que votre application peut utiliser pour lui.
Dernière modification le 7 novembre 2026