Benutzeraktion ausstehend: Automatische Problembehebung für markierte Transaktionen (DE)

Der schwierigste Teil der Transaktionsüberwachung ist nicht das Erkennen verdächtiger Zahlungen, sondern das, was danach geschieht. Lehnt man sie pauschal ab, blockiert man einen zahlenden Kunden, der völlig legitim sein könnte. Lässt man sie durchgehen, hat man das Risiko akzeptiert, das man gerade markiert hat. Die meisten Teams lösen dies mit einer manuellen Warteschlange: Ein Analyst sendet dem Benutzer eine E-Mail, wartet tagelang auf ein Dokument, und die Transaktion bleibt die ganze Zeit eingefroren.

Didits Transaktionsüberwachungs-API verfügt über einen vierten Status, der genau für diese Lücke geschaffen wurde: AWAITING_USER. Anstatt einer binären Genehmigung oder Ablehnung kann eine markierte Transaktion pausieren, eine bestimmte Aktion vom Benutzer anfordern – Identität erneut überprüfen, Nachweis von Geldern erbringen – und automatisch fortgesetzt werden, sobald diese Aktion abgeschlossen ist. Reibung entsteht nur dort, wo ein Risiko besteht, und es kostet die gleichen 0,02 $ pro Transaktion wie alles andere.

Dieser Leitfaden erklärt, wie der AWAITING_USER-Pfad funktioniert und wie er in Ihren Workflow integriert wird.

Wichtige Erkenntnisse

• AWAITING_USER ist einer von vier Transaktionsstatus – neben APPROVED, IN_REVIEW und DECLINED – so dass die Problembehebung ein erstklassiges Ergebnis und kein Workaround ist.
• Eine markierte Transaktion pausiert, anstatt fehlzuschlagen, fordert eine Stufenaktion vom Benutzer an und wird automatisch fortgesetzt, sobald die Aktion abgeschlossen ist.
• Die Stufenaktion kann eine erneute KYC-Prüfung, ein Upload eines Nachweises von Geldern oder jeder Verifizierungsschritt sein, der über die einheitliche /v3/-API ausgelöst wird.
• Webhooks steuern die Schleife – transaction.status.updated wird ausgelöst, wenn die Transaktion in und aus AWAITING_USER übergeht.
• Der gleiche Status existiert im Fallmanagement, so dass ein Analyst eine Warnung in AWAITING_USER verschieben und den Benutzer sie klären lassen kann.
• 0,02 $ pro Transaktion, keine Mindestbeträge. Eine während der Problembehebung ausgelöste erneute KYC-Prüfung oder AML-Prüfung wird zu ihrem eigenen veröffentlichten Satz abgerechnet.

Was AWAITING_USER bewirkt

Wenn eine Regel ausgelöst wird, weist die Engine einen Status zu. Drei der vier sind bekannt: APPROVED lässt die Transaktion durch, IN_REVIEW öffnet eine Warnung für einen Analysten, und DECLINED blockiert sie. Der vierte, AWAITING_USER, tut etwas anderes – er setzt die Transaktion aus und signalisiert, dass der Benutzer etwas tun muss, bevor sie gelöst werden kann.

Konkret: Eine Überweisung löst eine Regel für hohe Werte oder hohe Frequenz aus, die Engine gibt AWAITING_USER zurück, Ihre Anwendung fordert den Benutzer auf, den angeforderten Schritt abzuschließen (eine neue Lebendigkeitsprüfung, ein Dokumenten-Upload, eine Herkunftserklärung der Gelder), und die Verifizierungssitzung wird an die Plattform zurückgespeist. Sobald der Schritt abgeschlossen ist, wird die Transaktion neu bewertet und zu APPROVED verschoben (oder eskaliert, wenn die neuen Beweise die Situation verschlimmern). Kein Analyst muss sie überwachen.

Warum es wichtig ist

Harte Ablehnungen sind teuer. Jede falsch-positive Blockade ist ein frustrierter legitimer Kunde, ein Support-Ticket und oft ein abgewandertes Konto. Aber das Durchwinken markierter Zahlungen führt dazu, dass Unternehmen mit Durchsetzungsmaßnahmen konfrontiert werden. Die konventionelle Lösung – eine manuelle Warteschlange zur Problembehebung – tauscht einen Kostenfaktor gegen einen anderen: Analystenzeit, langsame Bearbeitung und eine tagelang eingefrorene Transaktion.

AWAITING_USER hebt diesen Kompromiss auf. Der Benutzer erledigt die Arbeit im Moment, am Punkt der Reibung – genau dann, wenn er motiviert ist, sie zu klären, weil seine eigene Transaktion wartet. Sie erkennen das Risiko, behalten den Kunden und bezahlen keinen Analysten, um ein Dokument zu verfolgen. Das ist der Unterschied zwischen einer Compliance-Kontrolle, die Sie Kunden kostet, und einer, die ihre Aufgabe leise erfüllt.

Technische Details

Eine Transaktion, die die Engine zur Problembehebung leitet, wird mit dem Status AWAITING_USER und den Regeln, die sie ausgelöst haben, zurückgegeben:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Sie reagieren, indem Sie den Benutzer auffordern und den Verifizierungsschritt in der einheitlichen /v3/-API auslösen. Wenn der Schritt abgeschlossen ist, teilt Ihnen ein Webhook mit, dass die Transaktion fortgesetzt wurde:

# webhook payload: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks. Abonnieren Sie transaction.created und transaction.status.updated. Das Status-Update-Ereignis wird sowohl beim Übergang der Transaktion in AWAITING_USER als auch beim Verlassen ausgelöst – so bleiben Ihr Ledger und Ihre Benutzeroberfläche ohne Polling synchron.

Preis. 0,02 $ pro Transaktion. Der Problembehebungsschritt selbst wird zu seinem eigenen veröffentlichten Satz abgerechnet: eine erneute KYC-Prüfung zu den Benutzerverifizierungssätzen, eine AML-Prüfung einer markierten Partei zu 0,20 $.

Der Problembehebungs-Loop, Schritt für Schritt

1. Regel auslösen. Eine Transaktion überschreitet einen Schwellenwert, der gemäß Ihrer Richtlinie behoben und nicht abgelehnt werden sollte – zum Beispiel eine erste hochwertige Überweisung von einem neuen Konto.
2. Pausieren, nicht fehlschlagen. Die Engine gibt AWAITING_USER anstelle von DECLINED zurück, mit der erforderlichen Aktion.
3. Benutzer auffordern. Ihre Anwendung zeigt die Stufenaktion an – eine erneute Lebendigkeitsprüfung, ein Dokumenten-Upload, eine Herkunftserklärung der Gelder – und löst die Verifizierungssitzung aus.
4. Benutzer schließt ab. Der Benutzer schließt den Schritt innerhalb desselben Workflows ab, in dem er sich bereits befand.
5. Automatisch fortsetzen. Die Transaktion wird mit den neuen Beweisen neu bewertet und zu APPROVED verschoben – oder eskaliert zu IN_REVIEW/DECLINED, wenn die Beweise das Risiko erhöhen. Ein transaction.status.updated-Webhook informiert Ihr Backend in jedem Fall.

Da derselbe AWAITING_USER-Status im Fallmanagement existiert, kann ein Analyst, der eine IN_REVIEW-Warnung bearbeitet, diese auch an den Benutzer zurücksenden, anstatt sie selbst zu lösen – die Warnung durchläuft OPEN → INVESTIGATING → AWAITING_USER und wird gelöst, sobald der Benutzer antwortet.

Anwendungsfälle

• Fintech – eine erste hochwertige Überweisung von einem kürzlich eingerichteten Konto pausiert für den Nachweis von Geldern, anstatt den Kunden zu blockieren.
• Krypto – eine ausgehende Überweisung an eine Wallet mit erhöhtem Risiko pausiert für eine Herkunftserklärung der Gelder, bevor sie abgewickelt wird.
• Kreditvergabe – eine Auszahlung, die ein synthetisches Identitätssignal auslöst, pausiert für eine erneute KYC-Lebendigkeitsprüfung.
• Marktplätze – eine Verkäuferauszahlung, die eine Frequenzregel auslöst, pausiert für eine erneute Verifizierung, bevor Gelder freigegeben werden.
• iGaming – ein Anstieg der Einzahlungsfrequenz pausiert für eine Stufenprüfung, die auch als Anlaufstelle für verantwortungsvolles Spielen dient.

Integration mit Didit

1. Legen Sie Ihre Problembehebungsrichtlinie fest. Legen Sie in der Business Console fest, welche Regeln zu AWAITING_USER statt zu DECLINED führen und welche Stufenaktion jede anfordert.
2. Transaktionen senden. POST /v3/transactions/, wenn Geld bewegt wird, mit einer stabilen transaction_id und vendor_data, die jeden mit seinem Benutzer verknüpfen.
3. Pause handhaben. Wenn eine Transaktion AWAITING_USER zurückgibt, fordern Sie den Benutzer auf und lösen Sie den Verifizierungsschritt in der /v3/-API aus.
4. Auf Fortsetzung warten. Reagieren Sie auf transaction.status.updated, um die Transaktion freizugeben oder zu halten, sobald der Benutzer den Schritt abgeschlossen hat.

Da alles über die einheitliche /v3/-API läuft, ist die KYC zur Problembehebung, die eine markierte Transaktion auslöst, dieselbe KYC, mit der Sie Benutzer onboarden – eine Identitäts- und Betrugsplattform, End-to-End.

Häufig gestellte Fragen

Was ist AWAITING_USER?

Es ist einer der vier Transaktionsstatus. Anstatt einer harten Ablehnung pausiert eine markierte Transaktion und fordert eine Benutzeraktion an – erneute Verifizierung oder Nachweis von Geldern – und wird dann automatisch fortgesetzt, sobald der Benutzer diese abgeschlossen hat.

Wird die Transaktion von selbst fortgesetzt?

Ja. Sobald der angeforderte Schritt abgeschlossen ist, wird die Transaktion neu bewertet und automatisch zu APPROVED verschoben – oder eskaliert, wenn die neuen Beweise das Risiko erhöhen. Ein transaction.status.updated-Webhook wird bei der Änderung ausgelöst.

Was kann die Stufenaktion sein?

Jeder Verifizierungsschritt in der einheitlichen /v3/-API – eine erneute KYC-Lebendigkeitsprüfung, eine erneute Dokumentenverifizierung, eine AML-Prüfung oder ein Upload eines Nachweises von Geldern.

Muss ein Analyst beteiligt sein?

Nein. Die automatische Problembehebungsschleife läuft ohne Analysten ab. Aber derselbe AWAITING_USER-Status existiert im Fallmanagement, so dass ein Analyst eine Warnung auch an den Benutzer zurücksenden kann, wenn er dies wünscht.

Was kostet es?

0,02 $ pro Transaktion. Der Problembehebungsschritt wird zu seinem eigenen Satz abgerechnet – eine erneute KYC-Prüfung zu den Benutzerverifizierungssätzen, eine AML-Prüfung zu 0,20 $.

Bereit zum Start?

Lesen Sie die Übersicht zur Transaktionsüberwachung in den Docs, sehen Sie, wie sie sich in den Rest der Plattform einfügt auf der Produktseite zur Transaktionsüberwachung, und überprüfen Sie die transparenten Preise pro Anruf auf der Preisseite. Wenn Sie bereit sind, starten Sie kostenlos – 500 kostenlose KYC-Prüfungen jeden Monat und Transaktionsüberwachung für 0,02 $ pro Anruf.