Travel Rule pour les paiements crypto

1) Qu'est-ce que Travel Rule et pourquoi il est nécessaire

Travel Rule est une obligation réglementaire pour les fournisseurs d'actifs virtuels (VASP) d'échanger les données d'identification de l'expéditeur et du destinataire lors des transferts de crypto-actifs. Objectif : réduire les risques AML/CTF, simplifier les enquêtes et améliorer la transparence des transferts VASP croisés, tout en maintenant l'infrastructure onchane opérationnelle.

• Les données « voyagent » avec la traduction (canal de communication off-chain VASP↔VASP).
• Les exigences et les seuils dépendent de la compétence ; souvent, le seuil est proche de ~ 1000 (en équivalent), mais dans un certain nombre de modes, il s'applique à des montants plus petits - fixez la norme locale dans votre politique.
• Les exigences distinguent les portefeuilles hosted (castodial) et unhosted (indépendant).

2) Objets et zones d'application

VASP → VASP (hosted ↔ hosted) : échange complet de données selon la norme (de préférence jusqu'au broadcast onchain).
VASP → Unhosted (autocasthodie) : collecte/vérification des informations sur le destinataire et l'origine des fonds de la politique locale RBA ; il n'y a pas d'échange avec la « contrepartie-VASP ».
Cross-border : Utilisez Discovery/Directory et les accords de confiance pour trouver une contrepartie et un canal sécurisé.

3) Quelles sont les données transmises (composition minimale)

• Nom (ou nom). entreprises), un identifiant client unique (de votre système),
• Adresse/pays ou date de naissance (variant selon le pays),
• Numéro de compte/portefeuille (identifiant/adresse interne),
• Contacts (si nécessaire), identifiant VASP (LEI/BIC/reg. numéro - le cas échéant).

• Nom/titre (si le destinataire est dans un autre VASP et vérifié),
• ID de compte/portefeuille chez le bénéficiaire-VASP,
• Avec unhosted - les informations recueillies auprès du client selon votre politique RBA.

• Actif/réseau (BTC, ETH/chain), montant, timestamp,
• Payment/Transfer ID, référence pour le contrôle de la qualité/des sanctions,
• ID de session/message Travel Rule.

4) Normes et protocoles d'échange

IVMS101 est un modèle de données (quoi et comment nommer).
TRISA/TRP/OpenVASP - protocoles réseau et « réseaux de confiance » (PKI, mTLS, répertoires VASP, routage, confirmation de livraison).
Les maisons/agrégateurs commerciaux peuvent mettre en œuvre l'interopérabilité (approche Gateway) et Discovery.

Recommandation : Abstraire le transport (couche adaptative) et stocker le IVMS101 comme « modèle canonique » pour changer librement le fournisseur/protocole sans casser l'API.

5) Architecture de mise en œuvre (référence)

1. Travel Rule Gateway (microservices) : réception/envoi de messages IVMS101, signature/cryptage, retraits, quotas.

2. Directory/Discovery : recherche de contre-VASP (registre, PKI, politique de confiance).

3. KYT/Santé Engine : contrôle des adresses/échanges/clusters, évaluation des risques avant expédition.

4. Moteur de conformité (RBA) : prise de décision : allow/hold/reject/request dop.danneh.

5. Gestion des cas : cas, pièces jointes, SLA, escalade (L1/L2/L3).

6. PII Vault : stockage sécurisé des données personnelles (cryptage, tokenization, RBAC, audit).

1. Le client crée une traduction → 2) COT/Sanctions pre-check → 3) Discovery de la contrepartie → 4) Échange de IVMS101 (jusqu'à onchain) → 5) Décision (allow/hold) → 6) Onchein broadcast → 7) Rapport postal/loging.

6) Porte-monnaie unhosted : Politiques et contrôles

Collecte des informations sur la contrepartie auprès du client (nom/pays/relation), preuve de la possession de l'adresse (signature du message, petit « transfert pruf », vérification en bourse).
Règles de risque : interdiction/limites pour les adresses à haut risque KYT (mixeurs, marchés « sombres », clusters de sanctions), interdiction des sites P2P sans KYC selon vos politiques.
Listes d'adresses blanches (address book/whitelisting) avec TTL et rhubarbe.

7) Intégration avec KUT/Sanctions et AML

KYT (Know Your Transaction) : évaluation des risques d'adresses/échanges, communications jusqu'à N-hop avec des clusters « mauvais », anomalies de volume/itinéraires.
Sanctions : dépistage du client/contrepartie (KYC/KYB) et des infrastructures (bourses, castodians).
Risque positif → hold, demande de documents (SoF/SoW) et/ou refus, si nécessaire - SAR/STR.

8) Données et vie privée (RGPD/sécurité)

Minimisation : ne stockez que les champs requis par Travel Rule ; séparer les PII des PAN/clés de paiement.
Cryptage : au repos (KMS/HSM) et en transit (mTLS), rotation des clés.
Accès : rigoureux RBAC, journal d'action, principe du « need-to-know ».
Retenshn : selon la loi de juridiction (souvent 5 ans et plus) ; l'expéditation automatique et les rapports de suppression.
DSR : procédures d'accès/correction/suppression, le cas échéant.

9) SLA, retrai et dégradation

• Pre-check (KUT/sanctions) : ≤ 5-15 c p95.
• Discovery + Exchange (VASP↔VASP) : ≤ 60-120 c p95 (y compris les retraits).
• Solution (allow/hold/reject) : ≤ 2-5 min p95 pour les cas auto ; vue manuelle de High-risk - ≤ 4 h.

• Backoff + jitter exponentiel ; les endpoints alternatifs.
• Problème sunrise (la contrepartie ne supporte pas Travel Rule) : exceptions/limites RBA, échange manuel sur un canal crypté (si la politique/la loi le permet) ou refus.

10) modèles UX (sans casser la conversion)

Pré-saisie des données du destinataire pour les traductions fréquentes (carnet d'adresses).
Messages clairs : « Vous devez confirmer l'adresse »/« Vous avez besoin des données du destinataire pour respecter la règle ».
Vérifications contextuelles (signature d'adresse, microréseau) avec conseils étape par étape.
Statuts et minuteries pour hold/check, attentes transparentes.
Alternatives : « Obtenir en bourse avec KYC » en cas de refus unhosted.

11) Métriques et contrôle de qualité

• Travel Rule coverage % (part des transferts VASP↔VASP avec un échange IVMS101 réussi).
• Proportion unhosted avec vérification d'adresse passée et SoF (par seuil).
• SLA hit rate sur l'échange/solutions ; proportion de cas manuels.

• KYT taux de risque élevé, refus de sanctions, SAR-conversion.
• Répétez les alertes par adresse/cluster, partagez « faux positif » par KYT.

• Temps avant la traduction p50/p95, refus à cause de Travel Rule (impact), conversion des traductions répétées (carnet d'adresses).

12) Matrice des solutions (croquis)

13) Anti-modèles

Envoyer des onchans avant la fin de l'échange de données VASP↔VASP (dans les modes où il est nécessaire avant la traduction).
Verrouillage « sourd » de tous sans exception RBA et vérification d'adresse.
L'absence de Discovery/Directory → une livraison instable et une false hold fréquente.
Stockage des PII excédentaires sans objectif/rétention ; logiques non divisées et PII.
Serrage rigide sur un fournisseur de protocole sans abstraction (vendor lock-in).

14) Chèque de mise en œuvre

• Politique de Travel Rule : juridictions, seuils, hosted/unhosted, exceptions RBA.
• Modèle canonique de la couche de IVMS101 et d'adaptateur sous TRISA/TRP/OpenVASP.
• Directory/Discovery и PKI/mTLS; gestion des VASP de confiance.
• Intégration des TAC/sanctions dans le pré-contrôle ; règles de hold/reject.
• PII Vault : chiffrement, RBAC, audit, rétention/DSR.
• SLA/retrai/alerties, métriques de dashboard ; les pleybooks des dégradations.
• Processus pour unhosted : vérification d'adresse, requêtes SoF, listes blanches.
• Gestion des cas et modèles de communication ; Procédure SAR/STR.
• Bancs d'essai : émulation de la contrepartie VASP, scénarios d'échec, test de chargement.
• Formation Payments/Risque/Conformité/Soutien et exercices réguliers.

15) Résumé

Travel Rule n'est pas un « cryptage », mais un échange de données sécurisé entre VASP. Construisez une passerelle avec le IVMS101 comme modèle canonique, connectez Discovery/Directory, intégrez les solutions KUT/sanctions et RBA, protégez le PII et définissez des SLA compréhensibles. Ensuite, les traductions VASP↔VASP et le travail avec des adresses unhosted seront rapides, conformes et ne ruineront pas la conversion.