> ## 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. # KYT-Fehlerbehebung: häufige Probleme & Lösungen > Didit KYT-Fehler beheben: txn_id-Kollisionen, Regeln ohne Auslösung, AML-Timeouts, Webhook-Signaturfehler, Währungsfallen – mit Lösungen. Eine Referenz häufiger Probleme mit Transaktionsüberwachung, mit Symptom, Ursache und Behebung. ## Fehler wegen doppelter `txn_id` **Symptom.** Beim Absenden einer Transaktion gibt die Anfrage `400` mit `A transaction with this transaction_id already exists.` im Feld `transaction_id` zurück, oder `409`, wenn zwei identische Anfragen gleichzeitig eintreffen. **Ursache.** `txn_id` (die `transaction_id`, die Sie senden) ist pro Anwendung eindeutig. Didit lehnt eine zweite Transaktion mit derselben `transaction_id` ab und gibt den vorhandenen Datensatz nicht zurück. **Behebung.** * Erzeugen Sie `txn_id` auf Ihrer Seite deterministisch (z. B. mit der ID aus Ihrer eigenen Transaktionsdatenbank). * Suchen Sie bei einem `400` oder `409` wegen einer doppelten `transaction_id` während eines Wiederholungsversuchs die bestehende Transaktion nach, statt sie erneut zu senden. Lesen Sie sie mit [`GET /v3/transactions/{uuid}/`](https://docs.didit.me/de/management-api/transactions/get) unter Verwendung der `uuid` aus der ersten Antwort, oder verwenden Sie die `transaction_id` (die Didit-UUID), die der Webhook `transaction.created` neben Ihrer `txn_id` mitliefert. * Handelte es sich nicht um einen Wiederholungsversuch, geben Sie der neuen Transaktion eine eigene `transaction_id`. ## Regel wird nicht ausgelöst **Symptom.** Sie haben eine Regel erstellt, die greifen sollte, aber bei keiner Transaktion erscheint sie in `rule_runs[]` mit `matched: true`. **Ursachen und Behebungen.** * **Die Anwendung befindet sich im Sandbox-Modus** – In einer Sandbox-Anwendung werden keine Regeln ausgewertet, kein AML-Screening durchgeführt, keine Abrechnung erstellt und keine Webhooks `transaction.created` und `transaction.status.updated` gesendet. Travel-Rule-Austausche laufen bei aktivierter Option weiterhin, und zwar gegen den [Didit Test VASP](https://docs.didit.me/de/transaction-monitoring/travel-rule-sandbox.md). Sie liefern Webhooks `travel_rule.status.updated` mit `environment: sandbox`. `rule_runs` ist leer und der Score bleibt `0`, unabhängig vom Modus Ihrer Regeln. Die Transaktion bleibt `APPROVED`, es sei denn, ein ablaufender Travel-Rule-Transfer wendet Ihr `timeout_outcome` an. Prüfen Sie `environment` in der Transaktionsantwort: `"sandbox"` bedeutet, dass sie nie ausgewertet wurde. Unter [Transaction Monitoring in der Sandbox](https://docs.didit.me/de/integration/sandbox-testing.md#transaktionsüberwachung-in-der-sandbox) erfahren Sie, wie Sie eine Regel validieren, bevor sie live geht. * **Der Regelmodus ist `DISABLED` oder `TEST`** – Prüfen Sie *Rules → \[rule] → Mode*. Nur `ACTIVE`-Regeln fließen in die Bewertung ein. `TEST`-Regeln werten aus, beeinflussen den Status aber nicht. * **Der Geltungsbereichsfilter schließt die Transaktion aus** – Der auf `transaction_type = finance` gesetzte Geltungsbereich passt z. B. nicht auf `travelRule`-Transaktionen. * **Das Aggregationsfenster ist kürzer als nötig** – Eine Regel „20 Transaktionen in 30 Tagen“ greift nicht, wenn erst 15 Transaktionen vorliegen. * **Das Bedingungsfeld ist null** – Ihre Regel prüft z. B. `counterparty.country_code`, Sie haben aber keine Gegenpartei übermittelt. * **Währungsumrechnung** – Die Regel vergleicht Schwellenwerte mit `amount_in_default_currency`. Weicht die Standardwährung Ihrer Anwendung von der Transaktionswährung ab, kann der umgerechnete Betrag unter dem Schwellenwert liegen. Mit der Funktion *Rules → \[rule] → Backtest* spielen Sie eine vergangene Transaktion erneut ab und sehen, warum die Regel ausgelöst wurde oder nicht. ## Regel wird bei allen Transaktionen ausgelöst **Symptom.** Eine Regel wird bei 90%+ der Transaktionen ausgelöst, und Ihre Prüfwarteschlange ist überflutet. **Ursache.** Die Bedingungen sind zu breit gefasst oder die Schwellenwerte zu niedrig. **Behebung.** * Fügen Sie `scope`-Filter hinzu, um die Anwendbarkeit einzugrenzen (z. B. nur ausgehende Transaktionen oder nur bestimmte Transaktionstypen). * Erhöhen Sie die Schwellenwerte (Beträge, Anzahl der Transaktionen innerhalb eines Zeitraums). * Setzen Sie die Regel eine Woche lang in den Modus `TEST`. Werten Sie die `rule_runs` aus, um die Trefferquote zu sehen, und schärfen Sie die Bedingungen, bevor Sie die Regel wieder aktivieren. ## Krypto-Screening mit Zeitüberschreitung **Symptom.** Die Transaktion wurde mit `status: APPROVED` abgeschlossen, aber das Array `provider_results[]` zeigt `status: FAILED` für eine Wallet, einen Transaktionshash oder einen Anbieter für das Krypto-Screening. **Ursachen.** * Die API des Anbieters war kurzzeitig nicht verfügbar. * Die Abfrage lief in eine Zeitüberschreitung (typischerweise \~10s). **Behebung.** * Transaktionen schlagen nie wegen Problemen beim Anbieter fehl, denn die Anreicherung erfolgt nach bestem Bemühen. * Wenn ein bestimmter Anbieter wiederholt ausfällt, prüfen Sie dessen Statusseite oder eröffnen Sie ein Support-Ticket. * Erwägen Sie, unter *Settings → Transaction Monitoring → Providers* Anbieterpräferenzen zu konfigurieren, damit Abfragen an alternative Anbieter geleitet werden. ## Fehlende IP-Anreicherung **Symptom.** Das Feld `applicant.ip_enrichment` einer Transaktion fehlt oder ist unvollständig. **Ursachen.** * Die Übermittlung enthält keine `applicant.device.ip`. * Die Adresse ist privat oder reserviert (nicht routingfähig). * Alle Anreicherungsanbieter waren vorübergehend nicht verfügbar. **Behebung.** * Erfassen Sie die Adresse des Absenders in Ihrem Client bzw. Server und übergeben Sie sie bei jeder Transaktion. * Verwenden Sie nur routingfähige Adressen, denn Didit überspringt private Bereiche stillschweigend. * Prüfen Sie den Anbieterstatus in der Konsole unter *Settings → Status*. ## Webhook-Signatur stimmt nicht überein **Symptom.** Ihr Endpoint weist Ereignisse ab, weil die Signatur nicht übereinstimmt. **Ursachen.** * Der rohe Anfrage-Body wurde verändert (JSON mit anderen Leerzeichen neu serialisiert). * Falsches Geheimnis. * Mehrere Ziele mit derselben URL. Die Signaturen unterscheiden sich pro Ziel. **Behebung.** * **Berechnen Sie die Signatur über den rohen Anfrage-Body**, nicht über das geparste JSON. Viele Frameworks bieten dafür eine Raw-Body-Middleware. * Rotieren Sie das Geheimnis, falls es kompromittiert wurde: *Webhook destinations → \[destination] → Rotate secret*. * Verwenden Sie pro URL nur ein Ziel, um Verwechslungen beim Geheimnis zu vermeiden. ## Webhook kommt nicht an **Symptom.** Transaktionen werden erstellt, aber Webhooks kommen nie an. **Ursachen.** * `enabled` des Ziels ist `false`. * Die URL ist nicht öffentlich erreichbar. * Das Ziel wurde nach wiederholten Fehlern automatisch deaktiviert. * Das Ereignis ist nicht in `subscribed_events` enthalten. **Behebung.** * Senden Sie ein Testereignis: *Webhook destinations → \[destination] → Send test*. * Prüfen Sie die letzten Zustellungen: *Webhooks → \[destination] → Deliveries*. Dort sehen Sie 4xx- und 5xx-Antworten mit Body und Headern. * Aktivieren Sie deaktivierte Ziele wieder. ## Währungsumrechnung scheint falsch **Symptom.** `amount_in_default_currency` stimmt nicht mit Ihrem erwarteten Kurs überein. **Ursachen.** * Der FX-Kurs ist der Mittelkurs zum `txn_date`. * Rückdatierte Transaktionen verwenden den historischen Kurs zu diesem Datum. * Manche Währungen (exotische Devisen) werden in größeren Abständen aktualisiert. **Behebung.** * Verwenden Sie `amount` und `currency` (die Originalwährung) für die Anzeige. * Verwenden Sie `amount_in_default_currency` nur für interne Schwellenwertprüfungen von Regeln. * Für Audit-Zwecke hält der Transaktionsdatensatz den bei der Auswertung verwendeten Umrechnungskurs fest. ## Gegenpartei stimmt nicht mit meiner Sperrliste überein **Symptom.** Sie haben ein Unternehmen über `vendor_data` auf die Sperrliste gesetzt, trotzdem wurde eine Transaktion mit dieser Gegenpartei durchgeführt. **Ursachen.** * Die Gegenpartei im Transaktions-Payload hat kein `vendor_data`: Sie wird als externer Snapshot gespeichert. * Die Schreibweise von `vendor_data` weicht ab. **Lösung.** * Übergeben Sie `counterparty.vendor_data` immer, wenn es sich bei der Gegenpartei um eine Entität auf Ihrer Plattform handelt. * Verwenden Sie überall dieselbe Schreibweise: `vendor_data` unterscheidet Groß- und Kleinschreibung. ## AWAITING\_USER-Transaktionen hängen fest **Symptom.** Transaktionen bleiben im Status `AWAITING_USER` hängen, weil der Benutzer die Remediation-Sitzung nie abschließt. **Ursachen.** * Der Benutzer hat die URL der Remediation-Sitzung nicht geöffnet. * Die Remediation-Sitzung ist abgelaufen. * Bei der Transaktion handelt es sich um einen Travel-Rule-Transfer, den eine Bibliotheksregel wie `travel-rule-pending-action` in `AWAITING_USER` überführt hat. Didit erstellt für eine Travel-Rule-Transaktion keine Standard-Remediation-Sitzung. Solange die Regel keinen eigenen Remediation-Workflow nennt, gibt es daher keinen Link zur Zustellung. **Lösung.** * Der Link zur Zustellung ist `remediation_session_url` aus der Antwort der Transaktion. Stellen Sie ihn dem Benutzer erneut zu. * Lösen Sie bei einer Travel-Rule-Transaktion den Transfer im Reiter **Travel Rule** auf und ändern Sie danach selbst den Transaktionsstatus. Das Auflösen des Transfers führt die Transaktion nicht automatisch aus `AWAITING_USER` heraus. * Remediation-Sitzungen folgen demselben Muster wie im [KYC-Schnellstart](https://docs.didit.me/de/getting-started/quick-start.md): Abonnieren Sie die Webhooks für den Abschluss. * Legen Sie in Ihrem eigenen System ein Timeout fest, damit veraltete Transaktionen ablaufen, wenn die Remediation nie abgeschlossen wird. ## Rate-Limit beim Erstellen **Symptom.** `429 Too Many Requests` bei Lastspitzen mit hohem Volumen. **Lösung.** * Beachten Sie den Header `Retry-After`. * Drosseln Sie den Datenverkehr auf Client-Seite bei Lastspitzen. * Wenden Sie sich an den Support, wenn Sie bei nachweislich hohem Produktionsvolumen höhere Limits benötigen. Siehe [Rate-Limits](https://docs.didit.me/de/integration/rate-limiting.md). ## Nächste Schritte > [card] [Integrationsleitfaden](https://docs.didit.me/de/transaction-monitoring/integration-guide.md) > > Vollständige Integrationsmuster. > [card] [Regeln](https://docs.didit.me/de/transaction-monitoring/rules.md) > > So funktioniert die Regelauswertung. > [card] [Webhooks](https://docs.didit.me/de/transaction-monitoring/webhooks.md) > > Funktionsweise von Webhooks. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.