> ## 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. # Transaktions-API erstellen: KYT-Einreichung > Didit KYT: Transaktion zur Risikobewertung, Screening und Travel Rule einreichen. 1,000 pro Monat inklusive, danach $0.001 je Transaktion. Prompt für die Create-Transaction-API Prompt in die Zwischenablage kopieren \

\`Submit a transaction for Didit monitoring through the Management API.

Endpoint:
POST https://verification.didit.me/v3/transactions/

Authentication:
Use the x-api-key header with my Didit API key.

Goal:
\- Submit a transaction for KYT (transaction monitoring). Didit runs the configured rules engine, blockchain analytics, and AML screening synchronously and returns the verdict in the response. The full detail (parties, rule runs, provider results, remediation links) is also returned.
\- A Travel Rule transfer is stored in the same call, but Didit contacts the counterparty after the response: travel_rule.status comes back AWAITING_COUNTERPARTY (or NOT_APPLICABLE, UNCONFIRMED_OWNERSHIP, or COMPLETED for your own verified wallet) with travel_rule.protocol null, and every later status change, including COUNTERPARTY_VASP_NOT_FOUND, arrives as a travel_rule.status.updated webhook. Your rules run again when the rail or the status changes.

When to call:
\- At payment authorization, before fanning out funds, to decide allow / hold / decline based on status, score, severity.
\- On post-trade events (gambling bets, audit-trail events, KYC events) for long-running monitoring without a per-transaction decision.
\- On crypto deposits / withdrawals — set transaction_details.currency_kind = "crypto" and provide the relevant wallet address in payment_method.account_id.
\- For Travel Rule, set transaction_category = "travel_rule" and include travel_rule_details (alias travelRule).
travel_rule_details.status is required (400 if missing); when Travel Rule is enabled, Didit runs the exchange and ignores the status you send, and otherwise Didit records the transfer passively with that status.
When the subject is a user with an approved Didit KYC verification and Travel Rule is on, Didit replaces the originator_data fields the verification holds with the verified values (metadata.originator_provenance says which); otherwise it sends originator_data as you provide it, so build it from the identity you verified.
beneficiary_data carries the beneficiary (name, wallet_address, chain) and any routing hints (travel_address, counterparty_vasp_lei, counterparty_vasp_name, counterparty_vasp_email).
If beneficiary_data.chain is empty, Didit takes transaction_details.crypto_params.crypto_chain, else custom_properties.crypto_chain, else the currency, uppercases it, and sets it only when it is a chain Didit recognises (for example ETH or BTC).
\- Chain shapes: on XRP, XLM, EOS, ATOM and HBAR send the destination tag or memo as payment_method.memo (or beneficiary_data.memo); on BTC, LTC, BCH and DOGE send the transaction's inputs and outputs as travel_rule_details.utxo; on bitcoin or Lightning, payment_method.account_id may be a Lightning payment request or Lightning Address. What Didit resolved is on travel_rule.chain_details (see /transaction-monitoring/travel-rule#chain-shapes).

Identifiers:
\- transaction_id (alias txnId) is YOUR identifier (max 128 chars), unique per application.
It becomes txn_id on subsequent calls.
Reusing a transaction_id that already exists returns 400 {"transaction_id": ["A transaction with this transaction_id already exists."]}, and when two identical requests race each other the loser gets 409.
Neither response returns the existing transaction, so to retry safely, treat a 400 or 409 for a duplicate id as already created and look the transaction up instead of resubmitting: GET /v3/transactions/{uuid}/ with the Didit uuid from the first response, or with the transaction_id (the Didit uuid) that the transaction.created webhook carries next to your txn_id.
GET does not accept your txn_id. Sandbox applications do not receive transaction.created or transaction.status.updated, so save the Didit uuid from the create response. Sandbox Travel Rule exchanges do emit travel_rule.status.updated with environment: sandbox.
\- The returned uuid is Didit's stable identifier — use it in GET /v3/transactions/{transaction_id}/.

Linking to entities:
\- subject.vendor_data (and optionally counterparty.vendor_data) are your internal user/business identifiers. They link the transaction to the long-lived User / Business entity assembled from prior verification sessions. Use the SAME vendor_data you supplied when creating the KYC session.

Minimum request body (application/json):
\{
"transaction_id": "your-txn-2026-05-17-001",
"transaction_category": "finance",   // finance | kyc | travel_rule | user_event | audit_trail_event | gambling_bet | gambling_limit_change | gambling_bonus_change
"transaction_details": {
"direction": "outbound",            // "inbound" | "outbound"
"amount": 1500,                     // number or decimal string, up to 18 decimal places (string for exact precision); never negative, because direction carries the sign
"currency": "EUR",                  // any ISO 4217 code (EUR, USD, NGN, ...) or a crypto symbol
"currency_kind": "fiat",            // "fiat" | "crypto" (optional)
"action_type": "withdrawal"         // optional, e.g. deposit/withdrawal/transfer
},
"subject": {                          // APPLICANT party
"entity_type": "individual",        // "individual" | "company"
"vendor_data": "user-12345",        // required
"full_name": "Maria Garcia",        // required
"address": { "country": "ESP" }     // optional
},
"counterparty": { ... },              // optional COUNTERPARTY party (same shape as subject)
"transaction_at": "2026-05-17T08:42:00Z",  // optional, defaults to now
"travel_rule_details": { "status": "AWAITING_COUNTERPARTY", ... }   // optional, for crypto Travel Rule; status is required inside it
}

Currency codes:
\- currency has no enum. Any ISO 4217 alphabetic code (EUR, USD, NGN, ...) and any crypto asset symbol (BTC, ETH, ...) are accepted and stored exactly as you send them, up to 10 characters.
\- Prefer a currently-circulating code. Not every accepted code has an exchange rate: withdrawn currencies and accounting units such as XDR are often still quoted, but when Didit has no rate for the code you send (for example the ISO accounting unit XSU, or a crypto symbol Didit does not price), automatic conversion to your base currency fails and preferred_currency_amount comes back null. A pre-converted amount_in_default_currency is always used as sent when present, so supply it for any code you are not sure has a rate.
\- Set currency_kind = "crypto" for on-chain amounts. The kind gates the transaction's own crypto AML screening: without currency_kind = "crypto" that regular screening step is skipped and no screening fee is estimated or charged for it, even with monitoring enabled or include_crypto_screening = true. Travel Rule attribution is a separate path: on a production application with Travel Rule and VASP attribution enabled, an outbound transaction_category = "travel_rule" request whose beneficiary wallet and chain cannot be reached over any rail triggers a VASP attribution wallet screening, and that screening is billed at the wallet screening price whatever currency_kind is or is not set. The kind does not change the stored decimal scale: up to 18 decimal places are kept either way, but only when amount arrives as a decimal string ("0.123456789012345678"). A JSON number is parsed as a binary float first, so anything beyond about 15 significant digits is rounded before it is stored (0.123456789012345678 is stored as 0.12345678901234568). The kind also decides how the amount is rendered in the transaction PDF. Crypto amounts render with up to 8 decimal places, fiat amounts with their ISO 4217 minor unit (2 for most currencies). Without the kind, RON, MNT and GEL are rendered as fiat because each is both a token and an ISO 4217 currency, so a small token amount can show as 0 in the report.
The VASP attribution screening is skipped when the transaction's own crypto screening already screened that wallet: Didit reuses that result and charges nothing extra.

Example call:
curl -X POST "https://verification.didit.me/v3/transactions/" \
-H "x-api-key: YOUR_API_KEY" -H "Content-Type: application/json" \
-d '{
"transaction_id": "your-txn-2026-05-17-001",
"transaction_category": "finance",
"transaction_details": {"direction":"outbound","amount":1500,"currency":"EUR","action_type":"withdrawal"},
"subject": {"entity_type":"individual","vendor_data":"user-12345","full_name":"Maria Garcia"}
}'

What to read from the response:
\- uuid — Didit transaction id, use for GET /v3/transactions/{transaction_id}/.
\- status - APPROVED | IN_REVIEW | DECLINED | AWAITING_USER (live verdict; at creation, AWAITING_USER comes from a rule action).
\- score (0–100, higher = riskier) and severity (LOW | MEDIUM | HIGH | CRITICAL).
\- decision_reason_code / decision_reason_label — machine + human verdict reason.
\- parties (role APPLICANT for the subject, COUNTERPARTY for the counterparty; kind USER, BUSINESS or EXTERNAL), cost_breakdown, rule_runs, provider_results (crypto screening results) and network_snapshot.
\- travel_rule - the Travel Rule transfer (status, protocol, required, originator_data, beneficiary_data, direction, rail, counterparty_vasp, delivery, discovery, reason, next_actions), or null; action_required - a pending wallet-ownership or verification step, or null.
reason and next_actions say why a COUNTERPARTY_VASP_NOT_FOUND or COUNTERPARTY_VASP_NOT_REACHABLE transfer is stuck and what moves it on (for example email_undeliverable: update_compliance_email, then resend); they are "" and [] for any other status.

Webhooks:
\- transaction.created fires after this call succeeds.
\- For a travel_rule transaction, travel_rule.status.updated fires for each Travel Rule transition, after transaction.created. Each webhook is delivered and retried on its own, so key on transaction_id rather than on arrival order.
\- transaction.status.updated fires whenever the verdict changes (manual review, async screening, rule re-runs). Subscribe a destination via POST /v3/webhook/destinations/.

Failure modes:
\- 400 - duplicate transaction_id, missing required field (including travel_rule_details.status), an unknown travel_rule_details.status ("Invalid travel rule status: ..."), invalid direction/category enum, or malformed party object.
\- 409 - a concurrent request with the same transaction_id was created first.
\- 403 - missing x-api-key (a wrong, revoked or expired key gets 401), or a key without permission for this action; the body is a { "detail": "..." } envelope.
\- 403 - the organization's balance cannot cover the fees this request would charge: { "detail": "...", "code": "insufficient_credits" }, and nothing is created.
\- 429 - more than 600 ingestion requests per minute for this API key (transaction and event ingestion share this budget, apart from the 300 of every other write); wait Retry-After seconds and retry.

Side effects:
\- Creates the transaction record and runs the synchronous rules + screening pipeline.
\- Links the transaction to the User / Business entity that shares the subject.vendor_data.
\- An outbound travel_rule transaction is billed once, at creation, on one line. It pays the Travel Rule fee ($0.02) when Travel Rule is on and Didit starts an exchange for it (amount at or above threshold_amount, including a transfer to a self-hosted wallet or to the user's own verified wallet). Otherwise it is billed as transaction monitoring (included in the plan's monthly transaction allowance, $0.001 each beyond it): below threshold_amount, a Lightning payment the Travel Rule does not apply to, or data recorded while Travel Rule is disabled. A resend never charges again.
\- An inbound travel_rule transaction pays no base fee, an application that joined Travel Rule free pays none on outbound transactions until it turns outbound billing on, and sandbox applications are never charged.
\- Crypto screening, when it runs, adds the Wallet Verification & Screening charge.

For the full integration shape, see /integration/integration-prompt.`

\
Einfügen in ## OpenAPI ````yaml de/openapi-25.json POST /v3/transactions/ 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/: post: tags: - Transactions summary: Transaktion erstellen description: >- Übermitteln Sie eine Transaktion zur synchronen AML-/Risikoüberwachung. Die Transaktion wird als `APPROVED` erstellt, anschließend werden Ihre Regeln (und gegebenenfalls das Krypto-Screening) inline ausgeführt und können den zurückgegebenen `status` auf `IN_REVIEW` oder `DECLINED` umstellen. **`transaction_id` ist Ihr Idempotenz-Schlüssel** (max. 128 Zeichen, eindeutig pro Anwendung); eine erneute Verwendung gibt 400 zurück. Ein `transaction.created`-Webhook wird bei Erfolg für Live-Anwendungen gesendet. Sandbox-Anwendungen werden nicht abgerechnet und senden keine `transaction.created`- oder `transaction.status.updated`-Webhooks. Travel-Rule-Austausche in der Sandbox senden `travel_rule.status.updated`-Webhooks mit `environment: sandbox`. Ein Travel-Rule-Transfer wird gespeichert und zurückgegeben, bevor eine Gegenpartei kontaktiert wird: `travel_rule.status` wird als `AWAITING_COUNTERPARTY` zurückgegeben (oder als `NOT_APPLICABLE` unterhalb Ihres Schwellenwerts, `UNCONFIRMED_OWNERSHIP` für eine deklarierte selbstverwahrte Wallet, `COMPLETED`, wenn die andere Wallet Ihre eigene verifizierte Wallet ist) und `travel_rule.protocol` ist null. Didit wählt dann den Übertragungsweg und leitet den Austausch ein, und jede spätere Statusänderung des Transfers, einschließlich `COUNTERPARTY_VASP_NOT_FOUND`, wenn kein Übertragungsweg die Gegenpartei erreicht, trifft als `travel_rule.status.updated`-Webhook ein. Ihre Regeln werden erneut ausgeführt, wenn sich der Übertragungsweg oder der Status ändert. operationId: createTransaction requestBody: required: true content: application/json: schema: type: object properties: transaction_id: type: string description: >- Ihre eindeutige Kennung für diese Transaktion (maximal 128 Zeichen). example: your-txn-2026-05-17-001 transaction_at: type: string format: date-time description: >- Wann die Transaktion stattgefunden hat. Standardmäßig jetzt, falls weggelassen. time_zone: type: string description: IANA-Zeitzonenkennung, z. B. `Europe/Madrid`. transaction_category: type: string description: >- Kategorie der Transaktion. CamelCase-Aliase (`travelRule`, `userPlatformEvent`, `gamblingBet`, …) werden ebenfalls akzeptiert; der gespeicherte/zurückgegebene Wert ist camelCase für mehrteilige Kategorien. example: finance enum: - finance - kyc - travel_rule - user_event - audit_trail_event - gambling_bet - gambling_limit_change - gambling_bonus_change - travelRule transaction_details: type: object description: Wesentliche Finanzdaten der Transaktion. required: - direction - amount - currency properties: direction: type: string description: >- Richtung der Transaktion relativ zur betreffenden Entität. Groß-/Kleinschreibung wird nicht beachtet; `in`/`out` werden als Aliase akzeptiert. Wird in Großbuchstaben zurückgegeben (`INBOUND`/`OUTBOUND`). example: outbound enum: - inbound - outbound - in - out amount: type: number description: >- Transaktionsbetrag (bis zu 18 Dezimalstellen). Senden Sie ihn als Dezimalstring (z. B. `"0.123456789012345678"`), wenn exakte Präzision erforderlich ist: Eine JSON-Zahl wird zuerst als binäre Gleitkommazahl geparst, sodass Ziffern jenseits von etwa 15 signifikanten Stellen gerundet werden, bevor der Betrag gespeichert wird. Muss null oder größer sein: Die Richtung trägt das Vorzeichen, und ein negativer Betrag gibt `400` zurück. example: 1500 currency: type: string description: >- Währungscode. Jeder alphabetische ISO-4217-Code wird akzeptiert (z. B. `EUR`, `USD`, `NGN`), ebenso wie ein Krypto-Asset-Symbol (z. B. `BTC`). Bevorzugen Sie einen aktuell im Umlauf befindlichen Code. Nicht jeder akzeptierte Code verfügt über einen Wechselkurs: Wenn für den Code keiner verfügbar ist (beispielsweise die ISO-Verrechnungseinheit `XSU` oder ein Krypto-Symbol, für das Didit keine Kurse bereitstellt), schlägt die automatische Konvertierung fehl und `preferred_currency_amount` wird als null zurückgegeben, es sei denn, die Anfrage enthielt einen vorkonvertierten Wert für `amount_in_default_currency`. example: EUR currency_kind: type: string description: Gibt an, ob die Währung `fiat` oder `crypto` ist. amount_in_default_currency: type: number nullable: true description: >- Vorab umgerechneter Betrag in der Standardwährung. Wenn weggelassen, wird eine automatische Währungsumrechnung versucht. Muss null oder größer sein. default_currency: type: string description: >- Der Standard-Währungscode für den umgerechneten Betrag. Jeder derzeit im Umlauf befindliche ISO-4217-Code. payment_details: type: string nullable: true description: Freitext-Zahlungsreferenz oder -Verwendungszweck. payment_reference_id: type: string nullable: true description: >- Externe Zahlungssystem-Referenz. Für das Krypto-AML-Transaktions-Hash-Screening senden Sie den Blockchain-Transaktions-Hash und übergeben Sie außerdem `subject.payment_method.account_id` mit der zugehörigen Adresse. action_type: type: string nullable: true description: >- Untertyp der Transaktion, z. B. `deposit`, `withdrawal`, `transfer`. crypto_params: type: object description: >- Auswahl des Krypto-Netzwerks, getrennt von der Währung (dem Asset-Symbol). Die Erfassung eines benutzerdefinierten Token-Symbols garantiert keine Abdeckung von Transaktions-Hashes für den zugehörigen Vertrag. properties: crypto_chain: type: string description: >- Tatsächliches Netzwerk, das für das Screening verwendet wurde. Das verwaltete Screening unterstützt BTC, ETH, LTC, XRP, BCH, DOGE, TRX, SOL, MATIC, BNB, BASE (Base), OP (Optimism), ARB (Arbitrum One), AVAX (Avalanche C-Chain), ADA (Cardano), XLM (Stellar) und HBAR (Hedera). Gängige Netzwerknamen werden ebenfalls akzeptiert, z. B. POLYGON oder POL für MATIC, BSC für BNB und TRON für TRX. Geben Sie dies bei Multi-Chain-Token immer an. Wenn die Angabe für USDT, USDC oder ETH mit einem 0x-Transaktions-Hash fehlt, schlägt Didit den Hash auf Ethereum, BNB Chain, Polygon, Base, Arbitrum und Optimism nach und führt das Screening auf dem Netzwerk durch, auf dem er gefunden wird; wird er auf keinem Netzwerk gefunden, wird die Transaktion nicht gescreent und custom_values.aml_screening_status lautet FAILED mit dem Grund in custom_values.aml_screening_error. Wenn die Angabe für USDT oder USDC beim Screening nach Wallet (ohne Transaktions-Hash) fehlt, wird eine Tron-Adresse auf Tron, eine Solana-Adresse auf Solana und eine 0x-Adresse auf dem ersten dieser sechs Netzwerke gescreent, auf dem sie eine Transaktion gesendet hat oder das Token hält, oder auf Ethereum, wenn sie auf keinem davon aktiv ist. Die Abdeckung angebundener Anbieter variiert; LIGHTNING erfordert einen unterstützten angebundenen Anbieter. example: BASE subject: type: object description: Das Subjekt (der Antragsteller) der Transaktion. required: - vendor_data - full_name properties: entity_type: type: string description: 'Entitätstyp: `individual` oder `company`.' vendor_data: type: string description: Ihre interne Benutzer-/Unternehmenskennung. example: user-12345 full_name: type: string description: Vollständiger Name der Zielperson. example: Maria Garcia first_name: type: string description: Vorname der Person. last_name: type: string description: Nachname der Person. date_of_birth: type: string format: date description: Geburtsdatum (JJJJ-MM-TT). address: type: object description: Adressobjekt. properties: country: type: string description: >- Ländercode (ISO 3166-1 Alpha-3 empfohlen). Wird in `country_code` der Partei kopiert. town: type: string state: type: string street: type: string post_code: type: string institution_details: type: object description: Details zur Institution (für institutionelle Subjekte). properties: name: type: string code: type: string address: type: object device_context: type: object description: >- Gerätekontext, der zum Transaktionszeitpunkt erfasst wurde. browser_family und platform müssen als explizite Top-Level-Schlüssel gesendet werden — sie werden nicht aus user_agent abgeleitet. Der camelCase-Alias device wird in der Anfrage ebenfalls akzeptiert. properties: fingerprint: type: string description: Eindeutiger Geräte-Fingerabdruck. persistent_device_id: type: string description: >- Stabiler sitzungsübergreifender Geräteidentifikator (v2-Fingerprint-Schema). user_agent: type: string description: >- User-Agent-String des Browsers oder der App. CamelCase-Alias: userAgent. browser_family: type: string description: >- Browser-Familie (z. B. Chrome, Firefox, Safari). Muss explizit gesendet werden — wird nicht aus user_agent abgeleitet. CamelCase-Alias: browserFamily. browser_version: type: string description: >- Browser-Versions-String. Muss explizit gesendet werden. CamelCase-Alias: browserVersion. platform: type: string description: >- Plattform-Identifikator (web, ios, android, macos, windows, linux). Muss explizit gesendet werden – wird nicht aus user_agent abgeleitet. os_family: type: string description: >- Betriebssystemfamilie (z. B. iOS, Android, Windows). CamelCase-Alias: osFamily. os_version: type: string description: >- Versionszeichenfolge des Betriebssystems. CamelCase-Alias: osVersion. accept_language: type: string description: >- Wert des Accept-Language-Headers. CamelCase-Alias: acceptLang. session_id: type: string description: >- Sitzungskennung der aktuellen Sitzung des Benutzers. In den Metadaten gespeichert. CamelCase-Alias: sessionId. session_age_ms: type: number description: >- Alter der Benutzersitzung in Millisekunden zum Transaktionszeitpunkt. CamelCase-Alias: sessionAgeMs. network_context: type: object description: >- Netzwerkkontext mit IP-Adresse und Geolokalisierung. Ein übergeordneter ipInfo-Block wird ebenfalls in dieses Objekt eingefügt. properties: ip_address: type: string description: 'Client-Adresse. CamelCase-Alias: ip.' ip_country_code: type: string description: >- Per Geo-IP aufgelöstes Land der IP-Adresse (ISO 3166-1 alpha-3). CamelCase-Alias: countryCode3. latitude: type: number description: >- Geografische Breite der IP-Adresse. CamelCase-Alias: lat. longitude: type: number description: >- Geografische Länge der IP-Adresse. CamelCase-Alias: lon. payment_method: type: object description: Vom Betreffenden verwendete Zahlungsmethode. properties: method_type: type: string description: >- Art der Zahlungsmethode: `bank_card`, `bank_account`, `crypto_wallet`, `ewallet`, `unhosted_wallet`, `other`. account_id: type: string description: >- Kontokennung (z. B. IBAN, Adresse). Für das Krypto-Screening sollte dieses Feld die Adresse dieses Teilnehmers enthalten. Das Screening eingehender Transaktions-Hashes erfordert die Einzahlungsadresse des Dienstes/Kunden für das Subjekt. Das Screening ausgehender Transaktionen verwendet die Ziel-Wallet der Gegenpartei. Bei einem Krypto-Transfer auf Bitcoin oder Lightning kann es sich um eine Lightning-Zahlungsanforderung (BOLT11-Rechnung, BOLT12-Angebot, LNURL) oder eine Lightning Address handeln: Didit speichert den darin genannten Zahlungsempfänger als Konto ("", wenn keiner genannt wird) und die Angaben der Anfrage unter `chain_details.lightning` des Travel-Rule-Transfers. Nach dem Speichern maximal 255 Zeichen. Bei einem Krypto-Transfer auf Bitcoin oder Lightning kann es sich um eine Lightning-Zahlungsanforderung (BOLT11-Rechnung, BOLT12-Angebot, LNURL) oder eine Lightning Address handeln: Didit speichert den darin genannten Zahlungsempfänger als Konto ("", wenn keiner genannt wird) und die Angaben der Anfrage unter `chain_details.lightning` des Travel-Rule-Transfers. Nach dem Speichern maximal 255 Zeichen. memo: type: string maxLength: 256 description: >- Das Destination-Tag oder Memo, das Teil der Wallet in einem Memo-Netzwerk ist (XRP, XLM, EOS, ATOM, HBAR). Bei einer gemeinsamen Exchange-Adresse ist jedes Memo eine eigene Zahlungsmethode. XRP: ein Destination-Tag, eine Ganzzahl von 0 bis 4294967295 (eine JSON-Zahl wird akzeptiert). XLM: ein Text-Memo von bis zu 28 Bytes, eine 64-Bit-ID oder ein 32-Byte-Hash in hexadezimaler Form. EOS: bis zu 256 Bytes. ATOM: bis zu 256 Zeichen. HBAR: bis zu 100 Bytes. Bitcoin-, EVM-, Solana-, Tron-, Litecoin-, Bitcoin Cash-, Dogecoin- und Lightning-Wallets unterstützen kein Memo: die Angabe eines Memos führt zu einem `400`. Alias: `destinationTag` oder `destination_tag`. issuing_country: type: string description: ISO 3166-1-Alpha-3-Ländercode des Ausstellers. counterparty: type: object description: Die Gegenpartei der Transaktion (optional). properties: entity_type: type: string description: 'Entitätstyp: `individual` oder `company`.' vendor_data: type: string description: Ihre interne Kennung für die Gegenpartei. full_name: type: string description: Vollständiger Name der Gegenpartei. first_name: type: string last_name: type: string date_of_birth: type: string format: date address: type: object description: Adressobjekt mit `country` (ISO 3166-1 Alpha-3). institution_details: type: object device_context: type: object description: >- Gerätekontext für die Gegenpartei. browser_family und platform müssen als explizite Schlüssel auf oberster Ebene übergeben werden – sie werden nicht aus user_agent abgeleitet. properties: fingerprint: type: string description: Eindeutiger Geräte-Fingerabdruck. persistent_device_id: type: string description: >- Stabiler sitzungsübergreifender Geräteidentifikator (v2-Fingerprint-Schema). user_agent: type: string description: >- User-Agent-String des Browsers oder der App. CamelCase-Alias: userAgent. browser_family: type: string description: >- Browser-Familie (z. B. Chrome, Firefox, Safari). Muss explizit gesendet werden — wird nicht aus user_agent abgeleitet. CamelCase-Alias: browserFamily. browser_version: type: string description: >- Browser-Versions-String. Muss explizit gesendet werden. CamelCase-Alias: browserVersion. platform: type: string description: >- Plattform-Identifikator (web, ios, android, macos, windows, linux). Muss explizit gesendet werden – wird nicht aus user_agent abgeleitet. os_family: type: string description: >- Betriebssystemfamilie (z. B. iOS, Android, Windows). CamelCase-Alias: osFamily. os_version: type: string description: >- Versionszeichenfolge des Betriebssystems. CamelCase-Alias: osVersion. accept_language: type: string description: >- Wert des Accept-Language-Headers. CamelCase-Alias: acceptLang. session_id: type: string description: >- Sitzungskennung für die Sitzung der Gegenpartei. In den Metadaten gespeichert. CamelCase-Alias: sessionId. session_age_ms: type: number description: >- Alter der Benutzersitzung in Millisekunden zum Transaktionszeitpunkt. CamelCase-Alias: sessionAgeMs. network_context: type: object description: >- Netzwerkkontext mit IP-Adresse und Geolokalisierung. Ein übergeordneter ipInfo-Block wird ebenfalls in dieses Objekt eingefügt. properties: ip_address: type: string description: 'Client-Adresse. CamelCase-Alias: ip.' ip_country_code: type: string description: >- Per Geo-IP aufgelöstes Land der IP-Adresse (ISO 3166-1 alpha-3). CamelCase-Alias: countryCode3. latitude: type: number description: >- Geografische Breite der IP-Adresse. CamelCase-Alias: lat. longitude: type: number description: >- Geografische Länge der IP-Adresse. CamelCase-Alias: lon. payment_method: type: object description: >- Von der Gegenpartei verwendete Zahlungsmethode. Bei travelRule-Transaktionen deklariert `method_type: "unhosted_wallet"` die Wallet der Gegenpartei als selbstverwahrt: Der Transfer überspringt das Gegenpartei-VASP-Routing, wird direkt in `UNCONFIRMED_OWNERSHIP` erstellt und (wenn `auto_wallet_verification` aktiviert ist) wird eine Sitzung des Wallet-Ownership-Widgets automatisch erstellt und im `action_required`-Block der Transaktion zurückgegeben. properties: method_type: type: string description: >- Art der Zahlungsmethode: `bank_card`, `bank_account`, `crypto_wallet`, `ewallet`, `unhosted_wallet`, `other`. Verwenden Sie `unhosted_wallet`, um eine selbstverwahrte Wallet für die Travel Rule anzugeben. account_id: type: string description: >- Kontokennung (z. B. IBAN oder Adresse). Bei einem Krypto-Transfer auf Bitcoin oder Lightning kann es sich um eine Lightning-Zahlungsanforderung (BOLT11-Rechnung, BOLT12-Angebot, LNURL) oder eine Lightning Address handeln: Didit speichert den darin genannten Zahlungsempfänger als Konto ("", wenn keiner genannt wird) und die Angaben der Anfrage unter `chain_details.lightning` des Travel-Rule-Transfers. Nach dem Speichern maximal 255 Zeichen. Bei einem Krypto-Transfer auf Bitcoin oder Lightning kann es sich um eine Lightning-Zahlungsanforderung (BOLT11-Rechnung, BOLT12-Angebot, LNURL) oder eine Lightning Address handeln: Didit speichert den darin genannten Zahlungsempfänger als Konto ("", wenn keiner genannt wird) und die Angaben der Anfrage unter `chain_details.lightning` des Travel-Rule-Transfers. Nach dem Speichern maximal 255 Zeichen. memo: type: string maxLength: 256 description: >- Das Destination-Tag oder Memo, das Teil der Wallet in einem Memo-Netzwerk ist (XRP, XLM, EOS, ATOM, HBAR). Bei einer gemeinsamen Exchange-Adresse ist jedes Memo eine eigene Zahlungsmethode. XRP: ein Destination-Tag, eine Ganzzahl von 0 bis 4294967295 (eine JSON-Zahl wird akzeptiert). XLM: ein Text-Memo von bis zu 28 Bytes, eine 64-Bit-ID oder ein 32-Byte-Hash in hexadezimaler Form. EOS: bis zu 256 Bytes. ATOM: bis zu 256 Zeichen. HBAR: bis zu 100 Bytes. Bitcoin-, EVM-, Solana-, Tron-, Litecoin-, Bitcoin Cash-, Dogecoin- und Lightning-Wallets unterstützen kein Memo: die Angabe eines Memos führt zu einem `400`. Alias: `destinationTag` oder `destination_tag`. issuing_country: type: string custom_properties: type: object description: >- Beliebige Schlüssel-Wert-Paare, die an die Transaktion angehängt sind. Jeder Schlüssel kann in Regelbedingungen mit dem Feldpfad `custom_values.` referenziert werden. additionalProperties: true example: merchant_id: test bank_name: test_2 travel_rule_details: type: object description: >- Travel Rule-Daten. Wenn Travel Rule aktiviert ist und transaction_category travel_rule ist, führt Didit den Austausch selbst durch: status, protocol, required und obligations_count werden ignoriert, und originator_data, beneficiary_data sowie metadata werden verwendet. Andernfalls speichert Didit diese Werte als passiven Travel Rule-Datensatz. Während Travel Rule aktiviert ist, muss ein ausgehender Transfer ab Ihrem Schwellenwert die Vorgaben des jeweiligen Regelwerks enthalten (EU TFR oder FATF-Empfehlung 16), geprüft für die von Ihnen übermittelten Seiten: Ein fehlendes Feld führt zu einer 400-Antwort unter `travel_rule_details.originator_data` oder `travel_rule_details.beneficiary_data`, beispielsweise "EU TFR requires the originator name." required: - status properties: status: type: string description: >- Erforderlich, wann immer Sie travel_rule_details senden. Einer der Travel Rule-Transferstatus (zum Beispiel AWAITING_COUNTERPARTY, COMPLETED, NOT_APPLICABLE); Kleinbuchstaben- und camelCase-Schreibweisen sowie die veralteten Werte UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED und EXEMPT werden ebenfalls akzeptiert und zugeordnet. Jeder andere Wert gibt 400 zurück. protocol: type: string required: type: boolean obligations_count: type: integer originator_data: type: object description: >- Auftraggeber-Partei als flache Felder oder eine IVMS-101-Person. Für Ihren Benutzer mit einer genehmigten KYC-Verifizierung ersetzt Didit die in der Verifizierung enthaltenen Felder durch die verifizierten Werte (siehe `metadata.originator_provenance`). Es muss ein Objekt sein: alles andere führt zu einem `400`. In einem Netzwerk mit Memos gibt ein `memo`-Schlüssel das Memo oder Tag der Wallet des Auftraggebers an. beneficiary_data: type: object description: >- Begünstigter, als flache Felder oder als eine IVMS-101-Person. Es muss ein Objekt sein: alles andere führt zu einem `400`. Um die Übertragung weiterzuleiten, liest Didit `wallet_address` (ein leerer Wert wird aus `counterparty.payment_method.account_id` übernommen), `chain` (übernommen aus `transaction_details.crypto_params.crypto_chain` oder der `currency`, wenn diese eine unterstützte Chain benennt), `name` (fällt auf `counterparty.full_name` zurück), `travel_address`, `counterparty_vasp_name`, `counterparty_vasp_lei` und `counterparty_vasp_email`. In einem Memo-Netzwerk gibt `memo` das Memo oder den Tag der Wallet des Begünstigten an; `wallet_address` und `memo` haben Vorrang vor der Zahlungsmethode der Gegenpartei. metadata: type: object utxo: allOf: - $ref: '#/components/schemas/TravelRuleUtxo' description: >- Optional, nur UTXO-Chains (BTC, LTC, BCH, DOGE). Die Inputs und Outputs der Transaktion, anhand derer Didit die Wallet des Auftraggebers und den Output des Begünstigten ableitet, wenn Sie diese nicht deklarieren. originator: type: object description: >- Ein IVMS-101-Auftraggeberblock: `originatorPersons` (eine `naturalPerson` oder `legalPerson`; eine juristische Person macht die Partei zu einem Unternehmen) und `accountNumber` (Wallet-Adressen). Wird für `originator_data` verwendet, wenn dieses Objekt leer ist. Ein fehlerhafter Block antwortet mit 400, aufgeschlüsselt nach seinem Pfad, zum Beispiel `originator.originatorPersons`. beneficiary: type: object description: >- Ein IVMS-101-Begünstigtenblock: `beneficiaryPersons` (eine `naturalPerson` oder `legalPerson`; eine juristische Person macht die Partei zu einem Unternehmen) und `accountNumber` (Wallet-Adressen). Wird für `beneficiary_data` verwendet, wenn dieses Objekt leer ist. Ein fehlerhafter Block antwortet mit 400, aufgeschlüsselt nach seinem Pfad, zum Beispiel `beneficiary.beneficiaryPersons`. ivms101: type: object description: >- Die `originator`- und `beneficiary`-Blöcke, verpackt in einem IVMS-101-Objekt (`IVMS101` wird ebenfalls akzeptiert). Blöcke auf oberster Ebene haben Vorrang vor denen des Wrappers. network_snapshot: type: object description: Vorberechneter Snapshot des Netzwerkgraphen. properties: nodes: type: array items: type: object edges: type: array items: type: object metrics: type: object include_crypto_screening: type: boolean nullable: true description: >- Transaktionsbezogene Überschreibung für das Krypto-Blockchain-Analyse-Screening. Wenn `true`, wird das Krypto-Screening unabhängig vom Standardwert der Anwendung durchgeführt. Wenn `false`, wird das Krypto-Screening übersprungen, selbst wenn es in den Anwendungseinstellungen aktiviert ist. Wenn weggelassen oder `null`, wird der in der Konsole konfigurierte Standardwert auf Anwendungsebene verwendet. Das Krypto-Screening erfordert `transaction_details.direction`, `currency_kind: "crypto"`, eine Chain/Währung und die durch die Richtung ausgewählte Wallet-Adresse: Eingehendes Pre-Transfer-Screening verwendet `counterparty.payment_method.account_id`, eingehendes Transaktions-Hash-Screening verwendet `subject.payment_method.account_id` und ausgehendes Screening verwendet `counterparty.payment_method.account_id`. Wenn `transaction_details.payment_reference_id` einen Blockchain-Transaktions-Hash enthält, führt Didit ein Transaktions-Screening durch und gibt eine Transaktionszusammenfassungs-Anreicherung zurück, sofern verfügbar. required: - transaction_id - transaction_category - transaction_details - subject examples: Minimal fiat withdrawal: summary: >- Kleinster zulässiger Payload für einen ausgehenden Fiat-Transfer value: transaction_id: your-txn-2026-05-17-001 transaction_category: finance transaction_details: direction: outbound amount: 1500 currency: EUR action_type: withdrawal subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia Crypto outbound with screening: summary: >- Ausgehende Krypto-Auszahlung an eine selbstverwahrte Wallet, Opt-in-Screening value: transaction_id: your-txn-2026-05-17-002 transaction_category: finance include_crypto_screening: true transaction_details: direction: outbound amount: 0.5 currency: BTC currency_kind: crypto amount_in_default_currency: 32500 default_currency: USD action_type: withdrawal subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia payment_method: method_type: crypto_wallet account_id: bc1qexampleexchangewalletaddressxyz issuing_country: ESP counterparty: entity_type: individual payment_method: method_type: unhosted_wallet account_id: bc1qexampleexternalwalletaddressabc Travel Rule transfer: summary: >- Ausgehender Krypto-Transfer mit Travel-Rule-Daten zu Auftraggeber und Begünstigtem value: transaction_id: your-txn-2026-05-17-003 transaction_category: travel_rule transaction_details: direction: outbound amount: 25000 currency: USDT currency_kind: crypto action_type: transfer subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia date_of_birth: '1992-03-14' address: country: ESP town: Madrid street: Calle Mayor 1 post_code: '28013' counterparty: entity_type: individual full_name: John Beneficiary institution_details: name: Beneficiary VASP, Inc. code: BVASP-US travel_rule_details: status: AWAITING_COUNTERPARTY protocol: IVMS101 required: true originator_data: name: Maria Garcia beneficiary_data: name: John Beneficiary responses: '201': description: >- Transaktion übermittelt und überwacht. Der Body enthält die vollständigen Transaktionsdetails (gleiche Struktur wie bei `GET /v3/transactions/{transaction_id}/`), die alle bereits angewendeten Regelergebnisse widerspiegeln. content: application/json: schema: $ref: '#/components/schemas/TransactionDetail' examples: Approved with no rule hits: value: uuid: abcdef12-3456-4890-abcd-ef1234567890 environment: live transaction_number: 4123 txn_id: your-txn-2026-05-17-001 txn_date: '2026-05-17T08:42:00Z' zone_id: Europe/Madrid transaction_type: finance action_type: withdrawal direction: OUTBOUND status: APPROVED source: LIVE amount: '1500' currency: EUR currency_type: fiat amount_in_default_currency: '1620.45' default_currency_code: USD preferred_currency_amount: '1620.45' preferred_currency_code: USD payment_details: Withdrawal to crypto wallet payment_txn_id: null score: 0 severity: null decision_reason_code: null decision_reason_label: null vendor_data: user-12345 metadata: subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia address: {} institution_details: {} device_context: {} counterparty: {} props: {} tags: [] parties: - uuid: b1111111-2222-4333-8444-555555555555 role: APPLICANT entity_type: individual kind: USER vendor_data: user-12345 full_name: Maria Garcia first_name: null last_name: null country_code: null dob: null address: {} institution_info: {} device: {} external_party_snapshot: null payment_methods: [] documents: [] activities: - uuid: d4e5f6a7-8901-4bcd-9ef0-123456789abc activity_type: TRANSACTION_CREATED source: TRANSACTION status: APPROVED title: withdrawal description: Transaction recorded. metadata: {} occurred_at: '2026-05-17T08:42:11Z' alerts: [] rule_runs: [] provider_results: [] travel_rule: null network_snapshot: null remediation: null action_required: null cost_breakdown: null Flagged for review: value: uuid: abcdef12-3456-4890-abcd-ef1234567891 environment: live transaction_number: 4124 txn_id: your-txn-2026-05-17-002 txn_date: '2026-05-17T08:42:00Z' zone_id: Europe/Madrid transaction_type: finance action_type: withdrawal direction: OUTBOUND status: IN_REVIEW source: LIVE amount: '0.5' currency: BTC currency_type: crypto amount_in_default_currency: '32500' default_currency_code: USD preferred_currency_amount: '32500' preferred_currency_code: USD payment_details: Withdrawal to crypto wallet payment_txn_id: null score: 78 severity: HIGH decision_reason_code: WALLET_HIGH_RISK decision_reason_label: Destination wallet flagged as high risk vendor_data: user-12345 metadata: subject: entity_type: individual vendor_data: user-12345 full_name: Maria Garcia address: {} institution_details: {} device_context: {} counterparty: {} props: order_id: ord-9988 tags: [] parties: - uuid: b1111111-2222-4333-8444-555555555555 role: APPLICANT entity_type: individual kind: USER vendor_data: user-12345 full_name: Maria Garcia first_name: null last_name: null country_code: null dob: null address: {} institution_info: {} device: {} external_party_snapshot: null payment_methods: [] documents: [] activities: [] alerts: - uuid: a7b8c9d0-1234-4abc-9def-567890abcdef title: Destination wallet flagged as high risk description: Provider risk score exceeded the configured threshold. severity: HIGH status: OPEN source: RULE metadata: {} created_at: '2026-05-17T08:42:12Z' due_at: null rule_runs: - uuid: e5f6a7b8-9012-4cde-af01-23456789abcd rule: f6a7b8c9-0123-4def-b012-3456789abcde rule_title: High-risk wallet screening rule_description: null rule_category: crypto matched: true is_test: false mode: ACTIVE severity: HIGH score_delta: 78 status_target: IN_REVIEW action_summary: score +78; change_status:IN_REVIEW metadata: {} created_at: '2026-05-17T08:42:12Z' provider_results: [] travel_rule: null network_snapshot: null remediation: null action_required: null cost_breakdown: null '400': description: >- Validierung fehlgeschlagen (fehlende Pflichtfelder, doppelte `transaction_id`, unbekannter Enum-Wert, ungültige Währung usw.). content: application/json: examples: Missing required field: value: transaction_details: amount: - This field is required. Duplicate transaction_id: value: transaction_id: - A transaction with this transaction_id already exists. Invalid category: value: non_field_errors: - Unsupported transaction category. Missing subject identity: value: subject: - subject.vendor_data and subject.full_name are required. Blocklisted participant: value: vendor_data: - >- The individual 'user-12345' is in the blocklist and cannot participate in transactions. '403': description: >- Fehlender, ungültiger oder widerrufener API-Schlüssel, oder der Schlüssel kann keine Transaktionen für diese Anwendung übermitteln. Ein fehlender Schlüssel gibt `403` zurück; ein falscher, widerrufener oder abgelaufener Schlüssel gibt `401` zurück. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- Eine andere Anfrage mit derselben `transaction_id` hat die Transaktion erstellt, während diese verarbeitet wurde, sodass nur eine von zwei gleichzeitigen Übermittlungen erfolgreich ist. Rufen Sie die bestehende Transaktion ab, anstatt sie erneut zu übermitteln. content: application/json: examples: Concurrent duplicate: value: detail: A transaction with this transaction_id already exists. '429': description: >- Rate-Limit überschritten: Transaktionserstellungen und Ereignis-Ingestion (`POST /v3/transactions/`, `POST /v3/events/`, `POST /v3/events/batch/`) teilen sich ein Kontingent von 600 Anfragen pro Minute pro API-Schlüssel, getrennt von den 300, die sich alle anderen Schreibanfragen teilen. Warten Sie `Retry-After` Sekunden und versuchen Sie es dann erneut. headers: Retry-After: description: >- Anzahl der Sekunden, die vor einem Wiederholungsversuch gewartet werden muss, aufgerundet, damit der Wiederholungsversuch im nächsten Zeitfenster liegt. schema: type: integer minimum: 1 example: 30 content: application/json: examples: Throttled: value: detail: >- Ingestion rate limit exceeded. You can make up to 600 requests per minute. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: |- curl -X POST 'https://verification.didit.me/v3/transactions/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{ "transaction_id": "your-txn-2026-05-17-001", "transaction_category": "finance", "transaction_details": { "direction": "outbound", "amount": 1500, "currency": "EUR", "action_type": "withdrawal" }, "subject": { "entity_type": "individual", "vendor_data": "user-12345", "full_name": "Maria Garcia" } }' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.create( transaction_id="your-txn-2026-05-17-001", transaction_category="finance", transaction_details={ "direction": "outbound", "amount": 1500.0, "currency": "EUR", "action_type": "withdrawal", }, subject={ "entity_type": "individual", "vendor_data": "user-12345", "full_name": "Maria Garcia", }, ) 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.create({ transaction_id: "your-txn-2026-05-17-001", transaction_category: "finance", transaction_details: { direction: "outbound", amount: 1500.0, currency: "EUR", action_type: "withdrawal", }, subject: { entity_type: "individual", vendor_data: "user-12345", full_name: "Maria Garcia", }, }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Transactions.Create(ctx, didit.TransactionsCreateParams{\n\tTransactionID: \"your-txn-2026-05-17-001\",\n\tTransactionCategory: \"finance\",\n\tTransactionDetails: didit.TransactionsCreateParamsTransactionDetails{\n\t\tDirection: \"outbound\",\n\t\tAmount: 1500.0,\n\t\tCurrency: \"EUR\",\n\t\tActionType: didit.String(\"withdrawal\"),\n\t},\n\tSubject: didit.TransactionsCreateParamsSubject{\n\t\tEntityType: didit.String(\"individual\"),\n\t\tVendorData: \"user-12345\",\n\t\tFullName: \"Maria Garcia\",\n\t},\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.TransactionsCreateParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().create(TransactionsCreateParams.builder() .transactionId("your-txn-2026-05-17-001") .transactionCategory(TransactionsCreateParams.TransactionCategory.of("finance")) .transactionDetails(TransactionsCreateParams.TransactionDetails.builder() .direction(TransactionsCreateParams.TransactionDetails.Direction.of("outbound")) .amount(1500.0) .currency("EUR") .actionType("withdrawal") .build()) .subject(TransactionsCreateParams.Subject.builder() .entityType("individual") .vendorData("user-12345") .fullName("Maria Garcia") .build()) .build()); System.out.println(result); - lang: php label: PHP source: |- transactions->create([ 'transaction_id' => 'your-txn-2026-05-17-001', 'transaction_category' => 'finance', 'transaction_details' => [ 'direction' => 'outbound', 'amount' => 1500.0, 'currency' => 'EUR', 'action_type' => 'withdrawal', ], 'subject' => [ 'entity_type' => 'individual', 'vendor_data' => 'user-12345', 'full_name' => 'Maria Garcia', ], ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.create( transaction_id: "your-txn-2026-05-17-001", transaction_category: "finance", transaction_details: { direction: "outbound", amount: 1500.0, currency: "EUR", action_type: "withdrawal", }, subject: { entity_type: "individual", vendor_data: "user-12345", full_name: "Maria Garcia", } ) 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.CreateAsync(new TransactionsCreateParams { TransactionId = "your-txn-2026-05-17-001", TransactionCategory = "finance", TransactionDetails = new() { Direction = "outbound", Amount = 1500.0, Currency = "EUR", ActionType = "withdrawal", }, Subject = new() { EntityType = "individual", VendorData = "user-12345", FullName = "Maria Garcia", }, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleUtxo: type: object description: >- Die Inputs und Outputs eines UTXO-Transfers (BTC, LTC, BCH, DOGE). Wird nur auf diesen Blockchains akzeptiert: Auf jeder anderen Blockchain führt dies zu einem `400`. Daraus leitet Didit die Wallet des Auftraggebers (die deklarierte, andernfalls die Input-Adresse mit dem größten Beitrag) und den Begünstigten-Output ab (den deklarierten, andernfalls den einzigen Output, der keine Input-Adresse als Wechselgeld auszahlt, andernfalls den einen Output, der den Transferbetrag zahlt). Das Ergebnis befindet sich in `chain_details` des Transfers. required: - outputs properties: inputs: type: array maxItems: 1000 items: $ref: '#/components/schemas/TravelRuleUtxoEntry' description: >- Optional. Ohne Inputs wird kein Auftraggeber abgeleitet und kein Wechselgeld-Output (Change) erkannt. outputs: type: array minItems: 1 maxItems: 1000 items: $ref: '#/components/schemas/TravelRuleUtxoEntry' TransactionDetail: type: object description: >- Vollständiger Überwachungsdatensatz für eine Transaktion, wie von `GET /v3/transactions/{transaction_id}/` und `POST /v3/transactions/` zurückgegeben. properties: uuid: type: string format: uuid description: >- Stabiler Transaktionsbezeichner von Didit. Als `{transaction_id}` für Folgeaufrufe verwenden. environment: type: string enum: - live - sandbox description: >- Umgebung der Anwendung, zu der die Transaktion gehört. Eine `sandbox`-Transaktion wird gespeichert, aber niemals ausgewertet, gescreent, benachrichtigt oder abgerechnet, sodass ihre leeren `rule_runs` „nicht ausgewertet“ bedeuten. transaction_number: type: integer description: >- Fortlaufende Transaktionsnummer innerhalb der Anwendung, wie in der Console angezeigt (z. B. `4123`). txn_id: type: string description: >- Die `transaction_id`, die Sie bei der Erstellung angegeben haben (max. 128 Zeichen). Eindeutig pro Anwendung. txn_date: type: string format: date-time description: >- Wann die Transaktion stattgefunden hat (aus `transaction_at`; standardmäßig der Übermittlungszeitpunkt). zone_id: type: string nullable: true description: Beim Erstellen angegebene IANA-Zeitzonenkennung. transaction_type: type: string description: >- Kategorie auf oberster Ebene wie gespeichert: `finance`, `kyc`, `travelRule`, `userPlatformEvent`, `gamblingBet`, `gamblingLimitChange`, `gamblingBonusChange`, `auditTrailEvent`. Beachten Sie, dass mehrteilige Werte in camelCase zurückgegeben werden, selbst wenn sie in snake_case übermittelt wurden. action_type: type: string description: >- Untertyp innerhalb der Kategorie (z. B. `deposit`, `withdrawal`, `transfer`). Standardmäßig die Kategorie, falls nicht angegeben. direction: type: string enum: - INBOUND - OUTBOUND description: >- Richtung relativ zur betreffenden Entität. Wird unabhängig von der übermittelten Schreibweise in Großbuchstaben gespeichert (bei der Eingabe werden `in`/`out`/`inbound`/`outbound` akzeptiert). status: type: string enum: - APPROVED - IN_REVIEW - DECLINED - AWAITING_USER description: >- Aktuelles Überwachungsergebnis. Transaktionen werden als `APPROVED` erstellt; Regeln können sie synchron auf `IN_REVIEW`/`DECLINED` umstellen. source: type: string enum: - LIVE - IMPORTED description: >- Wie der Datensatz entstanden ist: `LIVE` für Transaktionen, die über die API oder das SDK übermittelt wurden, `IMPORTED` für Transaktionen, die über den Import in der Konsole geladen wurden. amount: type: string description: >- Transaktionsbetrag als Dezimalstring ohne nachgestellte Nullen (z. B. `"1500"`, `"0.5"`, `"0.123456789012345678"`). Bis zu 18 Dezimalstellen. currency: type: string description: >- Währungscode von `amount`. Jeder alphabetische ISO-4217-Code wird akzeptiert (z. B. `EUR`, `USD`, `NGN`), ebenso wie ein Krypto-Asset-Symbol (z. B. `BTC`). Bevorzugen Sie einen aktuell im Umlauf befindlichen Code. Nicht jeder akzeptierte Code verfügt über einen Wechselkurs: Wenn für den Code keiner verfügbar ist (beispielsweise die ISO-Verrechnungseinheit `XSU` oder ein Krypto-Symbol, für das Didit keine Kurse bereitstellt), schlägt die automatische Konvertierung fehl und `preferred_currency_amount` wird als null zurückgegeben, es sei denn, die Anfrage enthielt einen vorkonvertierten Wert für `amount_in_default_currency`. currency_type: type: string nullable: true description: '`fiat` oder `crypto`, wie in `currency_kind` übermittelt.' amount_in_default_currency: type: string nullable: true description: >- Von Ihnen übermittelter, vorab umgerechneter Betrag als Dezimal-String ohne nachgestellte Nullen. default_currency_code: type: string nullable: true preferred_currency_amount: type: string nullable: true description: >- `amount` umgerechnet in die bevorzugte Währung der Anwendung, sofern verfügbar. preferred_currency_code: type: string nullable: true payment_details: type: string nullable: true description: >- Freitext-Zahlungsreferenz oder -Verwendungszweck aus der Übermittlung. payment_txn_id: type: string nullable: true description: >- Externe Zahlungssystem-Referenz (z. B. Blockchain-Transaktions-Hash) aus `payment_reference_id`. score: type: integer description: >- Durch Regeln kumulierter Risiko-Score (typischerweise 0–100). Höher = riskanter. severity: type: string nullable: true enum: - UNKNOWN - LOW - MEDIUM - HIGH - CRITICAL description: >- Kategorische Risikoschwere, festgelegt durch Regeln/Anbieter (`UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`). `null`, bis ein Wert festgelegt wird. decision_reason_code: type: string nullable: true description: Maschinenlesbarer Grund für den aktuellen `status`. decision_reason_label: type: string nullable: true description: Lesbare Bezeichnung für `decision_reason_code`. vendor_data: type: string nullable: true description: Bequemlichkeitskopie der `vendor_data` des Antragstellers. metadata: type: object description: >- Snapshot der Payloads von `subject` und `counterparty`, wie sie zum Zeitpunkt der Erstellung übermittelt wurden. props: type: object description: >- Die `custom_properties`, die Sie bei der Erstellung angegeben haben. Jeder Schlüssel kann in Regelbedingungen als `custom_values.` adressiert werden. tags: type: array items: type: object properties: uuid: type: string format: uuid name: type: string color: type: string description: type: string nullable: true source: type: string enum: - didit - custom description: >- Gibt an, ob das Tag eine Didit-Voreinstellung oder ein benutzerdefiniertes Tag ist. description: An die Transaktion angehängte Tags (manuell oder durch Regeln). parties: type: array items: type: object properties: uuid: type: string format: uuid role: type: string enum: - APPLICANT - REMITTER - BENEFICIARY - COUNTERPARTY description: >- Rolle der Partei. Der Erstellungs-Endpoint weist `APPLICANT` (das Subjekt) und `COUNTERPARTY` zu. entity_type: type: string enum: - individual - company - external - unhostedWallet kind: type: string enum: - USER - BUSINESS - EXTERNAL description: >- `USER`/`BUSINESS`-Parteien verweisen über `vendor_data` zurück auf eine Didit-eigene Entität. Hinter `EXTERNAL`-Parteien steht keine Didit-Entität. vendor_data: type: string nullable: true description: Ihre interne Benutzer-/Unternehmenskennung. full_name: type: string nullable: true first_name: type: string nullable: true last_name: type: string nullable: true country_code: type: string nullable: true description: >- Ländercode aus der übermittelten `address.country` (üblicherweise ISO 3166-1 Alpha-3). dob: type: string format: date nullable: true description: Geburtsdatum aus dem übermittelten `date_of_birth`. address: type: object description: Adressobjekt wie übermittelt. `{}` bei Auslassung. institution_info: type: object description: >- Details zur Institution wie übermittelt. `{}`, wenn sie weggelassen wurden. device: type: object description: >- Normalisierter Gerätekontext, einschließlich serverseitiger IP-Anreicherung unter network_context (Geolokalisierung, VPN-/Rechenzentrums-Flags), wenn eine IP angegeben wurde. properties: fingerprint: type: string description: Eindeutiger Geräte-Fingerabdruck. persistent_device_id: type: string description: >- Stabiler sitzungsübergreifender Geräteidentifikator (v2-Fingerprint-Schema). user_agent: type: string description: User-Agent-String des Browsers oder der App. browser_family: type: string description: Browser-Familie (z. B. Chrome, Firefox, Safari). browser_version: type: string description: Browser-Versions-String. platform: type: string description: >- Plattform-Identifikator (web, ios, android, macos, windows, linux). os_family: type: string description: Betriebssystemfamilie (z. B. iOS, Android, Windows). os_version: type: string description: Versionszeichenfolge des Betriebssystems. accept_language: type: string description: Wert des Accept-Language-Headers. session_id: type: string description: Sitzungskennung (in Metadaten gespeichert). session_age_ms: type: number description: Sitzungsalter in Millisekunden. network_context: type: object description: Netzwerkkontext mit IP-Adresse und Geolokalisierung. properties: ip_address: type: string description: Client-Adresse. ip_country_code: type: string description: >- Per Geo-IP aufgelöstes Land der IP-Adresse (ISO 3166-1 alpha-3). latitude: type: number description: Geografische Breite der IP-Adresse. longitude: type: number description: Geografische Länge der IP-Adresse. external_party_snapshot: type: object nullable: true description: >- Eingefrorene Kopie der Parteidaten für `EXTERNAL`-Parteien. `null`, solange die Partei mit einem Didit-Benutzer oder -Unternehmen verknüpft ist. description: Transaktionsparteien (Antragsteller, Gegenpartei). payment_methods: type: array items: type: object properties: uuid: type: string format: uuid payment_method_type: type: string enum: - bank_card - bank_account - e_wallet - crypto_wallet - unhosted_wallet - other label: type: string nullable: true fingerprint: type: string nullable: true description: >- SHA-256 über `type:account_id:issuing_country` — stabiler Identifikator, um die Wiederverwendung desselben Instruments zuzuordnen. account_id: type: string nullable: true description: Kontokennung (IBAN, Adresse, Karten-Token, …). issuing_country: type: string nullable: true owner_kind: type: string enum: - USER - BUSINESS - EXTERNAL vendor_data: type: string nullable: true description: >- Ihre Kennung für den Benutzer bzw. das Unternehmen, dem die Ressource gehört. owner_name: type: string nullable: true institution_info: type: object details: type: object description: Unverarbeitetes `payment_method`-Objekt wie übermittelt. external_owner_snapshot: type: object nullable: true role: type: string enum: - SOURCE - DESTINATION - FUNDING - BENEFICIARY description: >- Wie diese Methode in der Transaktion verwendet wurde. Der Endpoint zum Erstellen weist `SOURCE`/`DESTINATION` basierend auf der Richtung zu (ausgehend: Subjekt = SOURCE; eingehend: Subjekt = DESTINATION). description: Mit der Transaktion verknüpfte Zahlungsmethoden. documents: type: array description: >- Dateien, die der Transaktion über die Konsole angehängt wurden. `[]`, wenn keine vorhanden sind. items: type: object properties: uuid: type: string format: uuid label: type: string nullable: true note: type: string nullable: true uploaded_by: type: string nullable: true created_at: type: string format: date-time files: type: array items: type: object properties: uuid: type: string format: uuid file_url: type: string format: uri nullable: true description: >- Kurzlebige signierte Download-URL; rufen Sie sie bei Bedarf ab, anstatt sie zu speichern. original_filename: type: string nullable: true file_size: type: integer nullable: true activities: type: array items: type: object properties: uuid: type: string format: uuid activity_type: type: string description: >- Z. B. `TRANSACTION_CREATED`, `TRANSACTION_NOTE_ADDED`, `TRANSACTION_STATUS_CHANGED`. source: type: string status: type: string nullable: true title: type: string nullable: true description: type: string nullable: true metadata: type: object occurred_at: type: string format: date-time description: >- Einträge im Aktivitätsprotokoll (Erstellung, Notizen, manuelle Prüfungen, Statusänderungen). alerts: type: array items: type: object properties: uuid: type: string format: uuid title: type: string description: type: string nullable: true severity: type: string enum: - UNKNOWN - LOW - MEDIUM - HIGH - CRITICAL status: type: string enum: - OPEN - INVESTIGATING - AWAITING_USER - PENDING_SAR - SAR_FILED - RESOLVED - DISMISSED source: type: string enum: - RULE - PROVIDER - MANUAL metadata: type: object created_at: type: string format: date-time due_at: type: string format: date-time nullable: true description: >- Aktuell immer leer. Ein offener Alert ist eine Transaktion mit dem Status `IN_REVIEW` oder `AWAITING_USER`. rule_runs: type: array items: type: object properties: uuid: type: string format: uuid rule: type: string format: uuid description: UUID der Regel, die ausgeführt wurde. rule_title: type: string rule_description: type: string nullable: true rule_category: type: string matched: type: boolean description: >- Gibt an, ob die Bedingungen der Regel auf diese Transaktion zutrafen. Ein Durchlauf wird nur für übereinstimmende Regeln aufgezeichnet, daher tragen Live-Auswertungen immer `true`. is_test: type: boolean description: >- True, wenn die Regel im TEST-Modus ausgeführt wurde (keine Auswirkung auf Status/Score). mode: type: string enum: - ACTIVE - DISABLED - TEST severity: type: string nullable: true score_delta: type: integer description: >- Score, der durch die `add_score`-Aktionen dieser Regel hinzugefügt wurde. status_target: type: string nullable: true description: >- Status, der durch eine `change_status`-Aktion festgelegt wurde, falls vorhanden. action_summary: type: string nullable: true description: >- Zusammenfassung der von der Regel ausgeführten Aktionen, getrennt durch `; ` (z. B. `score +30; change_status:IN_REVIEW; add_tag:high_risk_country`). Bestandteile: `score +N`, `change_status:`, `add_tag:`, `add_note`, `add_to_list`, `open_case`. `null`, wenn die Regel keine Aktion ausgeführt hat. metadata: type: object description: >- Evaluierungsdetails: `scope_match`, `conditions[]` und `aggregations[]`. Jeder Bedingungseintrag enthält `field`, `operator`, `expected_value`, den aus der Transaktion gelesenen `current_value`, `matched`, `group_index` und `group_logic`. Jeder Aggregationseintrag (Velocity / Anzahl / Summe) enthält `metric`, `field`, `operator`, `expected_value`, den berechneten Wert `computed_value`, auf den das Aggregat ausgewertet wurde, `window`, `filters`, `matched` und `sample_references`; verzögerte asynchrone Aggregationen weisen `computed_value: null` und `deferred: true` auf. Eine verschachtelte Bedingungsgruppe ist ein Eintrag in `conditions[]` mit `operator` `any_of` oder `all_of`, `field` null und den Ergebnissen ihrer Elemente unter ihren eigenen `conditions`. created_at: type: string format: date-time description: >- Ausführungsergebnisse pro Regel – welche Regel ausgelöst wurde und mit welcher Auswirkung auf den Score. provider_results: type: array items: type: object properties: uuid: type: string format: uuid provider: type: string result_type: type: string enum: - FIAT_MONITORING - WALLET_SCREENING - TRANSACTION_SCREENING - TRAVEL_RULE - NETWORK_GRAPH - CUSTOM status: type: string severity: type: string nullable: true score: type: integer summary: type: string nullable: true payload: type: object description: Unverarbeitete Antwort-Payload des Anbieters. created_at: type: string format: date-time description: >- Unverarbeitete Provider-Payloads (AML-Screening, Blockchain-Analysen usw.). travel_rule: nullable: true allOf: - $ref: '#/components/schemas/TransactionTravelRule' description: >- Travel Rule-Transfer oder -Prüfung. Wird ausgefüllt, wenn `travel_rule_details` übermittelt wurde, sowie wenn Travel Rule aktiviert ist und die Transaktion mit `transaction_category: travelRule` erstellt wurde (Didit initiiert den Austausch selbst, auch ohne `travel_rule_details`). `null`, wenn kein Transfer oder keine Prüfung existiert. Bei einem eingehenden Transfer bleiben `originator_data` und `beneficiary_data` der Gegenpartei maskiert (`data_masked: true`), bis die Wallet-Inhaberschaft bestätigt ist. network_snapshot: type: object nullable: true description: >- Graph-Snapshot verknüpfter Transaktionen/Parteien, der von der Regel-Engine verwendet wird. Entweder der mit der Transaktion übermittelte `network_snapshot` oder der Graph, den Didit aus einem erfolgreichen AML-Wallet-Screening erstellt (der einen übermittelten ersetzt). `null`, wenn keines von beiden existiert. properties: uuid: type: string format: uuid nodes: type: array items: type: object edges: type: array items: type: object metrics: type: object remediation: type: object nullable: true description: >- Korrektursitzung, die dem Benutzer angeboten wird, wenn eine erneute Verifizierung erforderlich ist. Abgelöst durch `action_required`, den kanonischen Block; aus Gründen der Abwärtskompatibilität beibehalten. properties: session_id: type: string session_token: type: string url: type: string format: uri status: type: string action_required: type: object nullable: true description: >- Ausstehende Endbenutzer-Aktion, die zum Abschluss dieser Transaktion erforderlich ist, oder null, wenn keine vorhanden ist. Die Didit-SDKs starten die Aktion standardmäßig automatisch und aktualisieren die Transaktion nach deren Abschluss. Zwei Varianten, unterschieden durch `type`: `verification_session` (eine gehostete Verifizierungssitzung, die durch eine Regelaktion erstellt wurde) und `wallet_ownership` (eine Sitzung des Wallet-Ownership-Widgets, die für einen Travel-Rule-Transfer automatisch erstellt wurde, der einen Nachweis der Wallet-Kontrolle benötigt, gesteuert durch die Travel-Rule-Einstellung `auto_wallet_verification`). Wenn beide zutreffen könnten, hat `wallet_ownership` Vorrang, da sie den Travel-Rule-Austausch blockiert. oneOf: - $ref: '#/components/schemas/TransactionVerificationSessionAction' - $ref: '#/components/schemas/TransactionWalletOwnershipAction' discriminator: propertyName: type mapping: verification_session: '#/components/schemas/TransactionVerificationSessionAction' wallet_ownership: '#/components/schemas/TransactionWalletOwnershipAction' cost_breakdown: type: object nullable: true description: >- Kosten dieser Transaktion: `total_price` und `items`, eine pro Belastung, jeweils mit `usage_type`, `price`, `details` und `created_at`. Eine erneute Überprüfung derselben Transaktion ist ein neues Element. 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. TransactionTravelRule: type: object description: >- Der Travel-Rule-Transfer einer Transaktion, wie `GET /v3/transactions/{transaction_id}/`, der `201`-Status von `POST /v3/transactions/` und jede Zeile von `GET /v3/transactions/` ihn zurückgeben. `direction`, `rail`, `counterparty_vasp`, `delivery`, `discovery`, `reason` und `next_actions` haben dieselbe Struktur wie bei `PATCH /v3/transactions/{transaction_id}/travel-rule/`, sodass ein einziger Lesevorgang einer Transaktion zeigt, warum ihr Transfer feststeckt und was ihn weiterbringt. properties: uuid: type: string format: uuid status: type: string protocol: type: string nullable: true required: type: boolean obligations_count: type: integer 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: type: object nullable: true description: >- Der Namensabgleich, der über den Transfer entschieden hat (Wert und Strenge). Null, bis einer ausgeführt wurde. Die verglichenen Namen werden zusammen mit den Parteien maskiert. 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. metadata: type: object direction: type: string enum: - INBOUND - OUTBOUND description: Welche Seite des Austauschs diese Überweisung darstellt. rail: type: string nullable: true description: >- Die Schiene (Rail), über die der Transfer lief: `INTERNAL`, `TRP`, `GTR`, `TRUST`, `VERIFYVASP`, `SYGNA` oder `EMAIL` (`TEST_VASP` bei einer Sandbox-Anwendung, wenn der Didit Test VASP geantwortet hat), oder `null`, bis eine Schiene ausgewählt ist. 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. description: >- Der Verzeichniseintrag der Gegenpartei oder `null`, wenn der Transfer mit keinem verknüpft ist. delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Die neueste Nachricht, die der Transfer einer anderen Partei schuldet. `null`, wenn er keine geschuldet hat, beispielsweise unter `threshold_amount` oder bei einer deklarierten selbstverwahrten Wallet. 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' TransactionVerificationSessionAction: title: Verification session type: object properties: type: type: string enum: - verification_session url: type: string format: uri description: >- Gehostete Verifizierungs-URL, die für den Endbenutzer geöffnet werden soll. session_id: type: string format: uuid description: ID der Verifizierungssitzung. session_token: type: string description: >- Sitzungs-Token, das von den mobilen SDKs verwendet wird, um den Ablauf nativ zu starten. status: type: string description: Status der Verifizierungssitzung. required: - type - url TransactionWalletOwnershipAction: title: Wallet ownership type: object properties: type: type: string enum: - wallet_ownership url: type: string format: uri description: >- URL des gehosteten Widgets zum Nachweis der Wallet-Inhaberschaft. Öffnen Sie sie in einer echten Browseroberfläche – verwenden Sie auf Mobilgeräten SFSafariViewController oder einen Chrome Custom Tab, niemals eine eingebettete Webview. widget_session_id: type: string format: uuid description: Sitzungs-ID des Wallet-Eigentums-Widgets. expires_at: type: string format: date-time description: Wann die Widget-Sitzung abläuft. required: - type - url 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). 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.