> ## 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. # Wallet-Eigentum bestätigen API: Travel Rule Begünstigter > Bestätigen oder ablehnen Sie mit Didit, dass Ihr Kunde die Begünstigten-Wallet einer eingehenden Travel-Rule-Transaktion kontrolliert. API-Prompt zur Bestätigung der Wallet-Inhaberschaft Prompt in die Zwischenablage kopieren \

\`Confirm or deny wallet ownership on a Travel Rule transfer waiting on the beneficiary side - typically the beneficiary leg of an INTERNAL-rail transfer whose wallet address book entry has not been ownership-verified yet, a transfer whose counterparty wallet was declared self-hosted (counterparty.payment_method.method_type: "unhosted_wallet"), an inbound transfer in ON_HOLD, or an inbound TRP inquiry a compliance officer resolves by hand.

Endpoint:
POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/

Authentication:
Use the x-api-key header with my Didit API key. {transaction_id} is the Didit transaction uuid of the transfer your own application holds: on an INTERNAL-rail transfer that is your (beneficiary) side; on a declared self-hosted wallet it is the transaction you created, outbound or inbound.

Request body:
\{"confirmed": true}   or   {"confirmed": false}
Optionally {"confirmed": true, "wallet_address": "0x..."} - the payment address to return to the counterparty on an inbound TRP transfer.
On a declared self-hosted wallet transfer with no counterparty wallet on it, "wallet_address" supplies the wallet to verify; if neither the transfer nor the request names one, the request is rejected with 400.

Accepted states (anything else -> 409 "Transfer is not awaiting ownership confirmation."):
\- UNCONFIRMED_OWNERSHIP, in either direction.
\- ON_HOLD on an inbound transfer.
\- UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA on an inbound TRP transfer.

Behavior on a transfer Didit created itself (INTERNAL rail, sunrise registration, declared self-hosted wallet):
\- confirmed: true - marks the matching wallet address book entry ownership-verified, then runs the beneficiary name match on both sides: COMPLETED on a pass, COUNTERPARTY_MISMATCHED_DATA on a fail.
An inbound transfer whose deposit already settled then moves on to FINISHED.
\- confirmed: true on a declared self-hosted wallet - records that the customer verified who controls the counterparty wallet and completes the transfer (COMPLETED), outbound or inbound; an inbound deposit whose on-chain hash is already known moves on to FINISHED. The wallet is the counterparty's: the destination of a withdrawal, the originator's source wallet of a deposit. If it is not in the wallet address book yet, it is added as ownership-verified under the counterparty's name; if the book already holds it under a different holder name, the transfer goes to COUNTERPARTY_MISMATCHED_DATA.
\- confirmed: false - moves both sides of the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.
\- Resolving an inbound ON_HOLD with no matching entry, or confirming a declared self-hosted wallet, creates the entry from the transfer's wallet address and marks it verified.

Behavior on an inbound TRP transfer (answering the counterparty's inquiry):
\- confirmed: true - needs a payment address, taken from the request's wallet_address, then the matched entry, then beneficiary_data.wallet_address.
Didit creates or verifies the entry, posts the inquiry-resolution callback to the counterparty, sets ownership_confirmed and moves the transfer to COMPLETED.
\- confirmed: false - posts a declined resolution and moves the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.

Transfers a network delivered (GTR or Sygna Bridge):
\- An inbound transfer that waits for your review (UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA) is decided here: confirmed: true approves it (send wallet_address when the transfer names none), confirmed: false declines it. Didit answers the network after the response, with retries; the response's delivery field shows that answer.
\- VerifyVASP takes its answer when it asks, so a VerifyVASP transfer that would need your review is declined at once and cannot be decided here.
\- Receiving over a network is switched on by Didit per network, and none is switched on today.

What to read from the response:
\- The full transfer object. originator_data/beneficiary_data stay masked on inbound transfers (data_masked: true) until ownership is confirmed; data_unmasked then records when, why and by whom. data_match and mismatched_fields name the fields that differ after a mismatch.

Alternative: instead of this API call, send the end customer through the hosted wallet-ownership widget (POST /v3/travel-rule/widget-session/) and let them prove control cryptographically.

Failure modes:
\- 400 - on an inbound TRP approval with no payment address available: {"wallet_address": ["wallet_address is required to approve."]}.
\- 409 - the transfer is not in one of the accepted states, no entry in your wallet address book matches the transfer's wallet address (an inbound TRP approval, and an inbound ON_HOLD transfer that carries beneficiary_data.wallet_address, and a declared self-hosted wallet, create the missing entry instead), an INTERNAL transfer from another Didit customer needs a control proof (signed message or test deposit) first, or a network transfer was already answered over its network (a VerifyVASP transfer, or a GTR or Sygna Bridge transfer already decided).
\- 502 - the counterparty's TRP inquiry-resolution callback could not be delivered; the transfer keeps its current status.
\- 404 - unknown transaction or no Travel Rule transfer attached.

Full guide: /transaction-monitoring/travel-rule#confirming-wallet-ownership.`

\
Einfügen in ## Selbstverwahrte WalletsWurde die Wallet der Gegenpartei als selbstverwahrt deklariert (`counterparty.payment_method.method_type: "unhosted_wallet"`), wartet der Transfer im Status `UNCONFIRMED_OWNERSHIP`. Wenn Sie diesen Endpoint mit `confirmed: true` aufrufen, wird erfasst, dass Ihr Kunde verifiziert hat, wer diese Wallet kontrolliert, und der Transfer wird abgeschlossen (`COMPLETED`). Das gilt sowohl für ausgehende Auszahlungen als auch für eingehende Einzahlungen. Bei einer eingehenden Einzahlung, deren On-Chain-Hash bereits bekannt ist, wechselt der Transfer zu `FINISHED`.Die verifizierte Wallet gehört der Gegenpartei: Bei einer ausgehenden Auszahlung ist es das Ziel, bei einer eingehenden Einzahlung die Quelle (die Wallet des Auftraggebers). Didit fügt sie dem Wallet-Adressbuch als hinsichtlich der Inhaberschaft verifiziertes Wallet unter dem Namen der Gegenpartei hinzu. Sie wird daher mit dem Namen der Gegenpartei abgeglichen, bei einer Einzahlung mit dem Namen des Auftraggebers. Ist im Adressbuch für diese Wallet bereits ein anderer Inhabername hinterlegt, wechselt der Transfer stattdessen zu `COUNTERPARTY_MISMATCHED_DATA`.Nennt der Transfer überhaupt keine Wallet der Gegenpartei, übergeben Sie `wallet_address` im Anfragekörper. Enthalten weder der Transfer noch die Anfrage eine Adresse, wird die Anfrage mit `400` abgelehnt.Mit `confirmed: false` wird der Transfer abgelehnt (`COUNTERPARTY_VASP_GENERAL_DECLINE`). ## OpenAPI ````yaml de/openapi-25.json POST /v3/transactions/{transaction_id}/travel-rule/ownership/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/transactions/{transaction_id}/travel-rule/ownership/: post: tags: - Travel Rule summary: Wallet-Inhaberschaft bestätigen oder ablehnen description: >- Lösen Sie einen Transfer auf, der auf die Wallet-Inhaberschaft wartet: Rufen Sie ihn auf Ihrer eigenen Seite des Transfers auf, wenn er UNCONFIRMED_OWNERSHIP ist oder wenn es sich um einen eingehenden Transfer in ON_HOLD handelt. Das Bestätigen markiert den passenden Eintrag im Wallet-Adressbuch als hinsichtlich der Wallet-Inhaberschaft verifiziert (für einen eingehenden ON_HOLD-Transfer ohne Eintrag erstellt Didit einen aus beneficiary_data.wallet_address) und führt den Namensabgleich des Begünstigten auf beiden Seiten des Transfers aus; eine Ablehnung lehnt beide Seiten ab. Ein eingehender Transfer, dessen Einzahlung bereits abgewickelt wurde, wechselt zu FINISHED, wenn der Abgleich erfolgreich ist. Wenn die Gegenpartei-Wallet als selbstverwahrte Wallet deklariert wurde (counterparty.payment_method.method_type: unhosted_wallet), erfasst das Bestätigen, dass der Kunde verifiziert hat, wer diese Wallet kontrolliert, und schließt den Transfer in beiden Richtungen ab (COMPLETED) oder setzt ihn auf FINISHED für eine eingehende Einzahlung, deren On-Chain-Hash bereits bekannt ist. Die verifizierte Wallet ist die der Gegenpartei: das Ziel einer ausgehenden Abhebung oder die Quelle (Wallet des Auftraggebers) einer eingehenden Einzahlung. Befindet sie sich noch nicht in Ihrem Wallet-Adressbuch, fügt Didit sie als hinsichtlich der Wallet-Inhaberschaft verifiziert unter dem Namen der Gegenpartei hinzu; enthält das Adressbuch sie bereits unter einem anderen Inhabernamen, wechselt der Transfer zu COUNTERPARTY_MISMATCHED_DATA. Bei einem eingehenden TRP-Transfer in UNCONFIRMED_OWNERSHIP, ON_HOLD oder COUNTERPARTY_MISMATCHED_DATA sendet Didit stattdessen Ihre Entscheidung an den auftraggebenden VASP: Eine Genehmigung gibt die Zahlungsadresse zurück (wallet_address oder die Adresse des übereinstimmenden Eintrags) und setzt den Transfer auf COMPLETED; eine Ablehnung lehnt ihn ab. Derselbe Aufruf entscheidet auch über einen eingehenden Transfer, den eine GTR- oder Sygna-Bridge-Gegenpartei gesendet hat und der auf Ihre Überprüfung wartet (`UNCONFIRMED_OWNERSHIP`, `ON_HOLD` oder `COUNTERPARTY_MISMATCHED_DATA`): `confirmed: true` genehmigt ihn (übergeben Sie `wallet_address`, wenn der Transfer keine angibt) und `confirmed: false` lehnt ihn ab; dem Netzwerk wird nach der Antwort mit Wiederholungsversuchen geantwortet. VerifyVASP nimmt seine Antwort direkt bei der Anfrage entgegen, sodass ein VerifyVASP-Transfer, der Ihre Prüfung erfordern würde, sofort abgelehnt wird und nicht später entschieden werden kann. operationId: confirmTravelRuleOwnership parameters: - name: transaction_id in: path required: true description: >- Stabile UUID von Didit der Transaktion, die Ihre Anwendung für diesen Transfer hält: die Transaktion der Begünstigtenseite bei einem Transfer über die Schiene INTERNAL oder die von Ihnen erstellte Transaktion (ausgehend oder eingehend), wenn die Wallet der Gegenpartei als selbstverwahrt deklariert wurde. schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/TravelRuleOwnershipConfirmRequest' example: confirmed: true responses: '200': description: >- Der aktualisierte Transfer. Bei einem eingehenden Transfer bleiben die originator_data/beneficiary_data der Gegenpartei maskiert (`data_masked: true`), bis die Eigentümerstruktur bestätigt ist; danach zeichnet `data_unmasked` auf, wann, warum und durch wen dies geschah. content: application/json: schema: $ref: '#/components/schemas/TravelRuleTransferDetail' '400': description: >- Validierungsfehler: confirmed fehlt, eine eingehende TRP-Genehmigung hat keine wallet_address und keine Adresse als Fallback, oder `confirmed: true` bei einem deklarierten Transfer zu einer selbstverwahrten Wallet, der keine Gegenpartei-Wallet benennt und bei dem keine `wallet_address` übermittelt wurde. content: application/json: examples: No payment address: value: wallet_address: - wallet_address is required to approve. '404': description: >- Unbekannte Transaktion oder die Transaktion weist keinen Travel-Rule-Transfer auf. '409': description: >- Der Transfer wartet nicht auf die Eigentumsbestätigung, kein Eintrag im Wallet-Adressbuch stimmt mit der Wallet der Gegenpartei überein, ein INTERNAL-Transfer von einem anderen Didit-Kunden erfordert einen Kontrollnachweis (eine signierte Nachricht oder eine Testeinzahlung), bevor er bestätigt werden kann, oder ein Netzwerk-Transfer wurde bereits über sein Netzwerk beantwortet (ein VerifyVASP-Transfer oder ein GTR- oder Sygna-Bridge-Transfer, über den Sie oder Didit bereits entschieden haben). content: application/json: examples: Not awaiting confirmation: value: detail: Transfer is not awaiting ownership confirmation. No matching address book entry: value: detail: wallet address entry no longer available '502': description: >- Nur bei eingehenden TRP-Transfers: Didit konnte Ihre Entscheidung nicht an das auftraggebende VASP übermitteln, sodass sich der Transferstatus nicht ändert. content: application/json: examples: Callback not delivered: value: detail: >- Counterparty inquiry-resolution callback could not be delivered. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/ \ -H 'x-api-key: YOUR_API_KEY' -H 'Content-Type: application/json' \ -d '{"confirmed": true}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed=True, ) print(result) - lang: javascript label: Node.js source: >- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.transactions.travelRule.confirmOwnership("11111111-2222-3333-4444-555555555555", { confirmed: true, }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Transactions.TravelRule.ConfirmOwnership(ctx, \"11111111-2222-3333-4444-555555555555\", didit.TravelRuleOwnershipConfirmRequest{\n\tConfirmed: true,\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.TravelRuleOwnershipConfirmRequest; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().travelRule().confirmOwnership("11111111-2222-3333-4444-555555555555", TravelRuleOwnershipConfirmRequest.builder() .confirmed(true) .build()); System.out.println(result); - lang: php label: PHP source: >- transactions->travelRule->confirmOwnership('11111111-2222-3333-4444-555555555555', [ 'confirmed' => true, ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed: true ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Transactions.TravelRule.ConfirmOwnershipAsync("11111111-2222-3333-4444-555555555555", new TravelRuleOwnershipConfirmRequest { Confirmed = true, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleOwnershipConfirmRequest: type: object required: - confirmed properties: confirmed: type: boolean description: true, um die Inhaberschaft zu bestätigen, false, um sie abzulehnen. wallet_address: type: string default: '' description: >- Eingehende TRP-Transfers: die Zahlungsadresse, die Didit an das auftraggebende VASP zurückgibt, wenn Sie genehmigen. Standardmäßig die Adresse des übereinstimmenden Adressbucheintrags, danach beneficiary_data.wallet_address. Bei einem deklarierten Transfer mit selbstverwahrter Wallet, der keine Wallet der Gegenpartei benennt, die Wallet, deren Eigentümerschaft Sie verifiziert haben; ohne diese wird die Anfrage mit 400 abgelehnt. Bei anderen Transfers ignoriert. TravelRuleTransferDetail: type: object description: >- Vollständiges Transfer-Objekt, das von den Endpoints zur Eigentümerbestätigung und zum Abschließen/Abbrechen zurückgegeben wird. Solange das Wallet-Eigentum eines eingehenden Transfers unbestätigt ist, werden `originator_data` und `beneficiary_data` der Gegenpartei maskiert zurückgegeben (der erste Buchstabe jedes Wortes bleibt erhalten; Wallet, Chain und VASP-Routing bleiben lesbar) und `data_masked` ist true. properties: uuid: type: string format: uuid status: type: string enum: - AWAITING_COUNTERPARTY - ON_HOLD - COMPLETED - FINISHED - CANCELLED - EXPIRED - COUNTERPARTY_MISMATCHED_DATA - COUNTERPARTY_VASP_NOT_FOUND - COUNTERPARTY_VASP_NOT_REACHABLE - UNCONFIRMED_OWNERSHIP - COUNTERPARTY_VASP_GENERAL_DECLINE - NOT_ENOUGH_COUNTERPARTY_DATA - NOT_APPLICABLE direction: type: string enum: - INBOUND - OUTBOUND rail: type: string nullable: true enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - TEST_VASP - null description: >- Die Schiene (Rail), über die der Transfer geroutet wurde, oder null, wenn keine Schiene ausgewählt wurde (z. B. unterhalb des Schwellenwerts, eine selbstverwahrte Gegenpartei-Wallet, eine Registrierung nach Einzahlung oder keine erreichbare Gegenpartei). INTERNAL bedeutet, dass beide Seiten Didit-Anwendungen sind; EMAIL bedeutet, dass die Gegenpartei über einen per E-Mail gesendeten Abhol-Link erreicht wurde. TEST_VASP bedeutet, dass der Didit Test VASP den Sandbox-Transfer beantwortet hat. Über GTR, VERIFYVASP und SYGNA liest Didit die Antwort der Gegenpartei aus der Antwort des Netzwerks oder durch Abrufen alle 5 Minuten. TRUST sendet nur, sodass ein TRUST-Transfer auf AWAITING_COUNTERPARTY bleibt, bis er abläuft. Eine Netzwerk-Schiene wird nur verwendet, wenn Sie Ihre eigene Mitgliedschaft für dieses Netzwerk verknüpft haben. Sie wird nach der Rückgabe der Antwort auf die Transaktionserstellung ausgewählt, weshalb sie in dieser Antwort null ist. protocol: type: string nullable: true ivms_version: type: string example: ivms101.2023 required: type: boolean ownership_confirmed: type: boolean nullable: true deadline_at: type: string format: date-time nullable: true timeline: type: array items: type: object properties: status: type: string at: type: string format: date-time detail: type: string name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- Der Namensabgleich, über den dieser Eintrag entschieden hat, neben `detail`. Fehlt bei Einträgen, bei denen kein Name verglichen wurde. reason: type: string description: >- Nur beim Eintrag eines Übergangs vorhanden, der durch eine fehlgeschlagene Zustellung verursacht wurde: `email_undeliverable` oder `delivery_failed`, der Wert, den `reason` des Transfers meldet. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Due-Diligence-Score von 0 bis 100, wobei ein höherer Wert besser ist. Gleiche Skala wie im VASP-Verzeichnis. dd_score_breakdown: type: object description: >- Beiträge pro Komponente zu dd_score, ein Objekt pro Komponente wie im VASP-Verzeichnis (jurisdiction, verification, protocol, lei, history, essentials, responsiveness), jeweils {points, max, reason, detail}. {}, bis die Gegenpartei bewertet wurde. additionalProperties: type: object properties: points: type: number description: Für diese Komponente vergebene Punkte. max: type: integer description: Maximale Punktzahl, die diese Komponente vergeben kann. reason: type: string description: Maschinenlesbarer Code der Entscheidung der Komponente. detail: type: string description: Für Menschen lesbare Begründung für die vergebenen Punkte. dd_assessed_at: type: string format: date-time nullable: true description: >- Wann die Due-Diligence-Bewertung zuletzt durchgeführt wurde. Null, bis die Gegenpartei bewertet wurde. originator_data: type: object description: >- Auftraggeber-Partei. Bei einer eingehenden Überweisung werden die Werte der Gegenpartei maskiert, bis die Eigentümerstruktur bestätigt ist. beneficiary_data: type: object description: >- Begünstigter. Bei eingehenden Übertragungen werden die Werte der Gegenpartei maskiert, bis die Eigentümerschaft bestätigt ist. name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- Der Namensabgleich, der über die Überweisung entschieden hat, oder null, bis einer ausgeführt wurde. Solange die Parteien maskiert sind und auf der Kopie des anderen Kunden eines INTERNAL-Austauschs, werden `transfer_name`, `compared_name`, `matched_names` und `mismatched_names` ausgeblendet. `score` und `matched` können voneinander abweichen: `matched` richtet sich nach der Strenge, `score` ist die Ähnlichkeit der beiden vollständigen Namen. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Kürzel für `data_match.mismatched_fields`. Leer, wenn keine Unterschiede vorliegen. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- Wahr, solange die personenbezogenen Daten der Gegenpartei in dieser Antwort maskiert sind. created_at: type: string format: date-time delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Status der neuesten Nachricht, die dieser Transfer der anderen Seite schuldet. Null, wenn der Transfer nie eine geschuldet hat (zum Beispiel bei einem Wert unter `threshold_amount`, bei einer deklarierten selbstverwahrten Wallet oder bei einer Sunrise-Registrierung). discovery: type: array description: >- Wie Didit nach der Gegenpartei gesucht hat, ein Eintrag pro ausgeführtem Schritt. Leer, wenn keine Ermittlung stattgefunden hat, beispielsweise bei einem eingehenden Transfer. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Warum ein Transfer mit `COUNTERPARTY_VASP_NOT_FOUND` oder `COUNTERPARTY_VASP_NOT_REACHABLE` feststeckt; `""` für jeden anderen Status. Eine fehlgeschlagene Zustellung bestimmt dies zuerst, ausschließlich bei `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (der E-Mail-Provider hat die Compliance-E-Mail abgelehnt und es bleibt keine Adresse mehr zum Ausprobieren: beim Senden, bei einer Erinnerung oder als später gemeldeter permanenter Bounce) oder `delivery_failed` (die zustellende Schiene ist endgültig fehlgeschlagen: eine Netzwerkschiene hat die Nachricht abgelehnt oder keine Wiederholungsversuche mehr übrig, ein `TRP`-Identitäts-Host hat nicht geantwortet oder der `TRP`-Host der Gegenpartei hat die Anfrage nicht akzeptiert). Andernfalls bestimmt es der `discovery`-Trace: `awaiting_end_user` (kein Schritt hat eine Gegenpartei benannt, die Didit erreichen kann), `directory_match_no_route` (ein Schritt hat einen Verzeichnis-VASP benannt, der keine Route hat), `picked_member_without_proven_wallet` (der Endbenutzer hat einen Didit-Kunden ausgewählt, der die Kontrolle über die Wallet nicht nachgewiesen hat) oder `no_directory_match`, wenn der Trace keinen anderen Grund liefert. Ein erneutes Senden bringt den Transfer voran, sodass der Grund zurückgesetzt wird. Siehe [Warum ein Transfer feststeckt](/de/transaction-monitoring/travel-rule#warum-ein-transfer-blockiert-ist). next_actions: type: array description: >- Was den Transfer voranbringt; `[]` für jeden Status außer `COUNTERPARTY_VASP_NOT_FOUND` oder `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` bietet `update_compliance_email`, dann `resend`. `delivery_failed` bietet `resend`. Ein Discovery-Grund bietet `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint` und `resend`. items: $ref: '#/components/schemas/TravelRuleNextAction' chain_details: $ref: '#/components/schemas/TravelRuleChainDetails' TravelRuleNameMatch: type: object nullable: true description: >- Der Namensabgleich, der über die Überweisung entschieden hat, oder null, bis einer ausgeführt wurde. Solange die Parteien maskiert sind und auf der Kopie des anderen Kunden eines INTERNAL-Austauschs, werden `transfer_name`, `compared_name`, `matched_names` und `mismatched_names` ausgeblendet. `score` und `matched` können voneinander abweichen: `matched` richtet sich nach der Strenge, `score` ist die Ähnlichkeit der beiden vollständigen Namen. properties: score: type: integer minimum: 0 maximum: 100 description: >- Ähnlichkeit der beiden vollständigen Namen, 0 bis 100. 0, wenn einer der Namen leer ist. matched: type: boolean description: >- Gibt an, ob die Namen die Bedingung `strictness` erfüllen. Das Ergebnis des Transfers folgt `data_match`, das jedes Feld vergleicht, sodass ein Transfer COUNTERPARTY_MISMATCHED_DATA sein kann, während dies wahr ist. method: type: string enum: - none - exact_token - token_subset - token_containment - sequence_ratio description: >- Wie über `matched` entschieden wurde: none (`NONE`), exact_token (`STRICT`), token_subset (`DEFAULT`), token_containment (`CONTAINS`) oder sequence_ratio (`FUZZY`). strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY compared_with: type: string enum: - wallet_holder - counterparty_vasp description: >- wallet_holder: Der für die Wallet hinterlegte Inhaber. counterparty_vasp: Der Name, den die Gegenpartei auf der E-Mail-Antwortseite angegeben hat, oder die Antwort des Didit-Test-VASP in der Sandbox. transfer_name: type: string description: Der Name auf der Überweisung. compared_name: type: string description: Der Name, mit dem verglichen wurde. matched_names: type: array items: type: string description: Wörter aus `transfer_name`, die in `compared_name` gefunden wurden. mismatched_names: type: array items: type: string description: >- Wörter aus `transfer_name`, die in `compared_name` fehlen, gefolgt von Wörtern aus `compared_name`, die in `transfer_name` fehlen. TravelRuleDataMatch: type: object nullable: true description: >- Feldweiser Abgleich der Daten der an der Übertragung beteiligten Partei mit den Informationen der Gegenseite über den Wallet-Inhaber. Nennt Felder und Ergebnisse, niemals Werte, damit die Lesbarkeit erhalten bleibt, während die Daten der Gegenpartei maskiert sind. Null, bis ein Abgleich ausgeführt wurde. properties: matched: type: boolean description: True, wenn kein verglichenes Feld abweicht. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: Die Felder, die sich unterscheiden. fields: type: object description: >- Ein Eintrag pro verglichenem Feld für den Entitätstyp der Partei (`name`, `date_of_birth`, `address`, `account`; ein Unternehmen hat kein `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared`, wenn die Regel `NONE` ist oder eine der beiden Seiten keinen Wert für das Feld aufweist. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Audit-Eintrag des Zeitpunkts, zu dem die Daten der Gegenpartei demaskiert wurden. Null, solange die Daten noch maskiert sind, sowie bei ausgehenden Überweisungen. properties: at: type: string format: date-time reason: type: string enum: - ownership_confirmed - wallet_proof - address_book_match - own_verified_wallet - inquiry_approved - known_payment_method - travel_address description: >- Was die Inhaberschaft bestätigt hat: ownership_confirmed (Ihre Bestätigung über die Konsole oder die API), wallet_proof (ein Wallet-Nachweis im Widget oder ein eingehender INTERNAL-Transfer, festgelegt bei der Erstellung), address_book_match (eine verifizierte Adressbuch-Wallet), own_verified_wallet (die eigene verifizierte Wallet Ihres Benutzers), inquiry_approved (Ihre Genehmigung einer eingehenden TRP-Anfrage oder einer GTR- oder Sygna-Nachricht), known_payment_method (eine Wallet, mit der Ihr Benutzer bereits bezahlt hat) oder travel_address (die pro Wallet angegebene Travel Address). actor: type: string description: >- Wer die Bestätigung vorgenommen hat: die E-Mail-Adresse des Konsolenbenutzers oder die Bezeichnung des API-Schlüssels. Leer bei einer automatischen Entscheidung. TravelRuleDelivery: type: object description: >- Status der neuesten Nachricht, die der Transfer der anderen Seite schuldet. Didit kontaktiert die Gegenpartei, nachdem die Anfrage zurückgegeben wurde, die den Transfer erstellt oder geändert hat. Dieses Objekt gibt daher an, ob diese Nachricht durchgegangen ist: in der Warteschlange, wird gesendet, wartet auf Wiederholungsversuch nach einem Fehler, zugestellt oder fehlgeschlagen. Bei einem Fehler, von dem sich das Netzwerk noch erholen kann (keine rechtzeitige Antwort, fehlgeschlagene Verbindung, HTTP `408`, `429` oder `5xx`), wird der Versuch nach 30 Sekunden, 2 Minuten, 10 Minuten, 30 Minuten und 1 Stunde wiederholt. Wenn eine erste Nachricht (`kind: SEND`) endgültig fehlschlägt, weil das Netzwerk sie abgelehnt hat oder auch der sechste Versuch fehlgeschlagen ist, wechselt der Transfer zu `COUNTERPARTY_VASP_NOT_REACHABLE` mit `last_error` in seiner `timeline`; jede andere Nachricht, die endgültig fehlschlägt, wird in der `timeline` vermerkt. Der `status` des Transfers bleibt die maßgebliche Quelle für den Austausch selbst. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- Was die Nachricht übermittelt. `SEND`: die erste Nachricht des Transfers an die Gegenpartei (ausgehend; das Übertragungsnetzwerk wird beim Senden ausgewählt). `ANSWER`: Ihre Annahme oder Ablehnung gegenüber dem anfragenden Netzwerk (eingehend). `TXID`: der On-Chain-Transaktions-Hash, nachdem Sie den Transfer abgeschlossen haben. `CANCEL`: die Stornierung, nachdem Sie ihn abgebrochen haben. `POLL`: eine Statusabfrage an ein Netzwerk, das dies anbietet, die alle 5 Minuten wiederholt wird, während der Transfer auf die Gegenpartei wartet. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: Wartet auf den Versand. `SENDING`: Ein Versuch läuft. `RETRYING`: Ein Versuch ist fehlgeschlagen und der nächste erfolgt um `next_attempt_at`. `DELIVERED`: Die Gegenseite hat die Nachricht entgegengenommen. `FAILED`: Die Gegenseite hat sie abgelehnt oder der letzte Versuch ist fehlgeschlagen. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- Die Schiene (Rail), die die Nachricht übermittelt. Leer, bis Didit eine für eine erste Nachricht ausgewählt hat. attempts: type: integer minimum: 0 description: >- Bisher durchgeführte Versuche für diese Nachricht. Für eine Nachricht, die keine Statusabfrage ist, werden maximal 6 Versuche unternommen. last_error: type: string description: >- Die Art des Fehlers, der beim letzten Versuch aufgetreten ist, `""`, wenn keiner aufgetreten ist: beispielsweise `email undeliverable`, `trp identity endpoint unreachable` oder `trp transfer inquiry delivery failed`. Sie enthält niemals die eigene Antwort der Gegenpartei, die in der `timeline` des Transfers verbleibt. Wenn GTR mit einem Fehler antwortet, sind dessen eigener Statuscode und dessen Nachricht enthalten. Antwortinhalte sind niemals enthalten. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Wann der nächste Versuch ausgeführt wird, während die Nachricht `QUEUED` oder `RETRYING` ist. delivered_at: type: string format: date-time nullable: true description: Wann die Gegenseite die Nachricht entgegengenommen hat. TravelRuleDiscoveryStep: type: object description: >- Ein Schritt der Gegenpartei-Ermittlung, die Didit für einen ausgehenden Transfer durchgeführt hat, in der Reihenfolge der Ausführung. Der erste Schritt, der einen VASP mit einer Route benennt, beendet die Kette. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: ein anderer Didit-Kunde, der die Kontrolle über die Ziel-Wallet nachgewiesen hat. `wallet_attribution`: die Blockchain-Analyse-Zuordnung der Wallet. `network_lookup`: ein Netzwerk, das angeben kann, welcher VASP die Adresse hält. `customer_hint`: der VASP-Name, der LEI oder die Jurisdiktion, die Sie in `beneficiary_data` übermittelt haben. `end_user`: die Gegenpartei, die der Endbenutzer (oder Sie) ausgewählt hat, oder die Aufforderung, eine auszuwählen. outcome: type: string enum: - match - miss - skipped description: >- `match`: Der Schritt hat eine Gegenpartei benannt. `miss`: Er wurde ausgeführt und hat keine gefunden. `skipped`: Er konnte nicht ausgeführt werden, und `reason` gibt den Grund an. reason: type: string description: >- Maschinenlesbarer Grund, `""` bei einer Übereinstimmung: `no_proven_internal_wallet`, `attribution_disabled`, `already_attributed`, `no_attributed_entity`, `directory_match_no_route`, `gtr_address_lookup_runs_on_dispatch`, `no_membership`, `network_switched_off`, `no_network_address_lookup`, `no_directory_match`, `awaiting_end_user` oder `picked_member_without_proven_wallet`. vasp: type: string format: uuid nullable: true description: >- Der Verzeichnis-VASP, den der Schritt benannt hat, sofern einer benannt wurde. rail: type: string nullable: true description: >- Die Schiene (Rail), die diese Gegenpartei erreicht, sofern der Schritt eine gefunden hat. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Eine Maßnahme, die einen Transfer mit dem Status `COUNTERPARTY_VASP_NOT_FOUND` oder `COUNTERPARTY_VASP_NOT_REACHABLE` voranbringt. Siehe [Warum ein Transfer festhängt](/de/transaction-monitoring/travel-rule#warum-ein-transfer-blockiert-ist). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: Der Endbenutzer wählt die Ziel-VASP im Widget zum Wallet-Eigentumsnachweis aus, oder Sie senden einen PATCH mit `action=beneficiary_vasp`. `declare_self_hosted`: Der Endbenutzer deklariert die Wallet im Widget als selbstverwahrt. `add_vasp_hint`: Teilen Sie Didit über einen VASP-Namen, LEI oder eine Travel Address (beispielsweise eine `travel_address` im Adressbucheintrag der Ziel-Wallet) mit, wer die Gegenpartei ist, und senden Sie die Anfrage erneut. `update_compliance_email` und `resend` sind `action`-Werte von `PATCH /v3/transactions/{transaction_id}/travel-rule/`: Geben Sie die Compliance-E-Mail der Gegenpartei erneut an und führen Sie das Routing noch einmal durch. url: type: string format: uri description: >- Der Link zum Wallet-Ownership-Widget, bei `select_counterparty_vasp` und `declare_self_hosted`, solange der Transfer eine offene Widget-Sitzung hat. required: - action TravelRuleChainDetails: type: object description: >- Wie die Blockchain des Transfers ihre beiden Wallets benennt, wenn mehr als eine Adresse eine andere bezahlt. Leer (`{}`) bei einem Account-Chain-Transfer (EVM, Solana, Tron), bei dem die beiden Adressen die Wallets sind. Abgleich, Weiterleitung und das Adressbuch lesen die Wallets zuerst von hier aus. properties: chain: type: string description: >- Kanonische Chain, z. B. `BTC`, `XRP` oder `LIGHTNING` für einen Lightning-Transfer. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- Bei einem UTXO-Transfer: die Inputs und Outputs wie gespeichert (Beträge als Dezimal-Strings) und welche Outputs Didit als was interpretiert hat. properties: inputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' outputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' change_output_indexes: type: array items: type: integer description: Ausgaben, die an eine Eingabeadresse zurückzahlen. beneficiary_output_index: type: integer nullable: true description: >- Der Output, der den Begünstigten bezahlt; null, wenn keine unterschieden werden konnten. lightning: type: object description: >- Bei einem Lightning-Transfer: Inhalt der Zahlungsanforderung. Immer `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` oder `unknown`); eine BOLT11-Rechnung ergänzt `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` und `expires_at`; ein BOLT12-String ergänzt `blinded_paths` und `payee_node_id`; eine LNURL oder Lightning Address ihre `domain`. Es wird nichts über das Netzwerk aufgelöst: Die Anforderung wird lediglich decodiert. additionalProperties: true warnings: type: array items: type: string enum: - declared_originator_not_an_input - declared_beneficiary_not_an_output - beneficiary_output_ambiguous - beneficiary_output_amount_differs description: >- UTXO-Inkonsistenzen, die eine Überprüfung wert sind: Der angegebene Auftraggeber ist kein Input, der angegebene Begünstigte ist kein Output, es konnte kein einzelner Output des Begünstigten unterschieden werden oder der Begünstigten-Output zahlt einen anderen Betrag aus, als in der Transaktion angegeben ist. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- Bei einem ausgehenden Lightning-Transfer, dessen Zahlungsanforderung keinen Begünstigten nennt: der Grund, warum der Transfer `NOT_APPLICABLE` ist. `LIGHTNING_NO_PAYEE_IDENTIFIER` (die Anforderung nennt keinen Knoten des Begünstigten oder konnte nicht decodiert werden), `LIGHTNING_BOLT12_BLINDED_PAYEE` (das Angebot verbirgt seinen Begünstigten hinter blinden Pfaden), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (eine LNURL nennt einen Dienst, keinen Begünstigten). Derselbe Code leitet den letzten `timeline`-Eintrag des Transfers ein. TravelRuleChainSide: type: object description: Die Wallet einer Seite, wie von Didit aus den Chain-Daten aufgelöst. properties: address: type: string description: >- Die Wallet. Auf einem Memo-Netzwerk die klassische Adresse (eine XRP-X-Adresse wird in ihre klassische Adresse und ihr Tag aufgeteilt); auf Lightning die Knoten-ID des Zahlungsempfängers oder die Lightning-Adresse. memo: type: string description: >- Das Destination-Tag oder Memo, das Teil der Wallet ist; `""` für keines. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Woher die Wallet stammt: `declared` (Ihre Anfrage), `x_address` (aus einer XRP-X-Adresse aufgeteilt), `largest_input` (die UTXO-Input-Adresse mit dem größten Beitrag), `only_non_change_output` (der einzige UTXO-Output, der kein Wechselgeld ist), `amount_match` (der eine UTXO-Output, der den Überweisungsbetrag zahlt), `invoice_payee` (der Zahlungsempfänger, den eine Lightning-Zahlungsanforderung benennt), `updated` (nachträglich mit `action: update_originator_wallet` festgelegt). TravelRuleUtxoEntry: type: object description: >- Eine Eingabe oder Ausgabe einer UTXO-Transaktion, wie sie von der Blockchain erfasst wurde. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- Dezimal-Zeichenkette in der Einheit des Coins selbst (BTC, nicht Satoshis). Optional. example: '0.0125' txid: type: string maxLength: 128 description: Optional. Die Transaktion, deren Output ein Input ausgibt. vout: type: integer nullable: true minimum: 0 description: Optional. Der Index des Outputs, den ein Input ausgibt. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.