Daten­austausch nach der Travel Rule: TRISA, TRP & OpenVASP im Vergleich (DE)

Betrachtet man die FATF Travel Rule rein mechanisch, ist sie ein Nachrichtenproblem. Bevor eine Krypto-Überweisung abgeschlossen wird, muss die sendende VASP der empfangenden VASP ein strukturiertes Paket mit Informationen über den Absender und den Empfänger – Name, Identifikatoren, Kontoreferenzen – übermitteln, und die empfangende Seite muss dies bestätigen. Der Haken ist, dass es keine einzige globale Schiene für diesen Handshake gibt. Stattdessen gibt es konkurrierende Interoperabilitätsprotokolle, und eine Überweisung ist nur erfolgreich, wenn beide VASPs eines davon sprechen können.

Didit führt diesen Handshake für Sie aus. Der Datenaustausch nach der Travel Rule ist in das Transaktions-Monitoring integriert, und die Engine beherrscht die drei Protokolle, die VASPs tatsächlich in der Produktion verwenden – TRISA, TRP und OpenVASP. Sie senden die Überweisung einmal; die Engine ermittelt die Gegenpartei, wählt ein von beiden Seiten unterstütztes Protokoll, tauscht die Absender- und Empfängerdaten aus und verfolgt die Verpflichtung bis zu einem Status. Dieser Leitfaden erklärt die Protokolle, die Datenpakete und wie der Austausch abläuft.

Wichtige Erkenntnisse

• Die Travel Rule ist ein VASP-zu-VASP-Datenaustausch. Der Absender übermittelt Ursprungs- und Empfängerinformationen; der Empfänger sammelt und bestätigt sie.
• Drei Protokolle unterstützen diesen Austausch – TRISA, TRP und OpenVASP – jedes mit einem anderen Vertrauens- und Transportmodell. Didit unterstützt alle drei.
• Die Nutzlast ist der Datensatz des Absenders und Empfängers – die Parteien der Überweisung, so strukturiert, dass beide VASPs dieselben Felder lesen.
• Didit führt den Austausch innerhalb des Transaktions-Monitorings durch und löst jede Verpflichtung in einen von sechs Status auf (UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT).
• Eine /v3/ API. Krypto-Überweisungen werden an POST https://verification.didit.me/v3/transactions/ mit currency_kind: "crypto" gesendet, und das Wallet-Screening läuft parallel ab 0,02 $ (eigener Schlüssel).

Was die Protokolle leisten

Alle drei Protokolle lösen dieselben zwei Probleme – wie finde und vertraue ich der Gegenpartei-VASP? und wie sende ich ihr die Kundendaten sicher? – aber sie gehen dabei unterschiedliche Kompromisse ein.

• TRISA (Travel Rule Information Sharing Architecture) ist ein Peer-to-Peer-Modell, das auf einer Zertifizierungsstelle aufbaut. VASPs registrieren sich, weisen ihre Identität nach und erhalten Zertifikate, tauschen dann Daten direkt über einen verschlüsselten Kanal aus. Das Vertrauen ist im Verzeichnis der verifizierten Mitglieder verankert.
• TRP (Travel Rule Protocol) ist eine API-First-Spezifikation, die von einer Gruppe größerer Institutionen bevorzugt wird. Sie definiert einen leichtgewichtigen REST-Handshake zum Senden der Absender- und Empfängerdaten zwischen Gegenparteien, die eine Verbindung hergestellt haben.
• OpenVASP ist ein offener Standard, der On-Chain- und Messaging-Layer-Signalisierung verwendet, um eine Sitzung zwischen VASPs vor der Übertragung herzustellen, und dann die Kundendaten Off-Chain austauscht.

Eine VASP, die eine breite Reichweite anstrebt, muss mehr als eines unterstützen, da ihre Gegenparteien nicht alle dasselbe Protokoll verwenden werden. Den Austausch innerhalb von Didit durchzuführen bedeutet, dass Sie nicht ein Protokoll auswählen und hoffen müssen – die Engine verhandelt, welches Protokoll die Gegenpartei unterstützt.

Warum das wichtig ist

Gemäß der FATF-Empfehlung 16 und ihrer regionalen Umsetzungen – allen voran die EU-Geldtransferverordnung – ist der Austausch von Absender- und Empfängerdaten oberhalb des Schwellenwerts obligatorisch, und Aufsichtsbehörden prüfen dies. Die Anforderung ist jedoch in Bezug auf Ergebnisse (die Daten müssen übermittelt, gespeichert und bestätigt werden) formuliert, nicht auf Protokolle. Die Protokollfragmentierung ist eine technische Realität, die Sie erben, keine Regel, aus der Sie sich herauslesen können.

Gerade deshalb sollte die Protokollunterstützung nicht Ihr Problem sein, das Sie lösen müssen. Die Einrichtung einer TRISA-Registrierung, eines TRP-Endpunkts und der OpenVASP-Signalisierung – und die ständige Aktualisierung aller drei – sind laufende technische Kosten, die nichts mit Ihrem Produkt zu tun haben. Die Integration in dieselbe Überwachungs-Engine, die die Übertragung bereits bewertet, reduziert diese Kosten auf eine einzige Integration.

Technische Details

Die Übertragung wird über die vereinheitlichte /v3/ API erstellt. Der Absender ist der subject, der Empfänger ist die counterparty, und currency_kind: "crypto" löst die Travel Rule und die Wallet-Screening-Pfade aus.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_7b9e22",
    "category": "travel_rule",
    "amount": 12500,
    "currency": "BTC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T12:14:00Z",
    "subject": {
      "vendor_data": "user_8830",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Marta",
      "last_name": "Ferreira"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "bc1q...0a7k"
    }
  }'

Die Engine löst die Gegenpartei-VASP auf, wählt ein unterstütztes Protokoll aus, tauscht die Nutzlast aus und gibt das verwendete Protokoll sowie den Travel Rule Status zurück:

{
  "transaction_id": "txn_7b9e22",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRP",
  "counterparty_vasp": "vasp_resolved",
  "wallet_screening": {
    "risk_score": 9,
    "risk_level": "LOW"
  }
}

Die Absender/Empfänger-Nutzlast. Jede Überweisung enthält die beiden Parteien als strukturierte Datensätze – den Absender (der sendende Kunde) und den Empfänger (der empfangende Kunde) – so dass beide VASPs unabhängig vom Protokoll dieselben Felder zuordnen. Die Absenderdaten stellen Sie aus Ihren bereits vorhandenen KYC-Daten bereit; die Empfängerseite wird von der Gegenpartei während des Austauschs bestätigt.

Die sechs Status. Unabhängig davon, welches Protokoll den Austausch durchführt, wird die Verpflichtung auf einen Status aufgelöst:

Status	Bedeutung
UNKNOWN	Noch nicht bewertet, oder die Gegenpartei-VASP konnte nicht aufgelöst werden.
COMPLIANT	Daten ausgetauscht und bestätigt – Verpflichtung erfüllt.
PENDING_ACTION	Auf Ihrer Seite ist eine Aktion erforderlich, um fortzufahren.
PENDING_COUNTERPARTY	Wartet auf die Antwort der Gegenpartei-VASP.
FAILED	Der Austausch konnte nicht abgeschlossen werden – unerreichbare Gegenpartei, abgelehnte Daten oder Protokollkonflikt.
EXEMPT	Außerhalb des Geltungsbereichs – unterhalb des Schwellenwerts oder anderweitig nicht verpflichtet.

Wallet-Screening parallel. Die Adresse der Gegenpartei wird im selben Aufruf On-Chain gescreent, ab 0,02 $ pro Screening mit eigenem Schlüssel (Crystal oder Merkle Science), so dass ein Protokoll-Level COMPLIANT kein Risiko auf Adress-Ebene verbirgt.

Ein Protokoll wählen – und nicht wählen

Die praktische Empfehlung für eine VASP lautet: Nicht wählen. Ihre Gegenparteien verteilen sich auf TRISA, TRP und OpenVASP, und das Protokoll, das eine bestimmte Überweisung zu COMPLIANT führt, ist dasjenige, das diese Gegenpartei unterstützt. Da Didit das Protokoll pro Überweisung verhandelt, ist Ihre Integration unabhängig davon dieselbe – Sie senden die Absender- und Empfängerdaten einmal, und die Engine übernimmt den Handshake. Ein FAILED-Status mit einem Protokollkonflikt ist ein Signal, die Gegenpartei zu untersuchen, nicht eine Lücke in Ihrem Stack.

Anwendungsfälle

• VASPs und Börsen – erreichen Sie Gegenparteien über alle drei Protokolle von einer Integration aus, anstatt jede Schiene selbst aufzubauen und zu warten.
• On/Off-Ramps – tauschen Sie Absender- und Empfängerdaten mit Ziel-VASPs aus, während Sie die empfangende Wallet im selben Aufruf überprüfen.
• Verwahrer – verwalten Sie eine große Anzahl von Gegenparteien auf gemischten Protokollen mit einem einzigen, konsistenten Statusmodell.
• DeFi-Front-Ends – führen Sie den Austausch dort durch, wo eine regulierte VASP im Fluss sitzt, und lösen Sie ihn zu EXEMPT auf, wo die Verpflichtung tatsächlich nicht zutrifft.

So integrieren Sie sich mit Didit

1. Aktivieren Sie die Travel-Rule-Regeln. Schalten Sie in der Business Console die voreingestellten Travel-Rule-Regeln neben dem Krypto-Monitoring und Krypto-Screening ein.
2. Senden Sie die Übertragung. POST /v3/transactions/ mit currency_kind: "crypto", dem Absender als subject, dem Empfänger als counterparty und der Kategorie travel_rule.
3. Lesen Sie das Protokoll und den Status. Die Antwort teilt Ihnen mit, welches Protokoll den Austausch durchgeführt hat und den resultierenden travel_rule_status. Handeln Sie bei PENDING_* und FAILED Verpflichtungen.
4. Bearbeiten Sie Ausnahmen in der Konsole. Ausstehende und fehlgeschlagene Austausche, Warnungen und der Fall-Workflow befinden sich auf derselben Oberfläche wie Ihr Monitoring.

Alles läuft über die vereinheitlichte /v3/ API, sodass der Kunde, den Sie mit KYC an Bord geholt, mit AML gescreent und nun eine Überweisung für ihn durchführen, dieselbe Identität ist, die durch Monitoring, Wallet-Screening und die Travel Rule verfolgt wird.

Häufig gestellte Fragen

Welche Travel Rule Protokolle unterstützt Didit?

TRISA, TRP und OpenVASP – die drei Protokolle, die VASPs in der Produktion verwenden. Die Engine verhandelt dasjenige, das eine bestimmte Gegenpartei unterstützt.

Welche Daten werden ausgetauscht?

Die Absender- und Empfängerdatensätze – die Parteien der Überweisung – strukturiert, so dass beide VASPs dieselben Felder lesen. Sie liefern die Absenderdaten aus Ihrem bestehenden KYC; die Gegenpartei bestätigt die Empfängerseite.

Muss ich ein Protokoll auswählen?

Nein. Die Auswahl eines Protokolls würde Sie von Gegenparteien auf den anderen abschneiden. Didit wählt das Protokoll pro Überweisung basierend auf dem, was die Gegenpartei unterstützt.

Was passiert, wenn die Gegenpartei nicht erreicht werden kann?

Die Verpflichtung wird zu FAILED aufgelöst (mit einem Grund wie Protokollkonflikt oder unerreichbarer Gegenpartei) oder verbleibt bei PENDING_COUNTERPARTY, während Sie warten – beides ist in der Konsole sichtbar.

Ist dies ein separates Produkt vom Transaktions-Monitoring?

Nein. Der Datenaustausch ist in das Transaktions-Monitoring integriert, auf derselben Krypto-Überweisung, die Sie bereits für Monitoring und Wallet-Screening senden.

Bereit zum Start?

Lesen Sie die Travel Rule Dokumentation, sehen Sie das Gesamtbild auf der Lösungsseite für die Krypto-Travel Rule und der Produktseite für das Transaktions-Monitoring, und prüfen Sie die transparenten Preise pro Anruf auf der Preisseite. Wenn Sie bereit sind, starten Sie kostenlos – 500 kostenlose KYC-Prüfungen jeden Monat, mit dem in das Monitoring integrierten Travel Rule Datenaustausch.