Intégration des fournisseurs Travel Rule

1) Objectif de l'intégration

• maintenir le modèle canonique de la IVMS101,
• Avoir une couche d'adaptateur agnostique au fournisseur,
• assurer la sécurité (mTLS, signature, cryptage) et le SLA,
• couvrir les hosted↔hosted et les politiques pour les non-fonctionnaires.

2) Choix du protocole/fournisseur : modèle

2. 1 Protocoles et réseaux de confiance

TRISA/TRP/OpenVASP - p2r/fédérations avec PKI, catalogues VASP, confirmation de livraison.
Hobs/agrégateurs commerciaux - abstraire le transport, donner Discovery et routage.

2. 2 Critères de sélection (résumé)

Couverture des juridictions/VASR, Directory/Discovery qualité.
Compatible avec les IVMS101 et les extensions.
Sécurité (PKI, mTLS, signature), latinité/SLA, retrai/quorum.
Coût par message/volume, rapport et audit.
Prise en charge de la politique unhosted (validation de la propriété de l'adresse), sandbox et certification.

3) Architecture de référence de l'intégration

1. Payments Core → initie la cryptopérèse.

2. Compliance Orchestrator décide → si Travel Rule (seuil/géo/type de contrepartie) est nécessaire.

3. Travel Rule Gateway (votre service)

Modèle IVMS101 canonique ;

Adaptateurs à TRISA/TRP/OpenVASP/agrégateur ;

Signature/cryptage, idempotence, retrai/quotas.
4. Directory/Discovery → recherche de contrepartie, validation de certificats/stratégies.
5. KYT/Santé Engine → pré-vérification avant l'échange.
6. PII Vault → stockage des champs personnels, tokenisation, RBAC/audit.

1. Création d'une demande → 2) COT/Sanctions pre-check → 3) Discovery VASP → 4) Échange de IVMS101 (request/response) → 5) Décision allow/hold/reject → 6) Onchein broadcast → 7) Logs/rapport.

4) Modèle de données canoniques (IVMS101)

• Originator: name, identifier, country/address or DOB, account/wallet id.
• Beneficiary: name (при VASP), account/wallet id.
• Transaction: asset, chain, amount, timestamp, internal transfer id.
• Compliance refs: KYT check id, sanctions screen id, Travel Rule message id.

Pratique : gardez le IVMS101 comme « modèle canonique » dans votre OBD ; les adaptateurs effectuent des transformations en un protocole spécifique.

5) Security & Trust

mTLS avec authentification mutuelle (PKI/Directory).
Signature des messages et cryptage des contenus (PII).
RBAC/SoD : répartition des rôles pour l'envoi, l'approbation et l'exportation de données.
Logs/logs immuables : qui/quoi/quand a envoyé, version du schéma.

6) Discovery/Directory

Recherche de contrepartie par VASP ID, domaine, LEI/BIC (si disponible).
Mise en cache des enregistrements, rotation des certificats, liste des AC de confiance.
Canal Folback : demande de confirmation des détails via l'agrégateur ou le « pont » (si la politique l'autorise).

7) Gestion des flux et SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Solution auto-case : ≤ 2-5 min, High-risk manuel : ≤ 4 h.

• Backoff + jitter exponentiel ; idempotence par 'travel _ rule _ message _ id'.
• Auto-connexion à l'adaptateur de secours/à la dégradation.
• Quorum de confirmation de livraison/lecture (ACK/NACK).

8) Gestion des erreurs (playbook)

9) La politique pour les porte-monnaie unhosted

Preuve de possession de l'adresse (signature, « prouf-micro-transfert »).
KYT avant l'enrôlement et avant le retrait ; limites par segment.
Address book/whitelist avec TTL et revérification périodique.
Documenter les exceptions RBA (petites sommes/faible risque) - lorsque c'est légal.

10) PII Vault et la vie privée

Séparez le PII des logs d'exploitation et des données de paiement.
Cryptage (KMS/HSM), tokenization des identifiants, accès need-to-know.
Retraite par juridiction (souvent 5 + ans), auto-exportation, procédure DSR.
Versioner les schémas de IVMS101 et d'audit pour chaque échange.

11) Modèles d'intégration

11. 1 Couche adaptatrice

Interface : 'send (ivms_payload) -> ack '/' receive () -> ivms_payload'.
Transformations : IVMS101 ⇄ format spécifique (TRISA/TRP/OpenVASP/hub).
Versioning API, webhooks signés, retransmissions déterministes.

11. 2 Solutions de conformité

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Libération partielle si une partie des fonds est « propre ».
Lien avec KYT : n'envoyez pas de route de voyage sur des itinéraires apparemment interdits.

11. 3 Fiabilité

Deux fournisseurs/protocoles ou plus via une seule passerelle.
Health-checks, circuit-breaker, real-time alerte.

12) Essai et mise en service

Sandbox fournisseur + votre simulateur de contrepartie.
Jeu de cas : données complètes/incomplètes, temps, mismatch, méfiance de l'ICP.
Tests de charge (tournois de pointe/actions), mesure p50/p95/pertes.
Formation Payments/Risk/Support : scripts de communication avec les clients.

13) Métriques et dashboards

Coverage %: part des transferts VASP↔VASP avec un échange réussi.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject % et temps moyen de déverrouillage.
Taux complet/Ticket par Travel Rule, sortie NPS.
Cost per Exchange (all-in) : fournisseur + opéra. le temps.

14) Anti-modèles

Envoi Onchein jusqu'à la fin de Travel Rule où vous avez besoin de « pré-transfert ».
Un lien dur sur un fournisseur sans adaptateur-abstraction.
Stockage de PII dans des logs/analyses génériques sans tokenization.
Manque d'idempotence → prise de messages/décisions.
Ignorer unhosted-policy et la vérification d'adresse.
Pas de versioning des schémas/répertoires → des solutions « uniques ».

15) Chèque DP/Mise en œuvre (court)

• Soutien aux IVMS101 (champs obligatoires/optionnels), validation.
• Protocole (s) : TRISA/TRP/OpenVASP, agrégateurs ; Discovery/Directory и PKI.
• Sécurité : mTLS, signature/cryptage, journal des actions, webhooks signés.
• SLA/retrai : objectifs p95, backoff + jitter, circuit-breaker, faucher.
• Compatibilité avec les KUT/sanctions, API pré-check et corélation des cas.
• Unhosted-policy : confirmation d'adresse, whitelist avec TTL, limites.
• PII Vault : cryptage, RBAC/SoD, retraite/DSR, audit.
• Reporting : artefacts d'échange, versions de schémas/étiquettes, exportation pour SAR/STR.
• Sandbox/simulateurs, tests de charge et de tolérance aux pannes.
• Formation des équipes et modèles de communication avec les clients.

16) Résumé

L'intégration de Travel Rule est une architecture gateway avec des IVMS101 comme modèle canonique, Discovery/PKI pour la confiance, des adaptateurs multi-fournisseurs et des règles de sécurité/PII strictes. Liez-la aux solutions KYT et RBA, mettez votre politique en place, fournissez un SLA/faussaire et un UX transparent - et vos crypto-paiements/dépôts répondront aux exigences sans compromettre la vitesse et la conversion.