Travel Rule für Krypto-Zahlungen

1) Was ist die Travel Rule und warum wird sie benötigt?

Die Travel Rule ist eine regulatorische Anforderung für Anbieter von virtuellen Assets (VASPs), um die Identität von Absender und Empfänger bei Transfers von Krypto-Assets auszutauschen. Ziel: Verringerung der AML/CTF-Risiken, Vereinfachung der Untersuchungen und Verbesserung der Transparenz von Cross-VASP-Transfers unter Beibehaltung der Funktionsfähigkeit der Onchain-Infrastruktur.

• Die Daten „reisen“ zusammen mit der Übersetzung (Off-Chain-Kommunikationskanal VASP↔VASP).
• Anforderungen und Schwellenwerte hängen von der Gerichtsbarkeit ab; oft liegt die Schwelle in der Nähe von ~ 1000 (Äquivalent), aber in einer Reihe von Modi gilt auch für kleinere Beträge - fixieren Sie die lokale Norm in Ihrer Politik.
• Die Anforderungen unterscheiden zwischen hosted (Verwahrung) und unhosted (unabhängige) Geldbörsen.

2) Objekte und Einsatzgebiete

VASP → VASP (hosted ↔ hosted): vollständiger Datenaustausch nach Standard (vorzugsweise vor dem Onchain-Broadcast).
VASP → Unhosted: Sammlung/Verifizierung von Informationen über den Adressaten und die Herkunft der Mittel im Rahmen der lokalen RBA-Politik; kein Austausch mit „Kontrahent-VASP“.
Cross-Border: Verwenden Sie Discovery/Directory und Trust Agreements, um eine Gegenpartei und einen sicheren Kanal zu finden.

3) Welche Daten werden übertragen (Mindestzusammensetzung)

• Der Name (oder Naim. Unternehmen), eine eindeutige Kunden-ID (aus Ihrem System),
• Adresse/Land oder Geburtsdatum (je nach Land variabel),
• Kontonummer/Wallet-Nummer (interne ID/Adresse),
• Kontakte (falls erforderlich), VASP-ID (LEI/BIC/reg. Nummer - falls zutreffend).

• Name/Name (wenn der Empfänger in einem anderen VASP ist und verifiziert ist),
• Konto-/Wallet-ID des Begünstigten-VASP,
• Bei unhosted - Informationen, die vom Kunden gemäß Ihrer RBA-Richtlinie gesammelt wurden.

• Asset/Netzwerk (BTC, ETH/Kette), Betrag, Zeitstempel,
• Zahlungs-/Transfer-ID, TAC-Referenz/Sanktionsscreening,
• Die Sitzungs-/Nachrichten-ID der Reiseregel.

4) Austauschstandards und Protokolle

IVMS101 - Datenmodell (was und wie zu benennen).
TRISA/TRP/OpenVASP - Netzwerkprotokolle und „Vertrauensnetzwerke“ (PKI, mTLS, VASP-Verzeichnisse, Routing, Zustellbestätigung).
Kommerzielle Hubs/Aggregatoren können Interoperabilität (Gateway-Ansatz) und Discovery implementieren.

Empfehlung: Abstrahieren Sie den Transport (Adapter-Layer) und speichern Sie IVMS101 als „canonical model“, um den Provider/das Protokoll frei zu wechseln, ohne die API zu brechen.

5) Implementierungsarchitektur (Referenz)

1. Travel Rule Gateway (Microservice): Empfang/Versand von IVMS101-Nachrichten, Signatur/Verschlüsselung, Retrays, Quoten.

2. Verzeichnis/Entdeckung: Suche nach einem Gegen-VASP (Registry, PKI, Trust Policy).

3. KYT/Sanctions Engine: Adressen/Börsen/Cluster-Screening, Risikobewertung vor dem Versand.

4. Compliance Engine (RBA): Entscheidung treffen: allow/hold/reject/dop.danne.

5. Fallmanagement: Fälle, Anhänge, SLA, Eskalationen (L1/L2/L3).

6. PII Vault: sichere Speicherung personenbezogener Daten (Verschlüsselung, Tokenisierung, RBAC, Audit).

1. Der Kunde erstellt eine Übersetzung → 2) TAC/Pre-Check-Sanktionen → 3) Discovery des Vertragspartners → 4) Austausch von IVMS101 (vor der Onchain) → 5) Entscheidung (allow/hold) → 6) Onchain-Broadcast → 7) Post-Fact-Reporting/Logging.

6) Unhosted Geldbörsen: Politik und Kontrollen

Sammlung von Informationen über die Gegenpartei vom Kunden (Name/Land/Beziehung), Nachweis des Besitzes der Adresse (Unterschrift mit einer Nachricht, kleiner „Proof-Transfer“, Überprüfung an der Börse).
Risikoregeln: Verbot/Grenzwerte für Adressen mit hohem KYT-Risiko (Mixer, „dunkle“ Märkte, Sanktionscluster), Verbot von P2P-Plattformen ohne KYC gemäß Ihrer Richtlinie.
Weiße Adresslisten (Adressbuch/Whitelisting) mit TTL und Revue.

7) Integration mit TAC/Sanktionen und AML

KYT (Know Your Transaction): Risikobewertung von Adressen/Börsen, Verbindungen zu N-Hops mit „schlechten“ Clustern, Volumen-/Routenanomalien.
Sanktionen: Kunden/Gegenpartei-Screening (KYC/KYB) und Infrastruktur (Börsen, Depots).
Positives Risiko → Halten, Anforderung von Dokumenten (SoF/SoW) und/oder Ablehnung, falls erforderlich - SAR/STR.

8) Daten und Datenschutz (DSGVO/Sicherheit)

Minimierung: Speichern Sie nur die erforderlichen Travel Rule Felder; Trennen Sie die PII von der Zahlung PAN/Schlüssel.
Verschlüsselung: im Ruhezustand (KMS/HSM) und im Transit (mTLS), Schlüsselrotation.
Zugang: strenge RBAC, Aktivitätsprotokoll, Need-to-Know-Prinzip.
Retention: nach dem Recht der Gerichtsbarkeit (oft 5 + Jahre); automatische Lösch- und Löschberichte.
DSR: Verfahren für Zugang/Berichtigung/Löschung, falls zutreffend.

9) SLA, Retrays und Degradation

• Pre-Check (TAC/Sanktionen): ≤ 5-15 c p95.
• Discovery + Exchange (VASP↔VASP): ≤ 60-120 c p95 (einschließlich Retrays).
• Lösung (allow/hold/reject): ≤ 2-5 min p95 für auto-cases; Manuelles High-Risk Review - ≤ 4 Stunden

• Exponentieller Backoff + Jitter; alternative Endpoints.
• Sunrise-Problem (der Vertragspartner unterstützt die Travel Rule nicht): RBA-Ausnahmen/-Limits, manueller Austausch über einen verschlüsselten Kanal (sofern gesetzlich zulässig) oder Opt-out.

10) UX-Muster (ohne die Konvertierung zu brechen)

Vorbelegung der Empfängerdaten bei häufigen Überweisungen (Adressbuch).
Klare Botschaften: „Adressnachweis erforderlich “/„ Zur Einhaltung der Regel werden Empfängerdaten benötigt“.
Kontextprüfungen (Adresssignatur, Mikroübergabe) mit Schritt-für-Schritt-Hinweisen.
Status und Timer durch Halten/Überprüfen, transparente Erwartungen.
Alternativen: „Get an der Börse mit KYC“ bei Ausfall unhosted.

11) Metriken und Qualitätskontrolle

• Travel Rule Coverage% (Anteil der Transfers VASP↔VASP mit dem erfolgreichen Austausch von IVMS101).
• Anteil unhosted mit bestandener Adressverifizierung und SoF (nach Schwelle).
• SLA-Hit-Rate für Austausch/Entscheidungen; Anteil manueller Fälle.

• KYT-Hochrisikoquote, Sanktionsverweigerungen, SAR-Umstellung.
• Wiederholte Alerts nach Adressen/Clustern, teilen „false positive“ nach KYT.

• Zeit bis zur Übersetzung p50/p95, Ausfall durch Travel Rule (Impact), Umwandlung von Neuübersetzungen (Adressbuch).

12) Entscheidungsmatrix (Skizze)

13) Anti-Muster

Senden von Einlagen, bis der Datenaustausch abgeschlossen ist VASP↔VASP (in Modi, in denen vor der Übersetzung erforderlich ist).
„Blind“ blockiert alle Unhosted ohne RBA-Ausnahmen und Adressverifizierung.
Fehlende Discovery/Directory → instabile Lieferung und häufige False Hold.
Speicherung überschüssiger PII ohne Ziel/Retention; ungeteilte Protokolle und PII.
Harte Bindung an einen Protokollanbieter ohne Abstraktion (Vendor Lock-in).

14) Checkliste Umsetzung

• Travel Rule Policy: Jurisdiktionen, Schwellenwerte, hosted/unhosted, RBA-Ausnahmen.
• Kanonisches Modell IVMS101 und Adapterschicht unter TRISA/TRP/OpenVASP.
• Directory/Discovery и PKI/mTLS; Verwalten von vertrauenswürdigen VASPs.
• Einbeziehung der TAC/Sanktionen in die Vorprüfung; Hold/Reject-Regeln.
• PII Vault: Verschlüsselung, RBAC, Audit, Retention/DSR.
• SLA/Retrays/Alerts, Dashboards von Metriken; Playbooks der Degradierung.
• Prozesse für Unhosted: Addressable Verification, SoF-Requests, Whitelists.
• Case-Management und Kommunikationsvorlagen; SAR/STR Verfahren.
• Prüfstände: VASP-Gegenpartei-Emulation, Failure-Szenarien, Load-Test.
• Payments/Risk/Compliance/Support Schulungen und regelmäßige Übungen.

15) Zusammenfassung

Bei der Travel Rule geht es nicht „um Krypto“, sondern um den betriebssicheren Datenaustausch zwischen den VASPs. Bauen Sie ein Gateway mit IVMS101 als kanonischem Modell, verbinden Sie Discovery/Directory, integrieren Sie CUT/Sanktion und RBA-Lösungen, schützen Sie PII und stellen Sie verständliche SLAs ein. Dann werden VASP↔VASP-Übersetzungen und die Arbeit mit Unhosted-Adressen schnell und konform sein und die Konvertierung nicht zerstören.