Integration der Travel Rule der Anbieter

1) Ziel der Integration

• Unterstützung des kanonischen Modells der IVMS101,
• eine dem Anbieter agnostische Adapter-Schicht haben,
• Gewährleistung von Sicherheit (mTLS, Signatur, Verschlüsselung) und SLA,
• hosted↔hosted und Politik für Unhosted abdecken.

2) Protokoll-/Anbieterauswahl: Modelle

2. 1 Protokolle und Vertrauensnetzwerke

TRISA/TRP/OpenVASP - p2p/Verbände mit PKI, VASP-Katalogen, Lieferbestätigung.
Kommerzielle Hubs/Aggregatoren - abstrahieren Transport, geben Discovery und Routing.

2. 2 Auswahlkriterien (Zusammenfassung)

Abdeckung von Jurisdiktionen/VASR, Directory/Discovery Qualität.
Kompatibel mit IVMS101 und Erweiterungen.
Sicherheit (PKI, mTLS, Signatur), Latenz/SLA, Retrays/Quoren.
Kosten pro Nachricht/Volumen, Reporting und Audit.
Unterstützung für Unhosted Policy (Validierung von Adressbesitz), Sandbox und Zertifizierung.

3) Referenzarchitektur der Integration

1. Payments Core → initiiert eine Krypto-Umstellung.

2. Compliance Orchestrator entscheidet →, ob eine Travel Rule (Schwellenwert/Geo/Gegenpartei) erforderlich ist.

3. Travel Rule Gateway (Ihr Service)

kanonisches IVMS101 Modell;

Anpassungen an TRISA/TRP/OpenVASP/Aggregator;

Signatur/Verschlüsselung, Idempotenz, Retrays/Quoten.
4. Directory/Discovery → Suche nach Gegenpartei, Validierung von Zertifikaten/Richtlinien.
5. KYT/Sanctions Engine → Pre-Check vor dem Austausch.
6. PII Vault → Speicherung persönlicher Felder, Tokenisierung, RBAC/Audit.

1. Antragstellung → 2) TAC/Pre-Check-Sanktionen → 3) Discovery VASP → 4) Austausch von IVMS101 (Request/Response) → 5) Allow/Hold/Reject-Entscheidung → 6) Onchain-Broadcast → 7) Protokolle/Bericht.

4) Kanonisches Datenmodell (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.

Praxis: Speichern Sie IVMS101 als „canonical model“ in Ihrer Datenbank; Adapter machen Transformationen in ein bestimmtes Protokoll.

5) Security & Trust

mTLS mit gegenseitiger Authentifizierung (PKI/Directory).
Signieren von Nachrichten und Ende-zu-Ende-Verschlüsselung von Inhalten (PII).
RBAC/SoD: Rollenaufteilung für das Senden/Genehmigen/Exportieren von Daten.
Protokolle/unveränderliche Protokolle: wer/was/wann gesendet, Schemaversion.

6) Discovery/Directory

Suche der Gegenpartei nach VASP-ID, Domain, LEI/BIC (wo verfügbar).
Datensätze zwischenspeichern, Zertifikate rotieren, vertrauenswürdige CAs auflisten.
Folback-Kanal: Fordern Sie eine Bestätigung der Identität über einen Aggregator oder eine „Brücke“ an (sofern von der Politik erlaubt).

7) Flow Management und SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Auto-Case-Lösung: ≤ 2-5 Minuten, manuelles High-Risk: ≤ 4 Stunden.

• Exponentieller Backoff + Jitter; Idempotenz durch „travel _ rule _ message _ id“.
• Automatische Umschaltung auf Backup-Adapter/Hub bei Degradation.
• Quorum der Zustell-/Lesebestätigungen (ACK/NACK).

8) Fehlerbehandlung (Playbook)

9) Politik für Unhosted-Wallets

Nachweis des Besitzes der Adresse (Unterschrift, „Mikroproof-Transfer“).
KYT vor der Einschreibung und vor dem Rückzug; Segmentlimits.
Adressbuch/Whitelist mit TTL und periodischer Überprüfung.
Dokumentieren Sie RBA-Ausnahmen (kleine Beträge/geringes Risiko) - wo es legal ist.

10) PII Vault und Privatsphäre

Trennen Sie die PII von den Betriebsprotokollen und Zahlungsdaten.
Verschlüsselung (KMS/HSM), Tokenisierung von IDs, Need-to-Know-Zugriff.
Retention nach Gerichtsbarkeit (oft 5 + Jahre), Auto-Exiration, DSR-Verfahren.
Versionierung von IVMS101 und Audit Trail Schemas für jeden Austausch.

11) Integrationsmuster

11. 1 Adapter-Ebene

Schnittstelle: 'send (ivms_payload) -> ack '/' receive () -> ivms_payload'.
Transformationen: IVMS101 ⇄ ein bestimmtes Format (TRISA/TRP/OpenVASP/Hub).
API-Versionierung, signierte Webhooks, deterministische Neueinreichungen.

11. 2 Compliance-Lösungen

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Partielle Freigabe, wenn ein Teil der Mittel „sauber“ ist.
KYT-Verbindung: Senden Sie keine Travel Rule auf offensichtlich verbotenen Routen.

11. 3 Zuverlässigkeit

Zwei oder mehr Anbieter/Protokolle über ein einziges Gateway.
Gesundheitschecks, Circuit-Breaker, Echtzeit-Warnungen.

12) Prüfung und Inbetriebnahme

Die Sandbox des Anbieters + Ihr Kontrahenten-Simulator.
Fallset: vollständige/unvollständige Daten, Timeouts, Mismatch, PKI-Misstrauen.
Belastungstests (Spitzenturniere/Aktionen), Messung p50/p95/Verluste.
Payments/Risk/Support Training: Skripte für die Kommunikation mit Kunden.

13) Metriken und Dashboards

Coverage%: Anteil VASP↔VASP Überweisungen mit erfolgreichem Austausch.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject% und durchschnittliche Entsperrzeit.
Complaint/Ticket Rate nach Travel Rule, NPS Ausgabe.
Kosten pro Austausch (All-in): Anbieter + Oper. Zeit.

14) Anti-Muster

Onchain-Versand bis zum Abschluss der Travel Rule, wo „Pre-Transfer“ benötigt wird.
Harte Bindung an einen Anbieter ohne Adapter-Abstraktion.
Speicherung von PII in generischen Protokollen/Analysen ohne Tokenisierung.
Keine Idempotenz → doppelte Nachrichten/Entscheidungen.
Ignoriere unhosted-policy und Adressverifizierung.
Es gibt keine Versionierung von Schemata/Verzeichnissen → „nicht wiederholbare“ Lösungen.

15) Checkliste RFP/Umsetzung (kurz)

• Unterstützung für IVMS101 (obligatorische/optionale Felder), Validierung.
• Protokoll (e): TRISA/TRP/OpenVASP, Aggregatoren; Discovery/Directory и PKI.
• Sicherheit: mTLS, Signatur/Verschlüsselung, Aktivitätsprotokoll, signierte Webhooks.
• SLA/Retrays: p95 goals, backoff + jitter, circuit-breaker, failover.
• Kompatibilität mit TAC/Sanktionen, Pre-Check-API und Fallkorrelation.
• Unhosted-policy: Adressbestätigung, Whitelist mit TTL, Limits.
• PII Vault: Verschlüsselung, RBAC/SoD, Retention/DSR, Audit.
• Reporting: Austauschartefakte, Schema-/Label-Versionen, Export für SAR/STR.
• Sandbox/Simulatoren, Last- und Fail-Safe-Tests.
• Teamschulungen und Vorlagen für die Kommunikation mit Kunden.

16) Zusammenfassung

Travel Rule Integration ist eine Gateway-Architektur mit IVMS101 als kanonischem Modell, Discovery/PKI für Vertrauen, Multi-Provider-Adaptern und strengen Security/PII-Regeln. Verknüpfen Sie es mit KYT und RBA-Lösungen, schreiben Sie die Richtlinie für Unhosted auf, sichern Sie sich einen SLA/Failover und eine transparente UX - und Ihre Krypto-Auszahlungen/Einzahlungen werden die Anforderungen erfüllen, ohne Kompromisse bei Geschwindigkeit und Konvertierung einzugehen.