Daten und Nachrichten zur Travel Rule

Ein Travel-Rule-Programm ist nur so gut wie die Nachrichten, die es sendet und empfängt. Compliance-Teams müssen den Code nicht schreiben, aber sie müssen eine Nachricht lesen, ein fehlendes oder fehlerhaftes Feld erkennen, beurteilen können, ob ein Protokoll die Gegenpartei authentifiziert und die Daten schützt, und entscheiden, wann die Daten eintreffen müssen. Diese Lektion vermittelt Ihnen das dafür erforderliche Praxiswissen.

IVMS101: ein gemeinsames Datenmodell

Der interVASP Messaging Standard (IVMS101) legt fest, wie Daten zu Auftraggebern und Begünstigten strukturiert werden, damit beliebige zwei VASPs die Nachrichten des jeweils anderen lesen können. Eine gemeinsame Arbeitsgruppe der Branche veröffentlichte die erste Version im Mai 2020. Die aktuelle Version, IVMS 101.2023, wird von der interVASP Standards Working Group gepflegt, die im Juni 2024 eine Aktualisierung veröffentlichte.

IVMS101 ist ein Datenmodell, kein Protokoll. Die eigene Geltungsbereichserklärung schließt Informationssicherheit, Datenschutz, die Identifizierung von VASPs, Netzwerkprotokolle und Speicherung aus; außerdem enthält sie keine Aussagen dazu, wie der begünstigte VASP die Daten verwendet. Transaktionsdetails wie der Vermögenswert, der Betrag und die txid fallen ebenfalls nicht darunter; das Messaging-Protokoll überträgt sie in seiner eigenen Hülle.

Das Modell besteht aus einer kleinen Anzahl von Bausteinen:

Namen werden in eine primaryIdentifier (in der Regel den Familiennamen) und eine secondaryIdentifier (Vornamen) aufgeteilt, die jeweils mit einem Typcode versehen sind, etwa LEGL für den rechtlichen Namen oder ALIA für einen Alias. Namen in einer Landesschrift werden in localNameIdentifier eingetragen, die lateinische Schreibweise in nameIdentifier. Adressen enthalten einen addressType (HOME, BIZZ oder GEOG), einen verpflichtenden townName und ein country-Feld sowie entweder addressLine oder strukturierte Straßenfelder. Nationale Identifikatoren enthalten einen nationalIdentifierType, etwa CCPT (Reisepass), RAID (Identifikator der Registrierungsbehörde) oder LEIX (LEI).

Wichtige Validierungsregeln

IVMS101 versieht das Modell mit Einschränkungen, die Compliance-Prüfer als Checkliste verwenden können:

• Ein Auftraggeber, der eine natürliche Person ist, muss mindestens eine der folgenden Angaben haben: eine geografische Adresse, eine Kundenidentifikation, eine nationale Identifikation oder Geburtsdatum und Geburtsort. Dies entspricht dem „mindestens eine von“-Element im FATF-Datensatz.
• Jede Person benötigt mindestens einen Namen des Typs LEGL.
• Länderwerte müssen ISO-3166-1-Alpha-2-Codes (oder XX) sein, und Datumsangaben müssen ISO 8601 entsprechen. Ein Geburtsdatum muss in der Vergangenheit liegen.
• Der nationale Identifikator einer juristischen Person muss vom Typ RAID, MISC, LEIX oder TXID sein. Bei einem LEI gibt es weder ein Ausgabeland noch eine Registrierungsbehörde.
• Die Daten liegen in UTF-8 und, sofern nicht anders angegeben, in lateinischer Schrift vor.

Eine erfolgreiche Validierung zeigt, dass eine Nachricht wohlgeformt ist. Sie zeigt nicht, dass die Daten wahr sind oder zum richtigen Kunden gehören.

Eine Beispielnachricht

{
  "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" } } } }
}

Die fiktive Nachricht zeigt einen Auftraggeber, der eine natürliche Person ist und einen rechtlichen Namen, eine Wohnadresse sowie Geburtsdatum und Geburtsort angibt; damit erfüllt er die „mindestens eine von“-Regel mehr als ausreichend. Der Begünstigte hat lediglich einen Namen und ein Konto, was alles ist, was der auftraggebende VASP voraussichtlich wissen wird. Der auftraggebende VASP weist sich mit seinem rechtlichen Namen und seiner LEI aus (hier gekürzt). Der Ländercode XX ist nach dem Standard zulässig; eine echte Nachricht würde den ISO-Code enthalten. Normalerweise würde ein beneficiaryVASP-Block folgen.

Versionen sind wichtig. In der Version von 2020 war die Liste der Auftraggeber plural (originatorPersons), die Kontonummer stand direkt unter dem Auftraggeber und dem Begünstigten, und das Namens-Typ-Element für natürliche Personen hieß nameIdentifierType (ein ausgearbeitetes Beispiel im Text von 2023 selbst verwendet noch die alte Bezeichnung, weshalb eine tolerante Verarbeitung hilfreich ist). Ein Parser, der eine Version erwartet, kann Daten aus der anderen unbemerkt verwerfen. Deshalb schreibt IVMS 101.2023 payloadVersion verpflichtend vor.

Prüfung einer eingehenden Nachricht

Wenn eine Nachricht eintrifft, arbeitet der begünstigte VASP vor der Annahme eine feste Abfolge ab:

1. Version und Gültigkeit. payloadVersion auslesen, die Nachricht mit dem passenden Schema parsen und die Einschränkungen prüfen. Eine Nachricht, die die Prüfung nicht besteht, ist ein Ausnahmefall und kein Teilerfolg.
2. Kontenabgleich. Bestätigen, dass accountNumber (oder die Adresse und der Tag in der Protokollhülle) eine Einzahlungsadresse eines seiner Kunden ist.
3. Namensabgleich. Den Namen des Begünstigten mit dem verifizierten Namen des Kontoinhabers vergleichen. Eine unscharfe Übereinstimmungssuche verwenden, die vertauschte primäre und sekundäre Identifikatoren, fehlende Akzente, Transliterationabweichungen und Zweitnamen toleriert; außerdem den Übereinstimmungswert sowie den Grund für die Annahme oder Ablehnung dokumentieren.
4. Prüfung des Auftraggebers. Den Namen des Auftraggebers und, falls vorhanden, sein Geburtsdatum mit Sanktionslisten abgleichen und die Daten in die Überwachung einbeziehen.
5. Prüfung der Gegenpartei. Bestätigen, dass der originatingVASP dem authentifizierten Absender und einer Gegenpartei mit aktueller Due-Diligence-Prüfung entspricht.
6. Entscheidung und Speicherung. Annehmen oder ablehnen, die Antwort zurücksenden und die Nachricht, die Antwort und die spätere txid gemeinsam speichern.

Bei den Schritten 3 und 4 treten die meisten echten Auffälligkeiten auf: Zahlungen an die falsche Person, Konten, die von einer anderen Person als dem Kontoinhaber genutzt werden, und Sanktionsübereinstimmungen.

Protokolle und Netzwerke

IVMS101 benötigt einen Transport. Die Lösungen fallen in zwei große Gruppen:

• Offene Protokolle veröffentlichen ihre Spezifikationen, sodass sie von allen implementiert werden können. TRP (Travel Rule Protocol), das jetzt von der OpenVASP Association betreut wird, ist ein API-basiertes Protokoll, das gegenseitig authentifiziertes TLS und eine „Travel Address“ verwendet, die den Endpunkt des begünstigten VASP kodiert. TRISA (Travel Rule Information Sharing Architecture) kombiniert ein Verzeichnis, an verifizierte VASPs ausgestellte Zertifikate, gegenseitig authentifizierte Verbindungen und versiegelte Nachrichten, die nur der Empfänger entschlüsseln kann. OpenVASP begann als separates Protokoll, bevor dessen Verband die Betreuung von TRP übernahm.
• Geschlossene Netzwerke werden von einem einzelnen Betreiber geführt, der Mitglieder zulässt, das Verzeichnis hostet und die Nachrichten häufig weiterleitet. Der Beitritt kann einfacher sein, bindet das Unternehmen aber an die Reichweite dieses Betreibers.

Jede Lösung muss dieselben vier Probleme lösen:

Interoperabilität ist in der Praxis die häufigste Lücke. Ein Unternehmen, das ein Protokoll unterstützt, kann nur dessen Mitglieder erreichen. Deshalb unterstützen die meisten Unternehmen mehrere Protokolle oder verwenden Bridges und testen, ob die Felder bei der Übersetzung erhalten bleiben.

Abläufe vor und nach der Transaktion

Bei einem Ablauf vor der Transaktion sendet der auftraggebende VASP die Daten, wartet auf die Annahme durch den begünstigten VASP und überträgt erst dann die Transaktion und sendet die txid. Bei einem Ablauf nach der Transaktion wird die Transaktion zuerst übertragen und die Daten folgen danach.

Der Datenaustausch vor der Transaktion bietet eine stärkere Kontrolle, da eine bestätigte Übertragung nicht rückgängig gemacht werden kann. Abläufe nach der Transaktion sind weiterhin üblich, wenn das Tool der Gegenpartei nicht in Echtzeit antworten kann. In diesem Fall muss das Unternehmen überwachen, wie spät die Daten tatsächlich eintreffen.

Prüfungsschwerpunkt: IVMS101 ist ein Datenmodell und kein Protokoll; außerdem, was sein Geltungsbereich ausschließt (Sicherheit, VASP-Identifizierung, Transport, Transaktionsdaten); die wichtigsten Entitäten und Elemente von IVMS 101.2023, Namenstypen wie LEGL, Adresstypen und Identifikatortypen wie LEIX; wichtige Validierungsregeln (die „mindestens eine von“-Regel für Auftraggeber, die natürliche Personen sind, ein verpflichtender rechtlicher Name, ISO-Formate für Länder und Datumsangaben); das Lesen einer Beispielnachricht und das Erkennen eines fehlenden Elements; die Versionsunterschiede zwischen 2020 und 2023 und die Bedeutung von payloadVersion; offene Protokolle im Vergleich zu geschlossenen Netzwerken sowie die vier Probleme Ermittlung, Authentifizierung, Verschlüsselung und Interoperabilität; Abläufe vor und nach der Transaktion.