Règle de voyage MiCA pour les PSAN de l'UE : Guide Complet (FR)
Les fournisseurs de services d'actifs numériques (PSAN) de l'UE sont confrontés à la Règle de voyage dans le cadre du Règlement sur les transferts de fonds, en plus du régime d'agrément de MiCA.

Si vous dirigez une entreprise de cryptomonnaies dans l'UE, deux régimes façonnent désormais votre mode de fonctionnement. La MiCA – le Règlement sur les marchés de crypto-actifs – est le cadre européen de licence et de conduite, définissant qui peut offrir des services de crypto-actifs et selon quelles règles. En parallèle, la Règle de voyage, que l'UE met en œuvre via son Règlement sur les transferts de fonds : l'exigence d'échanger les informations de l'expéditeur et du bénéficiaire lors des transferts de crypto-actifs. MiCA vous indique comment être autorisé en tant que prestataire de services sur crypto-actifs (PSAN) ; la Règle de voyage vous dit quelles données doivent accompagner chaque transfert que vous envoyez et recevez.
Didit gère la seconde moitié. Le support de la Règle de voyage est intégré à la Surveillance des transactions, de sorte que le même moteur qui évalue vos transferts échange également les données de l'expéditeur et du bénéficiaire avec les PSAN contreparties via TRISA, TRP et OpenVASP, et suit chaque obligation selon l'un des six statuts. Ce guide explique comment les obligations de l'UE s'articulent et comment intégrer la partie de la Règle de voyage.
Points clés à retenir
- MiCA et la Règle de voyage sont des obligations différentes. MiCA est le régime européen de licence et de conduite des crypto-actifs ; la Règle de voyage (via le Règlement sur les transferts de fonds) est l'exigence d'échange de données expéditeur/bénéficiaire sur les transferts.
- Les PSAN de l'UE ont besoin des deux — une autorisation MiCA et un échange de données fonctionnel pour la Règle de voyage sur les transferts concernés.
- Didit couvre la partie Règle de voyage, intégrée à la Surveillance des transactions, avec le support de TRISA, TRP et OpenVASP et six statuts d'obligation.
- Les données que vous échangez proviennent de la KYC que vous détenez déjà — l'enregistrement de l'expéditeur est construit à partir de l'identité que vous avez vérifiée lors de l'intégration.
- Une API
/v3/unique. Les transferts de crypto-actifs sont postés surPOST https://verification.didit.me/v3/transactions/aveccurrency_kind: "crypto", avec un filtrage de portefeuille à partir de 0,02 $ (apportez votre propre clé).
Ce que MiCA et la Règle de voyage exigent
Il est important de bien distinguer les deux, car les équipes les confondent souvent et ne peuvent alors raisonner sur aucune des deux.
- MiCA est le règlement de l'UE qui place les services de crypto-actifs sous un cadre harmonisé — autorisation en tant que PSAN, exigences de gouvernance et de conduite, règles pour les émetteurs de jetons référencés à un actif et de monnaie électronique, et un régime de passeporting dans les États membres. MiCA est ce que vous devez être pour opérer.
- La Règle de voyage dans l'UE est mise en œuvre par le Règlement refondu sur les transferts de fonds, qui étend la règle de longue date des virements bancaires aux transferts de crypto-actifs. Elle exige que les informations de l'expéditeur et du bénéficiaire accompagnent les transferts et soient mises à la disposition des autorités. La Règle de voyage est quelles données doivent voyager avec chaque transfert.
Un PSAN agréé dans l'UE satisfait donc aux exigences d'autorisation et de conduite de MiCA et gère l'échange de données de la Règle de voyage sur ses transferts. Les deux se renforcent mutuellement — les données client que la Règle de voyage transmet sont les données KYC qu'un PSAN autorisé par MiCA collecte déjà — mais ce sont des obligations distinctes avec des preuves distinctes.
Pourquoi cela compte
Pour les entreprises de crypto-actifs de l'UE, les deux régimes sont actifs et supervisés. L'échange de données de la Règle de voyage est obligatoire pour les transferts concernés, et les autorités nationales compétentes l'examinent dans le cadre plus large de la lutte contre le blanchiment d'argent. Une erreur dans l'échange — ne pas transmettre les données de l'expéditeur, ou procéder sans confirmer la partie bénéficiaire lorsque cela est requis — constitue une constatation de supervision, et non une simple erreur administrative.
Le risque pratique est la duplication. Un PSAN qui construit la KYC à un endroit, le filtrage AML à un autre, et un connecteur de Règle de voyage séparé à un troisième se retrouve à réconcilier trois copies du même client à travers trois systèmes. Parce que Didit relie la même identité à travers la KYC, l'AML, la surveillance, le filtrage de portefeuille et la Règle de voyage sur une seule API /v3/, l'enregistrement de l'expéditeur sur un transfert est le client que vous avez déjà vérifié — pas de troisième copie à synchroniser.
Détails techniques
Les PSAN de l'UE envoient les transferts de crypto-actifs à l'API unifiée /v3/. L'expéditeur est le subject, le bénéficiaire est le counterparty, et currency_kind: "crypto" déclenche les chemins de la Règle de voyage et du filtrage de portefeuille.
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_e92b40",
"category": "travel_rule",
"amount": 8800,
"currency": "EURC",
"currency_kind": "crypto",
"direction": "OUTBOUND",
"txn_date": "2026-05-21T14:22:00Z",
"subject": {
"vendor_data": "user_3309",
"role": "ORIGINATOR",
"entity_type": "INDIVIDUAL",
"first_name": "Lukas",
"last_name": "Berg"
},
"counterparty": {
"role": "BENEFICIARY",
"entity_type": "INDIVIDUAL",
"wallet_address": "0x71be...d402"
}
}'
{
"transaction_id": "txn_e92b40",
"status": "APPROVED",
"travel_rule_status": "COMPLIANT",
"protocol": "TRISA",
"wallet_screening": { "risk_score": 12, "risk_level": "LOW" }
}
Les six statuts de la Règle de voyage. Chaque obligation se résout à un seul :
| Statut | Signification |
|---|---|
UNKNOWN | Pas encore évalué, ou le PSAN contrepartie n'a pas pu être résolu. |
COMPLIANT | Données expéditeur et bénéficiaire é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 complété — contrepartie inaccessible, données rejetées ou incompatibilité de protocole. |
EXEMPT | Hors champ d'application — en dessous du seuil ou non autrement obligatoire. |
Protocoles et règles. Le moteur parle TRISA, TRP et OpenVASP, négociant celui que la contrepartie prend en charge. Les transactions portent la catégorie travel_rule, et la bibliothèque de règles fournit des règles de Règle de voyage prédéfinies que vous activez et ajustez dans la Console.
Filtrage de portefeuille en parallèle. L'adresse de la contrepartie est filtrée sur la chaîne dans le même appel à partir de 0,02 $ par filtrage avec votre propre clé (Crystal ou Merkle Science).
Le problème du « sunrise », du point de vue de l'UE
Les PSAN de l'UE ressentent vivement le problème du « sunrise » : vous êtes entièrement obligé en vertu du Règlement sur les transferts de fonds, mais une contrepartie dans une juridiction qui n'a pas adopté la Règle de voyage n'a aucune obligation de réciprocité. Didit signale ces cas comme PENDING_COUNTERPARTY puis FAILED plutôt que comme des lacunes silencieuses, de sorte que votre politique — procéder avec un raisonnement documenté, suspendre ou bloquer — est explicite et enregistrée. Lorsque la juridiction de la contrepartie adopte la règle, les mêmes transferts commencent à être résolus comme COMPLIANT sans aucune modification de votre intégration.
Cas d'utilisation
- Échanges et PSAN de l'UE — exécutez l'échange de données de la Règle de voyage sur chaque transfert concerné tout en conservant les données de l'expéditeur liées à votre KYC de l'ère MiCA.
- Rampes d'accès/de sortie de l'UE — échangez des données avec les PSAN de destination dans toute l'UE et au-delà, en filtrant le portefeuille de réception dans le même appel.
- Dépositaires de l'UE — suivez les obligations à travers de nombreuses contreparties et protocoles avec un historique de statut prêt pour l'examinateur.
- Front-ends DeFi de l'UE — effectuez l'échange là où un PSAN réglementé est impliqué dans le flux et résolvez comme
EXEMPTlorsque l'obligation ne s'applique pas réellement.
Comment s'intégrer à Didit
- Activez les règles de la Règle de voyage dans la Console métier, en parallèle de la surveillance et du filtrage des crypto-actifs, ajustées à votre politique de risque PSAN.
- Envoyez les transferts de crypto-actifs avec
POST /v3/transactions/,currency_kind: "crypto", l'expéditeur commesubjectet le bénéficiaire commecounterparty, et la catégorietravel_rule. - Lisez les deux statuts — le
statusde la transaction pour le mouvement et letravel_rule_statuspour l'obligation — et agissez surPENDING_*etFAILED. - Gérez les exceptions dans la Console, où les obligations en attente, les alertes et le flux de travail des cas se trouvent avec le reste de votre surveillance.
Parce que tout est sur l'API unifiée /v3/, le client que vous intégrez avec la KYC et que vous filtrez avec l'AML pour satisfaire aux exigences de l'ère MiCA est la même identité qui fournit l'enregistrement de l'expéditeur sur chaque transfert de la Règle de voyage.
Foire aux questions
La Règle de voyage est-elle la même chose que MiCA ?
Non. MiCA est le régime européen de licence et de conduite des crypto-actifs ; la Règle de voyage est l'exigence d'échange de données expéditeur/bénéficiaire, mise en œuvre dans l'UE par le Règlement sur les transferts de fonds. Les PSAN de l'UE gèrent les deux.
Didit me rend-il agréé par MiCA ?
Non. L'autorisation MiCA est quelque chose que vous obtenez en tant que PSAN. Didit fournit l'infrastructure d'identité et de fraude — KYC, AML, surveillance, filtrage de portefeuille et l'échange de données de la Règle de voyage — qui prend en charge vos obligations de conformité.
Quels protocoles Didit utilise-t-il pour la Règle de voyage de l'UE ?
TRISA, TRP et OpenVASP. Le moteur négocie celui que la contrepartie donnée prend en charge.
Comment Didit gère-t-il le problème du « sunrise » pour les PSAN de l'UE ?
Les contreparties non adoptantes apparaissent comme PENDING_COUNTERPARTY puis FAILED plutôt que comme des lacunes silencieuses, de sorte que votre décision politique est explicite et enregistrée pour la piste d'audit.
La Règle de voyage est-elle un produit distinct ?
Non. Elle est intégrée à la Surveillance des transactions, sur le même transfert de crypto-actifs que vous envoyez déjà pour la surveillance et le filtrage de portefeuille.
Prêt à commencer ?
Lisez la documentation sur la Règle de voyage, voyez comment cela s'articule sur la page de solution de la Règle de voyage crypto 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 la Règle de voyage intégrée à la surveillance.