FATF Travel Rule: Integriert in die Transaktionsüberwachung (DE)

Die FATF Travel Rule stellt an jeden Anbieter virtueller Vermögenswerte (VASP) eine täuschend einfache Anforderung: Wenn Sie eine Krypto-Überweisung über dem Schwellenwert senden, müssen Sie identifizierende Informationen über den Originator und den Begünstigten mitsenden – und wenn Sie eine empfangen, müssen Sie dieselben Daten erfassen und überprüfen. Der schwierige Teil ist nicht das Prinzip. Es ist die Tatsache, dass es sich bei der Gegenpartei um einen anderen VASP auf einem anderen Stack in einer anderen Gerichtsbarkeit handelt, der möglicherweise dasselbe Protokoll unterstützt oder auch nicht und möglicherweise überhaupt nicht zur Einhaltung verpflichtet ist.

Didit handhabt dies ohne ein separates Produkt. Die Unterstützung der Travel Rule ist direkt in die Transaktionsüberwachung integriert. Dieselbe Engine, die jede Krypto-Überweisung in Echtzeit bewertet, tauscht auch Originator- und Begünstigtendaten mit dem Gegenpartei-VASP aus, verfolgt den Stand jeder Verpflichtung und führt parallel dazu ein On-Chain-Wallet-Screening durch. Sie senden die Transaktion einmal; Überwachung, Screening und die Travel Rule laufen alle darauf ab.

Dieser Leitfaden erklärt, wie das aussieht, warum es so aufgebaut ist und wie es integriert werden kann.

Wichtige Erkenntnisse

• Die Travel Rule ist Teil der Transaktionsüberwachung, kein Zusatz. Krypto-Überweisungen, die Sie bereits zur Überwachung senden, umfassen den Datenaustausch und die Verpflichtungsverfolgung der Travel Rule.
• Der Austausch von Originator- und Begünstigtendaten erfolgt zwischen Ihnen und dem Gegenpartei-VASP über die wichtigsten Protokolle – TRISA, TRP und OpenVASP.
• Sechs spezielle Status – UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT – zeigen Ihnen genau an, wo jede Verpflichtung steht.
• Voreingestellte Travel-Rule-Regeln sind in der Regelbibliothek enthalten, und Transaktionen tragen eine Kategorie travel_rule, sodass die Richtlinie im Kontext angewendet wird.
• Das On-Chain-Wallet-Screening läuft parallel ab 0,02 $ pro Screening mit "Bring-your-own-key" (Crystal oder Merkle Science).
• Eine vereinheitlichte /v3/ API. Krypto-Transaktionen werden an POST https://verification.didit.me/v3/transactions/ mit currency_kind: "crypto" gesendet.

Was die Travel Rule bewirkt

Die Financial Action Task Force (FATF) hat ihre langjährige Überweisungsregel – Empfehlung 16 – auf virtuelle Vermögenswerte ausgeweitet. Die Anforderung: Wenn ein VASP virtuelle Vermögenswerte im Namen eines Kunden überträgt, muss er die erforderlichen Originator- und Begünstigteninformationen einholen, speichern und übermitteln und den Behörden auf Anfrage zur Verfügung stellen. In der Praxis bedeutet das, dass zwei VASPs einander identifizieren, Kundendaten sicher austauschen und die Übertragung bestätigen müssen, bevor – oder während – die Vermögenswerte On-Chain bewegt werden.

Diese Bestätigung ist der Workflow, den Didit operationalisiert. Wenn Sie eine Krypto-Transaktion zur Überwachung senden, identifiziert die Engine den Gegenpartei-VASP, tauscht die Originator- und Begünstigten-Payloads über ein unterstütztes Protokoll aus und löst die Verpflichtung in einen Status auf, auf den Sie reagieren können. Eine Übertragung, die die Gegenpartei bestätigt, wird zu COMPLIANT; eine, die auf die andere Seite wartet, bleibt bei PENDING_COUNTERPARTY; eine unter dem Schwellenwert oder anderweitig außerhalb des Geltungsbereichs ist EXEMPT.

Warum es wichtig ist

Die Durchsetzung der Travel Rule ist nicht länger theoretisch. Die EU-Verordnung über Geldtransfers, die Umsetzung im Vereinigten Königreich und eine wachsende Liste nationaler Regime verlangen nun von VASPs den Datenaustausch, wobei die Aufsichtsbehörden dies aktiv überprüfen. Die Kosten für Fehler sind ein Lizenzierungsrisiko, nicht nur eine Geldstrafe.

Das operative Problem besteht darin, dass die meisten Teams die Travel Rule als viertes Werkzeug behandeln – getrennt von KYC, getrennt von AML, getrennt von der Transaktionsüberwachung – und dann Ingenieurszeit aufwenden, um vier Systeme bezüglich derselben Übertragung synchron zu halten. Didits Ansatz beseitigt diese Nahtstelle. Die Übertragung, die Sie bereits auf Strukturierung, Geschwindigkeit und das Risiko sanktionierter Gegenparteien überwachen, ist dieselbe Übertragung, die die Travel Rule-Verpflichtung trägt, sodass die Daten, der Status und der Audit-Trail an einem Ort leben.

Technische Details

Krypto-Transaktionen werden über die vereinheitlichte /v3/ API erstellt, denselben Endpunkt, der auch Fiat-Währungen verarbeitet. Das Setzen von currency_kind: "crypto" weist die Engine an, Krypto-Regeln zu bewerten und die Travel Rule- und Wallet-Screening-Pfade auszuführen.

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_c41f08",
    "category": "travel_rule",
    "amount": 4200,
    "currency": "USDC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T11:05:00Z",
    "subject": {
      "vendor_data": "user_4521",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "0x9f2a...c81d"
    }
  }'

Die Engine bewertet die Übertragung, eröffnet den Travel Rule-Datenaustausch mit dem Gegenpartei-VASP und gibt einen Transaktionsstatus sowie den Travel Rule-Status zurück:

{
  "transaction_id": "txn_c41f08",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "wallet_screening": {
    "risk_score": 18,
    "risk_level": "LOW"
  },
  "protocol": "TRISA"
}

Die sechs Travel Rule-Status. Jede Verpflichtung löst sich in genau einen auf:

Status	Bedeutung
UNKNOWN	Die Travel Rule-Verpflichtung wurde noch nicht bewertet oder der Gegenpartei-VASP kann nicht aufgelöst werden.
COMPLIANT	Originator- und Begünstigtendaten wurden ausgetauscht und bestätigt – die Verpflichtung ist erfüllt.
PENDING_ACTION	Auf Ihrer Seite ist etwas erforderlich – fehlende Originator-Daten oder ein Bestätigungsschritt.
PENDING_COUNTERPARTY	Sie warten auf die Antwort des Gegenpartei-VASP auf den Datenaustausch.
FAILED	Der Austausch konnte nicht abgeschlossen werden – unerreichbare Gegenpartei, abgelehnte Daten oder Protokoll-Fehlfunktion.
EXEMPT	Die Übertragung ist außerhalb des Geltungsbereichs – unterhalb des Schwellenwerts, Umgang mit selbst gehosteten Wallets oder anderweitig nicht verpflichtet.

Kategorie und Regeln. Transaktionen tragen eine category von travel_rule, damit die richtige Richtlinie angewendet wird, und die Regelbibliothek enthält voreingestellte Travel-Rule-Regeln, die Sie in der Konsole aktivieren und anpassen können, anstatt sie manuell zu codieren.

Wallet-Screening parallel. Da currency_kind auf crypto gesetzt ist, kann die Engine in demselben Aufruf ein On-Chain-Wallet-Screening für die Gegenpartei-Adresse durchführen – und dabei die Exposition gegenüber sanktionierten Entitäten, Mixern, Darknet-Märkten, Ransomware und gestohlenen Geldern überprüfen. Das Wallet-Screening beginnt bei 0,02 $ pro Screening mit "Bring-your-own-key" (Crystal oder Merkle Science).

Eine Engine, drei Aufgaben bei jeder Übertragung

Der Grund, warum die Travel Rule in die Transaktionsüberwachung integriert ist, liegt darin, dass eine Krypto-Übertragung drei Verpflichtungen gleichzeitig auslöst, die dieselben Daten teilen:

1. Überwachung – die Übertragung wird anhand der Krypto-Überwachungs- und Krypto-Screening-Regelbündel auf Strukturierung, Geschwindigkeit und anomale Muster bewertet.
2. Wallet-Screening – die Gegenpartei-Adresse wird On-Chain auf Risikobereitschaft überprüft.
3. Travel Rule – Originator- und Begünstigtendaten werden mit dem Gegenpartei-VASP ausgetauscht und die Verpflichtung wird einem der sechs Status zugeordnet.

Werden diese Aufgaben als drei separate Tools ausgeführt, benötigt jede eine eigene Integration, eine eigene Kopie der Übertragung und eine eigene Abstimmung. Werden sie als eine Engine ausgeführt, teilen sie sich den Transaktionsdatensatz, den Audit-Trail und die Konsole – und eine Travel Rule-Verpflichtung, die weitere Kundendaten erfordert, kann denselben AWAITING_USER-Korrekturschleife verwenden, den auch der Rest der Überwachung nutzt.

Anwendungsfälle

• VASPs und Börsen – erfüllen Sie die Travel Rule bei jeder ausgehenden und eingehenden Übertragung über dem Schwellenwert, ohne einen separaten Compliance-Stack aufbauen zu müssen, und halten Sie Überwachung, Screening und die Travel Rule in einem einzigen Datensatz.
• On/Off-Ramps – tauschen Sie Originator- und Begünstigtendaten mit Ziel-VASPs aus, während Sie das empfangende Wallet im selben Aufruf überprüfen.
• Verwahrer – verfolgen Sie Verpflichtungen über viele Gegenparteien und Protokolle hinweg, mit einem klaren Status für jede Übertragung für Prüfer.
• DeFi-Frontends – behandeln Sie die Travel Rule dort, wo eine regulierte Entität im Fluss sitzt, und greifen Sie auf EXEMPT und die Handhabung von selbst gehosteten Wallets zurück, wo die Verpflichtung tatsächlich nicht zutrifft.

So integrieren Sie Didit

1. Aktivieren Sie die Regelpakete. Aktivieren Sie in der Business Console die Krypto-Überwachung, das Krypto-Screening und die voreingestellten Travel-Rule-Regeln, und passen Sie die Schwellenwerte an Ihre Risikopolitik an.
2. Senden Sie Krypto-Transaktionen. POST /v3/transactions/ mit currency_kind: "crypto", einer direction, den Originator- (subject) und Begünstigten- (counterparty) Details und der Kategorie travel_rule, wo zutreffend.
3. Lesen Sie beide Status. Handeln Sie nach dem Transaktions-status für die Geldbewegung und dem travel_rule_status für die Verpflichtung – halten oder korrigieren Sie, wo Maßnahmen erforderlich sind.
4. Arbeiten Sie den Rest in der Konsole. Ausstehende und fehlgeschlagene Verpflichtungen, Warnungen und der Fall-Workflow befinden sich in derselben Oberfläche wie der Rest Ihrer Überwachung.

Da alles über die vereinheitlichte /v3/ API läuft, führt dieselbe Plattform, die KYC für Ihre Benutzer und KYB für Ihre Geschäftskunden durchführt, deren Überweisungen auch durch Überwachung, Wallet-Screening und die Travel Rule – eine Identitäts- und Betrugsplattform, End-to-End.

Häufig gestellte Fragen

Ist die Travel Rule ein separates Didit-Produkt?

Nein. Sie ist in die Transaktionsüberwachung integriert. Die Krypto-Überweisungen, die Sie bereits zur Überwachung senden, umfassen den Datenaustausch und die Verpflichtungsverfolgung der Travel Rule im selben Datensatz.

Welche Travel Rule-Protokolle unterstützen Sie?

Die wichtigsten Interoperabilitätsprotokolle – TRISA, TRP und OpenVASP – damit Sie Originator- und Begünstigtendaten mit Gegenpartei-VASPs über verschiedene Stacks hinweg austauschen können.

Was sind die Travel Rule-Status?

Sechs: UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED und EXEMPT. Sie zeigen Ihnen genau an, wo jede Verpflichtung steht.

Wie passt das Wallet-Screening dazu?

Krypto-Transaktionen (currency_kind: "crypto") können automatisch ein On-Chain-Wallet-Screening für die Gegenpartei-Adresse durchführen, ab 0,02 $ pro Screening mit "Bring-your-own-key" (Crystal oder Merkle Science).

Wo konfiguriere ich die Travel Rule-Regeln?

In der Business Console. Die Regelbibliothek enthält voreingestellte Travel-Rule-Regeln, die Sie aktivieren und anpassen können, und Transaktionen tragen eine Kategorie travel_rule, sodass die richtige Richtlinie im Kontext angewendet wird.

Bereit zum Start?

Lesen Sie die Travel Rule-Dokumentation, sehen Sie, wie sie in den breiteren Stack auf der Lösungsseite für die Krypto-Travel Rule und der Produktseite für die Transaktionsüberwachung passt, und überprüfen Sie die transparenten Preise pro Anruf auf der Preisseite. Wenn Sie bereit sind, starten Sie kostenlos – 500 kostenlose KYC-Überprüfungen jeden Monat, mit Überwachung, Wallet-Screening und der Travel Rule über eine API.