> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Travel Rule Interoperabilität – VASP mit Didit erreichen > So tauschen VASPs Travel-Rule-Daten mit Didit-Kunden aus: Travel Address, öffentliche TRP-Endpoints, Callback-URLs, E-Mail-Abholung und Sunrise-Registrierung. Diese Seite richtet sich an die **Gegenseite** eines [Didit Travel Rule](https://docs.didit.me/de/transaction-monitoring/travel-rule.md)-Austauschs: an den VASP der Gegenpartei (bzw. an dessen Entwicklungsteam), der Travel-Rule-Daten an einen VASP senden oder von ihm empfangen muss, der auf Didit läuft. Alles, was hier dokumentiert ist, ist öffentliche Infrastruktur, die von Didit betrieben wird. Sie benötigen weder ein Didit-Konto noch einen API-Schlüssel oder eine kommerzielle Beziehung zu Didit, um zu interoperieren. Die weitestgehende Integration erfordert lediglich HTTPS und JSON. ## Wie Didit einen Austausch weiterleitet Wenn ein Didit-Kunde eine Transaktion sendet, prüft Didit diese Wege in strikter Prioritätsreihenfolge und verwendet den ersten, der Sie erreichen kann: | Priorität | Weg | Was das für Sie bedeutet | | - | - | - | | 1 | `INTERNAL` | Beide VASPs laufen auf Didit, der Austausch wird innerhalb der Plattform abgewickelt und es erfolgt kein externer Aufruf. | | 2 | `TRP` | Sie stellen einen Travel-Rule-Protocol-(TRP)-Endpoint bereit, oder der Didit-Kunde kennt Ihre [Travel Address](#travel-addresses). Didit ruft Ihren TRP-Anfrage-Endpoint von Maschine zu Maschine auf, und zwar für `BTC`-, `ETH`- und `USDC`-Transfers (`USDC`, wenn der Transfer das Netzwerk nennt, über das er läuft). | | 3 | `GTR` | Für den Absender ist eine Global-Travel-Rule-(GTR)-Mitgliedschaft aktiv, und Sie sind über eine GTR-VASP-Kennung adressierbar. Didit liest Ihre Antwort aus der Antwort von GTR oder durch Abfrage des Status der Anfrage. | | 4 | `TRUST` | Für den Absender ist eine TRUST-Mitgliedschaft aktiv, und Sie sind über eine TRUST-Mitgliedschafts-ID adressierbar. Nur Senden: siehe die Warnung unten. | | 5 | `VERIFYVASP` | Für den Absender ist eine VerifyVASP-Mitgliedschaft aktiv, und Sie sind über eine VerifyVASP-ID adressierbar. Didit liest Ihre Antwort durch Abfrage des Status der Verifizierung. | | 6 | `SYGNA` | Für den Absender ist eine Sygna-Bridge-Mitgliedschaft aktiv, und Sie sind über einen Sygna-VASP-Code adressierbar. Didit spricht das Sygna-Protokoll nativ (ECIES-verschlüsseltes IVMS101, signierte Genehmigungsanfragen) und liest Ihre Genehmigungsantwort durch Abfrage des Status des Transfers. Der Sygna-Callback ist noch nicht aktiv. | | 7 | `EMAIL` | Es ist kein Protokollkanal verfügbar. Stattdessen erhält Ihr Compliance-Kontakt einen einmaligen [E-Mail-Abholungslink](#e-mail-abholung). | > [!WARNING] > > **Didit kann keine `TRUST`-Antwort empfangen und nimmt derzeit keine Transfers an, die über ein Netzwerk an Didit gesendet werden.** > Über `TRUST` erreicht ein Transfer eines Didit-Kunden Sie, Ihre Antwort kann jedoch nicht zurückkommen. Der Transfer läuft dann an der Bestätigungsfrist des Absenders ab, statt abgeschlossen zu werden. > Über `GTR`, `VERIFYVASP` und `SYGNA` liest Didit Ihre Antwort direkt aus dem Netzwerk, entweder aus dessen Antwort oder durch Abfrage des Transferstatus. Die obige Tabelle gilt für Transfers, die ein Didit-Kunde sendet. Wenn Sie einen Transfer an einen Didit-Kunden senden, kann Didit ihn nur als `TRP`-[Transferanfrage](#post-/trp/inquiries//) entgegennehmen, sobald der öffentliche TRP-Host von Didit aktiv ist (er antwortet noch nicht, siehe [TRP-Endpoints](#trp-endpoints)), oder nach der Abwicklung als [Sunrise-Registrierung](#sunrise-transfers-die-vor-dem-austausch-abgewickelt-wurden). Derzeit stellt kein Netzwerkweg und kein E-Mail-Kanal einen eingehenden Transfer an einen Didit-Kunden zu. Die Netzwerkwege (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) laufen über eine Mitgliedschaft auf der sendenden Seite. Derzeit muss das die eigene verbundene Mitgliedschaft des Didit-Kunden sein. Didit besitzt noch keine Plattform-Mitgliedschaft in einem dieser Netzwerke und befindet sich dort im Onboarding als Anbieter. GTR ist nicht standardmäßig enthalten, und für alle vier Netzwerke gilt dieselbe Mitgliedschaftsvoraussetzung. Der Absender sollte das Objekt `networks` in [Travel-Rule-Einstellungen abrufen](https://docs.didit.me/de/management-api/travel-rule/get-settings.md) prüfen: `didit` bedeutet, dass die Mitgliedschaft von Didit diese Anwendung als eigenen Teilnehmer im Netzwerk führt. `own` bedeutet eine verbundene Kundenmitgliedschaft, `off` bedeutet, dass das Plattform-Routing deaktiviert ist, und `unavailable` bedeutet, dass über dieses Netzwerk für die Anwendung derzeit niemand senden kann. Solange Didit keine Plattform-Mitgliedschaft besitzt, meldet kein Netzwerk `didit`. Das Aktivieren von Travel Rule aktiviert keine Netzwerk-Mitgliedschaft. Was jedes Netzwerk heute erreicht, steht unter [Travel-Rule-Netzwerke](https://docs.didit.me/de/transaction-monitoring/travel-rule-networks.md). Wenn Sie in einem dieser Netzwerke aktiv sind und der Didit-Kunde dort eine eigene Mitgliedschaft hat, teilen Sie ihm Ihre Netzwerkkennung mit. Dann erreicht Sie der Transfer über das Netzwerk, das Sie bereits betreiben. Über `SYGNA` entscheidet Ihre Genehmigungsantwort, ob der Transfer abgeschlossen oder abgelehnt wird. Didit fragt den Transferstatus alle 5 Minuten ab und registriert außerdem `https://trp.didit.me/sygna/callbacks/permission/{token}/` als Callback jeder Genehmigungsanfrage, mit einem Token, das für diesen Transfer erzeugt wurde. Dieser Callback liegt auf dem öffentlichen TRP-Host von Didit, der derzeit noch keine Anfragen beantwortet. Ein `permission_status` von `ACCEPTED` setzt den Transfer des Absenders auf `COMPLETED`. `REJECTED` setzt ihn auf `COUNTERPARTY_VASP_GENERAL_DECLINE`, oder auf `COUNTERPARTY_MISMATCHED_DATA`, wenn der `reject_code` `BVRC007` ist (der Name des Begünstigten stimmt nicht überein). Der Callback benötigt Ihre Signatur. Ohne gültige Signatur antwortet er mit `401` und `{"status": "INVALID_SIGNATURE"}`, bei einem unbekannten Token mit `404`, und bei einer bereits angewendeten Entscheidung erneut mit `200`. Ohne gemeinsame Mitgliedschaften ist `TRP` der Weg, den Sie einplanen sollten. Teilen Sie Ihre Travel Address mit dem Didit-Kunden, dann erreichen dessen Transfers Ihren TRP-Endpoint. Eine Antwort, die Sie in Ihrer Antwort auf die Anfrage geben, schließt den Transfer oder lehnt ihn sofort ab. Eine Antwort, die Sie später an den Callback von Didit senden, benötigt den öffentlichen TRP-Host von Didit, der noch nicht aktiv ist. Wenn keiner der Wege Sie identifizieren kann, führt Didit einen weiteren Auflösungsschritt aus: **Zuordnung über Blockchain-Analytik**. Die Ziel-Wallet wird mit Blockchain-Analysedaten abgeglichen. Wird sie Ihrem Exchange oder Verwahrdienst zugeordnet, trägt Didit Ihren Namen in sein VASP-Verzeichnis ein und wiederholt die Wege mit diesem Namen. Das bedeutet, dass Sie auch identifiziert werden können, wenn der Absender nur eine Adresse angegeben hat. Zugeordnete Transfers werden Ihnen erst automatisch zugestellt, wenn Ihr Verzeichniseintrag einen Weg enthält: einen verifizierten `TRP`-Endpoint, einen Netzwerkeintrag oder einen Compliance-Kontakt (siehe [Aufnahme ins Didit-VASP-Verzeichnis](#aufnahme-ins-didit-vasp-verzeichnis)). Die vollständige Auflösungskette lautet daher: ein Didit-Kunde, der die Kontrolle über die Wallet nachgewiesen hat (`INTERNAL`), und die Travel Address, die der Absender dafür gespeichert hat. Danach folgen die Protokoll- und Netzwerkwege und zuletzt die Blockchain-Analytik. ## Travel Addresses Jedes Didit-VASP mit aktivierter Travel Rule hat eine **Travel Address**, eine kompakte Zeichenkette, die mit `ta` beginnt und die URL des persönlichen TRP-Endpoints für Transferanfragen kodiert. Didit-Kunden finden ihre Travel Address in den Travel-Rule-Einstellungen und teilen sie mit ihren Gegenparteien. Wenn Ihnen ein Didit-Kunde seine Travel Address gibt, haben Sie alles, was Sie für die Kommunikation über TRP brauchen. Die Kodierung folgt der TRP-Konvention für Travel Addresses: * Entfernen Sie das Präfix `ta`. * Dekodieren Sie den Rest mit Base58Check (Bitcoin-Alphabet, Prüfsumme mit doppeltem SHA-256). * Die dekodierten Bytes ergeben die Anfrage-URL ohne Schema. Stellen Sie `https://` voran. * Die URL enthält immer das Query-Paar `t=i` (Typ: Anfrage). Eine dekodierte Didit-Travel-Address hat eine von zwei Formen: ``` https://trp.didit.me/trp/inquiries/{profile_uuid}/?t=i https://trp.didit.me/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/?t=i ``` `{profile_uuid}` identifiziert das gehostete VASP-Profil. Senden Sie Ihre Transferanfragen per POST an diese URL und fragen Sie vorher den passenden [Identity-Endpoint](#get-/trp/identity//) ab, um zu prüfen, mit wem Sie kommunizieren. Die zweite Form ist eine **Travel Address pro Wallet**. Sie bezeichnet eine einzelne Wallet des Didit-Kunden (`receiving_travel_address` in dessen Adressbuch), sodass Ihre Anfrage diese Wallet erreicht, ohne dass der Kunde sie anhand von Kontonummer oder Kontoinhabername zuordnen muss. Sobald die Wallet gelöscht oder einem anderen VASP zugeordnet ist, antwortet der Endpoint mit `404`. ## TRP-Endpoints Didit verwendet die TRP-API-Version `3.2.1` unter der Basis-URL `https://trp.didit.me`. Alle Endpoints tauschen JSON über HTTPS aus. > [!WARNING] > > Der öffentliche TRP-Host von Didit stellt diese Endpoints noch nicht bereit. Bis er bereitsteht, kann eine TRP-Anfrage oder Identitätsanfrage an einen Didit-Kunden nicht zugestellt werden. Dieser Abschnitt beschreibt den Vertrag, den der Host erfüllt, sobald er live ist. | Methode | Pfad | Zweck | | - | - | - | | `GET` | `/identity` | Identität des Plattformbetreibers (wird auch unter `/trp/identity` bereitgestellt). | | `GET` | `/trp/identity/{profile_uuid}/` | Identität eines gehosteten VASP-Profils. | | `POST` | `/trp/inquiries/{profile_uuid}/` | Eine Transfer-Anfrage an ein gehostetes VASP senden. | | `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | Eine Transfer-Anfrage für eine Wallet eines gehosteten VASP senden (eine Travel Address pro Wallet). | | `POST` | `/trp/callbacks/resolution/{token}/` | Eine Anfrage auflösen, die **Didit** Ihnen gesendet hat (genehmigen oder ablehnen). | | `POST` | `/trp/callbacks/confirmation/{token}/` | Einen Transfer bestätigen oder abbrechen, den Didit für Sie genehmigt hat. | Zwei TRP-Header sind wichtig: * `api-version` - die TRP-Protokollversion, die Sie verwenden, zum Beispiel `3.2.1`. Erforderlich bei Anfragen und bei beiden Callbacks. * `request-identifier` - Ihre eindeutige ID für die Anfrage, die in den Antwort-Headern zurückgegeben wird. Erforderlich bei Anfragen und bei beiden Callbacks. Eine Anfrage an die Inquiry- oder Callback-Endpoints ohne beide Header liefert `400` zurück. Jede Antwort von Didit enthält `api-version: 3.2.1` und gibt Ihren `request-identifier` zurück. ### GET /identity Liefert die Identität des Plattformbetreibers. Es sind keine Header erforderlich. ```bash theme={null} curl https://trp.didit.me/identity ``` ```json theme={null} { "name": "Didit", "lei": "", "x509": "" } ``` ### GET /trp/identity/{profile_uuid}/ Liefert die Identität des VASP, mit dem Sie gleich einen Austausch durchführen. Prüfen Sie damit Name und LEI, bevor Sie personenbezogene Daten (PII) senden. Didit führt dieselbe Prüfung umgekehrt durch, wenn es den Austausch initiiert: Stimmt die Identität, die Ihr Endpoint meldet, nicht mit dem erwarteten LEI oder Namen überein, wird der Austausch abgebrochen. ```bash theme={null} curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/ ``` ```json theme={null} { "name": "Bene CASP GmbH", "lei": "5493001KJTIIGC8Y1R12", "x509": "" } ``` Liefert `404`, wenn das Profil nicht existiert oder sein Travel-Rule-Setup deaktiviert ist. ### POST /trp/inquiries/{profile_uuid}/ Senden Sie eine Transfer-Anfrage. Sie sind das auftraggebende VASP, der Didit-Kunde ist das begünstigte VASP. ```bash theme={null} curl -X POST https://trp.didit.me/trp/inquiries/11111111-2222-3333-4444-555555555555/ \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 7f6a1c1e-0a63-4b1f-9f6e-7dcd7c3f1a01" \ -d '{ "asset": { "dti": "X9J9K872S" }, "amount": 250000000000000000, "callback": "https://trp.yourvasp.example/callbacks/inquiry/abc123", "IVMS101": { "originator": { "originatorPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"] }, "beneficiary": { "beneficiaryPersons": [ { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } } ], "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"] } } }' ``` | Feld | Typ | Beschreibung | | - | - | - | | `asset.dti` | string | Pflichtfeld. Der Digital Token Identifier (ISO 24165) des übertragenen Assets. Eine Anfrage ohne ihn wird mit `400` beantwortet; das vor 3.2.0 verwendete `asset.slip0044` wird nicht gelesen. | | `amount` | number | Pflichtfeld. Ganzzahliger Betrag in der kleinsten Einheit des Assets (Basiseinheiten gemäß den Dezimalstellen des DTI). Jede JSON-Schreibweise einer ganzen Zahl wird akzeptiert, auch die Exponentialform, ebenso eine Zeichenkette aus Ziffern. Ein Bruchteil oder ein Betrag, der nicht gespeichert werden kann, führt zu `400`. | | `callback` | string | Pflichtfeld. Absolute öffentliche `http(s)`-URL auf Ihrer Seite, an die Didit die Entscheidung zur Anfrage sendet (`https` wird empfohlen). Ein Wiederholungsversuch mit derselben `callback` wird der Anfrage zugeordnet, die er wiederholt. | | `IVMS101` | object | Pflichtfeld. Die IVMS-101-Payload: `originator.originatorPersons` und `beneficiary.beneficiaryPersons` (Didit liest das erste `naturalPerson` jeder Liste; Daten juristischer Personen werden nicht gelesen), dazu die `accountNumber`-Wallet-Arrays. | Auf diesem Weg werden Assets über den DTI identifiziert, und ein DTI kennzeichnet einen Token in einer einzigen Blockchain. Didit unterstützt derzeit `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) und `USDC` in neun Netzwerken; weitere Assets kommen mit der Zeit hinzu. Die vollständige Liste finden Sie unter [TRP-Asset-Identifier](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#trp-asset-kennungen). Eine Anfrage, deren DTI Didit nicht kennt, wird trotzdem angenommen und dem begünstigten VASP mit dem DTI als Asset-Code angezeigt. Eine Antwort `200` bedeutet, dass die Anfrage zur Verarbeitung angenommen wurde. `400` bedeutet fehlende TRP-Header oder einen ungültigen Body. `404` bedeutet, dass das Profil (oder die Wallet einer per-Wallet-Travel-Address) unbekannt oder deaktiviert ist. `422` bedeutet, dass die Anfrage eine TRP-Erweiterung verwendet: Didit unterstützt keine, daher wird ein `api-extensions`-Header oder ein `extensions`-Schlüssel im Body abgelehnt. Ein erneutes Senden derselben `request-identifier` ist idempotent: Die ursprüngliche Anfrage wird wiederverwendet statt dupliziert. Didit erstellt danach den eingehenden Transfer in der Anwendung des Kunden und gleicht ihn mit dem Adressbuch und der Richtlinie des Kunden ab. Der Begünstigte wird über die Wallet zugeordnet, die eine Travel Address pro Wallet nennt. Andernfalls wird er über die erste Adresse in `IVMS101.beneficiary.accountNumber` zugeordnet, oder ohne eine solche über den Namen aus `beneficiaryPersons[0].naturalPerson` gegen die verifizierten Wallet-Einträge des Kunden. Die `200`-Antwort enthält die Entscheidung, wenn Didit sie sofort geben kann: * `{"approved": {"address": "...", "callback": "..."}}`, wenn die Anfrage automatisch genehmigt wurde. Didit sendet diese Genehmigung nicht zusätzlich an Ihre `callback`-URL. * `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}`, wenn die Anfrage weder den Begünstigten noch eine Adresse nennt. Geben Sie deshalb immer beides an. * `{"version": "3.2.1"}`, wenn die Entscheidung des Didit-Kunden aussteht. Die **Entscheidung** kommt dann später als POST an Ihre `callback`-URL, mit einem der beiden unten stehenden Bodies. ```json theme={null} { "approved": { "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/" } } ``` ```json theme={null} { "rejected": "Wallet ownership denied by beneficiary VASP" } ``` Die Genehmigung kann automatisch erfolgen, wenn das begünstigte VASP die automatische Annahme aktiviert und der Begünstigte einem verifizierten Wallet-Eintrag auf der Blockchain des Assets entspricht. Sie kann auch auf eine manuelle Prüfung oder auf einen Nachweis der Wallet-Inhaberschaft auf Seiten des Begünstigten folgen. Rechnen Sie daher zwischen Anfrage und Entscheidung mit Verzögerung. Eine Anfrage wird nie einer Wallet zugeordnet, die der Didit-Kunde als Wallet eines anderen VASP erfasst hat. Ihr VASP-Name aus `originatingVASP` ist das, was der Didit-Kunde als auftraggebendes VASP des Transfers sieht. Didit setzt keine Frist für eine von Ihnen gesendete Anfrage, und ein Didit-Kunde, der sie abbricht, sendet Ihnen keine Ablehnung. Setzen Sie daher ein eigenes Timeout. Nachdem Sie eine Genehmigung erhalten und den Transfer On-Chain ausführen, schließen Sie den Austausch ab, indem Sie per POST an die `approved.callback`-URL senden, die Sie erhalten haben: ```bash theme={null} curl -X POST "https://trp.didit.me/trp/callbacks/confirmation/{token}/" \ -H "Content-Type: application/json" \ -H "api-version: 3.2.1" \ -H "request-identifier: 0b8e2f4a-6c1d-4e9a-8f3b-2d7c5a1e9f60" \ -d '{ "txid": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060" }' ``` Senden Sie stattdessen `{ "canceled": "reason" }` an dieselbe URL, wenn Sie den Transfer abbrechen. `txid` setzt den Transfer auf Empfängerseite auf `FINISHED`; `canceled` setzt ihn auf `CANCELLED`. Beide Callbacks antworten mit `204`, sobald sie verarbeitet wurden. `404` bedeutet einen unbekannten Token oder einen Transfer, der nicht mehr auf diesen Callback wartet. `400` bedeutet einen Body, der keines der beiden Felder des Callbacks enthält. ### Von Didit gesendete Anfragen beantworten Wenn ein Didit-Kunde über TRP einen Transfer an Sie veranlasst, führt Didit folgende Schritte aus: 1. Didit ruft `/identity` am Root des Hosts Ihrer Anfrage-URL ab (`https://{your-host}/identity`) und prüft den gemeldeten Namen und die LEI gegen die Angaben, die der Kunde erwartet. Stammt die Route aus dem Verzeichnis von Didit, muss Ihr `/identity` die LEI dieses Verzeichniseintrags melden. 2. Didit sendet per POST eine Transfer-Anfrage an Ihre Anfrage-URL, mit demselben Body-Aufbau wie oben: `asset.dti`, ein `amount` als JSON-Zahl in Basiseinheiten, ein `callback` und die `IVMS101`-Payload. Nur eine Antwort mit `2xx` gilt als zugestellt. Eine `3xx`-Antwort wird abgelehnt, weil Weiterleitungen nicht verfolgt werden. Jede andere Antwort wird mit Ihrem Statuscode auf der Transfer-Zeitleiste des Kunden vermerkt, zum Beispiel `refused by counterparty (HTTP 403): ...`. Beide Aufrufe enthalten die beiden TRP-Header, und Didit folgt bei ihnen keinen HTTP-Weiterleitungen. Stellen Sie `/identity` und die Anfrage-URL deshalb direkt bereit. Wenn `/identity` nicht erreichbar ist, keine LEI meldet, eine andere LEI als die vom Kunden angegebene meldet oder einen Namen meldet, der nicht übereinstimmt, stoppt Didit, bevor die Anfrage gesendet wird, und der Transfer des Kunden wechselt zu `COUNTERPARTY_VASP_NOT_REACHABLE`. Schlägt der anschließende POST der Anfrage fehl oder beantwortet Ihr Endpoint ihn mit einem Status `4xx` oder `5xx`, wechselt der Transfer ebenfalls zu `COUNTERPARTY_VASP_NOT_REACHABLE`. Der `callback` in dieser Anfrage verweist auf den Resolution-Endpoint von Didit (`/trp/callbacks/resolution/{token}/`). Antworten Sie, indem Sie per POST dieselben Resolution-Objekte senden, die Didit verwendet: `{ "approved": { "address": "...", "callback": "..." } }` zur Genehmigung (Ihr `callback` ist die Stelle, an die Didit die On-Chain-Bestätigung sendet) oder `{ "rejected": "reason" }` zur Ablehnung. Senden Sie dabei beide TRP-Header mit. Didit antwortet mit `204`, sobald die Antwort verarbeitet wurde, mit `404`, wenn der Transfer nicht mehr auf eine Auflösung wartet, und mit `400` bei einer Genehmigung ohne `address` oder wenn der `callback` keine öffentliche `http(s)`-URL ist, die Didit aufrufen wird. Nach der Genehmigung wechselt der Transfer auf Didit-Seite zu `COMPLETED`. Sobald der Kunde den On-Chain-Hash meldet, sendet Didit per POST `{ "txid": "..." }` an den von Ihnen angegebenen Bestätigungs-Callback (oder `{ "canceled": "reason" }`, falls der Transfer vorher storniert wird). > [!NOTE] > > Callback-Token sind einmalig verwendbare, nicht erratbare Geheimnisse, die pro Transfer erzeugt werden. Behandeln Sie die vollständigen Callback-URLs als vertraulich. Beachten Sie außerdem, dass eine Auflösung nur akzeptiert wird, solange der Transfer noch auf eine Auflösung wartet. ## E-Mail-Abholung Wenn kein Protokollkanal Sie erreicht und der Didit-Kunde Ihre Compliance-E-Mail-Adresse angegeben hat, greift Didit auf E-Mail zurück: Ihr Compliance-Ansprechpartner erhält eine Nachricht, die die Auftraggeber-VASP nennt, mit einem einmaligen, sicheren Abholungslink. Es sind kein Konto, kein API-Schlüssel und keine Integration nötig, denn das Link-Token dient als Authentifizierung. Beim Öffnen des Links wird der ausstehende Austausch angezeigt. Die zugrunde liegende API, die die gehostete Seite für Sie ansteuert, ist öffentlich: ```bash theme={null} curl https://verification.didit.me/v3/travel-rule/pickup/{token}/ ``` ```json theme={null} { "originator_vasp_name": "Origin CASP SL", "amount": "0.250000000000000000", "currency": "ETH", "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "status": "AWAITING_COUNTERPARTY" } ``` `amount` ist der gespeicherte Dezimalwert unverändert und enthält daher alle 18 Dezimalstellen. ```bash theme={null} 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" }' ``` `decision` ist `accept` oder `decline`. Bei Annahme geben Sie den Namen des Begünstigten so an, wie er in Ihren Unterlagen steht, damit die Auftraggeberseite den Namensabgleich durchführen kann. Alternativ senden Sie Ihre vollständige IVMS 101-Antwort als `ivms_response`. In diesem Fall hat der dort enthaltene Name des Begünstigten Vorrang. Bei Ablehnung können Sie einen `decline_reason` angeben (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` oder `other`). Außerdem können Sie ein `decline_detail` mit bis zu 512 Zeichen angeben, das bei `other` erforderlich ist. Eine Annahme ohne `beneficiary_name` wird als Abweichung erfasst, wenn der Absender einen Namen des Begünstigten übermittelt hat, es sei denn, der Absender hat den Namensabgleich deaktiviert. Die Antwort ist das resultierende `{"status": "..."}`: `COMPLETED`, wenn die Namen übereinstimmen, `COUNTERPARTY_MISMATCHED_DATA`, wenn sie nicht übereinstimmen, oder `COUNTERPARTY_VASP_GENERAL_DECLINE` nach einer Ablehnung. Sie können nur einmal antworten, solange der Transfer auf Sie wartet. Nach Ihrer Antwort, nach einer Stornierung des Transfers oder nach Ablauf seiner Bestätigungsfrist liefern beide Endpoints `410` zurück. Ein unbekanntes Token liefert `404`. Die Anfrage zeigt die vom Absender geteilten Auftraggeberfelder sowie einen IVMS 101-`ivms_request` in der Sprache Ihrer Jurisdiktion. Solange Sie nicht geantwortet haben, werden Sie 72, 24 und 6 Stunden vor der Frist erinnert. ## Sunrise: Transfers, die vor dem Austausch abgewickelt wurden Erreicht ein Transfer die Wallet eines Didit-Kunden, bevor ein Travel-Rule-Austausch stattgefunden hat, weil zu diesem Zeitpunkt kein gemeinsamer Kanal existierte, können die Daten auch nach der Abwicklung noch zugestellt werden. Senden Sie dem Didit-Kunden (Ihrer Begünstigten-Gegenpartei) die Travel-Rule-Payload über Ihren üblichen Kanal und bitten Sie ihn, sie zu registrieren. Er ruft [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/de/transaction-monitoring/travel-rule#nachträgliche-sunrise-registrierung-nach-der-einzahlung) mit der Blockchain, der `txid`, der Adresse, dem Betrag, der Währung und Ihren Auftraggeberdaten der Einzahlung auf. Fügen Sie Ihre VASP-Identität (Name, LEI und Travel Address) als `originating_vasp` in diese Payload ein, damit der Transfer des Didit-Kunden festhält, wer die Einzahlung gesendet hat. Die Angaben bleiben bei diesem Transfer und erstellen oder ändern niemals Ihren [Verzeichniseintrag](#aufnahme-ins-didit-vasp-verzeichnis). Die LEI muss eine gültige, 20 Zeichen lange LEI sein, und die Travel Address muss gültig sein. Andernfalls wird die Registrierung abgelehnt. ## Aufnahme ins Didit-VASP-Verzeichnis Didit pflegt ein VASP-Verzeichnis, das beim Routing ausgehender Transfers der Kunden von Didit abgefragt wird. Die Einträge stammen aus diesen Quellen: * Das vorläufige MiCA-Register der ESMA für Anbieter von Kryptowerte-Dienstleistungen, das wöchentlich ausgelesen wird: Ihr Name, Ihre LEI und Ihr Herkunftsmitgliedstaat, sofern Sie dort gelistet sind. * Das öffentliche TRISA-Verzeichnis, das wöchentlich ausgelesen wird: wer Sie sind, Ihr Land und Ihr TRISA-Eintrag. * Das globale LEI-Register, das Ihre LEI, weitere rechtliche Namen und Ihr Land ergänzt. * Die Zuordnung durch Blockchain-Analytik, wenn eine Ziel-Wallet Ihrer Börse oder Ihrem Verwahrungsdienst zugeordnet wird: Didit ergänzt Ihren Eintrag oder gleicht ihn ab und speichert den zugeordneten Namen als Alias. * Mitarbeitende von Didit, die Einträge kuratieren: geprüfte Routing-Kennungen und Netzwerkeinträge, Compliance-Kontakte, Aliase sowie Marken mit ihren Rechtsträgern. Was ein Kunde von Didit über Sie meldet, etwa ein `originating_vasp` bei einer Sunrise-Registrierung oder eine Travel Address bei einem Transfer, gilt nur für den Transfer dieses Kunden und ändert Ihren Eintrag nie. Transferanfragen, die Sie an einen Didit-Kunden senden, legen Ihren Eintrag ebenfalls nicht an und aktualisieren ihn auch nicht. Ihr Eintrag leitet einen Transfer an Sie weiter, wenn er einen verifizierten `TRP`-Endpoint, einen Netzwerkeintrag, den der Absender nutzen kann, oder einen Compliance-Kontakt für den E-Mail-Fallback enthält. Eine Compliance-Adresse auf einer Ihrer eigenen Domains, die über ihren Antwort-Link auf eine Anfrage antwortet, wird zu einem Kontakt, den jeder Didit-Kunde nutzen kann. Solange Ihr Eintrag keine Route enthält, erreicht Sie ein Didit-Kunde nur über die Felder, die er bei jedem Transfer übergibt: Ihre Travel Address, Ihre Netzwerkkennung (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id` oder `counterparty_sygna_vasp_code`) oder Ihre Compliance-E-Mail (`counterparty_vasp_email`). Damit Sie schon heute erreichbar sind, teilen Sie Ihre Travel Address, Ihre Netzwerkkennung oder Ihre Compliance-E-Mail mit den Didit-Kunden, mit denen Sie zusammenarbeiten. ## Checkliste für Gegenpartei-VASPs * **Sie betreiben TRP bereits**: Teilen Sie Ihre Travel Address und Ihre LEI mit dem Didit-Kunden. Seine Transfers in `BTC`, `ETH` und `USDC` kommen als standardmäßige TRP-Anfragen an Ihrem Endpoint an. Antworten Sie direkt in der Antwort auf die Anfrage. Eine spätere Antwort setzt den öffentlichen TRP-Host von Didit voraus, der noch nicht live ist. * **Sie nutzen GTR, TRUST oder VerifyVASP**: Teilen Sie Ihre Netzwerkkennung. Transfers kommen über dieses Netzwerk an, wenn der Didit-Kunde dort eine eigene Mitgliedschaft hat. Didit liest Ihre Antwort bei GTR oder VerifyVASP direkt aus dem Netzwerk, bei TRUST jedoch nicht. Veröffentlichen Sie deshalb zusätzlich einen TRP-Endpoint, wenn ein Austausch über TRUST abgeschlossen werden muss. [Travel-Rule-Netzwerke](https://docs.didit.me/de/transaction-monitoring/travel-rule-networks.md) beschreibt, wann sich das ändert. * **Sie nutzen Sygna Bridge**: Teilen Sie Ihren Sygna-VASP-Code. Wenn der Didit-Kunde eine eigene Sygna-Mitgliedschaft hat, schließt Ihre Berechtigungsantwort den Transfer ab oder lehnt ihn ab, sobald Didit sie per Polling liest. * **Sie haben noch keinen Protokollkanal**: Geben Sie dem Didit-Kunden eine überwachte Compliance-E-Mail. Sie erhalten dann Pickup-Links und können über die gehostete Seite ohne jede Integration antworten. * **Ein Transfer ist bereits abgewickelt**: Übermitteln Sie die Daten über die [Sunrise-Registrierung](#sunrise-transfers-die-vor-dem-austausch-abgewickelt-wurden) beim Didit-Kunden. * **Sie möchten auch an Didit-VASPs senden**: Fragen Sie Ihre Gegenpartei nach ihrer Travel Address aus den Travel-Rule-Einstellungen bei Didit. Rufen Sie dann [POST /trp/inquiries](#post-/trp/inquiries//) auf, sobald der öffentliche TRP-Host von Didit live ist. ## Nächste Schritte > [card] [Travel Rule](https://docs.didit.me/de/transaction-monitoring/travel-rule.md) > > Das Produkt für Kunden: Lebenszyklus, Einstellungen, Netzwerke und die /v3/-API. > [card] [Widget für Wallet-Eigentumsnachweise](https://docs.didit.me/de/transaction-monitoring/wallet-ownership-widget.md) > > Wie Eigentumsnachweise auf der Begünstigtenseite erhoben werden, wenn es sich um eine selbstverwahrte Wallet handelt. > [card] [Sunrise-Registrierung](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#nachträgliche-sunrise-registrierung-nach-der-einzahlung) > > Registrierung von Travel-Rule-Daten für Einzahlungen, die bereits On-Chain abgewickelt wurden. > [card] [Webhooks](https://docs.didit.me/de/integration/webhooks.md) > > Wie Didit-Kunden auf ihrer Seite jeden Statuswechsel eines Austauschs beobachten. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.