Une plateforme d'échange crypto ne déplace pas de la valeur de manière isolée. Chaque retrait vers un autre prestataire et chaque dépôt en provenance d'un autre est un transfert entre institutions, et les autorités attendent désormais que les informations sur les personnes derrière ces transferts voyagent avec les actifs. La travel rule — la norme internationale selon laquelle l'institution émettrice et l'institution réceptrice échangent des informations d'identification sur le donneur d'ordre et le bénéficiaire — s'applique aux transferts de crypto-actifs au Royaume-Uni depuis septembre 2023 et dans l'Union européenne depuis la fin de 2024. Pour une plateforme, elle n'est ni facultative ni nouvelle.
La règle est simple à énoncer et exigeante à exploiter. Une plateforme qui envoie les actifs d'un client vers un autre prestataire doit joindre des informations déterminées sur son propre client et sur le destinataire prévu ; celle qui reçoit des actifs doit obtenir les informations équivalentes et les vérifier avant de libérer les fonds. Le faire de façon fiable, à la vitesse attendue par les clients et pour des milliers de contreparties à des degrés de maturité variés, est un problème d'ingénierie et d'exploitation autant que de conformité.
Cet article expose ce que la règle demande à une plateforme, comment un processus s'organise autour des transferts sortants et entrants, comment la maturité des contreparties et les wallets self-hosted le compliquent, et comment les attentes britanniques et européennes façonnent la conception — au niveau du concept, du processus et de l'architecture de haut niveau, non une recette pour un protocole de messagerie.
Ce que la travel rule exige d'une plateforme
La travel rule impose au prestataire qui initie un transfert de crypto-actifs et à celui qui le reçoit d'échanger des informations d'identification sur les parties, de sorte qu'aucune extrémité ne soit anonyme pour les institutions qui le traitent. La plateforme émettrice transmet les informations identifiant son propre client, l'expéditeur, avec ce qu'elle détient sur le bénéficiaire ; la plateforme réceptrice les obtient, en vérifie l'exhaustivité et la cohérence et les intègre à ses contrôles anti-criminalité financière. Comme l'obligation s'appuie sur l'identification des clients qu'une plateforme réalise déjà, la capacité se conçoit au mieux avec la vérification KYC et le contrôle AML plutôt qu'ajoutée après coup.
Ce qui doit précisément être envoyé, et quand cela doit être vérifié, varie selon la juridiction et la nature du transfert, et cet article ne reformule aucun corpus de règles. Le point de conception reste constant : la plateforme doit produire des informations exactes sur le donneur d'ordre et le bénéficiaire pour un transfert sortant, et les recevoir, les valider et agir en conséquence pour un transfert entrant — pour chaque transfert concerné, sans effort manuel au moment où un client clique sur retirer.
Le processus travel rule fondamental
Un processus travel rule comporte deux chemins en miroir, et une bonne conception les traite comme des composantes à part entière des flux de retrait et de dépôt. Sur le chemin sortant, lorsqu'un client demande un retrait vers un autre prestataire, la plateforme détermine s'il est concerné, identifie l'institution réceptrice, réunit les informations requises et les transmet par un canal que les deux parties peuvent utiliser. Sur le chemin entrant, elle reçoit les informations d'accompagnement, vérifie qu'elles sont présentes et cohérentes, les filtre au regard des sanctions et des critères de risque et décide de créditer, de retenir ou d'interroger le transfert.
Les deux chemins partagent une dépendance qui façonne toute la conception : pour une adresse blockchain donnée, la plateforme doit pouvoir dire si la contrepartie est une autre institution réglementée ou un wallet self-hosted, car le traitement diffère nettement. Le tableau ci-dessous résume les responsabilités en miroir ; les attentes précises en matière de données et de vérification varient selon la juridiction.
| Étape du processus | Transfert sortant (plateforme émettrice) | Transfert entrant (plateforme bénéficiaire) |
|---|---|---|
| Périmètre et contrepartie | Déterminer le périmètre et identifier l'institution réceptrice. | Confirmer l'institution émettrice et l'arrivée des informations attendues. |
| Traitement des informations | Réunir des données exactes sur le donneur d'ordre et le bénéficiaire et les transmettre de façon sécurisée. | Recevoir les données et en vérifier l'exhaustivité et la cohérence. |
| Contrôles anti-criminalité financière | Filtrer la destination et le bénéficiaire avant la libération. | Filtrer le donneur d'ordre et effectuer les contrôles de sanctions avant le crédit. |
| Décision et traçabilité | Libérer, retenir ou rejeter ; conserver la preuve de l'envoi. | Créditer, retenir ou interroger ; conserver la preuve de la réception. |
VASP contreparties et problème du sunrise
Une plateforme ne peut échanger des informations avec une contrepartie qu'elle ne peut ni identifier ni joindre, et deux problèmes pratiques en découlent. Le premier est l'identification : à partir de la seule adresse blockchain, la plateforme doit déterminer si elle appartient à un autre prestataire réglementé — un prestataire de services sur actifs virtuels, ou VASP — et, le cas échéant, lequel et dans quelle juridiction, ce qui détermine les règles applicables. Le second est l'accessibilité : même lorsque la contrepartie est connue, les deux parties ont besoin d'un moyen commun et sécurisé de transmission, d'où l'importance de l'interopérabilité entre les solutions de messagerie du secteur, autant que celle de tout outil isolé.
Le rythme inégal d'adoption dans le monde crée le problème du sunrise : la norme est entrée en vigueur à des moments différents selon les lieux, si bien qu'une plateforme rencontre régulièrement des contreparties qui n'y sont pas encore soumises ou pas encore en mesure de recevoir des données travel rule. Une conception viable ne suppose pas que chaque contrepartie est prête. Elle définit le comportement de la plateforme lorsque les informations ne peuvent pas être échangées — recueillir et conserver ce qui est possible, appliquer une décision fondée sur le risque de poursuivre, retenir ou refuser, et consigner la justification — afin que les lacunes du réseau ne deviennent pas des lacunes dans ses propres contrôles.
Transferts impliquant des wallets self-hosted
Tout transfert ne se fait pas entre deux institutions. Les clients déposent depuis des wallets qu'ils contrôlent eux-mêmes, et retirent vers ceux-ci — wallets self-hosted, ou « non hébergés » —, et ceux-ci échappent au modèle d'institution à institution que présuppose la travel rule. Il n'y a pas de prestataire contrepartie avec qui échanger des informations, si bien que l'obligation change de forme : au lieu de transmettre des données à une autre institution, la plateforme recueille auprès de son propre client les informations pertinentes sur le wallet et, selon la juridiction et la valeur en jeu, prend des mesures pour s'assurer que le client le contrôle.
Le traitement des wallets self-hosted devient ainsi une branche distincte du processus, non une exception à traiter à la main. La plateforme doit reconnaître quand une adresse de contrepartie est probablement self-hosted plutôt qu'institutionnelle, recueillir les informations supplémentaires exigées et établir la maîtrise du wallet lorsque cela est attendu — le tout dans les mêmes flux que les clients utilisent déjà. Concevoir ce chemin délibérément évite qu'une catégorie vaste et légitime de transferts ne devienne une lacune de conformité ou une source de friction permanente.
Remarque : Le traitement des transferts vers et depuis des wallets self-hosted constitue un ensemble de contrôles supplémentaires, non une interdiction. L'objectif est de recueillir les informations exigées par chaque juridiction et d'établir la maîtrise du wallet lorsque cela est attendu, tout en gardant les transferts légitimes praticables pour les clients.
Protection des données et traçabilité
La travel rule déplace des données à caractère personnel entre institutions, et le faire licitement en est indissociable. Chaque message contient des informations identifiant des personnes réelles ; une plateforme doit donc les transmettre et les stocker de façon sécurisée, les limiter au nécessaire et les tenir sous la même discipline de protection des données que le reste de sa plateforme. Construire le processus sans vision claire de l'endroit où vont ces données, de qui peut les voir et de leur durée de conservation transforme un contrôle anti-criminalité financière en risque pour la protection des données.
La conservation est l'autre moitié. Une plateforme doit pouvoir montrer, après coup, quelles informations ont été envoyées ou reçues pour un transfert donné, quels contrôles ont été exécutés et pourquoi il a été libéré, retenu ou refusé. Cette preuve soutient le contrôle des sanctions et le contrôle AML, se place aux côtés des journaux d'audit de la plateforme et correspond à ce qu'une autorité ou un auditeur demandera à voir. Traiter les enregistrements travel rule comme une preuve d'audit à part entière — conservée et consultable — permet de démontrer que le contrôle fonctionne, et pas seulement qu'il existe.
Attentes au Royaume-Uni et dans l'UE
Pour une plateforme servant des clients au Royaume-Uni et dans l'UE, la travel rule est un droit en vigueur et non un projet futur. Au Royaume-Uni, elle s'applique aux transferts de cryptoactifs depuis septembre 2023, mise en œuvre par les règles de lutte contre le blanchiment et supervisée par la FCA, qui a exposé la manière dont elle attend des entreprises qu'elles recueillent, vérifient et partagent les informations requises. L'enregistrement au titre du régime de lutte contre le blanchiment ne vaut pas, à lui seul, agrément pour les activités plus larges qu'une plateforme peut exercer, et le futur régime britannique des cryptoactifs devrait s'appuyer sur ces obligations plutôt que les remplacer — là où la conception rejoint la préparation réglementaire pour le Royaume-Uni.
Dans l'Union européenne, les obligations d'information s'appliquent aux transferts de crypto-actifs depuis la fin de 2024, sans l'exemption de faible montant connue de certains transferts traditionnels, et au sein de l'environnement CASP agréé établi par le cadre plus large. La période transitoire de MiCA a pris fin. Les nouveaux projets de crypto-actifs dans l'UE doivent être conçus dès le départ pour un modèle d'exploitation de CASP agréé. La limite de ce qu'un partenaire technologique fournit doit être énoncée clairement. Nous ne fournissons pas d'avis juridiques et ne garantissons aucun agrément. Nous mettons en œuvre les exigences réglementaires et d'audit dans la technologie, l'infrastructure et l'exploitation. Quels transferts entrent dans le périmètre, et ce qui doit être envoyé et vérifié, relèvent de conseils qualifiés ; la tâche d'ingénierie est de rendre la plateforme capable d'y répondre de façon constante, dans le cadre de la préparation réglementaire pour l'UE.
Construire, acheter et intégrer
Peu de plateformes construisent la messagerie travel rule à partir de zéro : la valeur réside dans l'atteinte du plus grand ensemble possible de contreparties, et la portée dépend de solutions partagées et de l'interopérabilité plutôt que d'un canal sur mesure. Le choix réaliste porte sur la capacité à adopter et la façon de l'intégrer, selon des critères pratiques — le nombre de contreparties atteintes, la gestion de l'identification et du problème du sunrise, la propreté de l'insertion dans les flux existants de retrait, de dépôt, de KYC et de filtrage, et le lieu de traitement des données personnelles transportées. L'intégration décide de l'issue : le traitement travel rule doit devenir une composante native du cycle de vie du transfert plutôt qu'un ajout, ce qui relève de l'architecture autant que du choix du fournisseur. Une plateforme peut en juger en planifiant sa propre plateforme d'échange crypto.
Synthèse et prochaines étapes
La travel rule rend une plateforme responsable des informations d'identification qui accompagnent les transferts dans les deux sens : les réunir et les transmettre lorsqu'un client envoie des actifs, et les obtenir, les vérifier et agir en conséquence lorsqu'un client en reçoit. Les réalités plus difficiles qui l'entourent — identifier les contreparties à partir d'adresses, composer avec un réseau inégalement prêt, traiter les wallets self-hosted et déplacer des données personnelles licitement — en font une affaire d'ingénierie et d'exploitation, et pour le Royaume-Uni et l'UE, c'est un droit établi.
Les entreprises qui planifient ou exploitent une plateforme peuvent commencer par projeter le traitement travel rule sur leurs flux existants de retrait, de dépôt, d'identité et de filtrage, et par concevoir l'identification des contreparties, le traitement des wallets self-hosted et la conservation comme des parties de cet ensemble. Nos travaux sur le logiciel de plateforme d'échange crypto et le contrôle AML exposent comment ces contrôles sont intégrés par conception au cycle de vie du transfert plutôt qu'ajoutés à sa marge.
Concevoir la travel rule dans le flux de transfert, non autour. Grumpio construit des plateformes d'échange crypto où le traitement travel rule, l'identité et le filtrage font partie du fonctionnement des retraits et des dépôts.