Les 6 statuts de la Travel Rule et la question du "Sunrise" (FR)

Lorsqu'un PSAN envoie un transfert de crypto au-dessus du seuil, l'obligation FATF Travel Rule qui y est attachée ne se résout pas instantanément. Elle passe par différents états : peut-être que la contrepartie n'a pas encore répondu, peut-être que des données requises manquent de votre côté, peut-être que la destination est une juridiction qui n'a même pas encore adopté la règle. Pour gérer cela à grande échelle, vous avez besoin d'un modèle de statut clair et fini — et non d'une note en texte libre qu'un analyste doit interpréter.

Didit vous en donne exactement six. Parce que le support de la Travel Rule est intégré à la Surveillance des Transactions, chaque obligation sur chaque transfert de crypto se résout en l'un des statuts suivants : UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, ou EXEMPT. Ce guide explique ce que signifie chacun d'eux, comment agir en conséquence, et comment ces statuts vous offrent un moyen clair de gérer la partie la plus complexe de la conformité à la Travel Rule — le problème du "sunrise", où la règle est en vigueur dans votre juridiction mais pas celle de la contrepartie.

Points clés à retenir

• Six statuts, aucune ambiguïté. Chaque obligation de la Travel Rule est exactement l'un des statuts suivants : UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, ou EXEMPT.
• Le statut vous indique qui a la main — vous (PENDING_ACTION), la contrepartie (PENDING_COUNTERPARTY), ou personne parce que c'est fait (COMPLIANT) ou hors de portée (EXEMPT).
• Le problème du "sunrise" est l'adoption inégale de la Travel Rule à l'échelle mondiale — certaines juridictions l'appliquent, d'autres pas encore — ce qui vous amène à échanger des données avec des contreparties qui n'ont peut-être aucune obligation de réciprocité.
• Les statuts offrent un modèle de gestion clair pour le problème du "sunrise" : PENDING_COUNTERPARTY, FAILED, et EXEMPT correspondent directement aux cas produits par une contrepartie non adoptante.
• Il s'exécute dans la Surveillance des Transactions sur POST https://verification.didit.me/v3/transactions/ avec currency_kind: "crypto", avec un filtrage de portefeuille à partir de 0,02 $ (avec votre propre clé).

Ce que signifient les six statuts

Chaque transfert de crypto qui implique une obligation de la Travel Rule reçoit un travel_rule_status. Voici l'ensemble complet et comment agir sur chacun d'eux.

Statut	Signification	Que faire
UNKNOWN	L'obligation n'a pas encore été évaluée, ou le PSAN de la contrepartie ne peut pas être résolu.	Attendre la résolution ; enquêter si cela persiste.
COMPLIANT	Les données de l'expéditeur et du bénéficiaire ont été échangées et confirmées.	Rien — l'obligation est remplie.
PENDING_ACTION	Quelque chose de votre côté est requis — données de l'expéditeur manquantes ou étape de confirmation.	Fournir les données ; envisager une remédiation AWAITING_USER si elle est fournie par le client.
PENDING_COUNTERPARTY	Vous attendez que le PSAN de la contrepartie réponde à l'échange.	Maintenir selon la politique ; le moteur suit l'attente.
FAILED	L'échange n'a pas pu être effectué — contrepartie inaccessible, données rejetées ou incompatibilité de protocole.	Enquêter ; décider de procéder, de bloquer ou de traiter selon votre politique de "sunrise".
EXEMPT	Le transfert est hors de portée — sous le seuil, gestion de portefeuille auto-hébergé, ou non obligatoire autrement.	Procéder ; l'exemption est enregistrée pour la piste d'audit.

La valeur d'un ensemble fermé est que la politique devient exprimable. Vous pouvez dire « maintenir tout transfert crypto OUTBOUND en PENDING_COUNTERPARTY pendant un maximum de N heures, puis escalader » ou « procéder automatiquement sur EXEMPT » — des règles, pas des jugements.

Pourquoi c'est important

Les examens de la Travel Rule ne demandent pas seulement si vous avez échangé les données — ils demandent si vous pouvez montrer, par transfert, où en était l'obligation et pourquoi vous avez procédé ou non. Un modèle à six états est la piste d'audit : chaque transfert porte son statut, la raison, et le protocole qui a effectué (ou échoué à effectuer) l'échange. C'est la différence entre un enregistrement prêt pour l'examinateur et un exercice de reconstruction.

C'est également important sur le plan opérationnel, car la plupart des transferts ne sont pas COMPLIANT dès le premier passage. Ils restent en PENDING_COUNTERPARTY pendant que l'autre PSAN répond, ou arrivent à FAILED parce que la contrepartie n'est pas joignable. Une équipe qui ne peut pas voir ces états clairement finit soit par bloquer de bons transferts, soit par laisser passer des transferts obligatoires.

Le problème du "sunrise"

Le statut le plus difficile à interpréter est FAILED ou PENDING_COUNTERPARTY face à une contrepartie qui n'a tout simplement aucune obligation Travel Rule — parce que sa juridiction ne l'a pas adoptée. Le FATF a établi la règle ; les juridictions l'implémentent selon leurs propres délais. Le résultat est une couverture mondiale inégale : vous pouvez être pleinement obligé tandis que votre contrepartie, dans une juridiction non adoptante, n'a aucune obligation d'envoyer ou de confirmer quoi que ce soit. Cet écart est le problème du "sunrise" — le soleil s'est levé sur la règle dans certains endroits mais pas d'autres.

Le problème du "sunrise" ne peut être résolu unilatéralement par un PSAN ; c'est une fonction de la réglementation, pas de l'ingénierie. Mais il peut être géré, et les six statuts sont la solution :

• Une contrepartie non adoptante qui ne répond pas apparaît comme PENDING_COUNTERPARTY puis FAILED — et non comme un vide silencieux.
• Votre politique décide ce que signifie FAILED en raison de la non-adoption : procéder avec une justification documentée, maintenir ou bloquer. Le statut rend cette décision explicite et enregistrée.
• Les transferts réellement hors de portée se résolvent en EXEMPT, vous ne perdez donc pas de temps d'analyse sur eux.

L'important est que le problème du "sunrise" devienne un état documenté et basé sur des politiques plutôt qu'un cas limite indéfini. Lorsque la juridiction de la contrepartie adopte la règle, les mêmes transferts commencent à se résoudre en COMPLIANT sans modification de votre intégration.

Détails techniques

Les statuts sont renvoyés sur la transaction que vous publiez sur l'API unifiée /v3/.

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_a17d63",
    "category": "travel_rule",
    "amount": 3100,
    "currency": "ETH",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T13:40:00Z",
    "subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
  }'

{
  "transaction_id": "txn_a17d63",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "protocol": "OpenVASP",
  "wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}

Prix. Le support de la Travel Rule est inclus dans la Surveillance des Transactions. Le filtrage de portefeuille on-chain sur l'adresse de la contrepartie s'exécute en parallèle à partir de 0,02 $ par filtrage avec votre propre clé (Crystal ou Merkle Science).

Comment les statuts pilotent la boucle de remédiation

Un statut PENDING_ACTION signifie souvent que le client doit fournir quelque chose — confirmer un bénéficiaire, fournir des détails sur l'expéditeur. C'est là que la boucle de remédiation AWAITING_USER utilisée par le reste de la Surveillance des Transactions s'applique directement : au lieu d'un blocage ferme, le transfert est mis en pause, l'utilisateur est invité à fournir ce qui manque, et il reprend automatiquement une fois qu'il a résolu le problème. La friction ne s'applique qu'aux transferts qui en ont réellement besoin, et la chronologie des statuts enregistre chaque étape pour la piste d'audit.

Cas d'utilisation

• PSAN et plateformes d'échange — exprimer les politiques de maintien et d'escalade directement contre PENDING_COUNTERPARTY et FAILED, avec EXEMPT procédant automatiquement.
• Passerelles d'entrée/sortie (on/off-ramps) — gérer un volume élevé de contreparties de juridictions mixtes où le problème du "sunrise" est une réalité quotidienne.
• Dépositaires — conserver une piste de statut par transfert, prête pour l'examinateur, à travers de nombreuses contreparties et protocoles.
• Front-ends DeFi — s'appuyer sur EXEMPT pour les transferts réellement hors de portée et documenter la raison pour les autres.

Comment s'intégrer à Didit

1. Activer les règles de la Travel Rule dans la Console Business en même temps que la surveillance et le filtrage des cryptos, et écrire votre politique de "sunrise" comme des règles basées sur les statuts.
2. Envoyer des transferts de crypto avec POST /v3/transactions/, currency_kind: "crypto", et les parties expéditeur/bénéficiaire.
3. Ramifier sur travel_rule_status — procéder sur COMPLIANT/EXEMPT, remédier sur PENDING_ACTION, maintenir sur PENDING_COUNTERPARTY, enquêter sur FAILED.
4. Traiter les exceptions dans la Console, où la chronologie des statuts et le flux de travail des cas se trouvent avec le reste de votre surveillance.

Tout fonctionne sur l'API unifiée /v3/, de sorte que le statut d'un transfert est lié à la même identité que vous avez intégrée avec le KYC et filtrée avec l'AML.

Foire aux questions

Quels sont les six statuts de la Travel Rule ?

UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, et EXEMPT. Le travel_rule_status de chaque transfert est exactement l'un d'eux.

Qu'est-ce que le problème du "sunrise" ?

L'adoption inégale de la Travel Rule à l'échelle mondiale — certaines juridictions l'appliquent, d'autres ne l'ont pas encore adoptée. Cela vous amène à échanger des données avec des contreparties qui n'ont peut-être aucune obligation de réciprocité.

Comment Didit gère-t-il les contreparties non adoptantes ?

Elles apparaissent comme PENDING_COUNTERPARTY puis FAILED plutôt que comme des vides silencieux. Votre politique décide de procéder, de maintenir ou de bloquer — et la décision est enregistrée pour la piste d'audit.

Quelle est la différence entre PENDING_ACTION et PENDING_COUNTERPARTY ?

PENDING_ACTION signifie que la balle est de votre côté (données manquantes ou confirmation). PENDING_COUNTERPARTY signifie que vous attendez l'autre PSAN.

La Travel Rule est-elle un produit séparé ?

Non. Elle est intégrée à la Surveillance des Transactions, sur le même transfert de crypto que vous envoyez déjà pour la surveillance et le filtrage de portefeuille.

Prêt à commencer ?

Lisez la documentation de la Travel Rule, découvrez comment tout s'articule sur la page de solution de la crypto Travel Rule et la page produit de la Surveillance des Transactions, et consultez les tarifs transparents par appel sur la page des prix. Lorsque vous êtes prêt, commencez gratuitement — 500 vérifications KYC gratuites chaque mois, avec le suivi du statut de la Travel Rule intégré à la surveillance.