> ## 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überwachung Statuswerte: Transaktion & Fall > Didit-Referenz aller Transaktions-, Fall- und Travel-Rule-Status mit Übergängen. 1,000 Transaktionen/Monat inklusive, dann $0.001 je. Transaktionsüberwachung verwendet drei getrennte Statusmaschinen: die **Transaktion**, jeden **Fall** und (sofern zutreffend) die **Travel-Rule-Prüfung**. Diese Seite ist die Referenz. ## Transaktionsstatus Wird bei der Erstellung gesetzt und während des Lebenszyklus aktualisiert. | Status | Bedeutung | | - | - | | `APPROVED` | Die Transaktion hat alle unten genannten Regeln unterhalb des Prüfschwellenwerts bestanden. | | `IN_REVIEW` | Der Score hat den Prüfschwellenwert überschritten, oder eine Regel hat ausdrücklich eine Prüfung verlangt. Aufmerksamkeit des Analysten erforderlich. | | `DECLINED` | Der Score hat den Ablehnungsschwellenwert überschritten, oder eine Regel hat die Transaktion ausdrücklich abgelehnt. Transaktion abgelehnt. | | `AWAITING_USER` | Der Benutzer muss handeln, bevor die Transaktion abgewickelt werden kann. Didit setzt diesen Status nur über eine Regel: entweder über die Aktion `change_status` einer Regel (zum Beispiel die Opt-in-Bibliotheksregel `travel-rule-pending-action`, die bei einem Travel-Rule-Transfer in `ON_HOLD` auslöst) oder über eine Regelaktion, die eine zusätzliche Verifizierung erforderlich gemacht hat (eine Korrektursitzung wurde erstellt). Ein Travel-Rule-Transfer, der einen Nachweis der Wallet-Kontrolle benötigt, setzt diesen Status nicht allein: Die Transaktion behält den Status, den Ihre Regeln ihr zuweisen (in der Regel `APPROVED`), und der Block `action_required` enthält die URL zur Wallet-Eigentumsprüfung, sobald eine Widget-Sitzung aussteht. Lesen Sie den Block `action_required` der Transaktion für die konkrete Aktion und die konkrete URL. | ### Übergänge ```mermaid theme={null} stateDiagram-v2 [*] --> APPROVED: Score < review threshold, no blocking rules [*] --> IN_REVIEW: Score >= review threshold [*] --> DECLINED: Score >= decline threshold, or rule decline action [*] --> AWAITING_USER: Rule action change_status → AWAITING_USER IN_REVIEW --> APPROVED: Analyst cleared IN_REVIEW --> DECLINED: Analyst declined AWAITING_USER --> APPROVED: Remediation session approved AWAITING_USER --> DECLINED: Remediation session declined AWAITING_USER --> IN_REVIEW: Remediation session ended in review ``` Hinweis: Außerhalb der Travel Rule gibt es keinen direkten Übergang von `APPROVED` oder `DECLINED` zurück in andere Status. Bei Ablauf einer Travel-Rule-Frist setzt Ihr `timeout_outcome` den Status auf `IN_REVIEW` (`HOLD`) oder `DECLINED` (`REJECT`), unabhängig vom aktuellen Status. Eine Regel, die nach einem Travel-Rule-Übergang auslöst, kann eine `APPROVED`-Transaktion ändern. Verwenden Sie für Korrekturen Status-Patches über die Konsole; diese werden im Audit-Log protokolliert. ## Alerts Es gibt keinen eigenen Alert-Status. Ein offener Alert ist eine Transaktion im Status `IN_REVIEW` oder `AWAITING_USER`. Verwenden Sie daher den oben beschriebenen Transaktionsstatus. Siehe [Alerts](https://docs.didit.me/de/transaction-monitoring/alerts.md). ## Fallstatus Siehe [Fallmanagement](https://docs.didit.me/de/console/case-management/cases.md) für alle Details. | Status | Bedeutung | | - | - | | `OPEN` | Wird aktiv untersucht. | | `AWAITING_USER` | Wartet auf Eingaben des Benutzers. | | `RESOLVED` | Mit einer Auflösung abgeschlossen: `FALSE_POSITIVE`, `VALID_THREAT`, `INCONCLUSIVE`, `REQUIREMENTS_NOT_MET` oder `REQUIREMENTS_SATISFIED`. | Fälle haben eine separate **Priorität** (`LOW`, `MEDIUM`, `HIGH`). ## Status der Travel-Rule-Prüfung Transfers virtueller Vermögenswerte nach der FATF Travel Rule durchlaufen einen eigenen Austausch mit 13 Zuständen, der getrennt vom oben beschriebenen Transaktionsstatus läuft. Ein ausgehender Transfer beginnt in `AWAITING_COUNTERPARTY`, `NOT_APPLICABLE` (unterhalb von `threshold_amount`), `UNCONFIRMED_OWNERSHIP` (Wallet der Gegenpartei als selbstverwahrt deklariert), `COMPLETED` oder `COUNTERPARTY_MISMATCHED_DATA` (ein `INTERNAL`-Abgleich mit einer verifizierten Wallet, abhängig vom Namensabgleich), `COUNTERPARTY_VASP_NOT_FOUND` oder `COUNTERPARTY_VASP_NOT_REACHABLE`. Ein eingehender Transfer kann auch in `ON_HOLD` oder `NOT_ENOUGH_COUNTERPARTY_DATA` beginnen. Eine Sunrise-Registrierung, die einer verifizierten Wallet entspricht, mit übereinstimmendem oder fehlendem Namen des Begünstigten, geht direkt über `COMPLETED` nach `FINISHED`. Der Austausch endet in `FINISHED`, `CANCELLED` oder `EXPIRED`. | Status | Bedeutung | | - | - | | `AWAITING_COUNTERPARTY` | An die Gegenpartei gesendet; wartet auf deren Antwort. Ein über TRUST gesendeter Transfer bleibt in diesem Status, bis er abläuft, weil TRUST nichts zurücksendet, was Didit lesen kann. In einer Sandbox-Anwendung geht der Transfer an den [Didit Test VASP](https://docs.didit.me/de/transaction-monitoring/travel-rule-sandbox.md), der innerhalb von Didit mit dem von Ihnen gewählten Szenario antwortet. | | `UNCONFIRMED_OWNERSHIP` | Eigentum an der Wallet des Begünstigten noch nicht nachgewiesen. | | `ON_HOLD` | Didit setzt diesen Status nur bei eingehenden Transfers: bei einer Sunrise-Registrierung oder einer eingehenden `TRP`-Anfrage, deren Wallet nicht in Ihrem Adressbuch steht (oder, bei einer reinen Namensanfrage, deren Name zu keinem einzelnen verifizierten Inhaber passt), oder bei einer eingehenden `TRP`-Anfrage, die Ihre manuelle Entscheidung erfordert (automatische Annahme ist deaktiviert, oder die automatische Antwort konnte nicht zugestellt werden). Der Transaktionsstatus ändert sich dadurch nicht von selbst. Die Opt-in-Bibliotheksregel `travel-rule-pending-action` setzt `AWAITING_USER`. Lösen Sie diesen Status mit `POST /v3/transactions/{id}/travel-rule/ownership/`. | | `COMPLETED` | Daten von Auftraggeber und Begünstigtem stimmen überein; die Transaktion kann sicher On-Chain übertragen werden. | | `FINISHED` | On-Chain-Hash gemeldet; Austausch abgeschlossen. | | `CANCELLED` | Aus einem nicht endgültigen Status abgebrochen. | | `EXPIRED` | Die Bestätigungsfrist ist abgelaufen. Nur ein Transfer, der bei Fristablauf noch in `AWAITING_COUNTERPARTY` ist, läuft ab. Die Prüfung erfolgt alle 15 Minuten; andere Status laufen nie ab. Ihr `timeout_outcome` wird auf die Transaktion angewendet, und diese Änderung sendet keinen Webhook `transaction.status.updated`. | | `COUNTERPARTY_MISMATCHED_DATA` | Der Name des Begünstigten stimmt nicht überein. | | `COUNTERPARTY_VASP_NOT_FOUND` | Kein Kanal konnte die Gegenpartei auflösen. | | `COUNTERPARTY_VASP_NOT_REACHABLE` | Gegenpartei identifiziert, aber Didit konnte nicht zustellen: Ihr `TRP`-Endpoint war nicht erreichbar oder meldete eine andere oder fehlende LEI oder einen anderen Namen, oder ein Netzwerk-Kanal (GTR, TRUST, VerifyVASP, Sygna Bridge) konnte die Nachricht nicht zustellen. | | `COUNTERPARTY_VASP_GENERAL_DECLINE` | Die Gegenpartei hat den Austausch abgelehnt. | | `NOT_ENOUGH_COUNTERPARTY_DATA` | Eine eingehende `TRP`-Anfrage hat den Begünstigten weder über den Namen noch über die Adresse identifiziert. Für diesen Status gibt es keine Frist, und der Endpoint für die Eigentumsprüfung kann ihn nicht auflösen. Brechen Sie ihn daher mit `action: "cancel"` ab; der Absender wird nicht benachrichtigt. Didit setzt ihn nie bei einem ausgehenden Transfer; er erscheint dort nur, wenn Sie ihn selbst erfassen, und Sie können einen solchen Transfer mit `action: "resend"` erneut versuchen. | | `NOT_APPLICABLE` | Unterhalb von `threshold_amount`, daher wurde nichts ausgetauscht, oder ein von Ihnen erfasster Wert bei einem Transfer, den Didit nicht ausführt (Travel Rule deaktiviert, eine Transaktion, deren Typ nicht `travelRule` ist, oder ein veralteter Wert). | Ältere Integrationen senden möglicherweise noch die veralteten Werte `UNKNOWN`, `COMPLIANT`, `PENDING_ACTION`, `PENDING_COUNTERPARTY`, `FAILED` und `EXEMPT`. Didit ordnet sie automatisch den oben genannten Status zu. Siehe [Travel Rule](https://docs.didit.me/de/transaction-monitoring/travel-rule.md#lebenszyklus) für die maßgebliche Referenz. ## Status der Anbieterergebnisse Jedes Ergebnis eines externen Anbieters (Wallet-Screening, Fiat-Überwachung, Sanktions-Screening) wird mit einem eigenen Status gespeichert. Der Status wird unter `provider_results[]` in der Transaktionsantwort ausgegeben. | Status | Bedeutung | | - | - | | `PENDING` | Die Abfrage beim Anbieter läuft. | | `COMPLETED` | Das Ergebnis wurde erfolgreich zurückgegeben. | | `FAILED` | Der Anbieter hat einen Fehler gemeldet oder die Anfrage ist in ein Timeout gelaufen. | | `SKIPPED` | Der Anbieter wurde bewusst übersprungen (z. B. weil die Transaktion unterhalb des Schwellenwerts liegt). | ## Ergebnisse der Regelausführung Jeder `TransactionRuleRun` enthält: * `matched` (boolean): Wurde die Regel ausgelöst? * `is_test` (boolean): War die Regel zum Zeitpunkt der Auswertung im TEST-Modus? * `mode`: `ACTIVE`, `DISABLED` oder `TEST` zum Zeitpunkt der Auswertung. * `score_delta`: Beitrag zum Score (falls die Regel ausgelöst wurde und aktiv war). * `status_target`: Der Status, den die Regel angefordert hat (bei der Aktion `change_status`). Den Aufbau einer Regel finden Sie unter [Regeln](https://docs.didit.me/de/transaction-monitoring/rules.md). ## Codes für Entscheidungsgründe Häufige `reason`-Werte bei Statusübergängen: | Grund | Bedeutung | | - | - | | `rule_score_threshold` | Der Score hat den Schwellenwert für Prüfung oder Ablehnung überschritten. | | `rule_change_status` | Die Aktion `change_status` einer Regel hat einen Status erzwungen. | | `analyst_approved` / `analyst_declined` / `analyst_cleared` | Manuelle Aktion des Analysten. | | `user_action_approved` / `user_action_declined` / `user_action_in_review` | Ergebnis der verknüpften Remediation-Sitzung (die Benutzeraktion, die im Status `AWAITING_USER` angefordert wurde). | | `provider_update` | Der externe Anbieter hat das Ergebnis aktualisiert. | | `aml_confirmed_sanction` | Das AML-Screening hat eine Übereinstimmung mit einer Sanktionsliste bestätigt. | | `blocklist_applicant` / `blocklist_counterparty` | Durchsetzung der Sperrliste für eine Partei. | ## Nächste Schritte > [card] [Risiko-Scoring](https://docs.didit.me/de/transaction-monitoring/risk-scoring.md) > > Wie Scores auf Status abgebildet werden. > [card] [Alerts](https://docs.didit.me/de/transaction-monitoring/alerts.md) > > Lebenszyklus eines Alerts. > [card] [Fälle](https://docs.didit.me/de/transaction-monitoring/cases.md) > > Lebenszyklus eines Falls. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.