Zum Hauptinhalt springen
Diese Seite richtet sich an die Gegenseite eines Didit Travel Rule-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:
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 entgegennehmen, sobald der öffentliche TRP-Host von Didit aktiv ist (er antwortet noch nicht, siehe TRP-Endpoints), oder nach der Abwicklung als Sunrise-Registrierung. 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 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. 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). 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:
{profile_uuid} identifiziert das gehostete VASP-Profil. Senden Sie Ihre Transferanfragen per POST an diese URL und fragen Sie vorher den passenden Identity-Endpoint 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.
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.
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.

GET /trp/identity//

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.
Liefert 404, wenn das Profil nicht existiert oder sein Travel-Rule-Setup deaktiviert ist.

POST /trp/inquiries//

Senden Sie eine Transfer-Anfrage. Sie sind das auftraggebende VASP, der Didit-Kunde ist das begünstigte VASP.
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. 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.
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:
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).
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:
amount ist der gespeicherte Dezimalwert unverändert und enthält daher alle 18 Dezimalstellen.
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/ 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. 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 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 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 auf, sobald der öffentliche TRP-Host von Didit live ist.

Nächste Schritte

Travel Rule

Das Produkt für Kunden: Lebenszyklus, Einstellungen, Netzwerke und die /v3/-API.

Widget für Wallet-Eigentumsnachweise

Wie Eigentumsnachweise auf der Begünstigtenseite erhoben werden, wenn es sich um eine selbstverwahrte Wallet handelt.

Sunrise-Registrierung

Registrierung von Travel-Rule-Daten für Einzahlungen, die bereits On-Chain abgewickelt wurden.

Webhooks

Wie Didit-Kunden auf ihrer Seite jeden Statuswechsel eines Austauschs beobachten.
Zuletzt geändert am 7. November 2026