Travel Rule API nach FATF: VASP-Compliance

​

Überblick

• Sie reichen einen Transfer mit transaction_category: "travelRule" ein.
• Didit probiert die Wege in fester Prioritätsreihenfolge, um den Gegen-VASP zu erreichen, führt den Austausch über den ersten Weg durch, der ihn erreicht, und gleicht den Namen des Begünstigten, sofern die Gegenseite einen zurückgibt, mit dem von Ihnen übermittelten Namen ab.
• Erst wenn der Austausch COMPLETED erreicht, sollten Sie den Transfer on-chain übertragen.
• Anschließend melden Sie den On-Chain-Transaktions-Hash an Didit zurück, um den Austausch als FINISHED abzuschließen.

​

Was beim Einreichen eines Transfers ausgeführt wird

1. Validierung und Zuordnung des Subjekts. Die Payload wird validiert. Eine transaction_id, die in Ihrer Anwendung bereits verwendet wurde, wird mit 400 abgelehnt. Wenn zwei Anfragen mit derselben ID gleichzeitig eintreffen, erhält eine davon 409. Das subject wird über vendor_data mit Ihrem Benutzer- oder Unternehmensprofil verknüpft, damit der Transfer für das Monitoring auf diesem Profil erscheint. Ein auf einer Sperrliste stehendes Subjekt oder ein gesperrter vendor_data-Wert der Gegenpartei wird mit 400 abgelehnt, und es wird keine Transaktion angelegt. Auf Sperrlisten stehende Wallets, Bankkonten, IP-Adressen und Geräte werden in Schritt 6 geprüft und führen dort zur Ablehnung der Transaktion, nachdem das Routing gelaufen ist.
2. Geräte- und Netzwerkanreicherung. IP-Adressen der Parteien werden geo-angereichert. Jeder Gerätekontext (automatisch bei der SDK-Übermittlung) wird in den Geräte-Graphen normalisiert, denselben Graphen, den auch KYC-Sitzungen füllen. So funktioniert „nach Gerät verknüpft“ über Onboarding und Transaktionen hinweg.
3. Krypto-Screening. Bei Krypto-Transfers mit aktiviertem Monitoring wird die relevante Wallet (oder der On-Chain-Hash) vor jedem Austausch gegen Blockchain-Analysen geprüft: Sanktionsrisiko, Nähe zu Mixern, gestohlene Gelder. Siehe Krypto- und Wallet-Screening.
4. Travel-Rule-Transfer. Die Austausch-Engine prüft den Schwellenwert und berücksichtigt eine Erklärung zur selbstverwahrten Wallet. Danach speichert sie den Transfer: NOT_APPLICABLE unterhalb Ihres Schwellenwerts, UNCONFIRMED_OWNERSHIP für eine erklärte selbstverwahrte Wallet, COMPLETED, wenn die andere Wallet Ihre eigene verifizierte Wallet ist, und sonst AWAITING_COUNTERPARTY, wobei die Rail dann noch leer ist. Jede Statusänderung reiht ein travel_rule.status.updated-Ereignis in die Warteschlange ein. Didit sendet es nach dem transaction.created der Transaktion (Schritt 7).
5. Erzeugung der Wallet-Eigentumsprüfung. Wenn der Transfer einen Nachweis der Kontrolle durch den Endnutzer erfordert und auto_wallet_verification aktiviert ist, wird eine Widget-Sitzung zur Wallet-Eigentumsprüfung erzeugt und in action_required zurückgegeben.
6. Regelauswertung. Jede aktive Regel wird ausgeführt. Das EU-TFR-Regelpaket reagiert auf den Transferstatus aus Schritt 4, Ihre eigenen Regeln sehen die Screening-Ergebnisse aus Schritt 3. Eine Regel kann die Transaktion zurückhalten (IN_REVIEW), sie ablehnen oder eine Step-up-Verifizierung verlangen (AWAITING_USER).
7. Abrechnung und Benachrichtigung. Eine ausgehende Transaktion wird über eine Position abgerechnet: den Travel-Rule-Posten, wenn sie einen Austausch gestartet hat, andernfalls Transaction Screening. Ein eingehender Transfer fällt keine Gebühr an, und eine Sandbox-Anwendung wird nie berechnet. Die Antwort wird zurückgegeben, und transaction.created wird an Ihre Webhook-Ziele ausgelöst, gefolgt von den travel_rule.status.updated-Ereignissen aus Schritt 4.
8. Routing nach der Antwort. Didit durchläuft die sieben Rails in Prioritätsreihenfolge. Wenn keine Rail eine Lösung liefert, identifiziert die Zuordnung über Blockchain-Analysen die Gegenpartei, und die Rails werden ein einziges Mal erneut durchlaufen. Über die erste erreichbare Rail wird der Austausch abgewickelt: Der Transfer bleibt auf dieser Rail im Status AWAITING_COUNTERPARTY, während die Gegenpartei antwortet. Er wird sofort abgeschlossen, wenn eine INTERNAL-Gegenpartei gefunden wird (COMPLETED oder COUNTERPARTY_MISMATCHED_DATA). Er wird COUNTERPARTY_VASP_NOT_FOUND, wenn keine Rail die Gegenpartei erreicht. Jede Änderung löst travel_rule.status.updated aus, und Ihre Regeln laufen erneut, wenn sich der Status oder die Rail geändert hat. Ein Transfer, den das Routing in COUNTERPARTY_VASP_NOT_FOUND belässt, erhält an dieser Stelle seine Sitzung zur Wallet-Eigentumsprüfung (wenn auto_wallet_verification aktiviert ist). Lesen Sie sie mit Transaktion abrufen aus action_required der Transaktion aus.

​

Wie jeder Schritt Ihre Pflichten erfüllt

​

Lebenszyklus

​

Zustellung und Wiederholungsversuche

​

Veraltete Statuswerte

​

Einrichtung

curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "is_enabled": false,
  "jurisdiction": "EU",
  "name_matching_strictness": "DEFAULT",
  "confirmation_timeout_hours": 48,
  "timeout_outcome": "HOLD",
  "threshold_amount": "0.00",
  "inbound_auto_accept": true,
  "allow_self_declaration": true,
  "allow_screenshot_proof": true,
  "auto_wallet_verification": true,
  "vasp_attribution_enabled": true,
  "counterparty_screening_enabled": false,
  "sunrise_policy": "",
  "sunrise_jurisdictions": ["CO", "KH", "VN"],
  "non_responsive_policy": "",
  "legal_name": "",
  "lei": "",
  "compliance_email": "",
  "is_discoverable": true,
  "travel_address": "",
  "disabled_networks": [],
  "networks": {
    "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false },
    "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false },
    "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false },
    "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false }
  }
}

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "legal_name": "Origin CASP SL",
    "jurisdiction": "EU",
    "name_matching_strictness": "DEFAULT",
    "confirmation_timeout_hours": 48,
    "timeout_outcome": "HOLD",
    "is_discoverable": true
  }'

​

Strenge des Namensabgleichs

​

Modi der Eigentumsvalidierung

​

Datenweitergabe

{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}

• Natürliche Personen können name, wallet_address, address, national_id, customer_identification, date_of_birth und place_of_birth freigeben. Unternehmen teilen die ersten fünf.
• name und wallet_address werden immer übermittelt.
• Ein Entitätstyp, den Sie nie gewählt haben, gibt jedes Feld frei. Eine leere Liste ist ebenfalls eine Wahl: Sie gibt nur den Namen und die Wallet frei.
• Ein PUT wird pro Entitätstyp zusammengeführt, sodass das Senden von individual die gespeicherte Auswahl für company unberührt lässt.
• Eine Auswahl, die die Pflichten des Auftraggebers nach dem Regime Ihrer jurisdiction (EU TFR oder FATF Recommendation 16) nicht erfüllen kann, wird einschließlich einer leeren Liste mit 400 abgelehnt. Die Fehler stehen unter data_sharing_fields, geschlüsselt nach Entitätstyp.

​

Abgleich pro Feld

{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}

​

Schwellenwerte nach Rechtsraum

​

IVMS-101-Datenmodell

• Lateinische Schrift. IVMS 101 verlangt Werte in lateinischer Schrift. Transliterieren Sie Namen, die in einer anderen Schrift geschrieben sind. Der Namensabgleich von Didit vergleicht normalisierte Tokenmengen, daher scheitert ein Austausch nicht an Unterschieden bei Reihenfolge oder Groß- und Kleinschreibung. Unterschiedliche Schriften auf beiden Seiten führen allerdings zum Fehler.
• Verifizierte Daten senden. Wenn die Person, auf die sich vendor_data bezieht, ein Benutzer mit einer genehmigten KYC-Verifizierung bei Didit ist, überträgt Didit die verifizierte Identität und nicht die Werte, die Sie eingegeben haben. Siehe Verifizierte Daten und Herkunft. Für jede andere Person überträgt Didit genau das originator_data, das Sie senden. Erstellen Sie es deshalb aus der Identität, die Sie beim Onboarding verifiziert haben, und nicht aus einem nicht verifizierten Formularfeld. Genau das verlangt die FATF mit der Formulierung „required and accurate originator information“. Auf der INTERNAL-Rail erhält die Anwendung des Begünstigten zusätzlich das subject, das Sie gesendet haben (Name, vendor_data, Geburtsdatum, Land und Adresse), als Gegenpartei ihrer eingehenden Transaktion.

​

Verifizierte Daten und Herkunft

• der Auftraggeber eines ausgehenden Transfers, den Sie mit POST /v3/transactions/ anlegen;
• der Begünstigte eines eingehenden Transfers, den Sie mit POST /v3/transactions/ melden, oder mit POST /v3/travel-rule/inbound/, wenn das holder_vendor_data der zugeordneten Wallet diesen Benutzer nennt.

{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}

​

IVMS 101 direkt senden

• einen Block originator und einen Block beneficiary, wobei originatorPersons bzw. beneficiaryPersons eine naturalPerson oder eine legalPerson sowie accountNumber enthalten;
• dieselben Blöcke innerhalb eines Objekts ivms101 (oder IVMS101);
• eine IVMS-101-Person oder einen ganzen Block als originator_data oder beneficiary_data.

{
  "travel_rule_details": {
    "status": "AWAITING_COUNTERPARTY",
    "beneficiary": {
      "beneficiaryPersons": [
        {
          "naturalPerson": {
            "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] }
          }
        }
      ],
      "accountNumber": ["0xBeneficiaryWallet01"]
    }
  }
}

​

Erforderliche Daten nach Regelwerk

​

Travel Addresses

ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx

​

Testen ohne Netzwerk-Zugangsdaten

• Sandbox ausgehend: Senden Sie eine travelRule-Transaktion aus einer Sandbox-Anwendung. Nach der Schwellenwertprüfung und den Prüfungen selbstverwahrter Wallets beantwortet der Didit Test VASP sie innerhalb von Didit mit dem Szenario, das Sie über die Wallet oder den Namen des Begünstigten auswählen: akzeptieren, ablehnen, Namensabweichung, nicht erreichbar, Zeitüberschreitung oder selbstverwahrte Wallet. Es wird weder ein Netzwerk kontaktiert noch eine E-Mail versendet, und kein anderer Didit-Kunde erhält etwas.
• Sandbox eingehend: Lassen Sie den Test-VASP Ihnen mit Eingehende Transaktion des Test-VASP auslösen eine Transaktion senden, oder registrieren Sie selbst eine mit Eingehende Travel-Rule-Transaktion registrieren. Testen Sie eine unbekannte Wallet, eine nicht verifizierte Wallet, eine Abweichung beim Namen des Begünstigten und eine verifizierte, übereinstimmende Wallet. Mit diesen Tests werden echte Entscheidungen für eingehende Transaktionen getroffen, ohne ein Netzwerk zu kontaktieren.
• Zwei kontrollierte Live-Anwendungen: Verwenden Sie die Schiene INTERNAL zwischen zwei Ihrer eigenen Live-Anwendungen. Die empfangende Anwendung ist auffindbar und weist die Kontrolle über die Zielwallet mit einer signierten Nachricht oder einer Testeinzahlung nach. Alternativ können Sie eine kontrollierte TRP-Gegenpartei verwenden, um einen Austausch zwischen zwei Parteien ohne kommerzielle Netzwerk-Zugangsdaten zu testen. Live-Anwendungen können übliche Gebühren und Benachrichtigungen auslösen. Verwenden Sie deshalb nur Testidentitäten und Gegenparteien, die Sie kontrollieren.

​

Einen Transfer senden

1. Liegt der Betrag unter Ihrem konfigurierten threshold_amount, wird der Transfer sofort auf NOT_APPLICABLE gesetzt, und es wird nichts verhandelt.
2. Deklariert die Zahlungsmethode der Gegenpartei das Ziel als selbstverwahrte Wallet (payment_method.method_type: "unhosted_wallet"), wird kein Übertragungsweg versucht. Der Transfer geht direkt in UNCONFIRMED_OWNERSHIP, und das Widget zur Wallet-Eigentumsprüfung wird automatisch erstellt (siehe Deklarierte selbstverwahrte Wallets).
3. Andernfalls werden die Übertragungswege in Prioritätsreihenfolge ausgeführt, und der erste Weg, der die Gegenpartei erreichen kann, übernimmt den Austausch:
   • INTERNAL: Genau ein anderer Didit-Kunde hält einen Nachweis einer signierten Nachricht oder einer Testeinzahlung für beneficiary_data.wallet_address, der erstellt wurde, nachdem die Wallet zuletzt den Besitzer gewechselt hat. Ihre eigene Anwendung zählt nie. Wenn Ihr Endbenutzer im Widget zur Wallet-Eigentumsprüfung ein Mitglied des Didit-Netzwerks gewählt hat, zählt nur der Nachweis dieses Mitglieds. Die Anwendung dieses Kunden ist live (nicht Sandbox), hat Travel Rule aktiviert und is_discoverable gesetzt und ist das VASP, das Sie bei der Angabe von counterparty_vasp_lei oder counterparty_vasp_name genannt haben. Eine Wallet, die nur selbst deklariert ist, durch einen Screenshot belegt ist, nicht verifiziert ist oder nur im Adressbuch steht, erhält über INTERNAL niemals etwas.
   • TRP: Für das Asset des Transfers gibt es für das Transfernetzwerk eine Zuordnung zu einem Digital Token Identifier (siehe TRP-Asset-Kennungen), und die Payload enthält beneficiary_data.travel_address. Alternativ speichert der eigene Adressbucheintrag des Ziels eine solche Adresse, oder die Gegenpartei lässt sich im Verzeichnis auflösen (über counterparty_vasp_lei oder counterparty_vasp_name) und hat einen TRP-Endpoint.
   • GTR, TRUST, VERIFYVASP, SYGNA: Sie haben Ihre eigene Mitgliedschaft für dieses Netzwerk unter Marketplace verbunden, und die Gegenpartei wird auf eine Netzwerk-ID aufgelöst (explizites Feld oder Verzeichniseintrag, siehe Felder zur Auflösung der Gegenpartei). Didit besitzt in diesen Netzwerken noch keine Plattformmitgliedschaft, da es sich derzeit als Anbieter im Onboarding befindet. Daher ändert disabled_networks an diesem Schritt derzeit nichts.
   • EMAIL: beneficiary_data.counterparty_vasp_email wurde angegeben, oder counterparty_vasp_name wird auf einen Verzeichniseintrag mit einer Compliance-E-Mail aufgelöst.
4. Kann kein Übertragungsweg die Gegenpartei auflösen, führt Didit die Ermittlung der Gegenpartei aus. Ist vasp_attribution_enabled aktiviert, gehört dazu auch die Blockchain-Analyse-Attribution: Die Ziel-Wallet wird dem zugehörigen VASP zugeordnet. Der zugeordnete Name wird in beneficiary_data.counterparty_vasp_name (falls leer) und im Verzeichnis eingetragen, und die Übertragungswege werden einmal erneut ausgeführt. Eine Wallet, die einem VASP zugeordnet ist, dessen Verzeichniseintrag einen TRP-Endpoint, eine Netzwerk-ID oder eine Compliance-E-Mail enthält, wird so bereits beim zweiten Durchlauf geroutet.
5. Bleibt die Gegenpartei unaufgelöst, wechselt der Transfer in COUNTERPARTY_VASP_NOT_FOUND. Bei ausgehenden Transfers erstellt Didit automatisch das Widget zur Wallet-Eigentumsprüfung (wenn auto_wallet_verification aktiviert ist), damit der Transfer trotzdem als Transfer an eine selbstverwahrte Wallet abgeschlossen werden kann. Sie können das Routing später mit action: "resend" erneut ausführen, sobald Sie bessere Daten zur Gegenpartei haben.

​

TRP-Asset-Kennungen

​

Ermittlung der Gegenpartei

​

Felder zur Auflösung der Gegenpartei

​

Chain-Strukturen

​

UTXO-Transfers

• Auftraggeber: originator_data.wallet_address, wenn Sie es senden, andernfalls die Input-Adresse, die am meisten beigetragen hat (source: largest_input).
• Begünstigter: die angegebene Wallet, andernfalls der einzige Output, an den keine Input-Adresse als Wechselgeld zurückgeht (only_non_change_output), andernfalls der eine Output, auf den der Transferbetrag entfällt (amount_match).

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "btc-withdrawal-0042",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "amount": "0.25",
      "currency": "BTC",
      "currency_kind": "crypto"
    },
    "subject": { "vendor_data": "user-042", "full_name": "Ana Diaz" },
    "counterparty": { "full_name": "Luis Perez" },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": { "name": "Luis Perez", "counterparty_vasp_name": "Destination Exchange" },
      "utxo": {
        "inputs": [
          { "address": "bc1qsenderhotwallet01", "amount": "0.30" },
          { "address": "bc1qsendercoldwallet02", "amount": "0.05" }
        ],
        "outputs": [
          { "address": "bc1qbeneficiarydeposit01", "amount": "0.25" },
          { "address": "bc1qsenderhotwallet01", "amount": "0.0999" }
        ]
      }
    }
  }'

{
  "chain_details": {
    "chain": "BTC",
    "shape": "utxo",
    "originator": { "address": "bc1qsenderhotwallet01", "memo": "", "source": "largest_input" },
    "beneficiary": { "address": "bc1qbeneficiarydeposit01", "memo": "", "source": "only_non_change_output" },
    "utxo": {
      "inputs": [
        { "address": "bc1qsenderhotwallet01", "amount": "0.300000000000000000" },
        { "address": "bc1qsendercoldwallet02", "amount": "0.050000000000000000" }
      ],
      "outputs": [
        { "address": "bc1qbeneficiarydeposit01", "amount": "0.250000000000000000" },
        { "address": "bc1qsenderhotwallet01", "amount": "0.099900000000000000" }
      ],
      "change_output_indexes": [1],
      "beneficiary_output_index": 0
    }
  }
}

​

Memo- und Tag-Netzwerke

• Ein Adressbuch-Eintrag mit Memo trifft nur Transfers, die genau dieses Memo angeben. Ein Eintrag ohne Memo trifft die gesamte Adresse. Ein Transfer ohne Memo erreicht nie einen Eintrag mit Memo: Auf einer gemeinsamen Adresse gehört eine Einzahlung ohne ihren Tag niemandem.
• Eine XRP-X-Adresse enthält ihren Tag: Didit zerlegt sie in die klassische Adresse und den Tag (source: x_address). So trifft eine Wallet, die in einer der beiden Formen registriert ist, einen Transfer in der anderen Form.
• Jedes Memo auf einer gemeinsamen Adresse ist auf der Transaktion eine eigene Zahlungsmethode.
• Was die einzelnen Netzwerke akzeptieren: Ein XRP-Destination-Tag ist eine ganze Zahl von 0 bis 4294967295 (eine JSON-Zahl wird akzeptiert). Ein Stellar-Memo ist Text mit bis zu 28 Byte, eine 64-Bit-ID oder ein 32-Byte-Hash in Hex. EOS akzeptiert bis zu 256 Byte, Cosmos bis zu 256 Zeichen und Hedera bis zu 100 Byte. Ein Memo auf einer Chain ohne Memo-Feld (Bitcoin, EVM-Chains, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning) ergibt einen 400-Fehler.

​

Lightning

​

Auftraggeber-Wallet aktualisieren

curl -X PATCH "https://verification.didit.me/v3/transactions/$TRANSACTION_ID/travel-rule/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "update_originator_wallet", "wallet_address": "bc1qsendercoldwallet02" }'

• Nur ausgehende Transfers, niemals CANCELLED- oder EXPIRED-Transfers (409).
• Sind die UTXO-Inputs des Transfers bekannt, muss die Wallet eine davon sein (sonst 400). Senden Sie auch memo in einem Memo-Netzwerk.
• Es ändert nur den Datensatz: Nichts wird erneut an die Gegenpartei gesendet, und der Status bleibt unverändert. chain_details.originator wird zur neuen Wallet mit source: updated. Die timeline hält die vorherige und die neue Wallet fest, und das INTERNAL-Gegenstück des Transfers wird auf die gleiche Weise aktualisiert.

​

Blockchain-Analytics-Zuordnung

1. Hält die Zuordnung am Transfer fest: beneficiary_data.counterparty_vasp_name wird befüllt (sofern Sie keinen Wert angegeben haben), und die Metadaten des Transfers enthalten einen Block vasp_attribution mit dem Namen, dem Entitätstyp und dem Land der Entität sowie source: "blockchain_analytics".
2. Fügt die Stelle dem VASP-Verzeichnis hinzu (oder gleicht sie mit dem vorhandenen Eintrag ab), damit die Zuordnung über alle Transfers hinweg stabil bleibt.
3. Führt die Rails einmal mit dem zugeordneten Namen erneut aus. Verfügt ein Verzeichniseintrag bereits über einen TRP-Endpoint, wird der Transfer sofort geroutet, statt bei COUNTERPARTY_VASP_NOT_FOUND zu landen.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-05-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "originator_data": {
        "first_name": "Jane",
        "last_name": "Doe",
        "date_of_birth": "1990-04-12",
        "residence_country": "ES",
        "customer_identification": "user-042",
        "wallet_address": "0x135908330861442a814796ae99feac507925782a"
      },
      "beneficiary_data": {
        "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
        "name": "Ana Diaz",
        "counterparty_vasp_email": "compliance@bene-casp.example"
      }
    }
  }'

{
  "uuid": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "transaction_type": "travelRule",
  "direction": "OUTBOUND",
  "status": "APPROVED",
  "amount": "0.25",
  "currency": "ETH",
  "currency_type": "crypto",
  "travel_rule": {
    "uuid": "33333333-4444-5555-6666-777777777777",
    "status": "AWAITING_COUNTERPARTY",
    "protocol": null,
    "required": true,
    "obligations_count": 0,
    "originator_data": {
      "first_name": "Jane",
      "last_name": "Doe",
      "date_of_birth": "1990-04-12",
      "residence_country": "ES",
      "customer_identification": "user-042",
      "wallet_address": "0x135908330861442a814796ae99feac507925782a"
    },
    "beneficiary_data": {
      "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
      "name": "Ana Diaz",
      "counterparty_vasp_email": "compliance@bene-casp.example",
      "chain": "ETH"
    },
    "metadata": {
      "compliance_email_source": "caller_supplied"
    }
  },
  "action_required": null
}

• originator_data ist das, was Sie gesendet haben, da dem Beispiel-Subjekt keine genehmigte KYC-Verifizierung zugeordnet ist. Bei einem verifizierten Benutzer erstellt Didit es aus den verifizierten Daten (siehe Verifizierte Daten und Herkunft). Das Rail EMAIL zeigt dem Empfänger nur die Auftraggeber-Felder, die Sie in data_sharing_fields freigeben.
• beneficiary_data.chain ist ETH, weil die Anfrage kein Netzwerk nannte und Didit es aus der Währung abgeleitet hat.
• status ist APPROVED, weil keine Regel auf die Transaktion angewendet wurde. Ihre eigenen Regeln können einen anderen Status setzen.
• Der Compliance-Kontakt erhält den Abholungslink. Der Transfer wird abgeschlossen, schlägt beim Namensabgleich fehl oder wird abgelehnt, sobald der Kontakt antwortet, oder er läuft ab, wenn der Kontakt nicht antwortet (siehe E-Mail-Abholung).

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

Warum ein Transfer blockiert ist

• reason ist die maschinenlesbare Ursache, "" bei jedem anderen Status.
• next_actions listet auf, was den Transfer weiterbringt, [] bei jedem anderen Status.
• delivery ist die neueste Nachricht, die der Transfer der Gegenseite schuldet: kind, status (QUEUED, SENDING, RETRYING, DELIVERED oder FAILED), rail, attempts, last_error, next_attempt_at und delivered_at, oder null, wenn er keine Nachricht schuldet.
• discovery zeigt, wo Didit nach der Gegenpartei gesucht hat, mit einem Eintrag pro ausgeführtem Schritt: step, outcome (match, miss oder skipped), reason, vasp, rail und at.

{
  "uuid": "33333333-4444-5555-6666-777777777777",
  "status": "COUNTERPARTY_VASP_NOT_REACHABLE",
  "protocol": "EMAIL",
  "direction": "OUTBOUND",
  "rail": "EMAIL",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "FAILED",
    "rail": "EMAIL",
    "attempts": 1,
    "last_error": "email undeliverable",
    "next_attempt_at": null,
    "delivered_at": null
  },
  "reason": "email_undeliverable",
  "next_actions": [
    { "action": "update_compliance_email" },
    { "action": "resend" }
  ]
}

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

Deklarierte selbstverwahrte Wallets

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-07-002",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "counterparty": {
      "entity_type": "external",
      "full_name": "Jane Doe",
      "payment_method": {
        "method_type": "unhosted_wallet",
        "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9"
      }
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
        "name": "Jane Doe"
      }
    }
  }'

• Es wird kein Rail verwendet - es gibt keinen Gegenpartei-VASP, mit dem ausgetauscht werden könnte - und der Transfer wird direkt in UNCONFIRMED_OWNERSHIP angelegt.
• Ist auto_wallet_verification aktiviert (Standardeinstellung), erstellt Didit automatisch eine Widget-Sitzung zur Wallet-Eigentumsprüfung, die an die Transaktion gebunden ist, und gibt sie im Block action_required der Transaktion zurück; die SDKs starten sie bei der clientseitigen Übermittlung automatisch.
• Sobald der Kunde die Kontrolle über die Wallet nachweist, führt der Transfer den Abgleich des Begünstigten-Namens aus und wechselt zu COMPLETED (oder zu COUNTERPARTY_MISMATCHED_DATA bei einem fehlgeschlagenen Abgleich).

​

Empfangen

​

Bestätigung des Wallet-Eigentums

• Ein eingehender Transfer wird einem Eintrag im Adressbuch zugeordnet, dessen Eigentum noch nicht verifiziert ist.
• Die Wallet der Gegenpartei wurde als selbstverwahrt angegeben (counterparty.payment_method.method_type: "unhosted_wallet"), bei einer ausgehenden Auszahlung oder einer eingehenden Einzahlung. Siehe Angegebene selbstverwahrte Wallets.

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirmed": true}'

• UNCONFIRMED_OWNERSHIP, in beiden Richtungen.
• ON_HOLD bei einem eingehenden Transfer.
• UNCONFIRMED_OWNERSHIP, ON_HOLD oder COUNTERPARTY_MISMATCHED_DATA bei einem eingehenden TRP-Transfer, damit ein Compliance-Beauftragter eine Anfrage der Gegenpartei manuell klären kann.

• confirmed: true markiert den passenden Eintrag im Wallet-Adressbuch als eigentumsverifiziert und führt anschließend den Namensabgleich gegen den holder_name dieses Eintrags aus. Das Ergebnis ist COMPLETED, wenn der Abgleich besteht, und COUNTERPARTY_MISMATCHED_DATA, wenn nicht. Das Gegenstück auf der INTERNAL-Rail erhält, sofern es existiert, dasselbe Ergebnis. Bei einer angegebenen selbstverwahrten Wallet hält confirmed: true fest, dass Ihr Kunde die Kontrolle über die Wallet der Gegenpartei verifiziert hat, und schließt den Transfer ab (COMPLETED), ausgehend oder eingehend. Ein eingehender Transfer, dessen Einzahlung bereits gebucht wurde, geht direkt in FINISHED über.
• confirmed: false setzt beide Seiten des Transfers auf COUNTERPARTY_VASP_GENERAL_DECLINE.
• Der passende Eintrag wird in Ihrem Adressbuch allein anhand der Adresse gesucht, ohne Berücksichtigung der Chain. Wenn Sie ein eingehendes ON_HOLD ohne passenden Eintrag auflösen, wird der Eintrag aus beneficiary_data.wallet_address des Transfers angelegt und als verifiziert markiert. Eine angegebene selbstverwahrte Wallet ist die Ausnahme: Die Wallet wird, wie unten beschrieben, als eigentumsverifiziert in Ihrem Adressbuch registriert. In allen anderen Fällen gibt ein fehlender Eintrag 409 mit {"detail": "wallet address entry no longer available"} zurück. Dieselbe Antwort erhalten Sie für einen gelöschten Eintrag.

• confirmed: true benötigt eine Zahlungsadresse für die Rückgabe. Sie wird zunächst aus der wallet_address der Anfrage, dann aus dem passenden Eintrag und zuletzt aus beneficiary_data.wallet_address entnommen. Sind alle drei leer, gibt die Anfrage 400 mit {"wallet_address": ["wallet_address is required to approve."]} zurück. Didit legt den Eintrag an oder verifiziert ihn, sendet den Callback zur Anfrageklärung an die Gegenpartei, setzt ownership_confirmed und verschiebt den Transfer nach COMPLETED.
• confirmed: false sendet eine abgelehnte Klärung und setzt den Transfer auf COUNTERPARTY_VASP_GENERAL_DECLINE.
• Ist der Callback-Endpoint der Gegenpartei nicht erreichbar, gibt die Anfrage 502 zurück, und der Transfer behält seinen aktuellen Status. Bei einer Genehmigung wird der Eintrag im Wallet-Adressbuch trotzdem angelegt oder als verifiziert markiert.

{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}

• Ein Netzwerktransfer, der bereits über sein Netzwerk beantwortet wurde (ein VerifyVASP-Transfer oder ein bereits entschiedener GTR- oder Sygna-Bridge-Transfer), gibt 409 zurück (siehe Transfers aus einem Netzwerk).

​

Transfers aus einem Netzwerk

• Routing. Die Nachricht erreicht Ihre Anwendung, wenn sie den Teilnehmercode Ihrer eigenen verbundenen Mitgliedschaft in diesem Netzwerk nennt. Eine an die Mitgliedschaft von Didit adressierte Nachricht erreicht Sie nur, wenn Sie der einzige aktive Didit-Kunde sind, der die Kontrolle über die Begünstigten-Wallet nachgewiesen hat. Alles andere wird abgelehnt, sodass kein Kunde jemals den Transfer eines anderen Kunden erhält.
• Entscheidung. Didit legt den eingehenden Transfer in Ihrer Anwendung an und behandelt ihn wie eine TRP-Anfrage: Wallet-Abgleich, Eigentum, Namensabgleich und inbound_auto_accept.
• Einmalig. Netzwerke senden eine Nachricht erneut, bis sie beantwortet ist. Eine Wiederholung erhält dieselbe Antwort wie die erste Kopie, und nichts wird ein zweites Mal angelegt oder entschieden.
• Ihre Prüfung, über GTR und SYGNA. Ein Transfer, der auf Sie wartet (UNCONFIRMED_OWNERSHIP, ON_HOLD oder COUNTERPARTY_MISMATCHED_DATA), entscheiden Sie mit POST .../travel-rule/ownership/: confirmed: true genehmigt ihn (übergeben Sie wallet_address, wenn der Transfer keine nennt), und confirmed: false lehnt ihn ab. Didit antwortet dem Netzwerk nach Ihrer Antwort, mit denselben Wiederholungsversuchen. Ein bereits beantworteter Transfer gibt 409 zurück.
• Keine spätere Antwort über VERIFYVASP. VerifyVASP erwartet seine Antwort bereits bei der Anfrage. Ein Transfer, der Ihre Prüfung bräuchte, wird deshalb sofort abgelehnt und kann später nicht mehr entschieden werden (409).

​

Maskierte Daten der Gegenpartei

{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}

​

Rückmeldung bei Abweichungen

{
  "status": "COUNTERPARTY_MISMATCHED_DATA",
  "mismatched_fields": ["date_of_birth"],
  "data_match": {
    "matched": false,
    "mismatched_fields": ["date_of_birth"],
    "fields": {
      "name": { "result": "matched", "strictness": "DEFAULT" },
      "date_of_birth": { "result": "mismatched", "strictness": "STRICT" },
      "address": { "result": "not_compared", "strictness": "NONE" },
      "account": { "result": "matched", "strictness": "STRICT" }
    }
  }
}

​

Übereinstimmungswert des Namens

{
  "name_match": {
    "score": 90,
    "matched": false,
    "method": "sequence_ratio",
    "strictness": "FUZZY",
    "compared_with": "wallet_holder",
    "transfer_name": "Ana Diaz",
    "compared_name": "Ana Diaz Garcia",
    "matched_names": ["Ana", "Diaz"],
    "mismatched_names": ["Garcia"]
  }
}

• score ist die Ähnlichkeit der beiden vollständigen Namen, von 0 bis 100, und 0, wenn einer der beiden Namen leer ist. matched ist das Ergebnis bei strictness, daher können beide voneinander abweichen: FUZZY entscheidet anhand seiner eigenen Ähnlichkeitsquote von 0.85.
• matched_names sind die Wörter des Namens der Überweisung, die im anderen Namen gefunden wurden. mismatched_names sind die Wörter, die eine Seite hat und die andere nicht.
• method ist none, exact_token, token_subset, token_containment oder sequence_ratio, für NONE, STRICT, DEFAULT, CONTAINS und FUZZY.
• compared_with ist wallet_holder (der für die Wallet hinterlegte Inhaber) oder counterparty_vasp (der Name, den die Gegenpartei auf der E-Mail-Antwortseite angegeben hat, oder die Antwort des Didit Test-VASPs).
• Das Ergebnis der Überweisung folgt data_match, das jedes Feld vergleicht. Daher kann eine Überweisung COUNTERPARTY_MISMATCHED_DATA sein, während name_match.matched true ist.
• name_match steht am Überweisungsobjekt, das die Travel-Rule-Endpunkte zurückgeben, und am eingebetteten travel_rule der Transaktion. Es ist null, bis ein Name verglichen wurde. Die Überweisungsliste und die Webhooks enthalten es nicht.
• Die Namen sind ausgeblendet, solange die Parteien maskiert sind, und in der Ansicht des anderen Kunden bei einem INTERNAL-Austausch.

​

Nachrichten und Dokumentenanfragen

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}'

• kind ist MESSAGE (Standard) oder DOCUMENT_REQUEST. Eine Dokumentenanfrage braucht mindestens einen Eintrag in requested_documents (bis zu 10). Eine Nachricht braucht einen body (bis zu 5000 Zeichen) oder eine Datei.
• reply_to verweist auf eine frühere Nachricht derselben Überweisung. Eine Antwort der anderen Seite, die ein Dokument enthält, erfüllt die Dokumentenanfrage, auf die sie antwortet, und fulfilled_at wird darauf gesetzt. Ihre eigene Antwort erfüllt niemals Ihre eigene Anfrage.
• Senden Sie eine Multipart-Anfrage mit files, um bis zu 5 Dateien mit je 10 MB anzuhängen, als PDF, PNG, JPEG oder WebP. Didit prüft den Inhalt jeder Datei, nicht nur den angegebenen Typ. Bei jedem anderen Dateityp antwortet die Anfrage auf files mit 400 (“Attach PDF, PNG, JPEG or WebP files only.”).
• Eine Überweisung umfasst bis zu 100 Nachrichten, davon bis zu 20 mit Anhängen (jeweils mit bis zu 5 Dateien), beide Seiten zusammengerechnet. Wird eine dieser Grenzen überschritten, antwortet die Anfrage mit 400. Nachrichtenanhänge zählen nicht zu den eigenen Dokumenten einer Transaktion.
• Nachrichten funktionieren über die Rails INTERNAL und EMAIL. Bei INTERNAL sieht der andere Didit-Kunde die Nachricht auf seiner Seite des Paars. Bei EMAIL wird die Gegenpartei per E-Mail benachrichtigt und antwortet im Abholportal. Kann diese Benachrichtigungs-E-Mail nicht gesendet werden, wird die Nachricht trotzdem gespeichert und die Anfrage antwortet mit 201.
• Die Anfrage antwortet mit 409 und einem Grund in detail bei einer Überweisung über TRP, GTR, TRUST, VerifyVASP oder Sygna (diese Protokolle übertragen keine Nachrichten), bei einer Überweisung ohne Gegenpartei, bei einer INTERNAL-Überweisung, deren Daten nicht mit dem Wallet-Inhaber übereinstimmten (der Empfänger hat nichts erhalten), bei einer INTERNAL-Überweisung, deren Empfänger die Kontrolle über die Wallet noch nicht nachgewiesen hat (auf beiden Seiten, bis er es tut), bei einer EMAIL-Überweisung, deren Gegenpartei keine Compliance-E-Mail-Adresse mehr hat, und bei einer EMAIL-Überweisung, deren Abhol-Link abgelaufen oder deren Überweisung geschlossen ist.
• Wenn die Gegenpartei zurückschreibt, wird kein Webhook ausgelöst. Rufen Sie den Nachrichten-Endpunkt ab.
• Die E-Mail, die die Gegenpartei über eine neue Nachricht informiert, wird auf Englisch versendet.

​

Wallet-Adressbuch

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "chain": "ETH",
    "holder_name": "Ana Diaz",
    "holder_vendor_data": "user-042",
    "self_declared": true
  }'

​

Wallets in großen Mengen importieren

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/import/ \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@wallets.csv;type=text/csv"

address,address_hash,chain,memo,holder_name,holder_vendor_data
0xBeneficiaryWallet01,,ethereum,,Ana Diaz,user-042
,4f7d2e1c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e,bitcoin,,,user-043
rExchangeSharedAddress01,,XRP,104729,Ana Diaz,user-042

​

E-Mail-Abholung für nicht erreichbare Gegenparteien

• An die richtigen Adressen. Eine übergebene counterparty_vasp_email ist der einzige Empfänger. Andernfalls schreibt Didit an bis zu drei Adressen: an die Kontakte der Gegenpartei, bei denen kein Bounce aufgetreten ist (zuerst Ihre eigenen, dann die Plattform-Kontakte, und zwar jene, die zuerst geantwortet haben), und danach an die Compliance-E-Mail des Verzeichniseintrags, sofern noch ein Platz frei ist. Jede Adresse erhält eine eigene E-Mail.
• In Ihrem Namen. Die E-Mail kommt von der Adresse von Didit mit dem Absender „Ihr rechtlicher Name via Didit“, in der Sprache der Jurisdiktion der Gegenpartei (Englisch, wenn keine bekannt ist). Der Link öffnet die Antwortseite in dieser Sprache. Sie erhalten keine Kopie. Verfolgen Sie den Verlauf des Transfers in der Zeitleiste.
• Mit Erinnerungen. Bis die Gegenpartei antwortet, erinnert Didit sie 72, 24 und 6 Stunden vor der Frist, mindestens 12 Stunden nach der Anfrage oder der letzten Erinnerung, und niemals nach der Frist.
• Umgang mit Bounces. Ein Bounce oder eine Spam-Beschwerde markiert den erreichten Kontakt als ungültig und vermerkt den Grund, und die Zeitleiste des Transfers vermerkt dies. Ein Plattform-Kontakt ist dann für jeden Didit-Kunden ungültig, Ihr eigener Anwendungskontakt nur für Ihre Anwendung. Stellt der E-Mail-Versand von Didit an eine Adresse ganz ein (nach einem dauerhaften Bounce, einer Spam-Beschwerde oder einer Abmeldung), wird jeder Kontakt an dieser Adresse als ungültig markiert (suppressed). Diese Kontakte sind wieder gültig, sobald der Versand an die Adresse wieder aufgenommen wird. Ist keine Adresse mehr übrig, an die geschrieben werden kann, wechselt der Transfer zu COUNTERPARTY_VASP_NOT_REACHABLE, und seine Zeitleiste enthält den Grund des empfangenden Mailservers. Ein dauerhafter Bounce oder eine Spam-Beschwerde an die übergebene counterparty_vasp_email führt sofort dazu, weil sie der einzige Empfänger ist. Ein vorübergehender Bounce (soft_bounce) an diese Adresse oder an die Compliance-E-Mail des Verzeichniseintrags lässt die Anfrage dagegen für die Erinnerungen offen.

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "reference": "33333333-4444-5555-6666-777777777777",
  "requested_at": "2026-07-05T10:00:00Z",
  "originator_vasp_name": "Origin CASP SL",
  "originator_vasp_lei": "529900EXAMPLEORIG001",
  "recipient_vasp_name": "Example Counterparty VASP",
  "language": "es",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "fiat_amount": "",
  "fiat_currency": "",
  "chain": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY",
  "ivms_version": "ivms101.2023",
  "deadline_at": "2026-07-07T10:00:00Z",
  "reminders_sent": 0,
  "contact": "",
  "decline_reasons": ["data_mismatch", "not_our_customer", "wallet_not_hosted", "sanctions", "risk_appetite", "jurisdiction", "insufficient_data", "other"],
  "join_invitation": { "eligible": false, "url": "" },
  "originator_data": { "name": "Jane Doe", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
  "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb" },
  "ivms_request": {
    "originator": {
      "originatorPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Doe", "secondaryIdentifier": "Jane", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
    },
    "beneficiary": {
      "beneficiaryPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
    }
  },
  "data_masked": false
}

curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept", "beneficiary_name": "Ana Diaz"}'

​

Nicht zugeordnete Einzahlungen

curl "https://verification.didit.me/v3/travel-rule/unmatched/" \
  -H "x-api-key: YOUR_API_KEY"

curl -X POST "https://verification.didit.me/v3/travel-rule/unmatched/{transaction_uuid}/match/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_id": "<uuid of the received message transaction>"}'

​

Nachträgliche Sunrise-Registrierung nach der Einzahlung

curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "eth",
    "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b",
    "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "amount": "500.00",
    "currency": "USDC",
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz" },
    "originating_vasp": {
      "name": "Northwind Digital Assets Ltd",
      "lei": "5493001KJTIIGC8Y1R12",
      "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg"
    }
  }'

• Kein passender Eintrag -> ON_HOLD. Lösen Sie ihn mit POST .../travel-rule/ownership/: confirmed: true fügt die Wallet als verifiziert zu Ihrem Adressbuch hinzu und führt den Namensabgleich durch. Bei einer Übereinstimmung wechselt der Transfer zu COMPLETED und danach zu FINISHED.
• Eintrag vorhanden, aber die Eigentümerstruktur ist nicht nachgewiesen -> UNCONFIRMED_OWNERSHIP.
• Name des Begünstigten stimmt nicht mit dem holder_name des Eintrags überein -> COUNTERPARTY_MISMATCHED_DATA.
• Verifizierter Eintrag und Name stimmen überein -> COMPLETED, danach sofort FINISHED (die Einzahlung ist bereits abgewickelt).

{
  "transaction_id": "44444444-5555-6666-7777-888888888888",
  "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e",
  "created": true,
  "travel_rule": {
    "uuid": "55555555-6666-7777-8888-999999999999",
    "status": "FINISHED",
    "direction": "INBOUND",
    "rail": null,
    "protocol": null,
    "ivms_version": "ivms101.2023",
    "required": true,
    "ownership_confirmed": true,
    "deadline_at": null,
    "timeline": [
      { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" },
      { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" }
    ],
    "counterparty_vasp": null,
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" },
    "created_at": "2026-07-06T10:15:02.087412Z"
  }
}

​

Widget zur Wallet-Eigentümerstruktur

​

Verzeichnis

curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \
  -H "x-api-key: YOUR_API_KEY"

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91",
      "kind": "directory",
      "name": "Example Counterparty VASP",
      "lei": "529900EXAMPLECPTY001",
      "jurisdiction": "DE",
      "domains": ["counterparty.example"],
      "reachable": true,
      "aliases": [{ "name": "Example Counterparty", "kind": "trading_name" }],
      "networks": [
        {
          "network": "GTR",
          "code": "EXAMPLE01",
          "listed_name": "Example Counterparty VASP",
          "country": "DE",
          "verified_at": "2026-10-12T09:30:00Z",
          "last_seen_at": "2026-10-12T09:30:00Z",
          "source": "staff"
        }
      ],
      "routes": [
        { "rail": "GTR", "status": "unavailable", "reason": "no_membership", "via": "" },
        { "rail": "EMAIL", "status": "available", "reason": "", "via": "contact" }
      ],
      "umbrella": null,
      "entities": [],
      "contacts": [
        {
          "id": "6c1f9b8e-2d4a-4f7e-8b3c-5a9d0e1f2a3b",
          "email": "travelrule@counterparty.example",
          "name": "Travel Rule desk",
          "source": "staff",
          "scope": "platform",
          "verified_at": null
        }
      ],
      "dd_status": "NOT_STARTED",
      "dd_score": 62,
      "dd_score_breakdown": {
        "jurisdiction": { "points": 25.0, "max": 25, "reason": "jurisdiction_not_high_risk", "detail": "DEU is not on the high-risk jurisdiction list" },
        "verification": { "points": 3.8, "max": 15, "reason": "dd_status_not_started", "detail": "due diligence status NOT_STARTED" },
        "protocol": { "points": 6.0, "max": 15, "reason": "email_only", "detail": "reachable over the email fallback only" },
        "lei": { "points": 10.0, "max": 10, "reason": "lei_valid", "detail": "valid LEI on record" },
        "history": { "points": 5.0, "max": 10, "reason": "no_history", "detail": "no exchange history" },
        "essentials": { "points": 7.5, "max": 15, "reason": "no_essential_checks", "detail": "no decided essential check yet" },
        "responsiveness": { "points": 5.0, "max": 10, "reason": "responsiveness_unknown", "detail": "0 decided recent requests, too few to judge" }
      },
      "dd_assessed_at": "2026-10-12T09:30:00Z",
      "dd_score_semantic": "higher_is_safer",
      "risk_level": "MEDIUM",
      "responsiveness": { "status": "UNKNOWN", "answered": 0, "total": 0, "computed_at": "2026-10-12T09:30:00Z" },
      "essential_checks": {},
      "reachable_rails": ["GTR", "EMAIL"],
      "is_didit_customer": false,
      "decision": {
        "decision": "APPROVED",
        "reason": "Licensed in DE",
        "decided_by": "",
        "updated_at": "2026-10-14T10:05:00Z",
        "inherited_from": null
      },
      "entity_screening": {
        "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
        "status": "Approved",
        "total_hits": 0,
        "score": null,
        "screened_at": "2026-10-14T09:58:00Z",
        "fresh": true,
        "flagged": false
      },
      "questionnaires": []
    }
  ]
}

​

Routen

• TRP, wenn der Eintrag einen TRP-Endpoint enthält, den das Verzeichnis verifiziert hat.
• GTR, TRUST, VERIFYVASP, SYGNA, wenn ein Netzwerk den VASP unter einem Code führt. Die Route ist nur available, wenn Ihre Anwendung heute über dieses Netzwerk senden kann (via: own_membership für Ihre eigene verbundene Mitgliedschaft, via: didit_membership für die Mitgliedschaft von Didit). Andernfalls ist sie unavailable mit reason: no_membership oder reason: network_switched_off und wird niemals als Weg zum VASP angezeigt. Die eigenen Netzwerkmitgliedschaften von Didit sind noch nicht aktiv. Daher ist eine Netzwerkroute derzeit nur über eine Mitgliedschaft verfügbar, die Sie im Marketplace verbunden haben.
• EMAIL, wenn für den Eintrag ein Compliance-Kontakt vorhanden ist.
• INTERNAL für ein Mitglied des Didit-Netzwerks.

​

Marken und ihre Rechtsträger

​

Kontakte

curl -X POST https://verification.didit.me/v3/travel-rule/counterparty-contacts/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"counterparty": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "email": "compliance@counterparty.example", "name": "Compliance desk"}'

• GET /v3/travel-rule/counterparty-contacts/ listet jeden Kontakt, an den Ihre Anwendung senden darf, einschließlich Plattformkontakte und unzustellbarer Kontakte, neueste zuerst. Die Paginierung erfolgt mit limit und offset. Filtern Sie mit ?counterparty= und einer id eines Verzeichniseintrags. Ein Wert, der keine UUID ist, führt zu einer Antwort 400.
• POST fügt einen privaten Kontakt hinzu (counterparty, email, optional name) und antwortet mit 201. Wenn die Adresse unter Ihren eigenen Kontakten für diesen Eintrag bereits vorhanden ist, wird dieser Kontakt zurückgegeben. Ein unbekannter Eintrag führt zu einer Antwort 400 ("No directory entry with this id.").
• DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/ löscht einen Ihrer eigenen Kontakte (204). Plattformkontakte können nicht gelöscht werden und führen zu einer Antwort 404.

​

So gelangen Einträge in das Verzeichnis

• Das ESMA-Zwischenregister der MiCA-Anbieter von Krypto-Dienstleistungen, das wöchentlich eingelesen wird: Name, LEI und Heimatmitgliedstaat jedes Anbieters.
• Das öffentliche TRISA-Verzeichnis, das wöchentlich eingelesen wird: wer jedes Mitglied ist, in welchem Land es ansässig ist und welchen TRISA-Eintrag es hat. Ein Eintrag, den das Verzeichnis drei Wochen lang nicht mehr anzeigt, wird entfernt.
• Das globale LEI-Register ergänzt bei einem Eintrag die LEI, weitere amtliche Firmennamen und das Land und findet die LEI eines Eintrags über dessen exakten amtlichen Namen in dessen Land.
• Zuordnung durch Blockchain-Analytics ergänzt oder gleicht den VASP ab, dem eine Ziel-Wallet gehört, und behält den zugeordneten Namen als Alias.
• Didit-Mitarbeitende pflegen Einträge: verifizierte Routing-Kennungen und Netzwerkeinträge, Compliance-Kontakte, Aliase, Marken und deren Gesellschaften, zusammengeführte Duplikate und ausgeblendete Einträge.

​

Das Didit-Netzwerk

• Ihre Anwendung befindet sich in der Produktion (nicht in der Sandbox) und die Travel Rule ist aktiviert;
• is_discoverable ist true und legal_name ist gesetzt;
• compliance_email ist gesetzt und bestätigt: Senden Sie die Bestätigung mit POST /v3/travel-rule/settings/compliance-email/confirmation/ und öffnen Sie den E-Mail-Link. Bei einer Änderung der Adresse ist eine neue Bestätigung erforderlich;
• Didit hat die Anwendung nicht als Test-, Demo- oder interne Anwendung markiert.

​

Routing-Kennungen

​

Due-Diligence für Gegenparteien

• Die gemeinsame Bewertung. Jeder Verzeichniseintrag enthält einen Due-Diligence-Score, seine Risikostufe, einen Reaktionsstatus und einen Bericht über wesentliche Prüfungen. Didit berechnet diese Werte aus den eigenen Daten der Plattform, sodass jeder Kunde dieselben Werte sieht.
• Ihre eigenen Unterlagen. Ihre Entscheidung über die VASP, Ihre Sanktionsprüfung und Ihr Screening auf negative Medienberichte sowie die Due-Diligence-Fragebögen, die Sie mit ihr ausgetauscht haben, gehören ausschließlich zu Ihrer Anwendung. Kein anderer Kunde sieht sie, und sie verändern nie den gemeinsamen Eintrag.

​

Score und Risikostufe

​

Wesentliche Prüfungen

​

Reaktionsfähigkeit

{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }

• Wird gezählt: Anfragen über einen Netzwerk- oder Protokollkanal sowie Anfragen, die an eine gemeinsam genutzte Adresse per E-Mail gesendet wurden. Dazu gehören die Compliance-Adresse des Eintrags oder ein Plattformkontakt.
• Wird nie gezählt: Eine Anfrage, die per E-Mail an eine von einem Kunden selbst eingegebene Adresse gesendet wurde, oder an einen privaten Kontakt eines Kunden. Ein solcher Austausch bleibt im Transferverlauf des Kunden und kennzeichnet die VASP nie für alle anderen.
• Beantwortet: COMPLETED, FINISHED, COUNTERPARTY_VASP_GENERAL_DECLINE oder COUNTERPARTY_MISMATCHED_DATA. Eine Ablehnung oder eine Nichtübereinstimmung ist eine Antwort: Die VASP hat reagiert.
• Unbeantwortet: EXPIRED.
• Weder noch: jeder andere Status. Eine CANCELLED-Anfrage ist eine eigene Handlung des Absenders. COUNTERPARTY_VASP_NOT_REACHABLE kann auf Seiten des Absenders ein Fehler sein. Eine Anfrage, die noch läuft, ist noch nicht entschieden.

​

Ihre Entscheidung zu einer Gegenpartei

curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}'

{
  "decision": {
    "decision": "BLOCKED",
    "reason": "Unlicensed in its home jurisdiction",
    "decided_by": "",
    "updated_at": "2026-10-14T10:05:00Z",
    "inherited_from": null
  }
}

• Die Entscheidung ist nur für Ihre Anwendung sichtbar: Ein anderer Kunde sieht sie nie, und sie ändert nie den gemeinsamen Eintrag.
• Eine Entscheidung allein bewirkt nichts und ändert nie, wie ein Transfer geroutet wird. Sie wirkt sich auf Ihre Transaktionen über das Regelfeld counterparty_dd_status aus: Installieren Sie die Presets oder schreiben Sie eigene Regeln darauf.
• Eine Entscheidung zu einer Marke gilt für jede ihrer Entitäten, die keine eigene Entscheidung hat, und die Entität zeigt die Marke in inherited_from an. Eine Entscheidung zur Entität überschreibt die der Marke für diese Entität.
• GET liefert die Entscheidung, die gilt, oder {"decision": null}. DELETE löscht Ihre eigene Entscheidung und liefert zurück, was danach gilt: die Entscheidung der Marke für eine Entität, andernfalls null. Die Anfrage liefert 404 zurück, wenn Ihre Anwendung zu der Gegenpartei keine eigene Entscheidung hat.
• reason ist optional, bis zu 255 Zeichen lang, und jedes PUT ersetzt es. decided_by ist der Konsolenbenutzer, der die Entscheidung getroffen oder zuletzt geändert hat, und ist leer, wenn sie über einen API-Schlüssel getroffen wurde.

​

Screening der Gegenpartei

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh": false}'

{
  "outcome": "screened",
  "screening": {
    "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
    "status": "In Review",
    "total_hits": 2,
    "score": 85.0,
    "screened_at": "2026-10-14T09:58:00Z",
    "fresh": true,
    "flagged": true
  }
}

• Abrechnung. Jedes neue Screening kostet den Preis für das AML-Screening von Unternehmen Ihrer Organisation. GET /v3/travel-rule/vasps/{vasp_id}/screening/ liefert diesen price, fresh_days und ob das Screening enabled ist, kostenlos. Ein Screening, das jünger als 30 Tage ist, ist aktuell: POST liefert es mit 200 und outcome: reused erneut zurück und rechnet nichts ab, es sei denn, Sie senden refresh: true. Bei einem neuen Screening wird 201 mit outcome: screened zurückgegeben. Sandbox-Anwendungen werden niemals geprüft oder abgerechnet.
• Automatisches Screening. Ist das Screening aktiviert, prüft Didit außerdem die Gegenpartei eines ausgehenden Austauschs, sobald der Austausch beginnt, bevor Ihre Regeln die Transaktion auswerten, unter denselben Bedingungen für Wiederverwendung und Abrechnung. Eine Ablehnung oder ein Fehler an dieser Stelle lässt den Transfer nie scheitern.
• Ergebnis. status ist Approved, wenn kein möglicher Treffer Aufmerksamkeit erfordert, und In Review oder Declined bei einem möglichen Treffer bei Sanktionen oder negativen Medienberichten. flagged ist true, solange ein aktuelles Screening In Review oder Declined ist.
• Auswirkung. Solange Ihr letztes Screening einer Gegenpartei markiert ist und das Screening aktiviert bleibt, ist counterparty_risk_level in Ihren Regeln HIGH. Damit hält das Preset travel-rule-counterparty-high-risk nach der Installation ihre Transfers zurück. Das gemeinsame risk_level im Verzeichnis ändert sich nicht.
• Datenschutz. Das Screening ist nur für Ihre Anwendung sichtbar: Ein anderer Kunde sieht es nie, und es ändert nie den gemeinsamen Eintrag. Das Verzeichnis zeigt Ihr letztes Screening als entity_screening an.
• Ablehnungen. 409, wenn das Screening deaktiviert ist, bei einer Sandbox-Anwendung oder während bereits ein Screening derselben Gegenpartei läuft. 403 mit code: insufficient_credits, wenn Ihr Guthaben den Preis nicht deckt. 502, wenn das Screening nicht abgeschlossen werden konnte. In keinem dieser Fälle wird etwas abgerechnet.

​

Fragebogen zur Sorgfaltsprüfung

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sent_to": "travelrule@counterparty.example"}'

{
  "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f",
  "status": "SENT",
  "form_version": "1",
  "sent_to": "travelrule@counterparty.example",
  "sent_at": "2026-10-14T10:00:00Z",
  "expires_at": "2026-11-13T10:00:00Z",
  "answered_at": null,
  "valid_until": null,
  "current": false,
  "answers": {}
}

• Empfänger. sent_to muss eine hinterlegte Compliance-Adresse sein: bei einem Verzeichniseintrag deren Compliance-Adresse oder ein Kontakt, den Ihre Anwendung in contacts sieht; bei einem Mitglied des Didit-Netzwerks deren bestätigte Compliance-E-Mail. Lassen Sie das Feld weg, um die Adresse zu verwenden, an die eine Travel-Rule-E-Mail an die Gegenpartei geht: zuerst Ihr eigener Kontakt, dann ein Plattformkontakt, dann die Compliance-Adresse des Eintrags. Didit sendet den Fragebogen nie an eine andere Stelle und antwortet mit 400, wenn die Gegenpartei keine Compliance-Adresse hinterlegt hat.
• Beantwortung. Der Link öffnet /v3/travel-rule/questionnaires/{token}/, eine Seite für eine Person bei der Gegenpartei, die dafür kein Konto und keinen API-Schlüssel benötigt. Sie beantwortet jede Frage, bis zu 2.000 Zeichen je Frage (N/A, wenn eine Frage nicht zutrifft), und reicht sie einmal ein. Eine Gegenpartei kann außerdem {"answers": {"<question id>": "<answer>"}} an denselben Link senden. Ein Link, der bereits verwendet oder ersetzt wurde oder dessen Gültigkeitsfrist abgelaufen ist, zeigt stattdessen eine Seite mit abgelaufenem Link. Die E-Mail und die Seite sind übersetzt; die Fragen selbst stehen immer auf Englisch, damit ihre Bedeutung in allen Sprachen gleich bleibt.
• Fristen. Die Gegenpartei hat 30 Tage Zeit zu antworten (expires_at). Antworten bleiben 365 Tage gültig (valid_until), und current ist bis dahin true. Ein unbeantworteter Fragebogen nach Ablauf der Frist und Antworten nach Ablauf ihrer Gültigkeit werden EXPIRED.
• Ein offener Fragebogen pro Gegenpartei. Ein neuer Versand ersetzt Ihren früheren unbeantworteten Fragebogen an dieselbe Gegenpartei: Er wird EXPIRED, und sein Link funktioniert nicht mehr. An eine Adresse kann nur eine E-Mail pro Minute gehen; ein schnellerer Versand führt zu 429.
• Antworten abrufen. GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/ listet Ihre Fragebögen zu der Gegenpartei auf, neueste zuerst, wobei answers nach Frage-ID als Schlüssel strukturiert ist, sobald beantwortet. Das Verzeichnis zeigt sie als questionnaires an. Sie sind nur für Ihre Anwendung sichtbar.

​

Transfers mit einer Gegenpartei

​

Sunrise-Richtlinie und Richtlinie für nicht reagierende Gegenparteien

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}'

1. sunrise_policy, wenn sie gesetzt ist und die Rechtsordnung der Gegenpartei in sunrise_jurisdictions enthalten ist.
2. non_responsive_policy, wenn sie gesetzt ist und die Gegenpartei UNRESPONSIVE ist.
3. timeout_outcome in allen anderen Fällen, einschließlich eines Transfers an ein Didit-Netzwerkmitglied oder an eine Gegenpartei ohne Verzeichniseintrag.

​

Regelfelder und Vorlagen

​

Webhooks

{
  "event_id": "9c0c8b8a-1111-4222-9333-666666666666",
  "webhook_type": "travel_rule.status.updated",
  "timestamp": 1774970000,
  "created_at": 1774970000,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "transaction_id": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "travel_rule_status": "COMPLETED",
  "rail": "INTERNAL",
  "direction": "OUTBOUND"
}

​

Preise

• Sie gilt für eine ausgehende travelRule-Transaktion in einer Anwendung mit aktivierter Travel Rule, deren Betrag mindestens Ihrem threshold_amount entspricht, sodass Didit dafür einen verwalteten Austausch startet. Ein Transfer an eine selbstverwahrte Wallet oder an die eigene verifizierte Wallet Ihres Benutzers zählt ebenfalls: Der Eigentumsnachweis ist dessen Austausch.
• Jede andere ausgehende Transaktion, die Travel-Rule-Daten enthält, wird als standardmäßiges Transaction Screening abgerechnet. Das ist in Ihrem Tarif bis zu dessen monatlichem Transaktionskontingent enthalten und kostet darüber hinaus $0.001. Dazu gehören ein Transfer unterhalb Ihres Schwellenwerts, eine Lightning-Zahlung, auf die die Travel Rule nicht angewendet wird, und ein passiv erfasster Transfer, wenn Travel Rule ausgeschaltet ist. Eine Transaktion wird über genau eine der beiden Positionen abgerechnet, niemals über beide.
• Eingehende travelRule-Transaktionen verursachen keine Gebühr für Travel Rule oder Monitoring. Das gilt für den eingehenden Transaktionsabschnitt, den Didit in der Anwendung des Begünstigten über die INTERNAL-Schiene erstellt, für eingehende TRP-Anfragen und für Registrierungen nach der Einzahlung.
• Eine Anwendung, die dem kostenlosen Travel-Rule-Angebot beigetreten ist, zahlt bei ausgehenden travelRule-Transaktionen keine der beiden Gebühren, bis sie die ausgehende Abrechnung mit POST /v3/travel-rule/workspace/billing/ aktiviert. Der Empfang bleibt kostenlos.
• Sandbox-Anwendungen werden nie berechnet.
• Die Travel-Rule-Gebühr ist mit $0.02 angesetzt, Transaction Screening mit $0.001 jenseits Ihres Kontingents. Jede Transaktion wird zum Preis der Position berechnet, über die sie abgerechnet wird.
• Wenn auf derselben Transaktion auch Krypto-AML-/Wallet-Screening läuft (zum Beispiel bei einer eingehenden Einzahlung mit currency_kind: "crypto" und aktiviertem Monitoring), wird das separat zum Standardpreis für Wallet Verification & Screening berechnet. Es ist nicht in der Travel-Rule-Gebühr enthalten.
• Gegenpartei-Screening muss ausdrücklich aktiviert werden und wird separat berechnet, zum Preis für Company AML Screening pro Screening. Ein Screening, das jünger als 30 Tage ist, wird ohne Kosten wiederverwendet. Entscheidungen, Fragebögen und die Due-Diligence-Bewertung im Verzeichnis kosten nichts.

​

Attribution-Preise

• Das Krypto-Monitoring hat die Wallet bei dieser Transaktion bereits geprüft: Das gespeicherte Ergebnis wird wiederverwendet. Es fällt ein Analytics-Aufruf und eine Abrechnung für Wallet Verification & Screening an (dieselbe, die das Krypto-Monitoring bereits erzeugt hat). Die Attribution fügt nichts hinzu.
• Das Krypto-Monitoring lief nicht: Didit führt den erforderlichen Analytics-Aufruf einmal aus und gibt dessen vollen Wert weiter. Die Transaktion wird zum Standardpreis für Wallet Verification & Screening abgerechnet ($0.15 mit von Didit verwalteter Analytics) und erhält dafür die vollständige Krypto-Screening-Ausgabe zurück: Risiko-Score, Risikokategorie der Wallet, Netzwerk-Snapshot, nicht nur den VASP-Namen. Die Nutzungsposition ist mit dem Auslöser travel_rule_attribution markiert, damit die Abrechnung nachvollziehbar ist.
• Eigener Analytics-Schlüssel: Hier gilt dieselbe Plattformgebühr wie für das Krypto-Monitoring mit Ihrem eigenen Schlüssel ($0.02 pro Aufruf). Ihr Anbieter stellt Ihnen die zugrunde liegende Abfrage direkt in Rechnung.
• Fehlgeschlagene Abfragen werden nie berechnet. Wiederholungen verwenden die gespeicherte Attribution ohne neuen Aufruf und ohne neue Abrechnung. Sandbox-Anwendungen werden nie berechnet.

​

Regelpaket EU TFR

​

Warum das auf einer Plattform besser funktioniert

• Verifizierte Daten bereits vorhanden. Die betroffene Person jedes Transfers ist über vendor_data mit dem KYC-Profil verknüpft, das Didit beim Onboarding verifiziert hat (Dokument-OCR, Liveness-Erkennung, Gesichtsabgleich). So können Sie originator_data auf derselben Plattform aus verifizierten Feldern aufbauen. Bei einem Benutzer mit genehmigter KYC-Verifizierung übermittelt Didit die verifizierte Identität und nicht die von Ihnen eingegebenen Werte (siehe Verifizierte Daten und Herkunftsnachweis).
• Biometrische Step-up-Prüfung für riskante Transfers. Eine Regel kann jeden Transfer mit hohem Betrag zurückhalten, bis der Benutzer eine biometrische Nachprüfung gegen das beim Onboarding erfasste Gesicht bestanden hat, die wirksamste Antwort auf eine Kontoübernahme im Moment der Auszahlung. Siehe das Praxisbeispiel.
• Ein einheitlicher Gerätegraph. Über das SDK übermittelte Transfers enthalten dieselben Geräteinformationen und -signale wie KYC-Sitzungen. Damit ist „neues Gerät + hoher Betrag + erstmaliger Begünstigter“ eine einzige Regel und keine Data-Warehouse-Verknüpfung.
• Screening, Regeln, Fälle und Exchange an einem Ort. Das Wallet-Screening, das die VASP der Gegenpartei zuordnet, ist dasselbe Screening, das Ihre Regeln und Analysten sehen. Das bedeutet eine Abrechnung, eine Konsole und einen Audit-Trail.
• Veröffentlichte Preise. $0.02 pro ausgehendem Exchange, keine Volumenstufen, kein Verkaufsgespräch.

​

FAQ

​

Wie der Austausch funktioniert

​

Preise und Lizenzierung

​

Betrieb und Daten

​

Nächste Schritte