Échange de Données Travel Rule : TRISA, TRP & OpenVASP (FR)

En réduisant la Travel Rule du GAFI à sa mécanique, il s'agit d'un problème de messagerie. Avant qu'un transfert crypto ne soit réglé, le PSAN émetteur doit transmettre au PSAN récepteur un paquet structuré décrivant l'expéditeur et le bénéficiaire (nom, identifiants, références de compte), et le côté récepteur doit l'accuser réception. Le problème est qu'il n'existe pas de voie mondiale unique pour cette poignée de main. Il existe plutôt des protocoles d'interopérabilité concurrents, et un transfert ne réussit que lorsque les deux PSAN peuvent parler l'un d'entre eux.

Didit gère cette poignée de main pour vous. L'échange de données de la Travel Rule est intégré à Transaction Monitoring, et le moteur parle les trois protocoles que les PSAN utilisent réellement en production — TRISA, TRP et OpenVASP. Vous envoyez le transfert une seule fois ; le moteur résout la contrepartie, choisit un protocole pris en charge par les deux parties, échange les charges utiles de l'expéditeur et du bénéficiaire, et suit l'obligation jusqu'à un statut. Ce guide explique les protocoles, les charges utiles et le déroulement de l'échange.

Points clés à retenir

• La Travel Rule est un échange de données de PSAN à PSAN. L'expéditeur transmet les informations sur l'expéditeur et le bénéficiaire ; le récepteur les collecte et les confirme.
• Trois protocoles prennent en charge cet échange — TRISA, TRP et OpenVASP — chacun avec un modèle de confiance et de transport différent. Didit prend en charge les trois.
• La charge utile est l'enregistrement de l'expéditeur et du bénéficiaire — les parties au transfert, structurées de manière à ce que les deux PSAN lisent les mêmes champs.
• Didit gère l'échange au sein de Transaction Monitoring, résolvant chaque obligation à l'un des six statuts (UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT).
• Une seule API /v3/. Les transferts crypto sont postés à POST https://verification.didit.me/v3/transactions/ avec currency_kind: "crypto", et le filtrage des portefeuilles s'exécute en parallèle à partir de 0,02 $ (apportez votre propre clé).

Ce que font les protocoles

Les trois protocoles résolvent les deux mêmes problèmes — comment trouver et faire confiance au PSAN contrepartie ? et comment lui envoyer les données client en toute sécurité ? — mais ils font des compromis différents.

• TRISA (Travel Rule Information Sharing Architecture) est un modèle pair-à-pair basé sur une autorité de certification. Les PSAN s'inscrivent, prouvent leur identité et reçoivent des certificats, puis échangent des données directement via un canal crypté. La confiance est ancrée dans le répertoire des membres vérifiés.
• TRP (Travel Rule Protocol) est une spécification API-first favorisée par un groupe de grandes institutions. Elle définit un échange REST léger pour l'envoi de la charge utile de l'expéditeur et du bénéficiaire entre des contreparties ayant établi une connexion.
• OpenVASP est une norme ouverte qui utilise la signalisation on-chain et au niveau de la couche de messagerie pour établir une session entre les PSAN avant le transfert, puis échange les données client hors chaîne.

Un PSAN qui souhaite une large portée doit en prendre en charge plusieurs, car ses contreparties ne seront pas toutes sur le même protocole. Exécuter l'échange au sein de Didit signifie que vous ne choisissez pas un protocole en espérant — le moteur négocie celui que la contrepartie prend en charge.

Pourquoi c'est important

En vertu de la Recommandation 16 du GAFI et de ses mises en œuvre régionales — le Règlement de l'UE sur les transferts de fonds étant le principal d'entre eux — l'échange de données sur l'expéditeur et le bénéficiaire est obligatoire au-dessus du seuil, et les superviseurs l'examinent. Mais l'exigence est formulée en termes de résultats (les données doivent être transmises, conservées et confirmées), et non de protocoles. La fragmentation des protocoles est une réalité technique que vous héritez, pas une règle que vous pouvez contourner.

C'est précisément pourquoi la prise en charge des protocoles ne devrait pas être votre problème à construire. Mettre en place l'inscription TRISA, un point de terminaison TRP et la signalisation OpenVASP — et maintenir les trois à jour — est un coût d'ingénierie permanent qui n'a rien à voir avec votre produit. L'intégrer dans le même moteur de surveillance qui évalue déjà le transfert réduit ce coût à une seule intégration.

Détails techniques

Le transfert est créé via l'API unifiée /v3/. L'expéditeur est le subject, le bénéficiaire est la counterparty, et currency_kind: "crypto" déclenche les chemins de la Travel Rule et du filtrage des portefeuilles.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_7b9e22",
    "category": "travel_rule",
    "amount": 12500,
    "currency": "BTC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T12:14:00Z",
    "subject": {
      "vendor_data": "user_8830",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Marta",
      "last_name": "Ferreira"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "bc1q...0a7k"
    }
  }'

Le moteur résout le PSAN contrepartie, sélectionne un protocole pris en charge, échange la charge utile et renvoie le protocole utilisé ainsi que le statut de la Travel Rule :

{
  "transaction_id": "txn_7b9e22",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRP",
  "counterparty_vasp": "vasp_resolved",
  "wallet_screening": {
    "risk_score": 9,
    "risk_level": "LOW"
  }
}

La charge utile expéditeur/bénéficiaire. Chaque transfert contient les deux parties en tant qu'enregistrements structurés — l'expéditeur (le client qui envoie) et le bénéficiaire (le client qui reçoit) — de sorte que les deux PSAN correspondent aux mêmes champs quel que soit le protocole. Les données de l'expéditeur proviennent de votre KYC existant ; le côté bénéficiaire est confirmé par la contrepartie pendant l'échange.

Les six statuts. Quel que soit le protocole qui effectue l'échange, l'obligation se résout à un seul statut :

Statut	Signification
UNKNOWN	Pas encore évalué, ou le PSAN contrepartie n'a pas pu être résolu.
COMPLIANT	Données échangées et confirmées — obligation remplie.
PENDING_ACTION	Une action de votre part est requise pour continuer.
PENDING_COUNTERPARTY	En attente de la réponse du PSAN contrepartie.
FAILED	L'échange n'a pas pu être réalisé — contrepartie inaccessible, données rejetées ou incompatibilité de protocole.
EXEMPT	Hors champ d'application — sous le seuil ou non soumis à l'obligation.

Filtrage des portefeuilles en parallèle. L'adresse de la contrepartie est filtrée on-chain dans le même appel à partir de 0,02 $ par filtrage avec apport de votre propre clé (Crystal ou Merkle Science), de sorte qu'un statut COMPLIANT au niveau du protocole ne cache pas un risque au niveau de l'adresse.

Choisir — et ne pas choisir — un protocole

Le conseil pratique pour un PSAN est : ne choisissez pas. Vos contreparties sont réparties entre TRISA, TRP et OpenVASP, et le protocole qui fait passer un transfert donné à COMPLIANT est celui que cette contrepartie prend en charge. Parce que Didit négocie le protocole par transfert, votre intégration est la même quoi qu'il arrive — vous envoyez les données de l'expéditeur et du bénéficiaire une seule fois, et le moteur gère la poignée de main. Un statut FAILED avec une incompatibilité de protocole est un signal pour enquêter sur la contrepartie, pas un manque dans votre pile.

Cas d'utilisation

• PSAN et plateformes d'échange — atteignez les contreparties sur les trois protocoles à partir d'une seule intégration, au lieu de construire et de maintenir chaque voie.
• On/off-ramps — échangez les données de l'expéditeur et du bénéficiaire avec les PSAN de destination tout en filtrant le portefeuille récepteur dans le même appel.
• Dépositaires — gérez un grand nombre de contreparties sur des protocoles mixtes avec un modèle de statut unique et cohérent.
• Interfaces DeFi — effectuez l'échange là où un PSAN réglementé est impliqué dans le flux, et résolvez à EXEMPT lorsque l'obligation ne s'applique pas réellement.

Comment s'intégrer à Didit

1. Activez les règles de la Travel Rule. Dans la console d'entreprise, activez les règles prédéfinies de la Travel Rule en plus de la surveillance crypto et du filtrage crypto.
2. Envoyez le transfert. POST /v3/transactions/ avec currency_kind: "crypto", l'expéditeur comme subject, le bénéficiaire comme counterparty, et la catégorie travel_rule.
3. Lisez le protocole et le statut. La réponse vous indique quel protocole a effectué l'échange et le travel_rule_status résultant. Agissez sur les obligations PENDING_* et FAILED.
4. Gérez les exceptions dans la console. Les échanges en attente et échoués, les alertes et le flux de travail des cas se trouvent au même endroit que votre surveillance.

Tout fonctionne sur l'API unifiée /v3/, de sorte que le client que vous avez intégré avec KYC, filtré avec AML, et pour lequel vous effectuez maintenant un transfert est la même identité suivie par la surveillance, le filtrage des portefeuilles et la Travel Rule.

Questions fréquentes

Quels protocoles de la Travel Rule Didit prend-il en charge ?

TRISA, TRP et OpenVASP — les trois protocoles que les PSAN utilisent en production. Le moteur négocie celui que la contrepartie prend en charge.

Quelles données sont échangées ?

Les enregistrements de l'expéditeur et du bénéficiaire — les parties au transfert — structurés de manière à ce que les deux PSAN lisent les mêmes champs. Vous fournissez l'expéditeur à partir de votre KYC existant ; la contrepartie confirme le côté bénéficiaire.

Dois-je choisir un protocole ?

Non. Choisir un protocole vous couperait des contreparties sur les autres. Didit sélectionne le protocole par transfert en fonction de ce que la contrepartie prend en charge.

Que se passe-t-il si la contrepartie est inaccessible ?

L'obligation se résout à FAILED (avec une raison telle que l'incompatibilité de protocole ou la contrepartie inaccessible) ou reste à PENDING_COUNTERPARTY pendant que vous attendez — les deux sont visibles dans la console.

Est-ce un produit distinct de Transaction Monitoring ?

Non. L'échange de données est intégré à Transaction Monitoring, sur le même transfert crypto que vous envoyez déjà pour la surveillance et le filtrage des portefeuilles.

Prêt à commencer ?

Lisez la documentation de la Travel Rule, consultez l'ensemble des informations sur la page de la solution Crypto Travel Rule et la page produit Transaction Monitoring, et vérifiez les prix transparents par appel sur la page des tarifs. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, avec l'échange de données de la Travel Rule intégré à la surveillance.