KYT-Fehlerbehebung: häufige Probleme & 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}/ 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. 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 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: 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.

​

Nächste Schritte