Données et messagerie de la Travel Rule

Un programme de Travel Rule n'est efficace que dans la mesure où les messages qu'il envoie et reçoit le sont. Les équipes de conformité n'ont pas besoin d'écrire le code, mais elles doivent pouvoir lire un message, repérer un champ manquant ou mal formé, évaluer si un protocole authentifie la contrepartie et protège les données, et déterminer quand les données doivent arriver. Cette leçon vous apporte ces connaissances pratiques.

IVMS101 : un modèle de données commun

La norme de messagerie interVASP (IVMS101) définit la structure des données de l'initiateur et du bénéficiaire afin que deux VASP puissent lire leurs messages respectifs. Un groupe de travail conjoint du secteur a publié la première version en mai 2020. La version actuelle, IVMS 101.2023, est maintenue par le groupe de travail sur les normes interVASP, qui a publié une mise à jour en juin 2024.

IVMS101 est un modèle de données, pas un protocole. Sa déclaration de portée exclut la sécurité de l'information, la confidentialité des données, l'identification des VASP, les protocoles réseau et le stockage, et ne dit rien sur la manière dont le VASP du bénéficiaire utilise les données. Les détails de la transaction, tels que l'actif, le montant et le txid, n'en font pas non plus partie ; le protocole de messagerie les transporte dans sa propre enveloppe.

Le modèle comporte un petit nombre d'éléments constitutifs :

Les noms sont divisés en un primaryIdentifier (généralement le nom de famille) et un secondaryIdentifier (prénoms), chacun étant associé à un code de type comme LEGL pour le nom légal ou ALIA pour un alias. Les noms dans un alphabet national sont indiqués dans localNameIdentifier, tandis que la forme latine figure dans nameIdentifier. Les adresses comportent un addressType (HOME, BIZZ ou GEOG), un townName et un country obligatoires, ainsi que soit un addressLine, soit des champs d'adresse structurés. Les identifiants nationaux comportent un nationalIdentifierType, comme CCPT (passeport), RAID (identifiant de l'autorité d'enregistrement) ou LEIX (LEI).

Règles de validation à connaître

IVMS101 associe des contraintes au modèle, et une personne chargée de la vérification de la conformité peut s'en servir comme liste de contrôle :

• Un initiateur qui est une personne physique doit avoir au moins l'un des éléments suivants : une adresse géographique, une identification du client, une identification nationale, ou la date et le lieu de naissance. Cela reprend l'élément « l'un des éléments suivants » de l'ensemble de données du GAFI.
• Chaque personne doit avoir au moins un nom de type LEGL.
• Les valeurs de pays doivent être des codes ISO 3166-1 alpha-2 (ou XX), et les dates doivent respecter la norme ISO 8601. Une date de naissance doit être passée.
• L'identifiant national d'une personne morale doit être de type RAID, MISC, LEIX ou TXID. Un LEI ne comporte ni pays de délivrance ni autorité d'enregistrement.
• Les données sont en UTF-8 et, sauf indication contraire, en alphabet latin.

La réussite de la validation montre qu'un message est bien formé. Elle ne prouve ni que les données sont exactes ni qu'elles correspondent au bon client.

Exemple de message

{
  "payloadMetadata": { "payloadVersion": "101.2023" },
  "originator": { "originatorPerson": [ {
    "naturalPerson": {
      "name": { "nameIdentifier": [ { "primaryIdentifier": "Moreau", "secondaryIdentifier": "Lea",
                "naturalPersonNameIdentifierType": "LEGL" } ] },
      "geographicAddress": [ { "addressType": "HOME", "streetName": "Harbor Road", "buildingNumber": "18",
                "townName": "Port Alder", "country": "XX" } ],
      "dateAndPlaceOfBirth": { "dateOfBirth": "1990-03-14", "placeOfBirth": "Port Alder" } },
    "accountNumber": [ "bc1q…7k3f" ] } ] },
  "beneficiary": { "beneficiaryPerson": [ {
    "naturalPerson": { "name": { "nameIdentifier": [ { "primaryIdentifier": "Okafor",
                "secondaryIdentifier": "Chidi", "naturalPersonNameIdentifierType": "LEGL" } ] } },
    "accountNumber": [ "bc1q…9m2x" ] } ] },
  "originatingVASP": { "originatingVASP": { "legalPerson": {
    "name": { "nameIdentifier": [ { "legalPersonName": "Alpha Exchange Ltd", "legalPersonNameIdentifierType": "LEGL" } ] },
    "nationalIdentification": { "nationalIdentifier": "5493…0042", "nationalIdentifierType": "LEIX" } } } }
}

Ce message fictif présente un initiateur qui est une personne physique avec un nom légal, une adresse personnelle et une date et un lieu de naissance, ce qui satisfait largement à la règle « l'un des éléments suivants ». Le bénéficiaire n'a qu'un nom et un compte, ce qui correspond à tout ce que le VASP initiateur est censé connaître. Le VASP initiateur s'identifie par son nom légal et son LEI (tronqué ici). Le code de pays XX est autorisé par la norme ; un message réel contiendrait le code ISO. Un bloc beneficiaryVASP suivrait normalement.

Les versions comptent. Dans la version 2020, la liste des initiateurs était au pluriel (originatorPersons), le numéro de compte se trouvait directement sous l'initiateur et le bénéficiaire, et l'élément de type de nom de personne physique s'appelait nameIdentifierType (un exemple détaillé du texte de 2023 utilise encore l'ancien nom, d'où l'intérêt d'une analyse tolérante). Un analyseur syntaxique qui s'attend à une seule version peut supprimer silencieusement des données de l'autre, c'est pourquoi IVMS 101.2023 rend payloadVersion obligatoire.

Vérification d'un message entrant

Lorsqu'un message arrive, le VASP du bénéficiaire suit une séquence définie avant de l'accepter :

1. Version et validité. Lire payloadVersion, analyser le message avec le schéma correspondant et effectuer les contrôles de contraintes. Un message qui échoue est une exception, pas une réussite partielle.
2. Correspondance du compte. Confirmer que accountNumber (ou l'adresse et le tag dans l'enveloppe du protocole) est une adresse de dépôt appartenant à l'un de ses clients.
3. Correspondance du nom. Comparer le nom du bénéficiaire au nom vérifié du titulaire du compte. Utiliser une correspondance approximative qui tolère l'inversion des identifiants principal et secondaire, l'absence d'accents, les différences de translittération et les deuxièmes prénoms, puis consigner le score et le motif de l'acceptation ou du rejet.
4. Filtrage de l'initiateur. Vérifier le nom de l'initiateur et, s'il est présent, sa date de naissance par rapport aux listes de sanctions, et intégrer les données à la surveillance.
5. Vérification de la contrepartie. Confirmer que le originatingVASP correspond à l'expéditeur authentifié et à une contrepartie ayant fait l'objet d'un contrôle préalable à jour.
6. Décision et stockage. Accepter ou rejeter, renvoyer la réponse et stocker ensemble le message, la réponse et le txid final.

C'est aux étapes 3 et 4 que surviennent la plupart des problèmes réels : paiements adressés à la mauvaise personne, comptes utilisés par quelqu'un d'autre que leur titulaire et correspondances avec des listes de sanctions.

Protocoles et réseaux

IVMS101 nécessite un moyen de transport. Les solutions se répartissent en deux grandes catégories :

• Les protocoles ouverts publient leurs spécifications afin que chacun puisse les mettre en œuvre. TRP (Travel Rule Protocol), désormais maintenu sous l'égide de l'OpenVASP Association, est un protocole fondé sur une API qui utilise TLS avec authentification mutuelle et une « Travel Address » encodant le point de terminaison du VASP bénéficiaire. TRISA (Travel Rule Information Sharing Architecture) combine un répertoire, des certificats délivrés à des VASP vérifiés, des connexions avec authentification mutuelle et des enveloppes scellées que seul le destinataire peut déchiffrer. OpenVASP était initialement un protocole distinct avant que son association ne prenne en charge la gestion de TRP.
• Les réseaux fermés sont gérés par un seul opérateur qui admet les membres, héberge le répertoire et a souventchemine les messages. Il peut être plus facile de les rejoindre, mais l'entreprise dépend alors de la couverture de cet opérateur.

Chaque solution doit résoudre les quatre mêmes problèmes :

L'interopérabilité est la lacune pratique la plus fréquente. Une entreprise qui prend en charge un seul protocole ne peut joindre que les membres de ce protocole ; la plupart des entreprises en prennent donc en charge plusieurs ou utilisent des passerelles, et vérifient que les champs sont conservés lors de la traduction.

Flux prétransactionnels et posttransactionnels

Dans un flux prétransactionnel, le VASP initiateur envoie les données, attend l'acceptation du VASP bénéficiaire, puis diffuse la transaction et envoie le txid. Dans un flux posttransactionnel, la transaction est d'abord diffusée et les données suivent.

L'échange prétransactionnel constitue un contrôle plus robuste, car un transfert confirmé ne peut pas être annulé. Les flux posttransactionnels restent fréquents lorsque l'outil de la contrepartie ne peut pas répondre en temps réel ; l'entreprise doit alors surveiller le délai réel d'arrivée des données.

Points clés pour l'examen : comprendre qu'IVMS101 est un modèle de données, pas un protocole, et connaître les éléments exclus de sa portée (sécurité, identification des VASP, transport, données de transaction) ; connaître les principales entités et les principaux éléments d'IVMS 101.2023, les types de noms tels que LEGL, les types d'adresses et les types d'identifiants tels que LEIX ; connaître les principales règles de validation (la règle « l'un des éléments suivants » pour les initiateurs qui sont des personnes physiques, le nom légal obligatoire, les formats ISO des pays et des dates) ; savoir lire un exemple de message et repérer un élément manquant ; connaître les différences entre les versions 2020 et 2023 et l'importance de payloadVersion ; distinguer les protocoles ouverts des réseaux fermés et connaître les quatre problèmes de découverte, d'authentification, de chiffrement et d'interopérabilité ; distinguer les flux prétransactionnels des flux posttransactionnels.