Travel Rule Netzwerke: Status und Anbindung

Ein Travel Rule-Austausch erreicht die VASP der Gegenpartei über einen Kanal. Drei Kanäle erfordern keine Mitgliedschaft: INTERNAL zwischen zwei Didit-Kunden, das offene Travel Rule Protocol (TRP) und EMAIL. Die vier Netzwerk-Kanäle (GTR, TRUST, VERIFYVASP, SYGNA) erfordern auf der sendenden Seite eine Mitgliedschaft in diesem Netzwerk. Diese Seite beschreibt, was jeder Kanal heute leistet, damit Sie wissen, welche Gegenparteien erreichbar sind, bevor Sie sich auf eine Route verlassen.

​

Status auf einen Blick

„Funktioniert“ bedeutet, dass Didit den Austausch sendet und die Antwort liest. „Implementiert, noch nicht im Live-Betrieb nachgewiesen“ bedeutet, dass Didit den Austausch sendet und die Antwort des Netzwerks liest, aber noch kein Austausch über dieses Netzwerk mit einem Live-Netzwerk abgeschlossen wurde. Keiner dieser Status bedeutet, dass eine bestimmte Gegenpartei erreichbar ist. Das hängt von der Gegenpartei ab. Die routes jeder VASP im Verzeichnis geben an, welche Kanäle Ihre Anwendung dafür derzeit nutzen kann. EMAIL überträgt nur Ihre ausgehenden Anfragen. Die Antwortseite ist der Ort, an dem eine Gegenpartei auf eine dieser Anfragen antwortet. Keine VASP kann Ihnen einen Transfer per E-Mail senden. Bevor Sie sich auf GTR, VerifyVASP, Sygna Bridge oder TRUST verlassen, verbinden Sie Ihre Mitgliedschaft und führen Sie einen ersten Austausch mit einer Gegenpartei durch, die Sie kennen.

​

Kanäle ohne Mitgliedschaft

​

INTERNAL

Beide VASPs laufen auf Didit, daher wird der Austausch innerhalb der Plattform abgewickelt, ohne ausgehenden Aufruf. Der Empfänger muss ein aktiver Didit-Kunde mit aktivierter Travel Rule sein, der die Kontrolle über die Ziel-Wallet nachgewiesen hat, entweder mit einer signierten Nachricht oder einer Testeinzahlung. Eine selbst angegebene, nur per Screenshot belegte oder nicht verifizierte Wallet erhält nichts. Siehe Transaktion senden.

​

TRP

Didit unterstützt das Travel Rule Protocol nativ. Ein Transfer läuft über TRP, wenn er die Travel Address der Gegenpartei enthält, der Adressbucheintrag der Ziel-Wallet eine solche speichert oder die Gegenpartei im Verzeichnis mit einem TRP-Endpoint aufgelöst wird, den das Verzeichnis verifiziert hat. Jeder TRP-Austausch, der nicht in einem einzigen Aufruf abgeschlossen wird, benötigt den öffentlichen TRP-Host von Didit, auf den die Travel Addresses zeigen:

• Senden. Eine Gegenpartei, die Ihre Anfrage sofort in ihrer Antwort beantwortet, schließt den Transfer ab oder lehnt ihn ab. Eine Gegenpartei, die später antwortet, sendet ihre Antwort an den TRP-Host von Didit. Dieser Austausch kann daher erst abgeschlossen werden, wenn der Host live ist. Der Transfer wartet und läuft zum Fristende ab. Didit sendet die Anfrage einmal und wiederholt sie nicht. Wenn der TRP-Host der Gegenpartei nicht erreichbar ist oder die Anfrage ablehnt, wird der Transfer sofort zu COUNTERPARTY_VASP_NOT_REACHABLE. Sie können ihn dann mit action: "resend" erneut senden.
• Empfangen. Andere VASPs erreichen Sie über Ihre Travel Address auf diesem Host. Daher kann keine Gegenpartei Ihnen eine TRP-Anfrage senden, bevor der Host live ist.

Der öffentliche TRP-Host von Didit stellt diese Endpoints noch nicht bereit. Travel-Rule-Interoperabilität dokumentiert die Endpoints, die Gegenparteien aufrufen, sobald dies der Fall ist.

​

EMAIL

Wenn kein Protokoll die Gegenpartei erreicht, sendet Didit an deren Compliance-Adressen einen einmaligen Link zu einer gehosteten Seite, auf der sie annehmen oder ablehnen können. Auf deren Seite ist kein Konto und keine Integration erforderlich. Siehe E-Mail-Abholung.

​

Netzwerkanbindungen

​

Mit eigener Mitgliedschaft

Verbinden Sie Ihre eigene Mitgliedschaft im Bereich Marketplace der Konsole (Kategorie Travel Rule networks). Ihre Transfers laufen dann unter Ihrer eigenen Netzwerkidentität, und eine verbundene Mitgliedschaft hat immer Vorrang vor der Mitgliedschaft von Didit. GTR, TRUST und VerifyVASP akzeptieren außerdem optional ein Client-Zertifikat für gegenseitiges TLS, einen Client-Schlüssel und ein CA-Bundle (PEM), für eine Mitgliedschaft, die gegenseitiges TLS oder eine private CA nutzt.

• Didit sendet im Hintergrund und wiederholt den Versuch bei einem Netzwerk, das nicht antwortet oder mit einem vorübergehenden Fehler antwortet (keine rechtzeitige Antwort, fehlgeschlagene Verbindung, HTTP 408, 429 oder 5xx): nach 30 Sekunden, dann nach 2, 10, 30 und 60 Minuten. Nach dem sechsten fehlgeschlagenen Versuch wechselt der Transfer in den Status COUNTERPARTY_VASP_NOT_REACHABLE. Eine Ablehnung, etwa eine andere 4xx-Antwort oder eine Weiterleitung, wird nicht wiederholt: Der Transfer wechselt sofort in den Status COUNTERPARTY_VASP_NOT_REACHABLE.
• Ein Transfer, dessen Antwort nie eintrifft, wartet im Status AWAITING_COUNTERPARTY, bis confirmation_timeout_hours verstrichen ist. Danach läuft er ab, und Ihr timeout_outcome wird angewendet.
• Der Empfang eines Transfers, den ein anderes VASP über GTR, VerifyVASP oder Sygna Bridge an Sie sendet, ist noch nicht aktiviert. Didit aktiviert ihn pro Netzwerk. Bis dahin können diese Netzwerke keinen Transfer an Sie zustellen.
• Beim Speichern einer Mitgliedschaft wird 400 zurückgegeben, wenn ihr Teilnehmercode der eigene Code von Didit in diesem Netzwerk ist oder ein Code, den bereits eine andere Anwendung belegt.
• Netzwerkanfragen übermitteln Ihre Zugangsdaten nur an den Host dieses Netzwerks und folgen niemals einer Weiterleitung. Das TRUST-Datenpaket geht ohne Ihren API-Schlüssel, Ihre Mitglieds-ID und Ihr Client-Zertifikat an den Begünstigten.

​

Über die Mitgliedschaft von Didit

Sobald Didit eine Netzwerkmitgliedschaft hält, kann ein Kunde ohne eigene Mitgliedschaft das Netzwerk als eigener Teilnehmer über die Mitgliedschaft von Didit erreichen, mit dem Teilnehmercode, den ihm das Netzwerk zuweist. Ausgehende Nachrichten nennen Ihren Code, niemals den von Didit. Dies wird nur für GTR und Sygna Bridge angeboten. TRUST nimmt Mitglieder immer nur einzeln auf, ein VASP nach dem anderen, und eine VerifyVASP-Enclave bedient genau ein VASP. Beide Netzwerke sind daher nur mit Ihrer eigenen Mitgliedschaft erreichbar. Der Beitritt erfolgt in drei Schritten: Beantworten Sie den Due-Diligence-Fragebogen von Didit für Netzwerke, lassen Sie Didit ihn genehmigen und beantragen Sie anschließend die Netzwerkanbindung. Didit registriert Sie beim Netzwerk, und Ihr Teilnehmer wird aktiv, sobald das Netzwerk ihm einen Code zuweist. Dieser Ablauf ist noch nicht geöffnet. Solange das so ist, antwortet das Speichern oder Einreichen des Fragebogens und das Anfordern eines Netzwerks mit 403 und code: travel_rule_platform_networks_disabled, und GET /v3/travel-rule/networks/ meldet platform_networks_enabled: false.

​

Den Status Ihrer Anwendung auslesen

GET /v3/travel-rule/settings/ und GET /v3/travel-rule/networks/ geben networks zurück, mit den Schlüsseln gtr, trust, verifyvasp und sygna. Jeder Eintrag zeigt, was das Netzwerk für Ihre Anwendung heute leisten kann: mode fasst den Status als own, didit, off oder unavailable zusammen. Zuerst wird Ihre eigene Mitgliedschaft geprüft, dann disabled_networks, dann die Mitgliedschaft von Didit. Heute zeigt ein Netzwerk own_membership an, sobald Sie Ihre eigene Mitgliedschaft verbunden haben. Andernfalls zeigen GTR und Sygna Bridge didit_onboarding an (unavailable mit sandbox_application bei einer Sandbox-Anwendung), und TRUST und VerifyVASP zeigen unavailable mit own_membership_only an, auch in der Sandbox. Eine Sandbox-Anwendung sendet niemals über ein Netzwerk, auch dann nicht, wenn Ihre eigene Mitgliedschaft verbunden ist und own_membership anzeigt: Ihre Transfers gehen an den Didit Test VASP. connected bedeutet, dass Ihre gespeicherte Mitgliedschaft die lokale Validierung bestanden hat, nicht, dass ein Austausch erfolgreich war. Der erste Live-Austausch bestätigt dies gegenüber dem Netzwerk.

​

Was sich ändert, wenn ein Netzwerk live geht

Diese Seite, der Status networks und jede Verzeichnisroute ändern sich gemeinsam. An Ihrer Integration ändert sich nichts: Ein Transfer wird über das Netzwerk geroutet, sobald Ihre Anwendung dort eine Mitgliedschaft hat, und zwar in der Reihenfolge der Übertragungswege, die unter So routet Didit einen Austausch beschrieben ist. Um ein Netzwerk anzufragen, das Didit noch nicht erreicht, verwenden Sie die Kachel Zugang anfragen im Marketplace. Jede Anfrage zeigt ihren Status (Offen, Kontaktiert, In Bearbeitung, Live oder Abgelehnt) mit der neuesten Notiz von Didit. Wenn Didit den Status oder die Notiz ändert, sendet Didit eine E-Mail an das Teammitglied, das die Anfrage gestellt hat, solange das Teammitglied noch Mitglied Ihrer Organisation ist. Eine mit einem API-Schlüssel gestellte Anfrage erhält keine E-Mail, daher verfolgen Sie sie im Marketplace.

​

Nächste Schritte