AWAITING_USER: Auto-Remediation for Flagged Transactions

The hardest part of transaction monitoring isn't catching the suspicious payment — it's what you do next. Decline it outright and you block a paying customer who may be entirely legitimate. Wave it through and you've accepted the risk you just flagged. Most teams resolve this with a manual queue: an analyst emails the user, waits days for a document, and the transaction sits frozen the whole time.

Didit's Transaction Monitoring API has a fourth status built for exactly this gap: AWAITING_USER. Instead of a binary approve-or-decline, a flagged transaction can pause, request a specific action from the user — re-verify identity, supply proof of funds — and resume automatically the moment they clear it. Friction lands only where risk does, and it costs the same $0.02 per transaction as everything else.

This guide explains how the AWAITING_USER path works and how to wire it into your flow.

Key takeaways

• AWAITING_USER is one of four transaction statuses — alongside APPROVED, IN_REVIEW, and DECLINED — so remediation is a first-class outcome, not a workaround.
• A flagged transaction pauses instead of failing, requests a step-up action from the user, and resumes automatically once the action is cleared.
• The step-up can be a re-KYC, a proof-of-funds upload, or any verification step spawned on the unified /v3/ API.
• Webhooks drive the loop — transaction.status.updated fires when the transaction enters and leaves AWAITING_USER.
• The same status exists in case management, so an analyst can move an alert into AWAITING_USER and let the user clear it.
• $0.02 per transaction, no minimums. A re-KYC or AML check spawned during remediation is billed at its own published rate.

What AWAITING_USER does

When a rule fires, the engine assigns a status. Three of the four are familiar: APPROVED lets the transaction through, IN_REVIEW opens an alert for an analyst, and DECLINED blocks it. The fourth, AWAITING_USER, does something different — it suspends the transaction and signals that the user must do something before it can resolve.

Concretely: a transfer trips a high-value or high-velocity rule, the engine returns AWAITING_USER, your application prompts the user to complete the requested step (a fresh liveness check, a document upload, a source-of-funds declaration), and the verification session feeds back into the platform. Once the step clears, the transaction re-evaluates and moves to APPROVED (or escalates if the new evidence makes things worse). No analyst has to babysit it.

Why it matters

Hard declines are expensive. Every false-positive block is a frustrated legitimate customer, a support ticket, and often a churned account. But waving flagged payments through is how firms end up in enforcement actions. The conventional fix — a manual remediation queue — trades one cost for another: analyst time, slow turnaround, and a transaction frozen for days.

AWAITING_USER collapses that trade-off. The user does the work, in the moment, at the point of friction — exactly when they're motivated to clear it because their own transaction is waiting. You catch the risk, you keep the customer, and you don't pay an analyst to chase a document. It's the difference between a compliance control that costs you customers and one that quietly does its job.

Technical details

A transaction that the engine routes to remediation comes back with the AWAITING_USER status and the rules that triggered it:

{
  "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"
}

You react by prompting the user and spawning the verification step on the unified /v3/ API. When the step completes, a webhook tells you the transaction has moved on:

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

Webhooks. Subscribe to transaction.created and transaction.status.updated. The status-updated event fires both when the transaction enters AWAITING_USER and when it leaves — so your ledger and your UI stay in sync without polling.

Price. $0.02 per transaction. The remediation step itself is billed at its own published rate: a re-KYC at User Verification rates, an AML check on a flagged party at $0.20.

The remediation loop, step by step

1. Trip a rule. A transaction crosses a threshold that your policy says should be remediated rather than declined — say, a first high-value transfer from a new account.
2. Pause, don't fail. The engine returns AWAITING_USER instead of DECLINED, with the required action attached.
3. Prompt the user. Your application surfaces the step-up — a liveness re-check, a document upload, a source-of-funds declaration — and spawns the verification session.
4. User clears it. The user completes the step inside the same flow they were already in.
5. Resume automatically. The transaction re-evaluates with the new evidence and moves to APPROVED — or escalates to IN_REVIEW/DECLINED if the evidence raises the risk. A transaction.status.updated webhook tells your backend either way.

Because the same AWAITING_USER state exists in case management, an analyst working an IN_REVIEW alert can also push it back to the user instead of resolving it themselves — the alert moves through OPEN → INVESTIGATING → AWAITING_USER and resolves once the user responds.

Use cases

• Fintech — a first high-value transfer from a recently onboarded account pauses for proof of funds rather than blocking the customer.
• Crypto — an outbound transfer to a wallet with elevated exposure pauses for a source-of-funds declaration before settling.
• Lending — a disbursement that trips a synthetic-identity signal pauses for a re-KYC liveness check.
• Marketplaces — a seller payout that trips a velocity rule pauses for re-verification before funds release.
• iGaming — a deposit-velocity spike pauses for a step-up check, which doubles as a responsible-gaming touchpoint.

How to integrate with Didit

1. Decide your remediation policy. In the Business Console, set which rules route to AWAITING_USER instead of DECLINED, and which step-up action each one requests.
2. Send transactions. POST /v3/transactions/ as money moves, with a stable transaction_id and vendor_data linking each to its user.
3. Handle the pause. When a transaction returns AWAITING_USER, prompt the user and spawn the verification step on the /v3/ API.
4. Listen for the resume. React to transaction.status.updated to release or hold the transaction once the user clears the step.

Because it's all on the unified /v3/ API, the remediation KYC a flagged transaction spawns is the same KYC you onboard users with — one identity-and-fraud platform, end to end.

Frequently asked questions

What is AWAITING_USER?

It's one of the four transaction statuses. Instead of a hard decline, a flagged transaction pauses and requests a user action — re-verification or proof of funds — then resumes automatically once the user clears it.

Does the transaction resume on its own?

Yes. Once the requested step is cleared, the transaction re-evaluates and moves to APPROVED automatically — or escalates if the new evidence raises the risk. A transaction.status.updated webhook fires on the change.

What can the step-up be?

Any verification step on the unified /v3/ API — a re-KYC liveness check, a document re-verification, an AML check, or a proof-of-funds upload.

Does an analyst have to be involved?

No. The auto-remediation loop runs without an analyst. But the same AWAITING_USER state exists in case management, so an analyst can also push an alert back to the user when they choose to.

What does it cost?

$0.02 per transaction. The remediation step is billed at its own rate — a re-KYC at User Verification rates, an AML check at $0.20.

Ready to get started?

Read the Transaction Monitoring overview in the docs, see how it fits the rest of the platform on the Transaction Monitoring product page, and check transparent per-call pricing on the pricing page. When you're ready, start free — 500 free KYC checks every month, and transaction monitoring at $0.02 per call.