Transaction Monitoring API: Real-Time Rules, Case Management & SAR Workflows

Onboarding a user with KYC tells you who they are on day one. It tells you nothing about what they do on day ninety. Transaction monitoring is the other half of compliance — the continuous layer that watches money move and flags the patterns that matter: structuring, rapid in-and-out, velocity spikes, sanctioned counterparties, and high-risk jurisdictions.

Didit's Transaction Monitoring API is a real-time rule engine for exactly that. You send a transaction, it returns a decision in milliseconds, and anything that trips a rule lands in a built-in case manager where your analysts investigate, escalate, and file Suspicious Activity Reports (SARs). It works for both fiat and crypto, and it costs $0.02 per transaction with no minimums.

This guide walks through how it works, what the rule engine ships with, and how to integrate it.

Key takeaways

• Real-time decisioning. Every transaction returns one of four statuses — APPROVED, IN_REVIEW, DECLINED, or AWAITING_USER — so you can act before the money settles.
• 11 built-in rule bundles cover AML/CTF, anomaly detection, FATF patterns, device intelligence, fraud, crypto monitoring, crypto screening, responsible gaming, and e-commerce. Build your own on top.
• Built-in case management and SAR workflow — alerts, analyst assignment, investigation states, and SAR filing live inside the same product, not a separate tool.
• AWAITING_USER auto-remediation lets a flagged transaction trigger a verification step (re-KYC, proof of funds) and resume automatically once the user clears it.
• Fiat and crypto in one engine. Crypto transactions can trigger on-chain wallet screening automatically.
• $0.02 per transaction, pay-per-call, no minimums. AML screening on a flagged party is billed separately at $0.20 per check.

What transaction monitoring does

A KYC check is a snapshot; transaction monitoring is the film. Once a user is onboarded, every payment, transfer, deposit, withdrawal, bet, or trade they make is a signal. Looked at individually, most of those signals are noise. Looked at as a stream — with velocity windows, aggregation, and counterparty context — the patterns that indicate money laundering, fraud, or sanctions evasion become visible.

Didit scores each transaction as it happens against a library of rules, attaches a risk score, and assigns a status. Low-risk transactions pass through silently. Anything that crosses a threshold is held for review, declined outright, or routed back to the user for remediation — and an alert is opened for an analyst.

Why it matters

Regulators expect ongoing monitoring, not just onboarding checks. The EU's AML directives, the FATF recommendations, and equivalent regimes worldwide all require regulated firms to monitor transactions on a risk basis and report suspicious activity. The failure modes are expensive: missed structuring, undetected sanctioned counterparties, or a velocity pattern that turns out to be a mule network.

The operational problem is just as real. Most teams stitch monitoring together from a rules vendor, a separate case-management tool, and a manual SAR process in spreadsheets. Didit collapses that stack into one API and one console: rules, alerts, investigation, and reporting in the same place, priced per transaction so the cost scales with usage instead of seat licenses.

Technical details

Transactions are created against the unified /v3/ API. Each transaction is idempotent on a transaction_id that you control (unique per application), so retries never double-count.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_8f3a91",
    "category": "finance",
    "amount": 9800,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T10:32:00Z",
    "subject": {
      "vendor_data": "user_4521",
      "role": "SENDER",
      "entity_type": "INDIVIDUAL"
    },
    "counterparty": {
      "role": "RECEIVER",
      "entity_type": "INDIVIDUAL"
    },
    "payment_method": "BANK_TRANSFER"
  }'

The engine evaluates the transaction against every active rule and returns a status plus the rules that triggered:

{
  "transaction_id": "txn_8f3a91",
  "status": "IN_REVIEW",
  "risk_score": 62,
  "triggered_rules": [
    { "name": "Structuring — amount below reporting threshold", "bundle": "AML/CTF", "action": "ADD_SCORE" },
    { "name": "High velocity — sender 24h count", "bundle": "Anomaly detection", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_2c70d4"
}

Statuses. Every transaction resolves to one of four:

Status	Meaning
APPROVED	No rule crossed a decline threshold — the transaction proceeds.
IN_REVIEW	A rule flagged the transaction — an alert is opened for an analyst.
DECLINED	A hard rule (e.g. sanctioned counterparty) blocked the transaction.
AWAITING_USER	The transaction is held pending a user action — re-verification or proof of funds.

Categories. Transactions carry a category so rules apply in context: finance, kyc, travel_rule, user_platform_event, gambling_bet, gambling_limit_change, gambling_bonus_change, and audit_trail_event.

Velocity and aggregation. Custom rules evaluate over time windows with count, sum, and distinct-count aggregations — so you can express "more than 5 inbound transfers from distinct counterparties in 24 hours" or "cumulative volume over €10,000 in 7 days" without writing your own stream processor.

Webhooks. Subscribe to transaction.created and transaction.status.updated to keep your ledger in sync when an analyst resolves an alert.

Price. $0.02 per transaction, billed per call, no minimums. If a flagged transaction triggers AML screening on a party, that check is billed separately at $0.20.

The 11 built-in rule bundles

You don't start from a blank rulebook. Didit seeds the engine with 11 bundles you can switch on and tune:

1. Finance — structuring, large transactions, threshold avoidance.
2. AML/CTF — cumulative volume, rapid in/out, sanctions, PEP exposure, high-risk jurisdictions.
3. Anomaly detection — velocity spikes, dormant-account reactivation, behavioral outliers.
4. FATF — patterns aligned to FATF red-flag indicators.
5. Device intelligence — device fingerprint and session-risk signals.
6. Fraud prevention — mule patterns, multi-accounting, account takeover signals.
7. Crypto monitoring — on-chain transaction patterns.
8. Crypto screening — wallet risk and source-of-funds exposure.
9. Responsible gaming — deposit velocity, limit changes, bonus abuse.
10. E-commerce — chargeback and refund-abuse patterns.
11. Custom — your own rules with conditions, velocity windows, and actions.

Each rule's action can add to the risk score, change the status, add tags or notes, or add the party to a list — so policy is expressed declaratively, and changes are reviewed in the Console rather than shipped in code.

Crypto, wallet screening, and the Travel Rule

Set currency_kind: "crypto" with a direction (INBOUND or OUTBOUND) and the engine can automatically run on-chain wallet screening on the counterparty address — checking exposure to sanctioned entities, darknet markets, mixers, ransomware, and stolen funds. Wallet screening starts at $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

For Virtual Asset Service Providers, the same engine carries FATF Travel Rule support: originator and beneficiary data exchange with obligation tracking across protocols, and dedicated travel-rule statuses (COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, EXEMPT, and more). One product covers monitoring, screening, and the Travel Rule.

Case management and SAR workflow

When a rule fires, an alert opens. Didit ships the workbench to handle it — no separate case tool required.

• Alerts carry a source (rule-triggered, provider-triggered, or analyst-created) and move through states: OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
• Cases group related alerts, hold priority and severity, and track an investigation through OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, and RESOLVED.
• Analysts are assigned, performance is measurable, and the SAR workflow lives in the same console where the alert was raised.

The AWAITING_USER path is what makes this practical at scale: instead of a hard decline, a flagged transaction can pause and ask the user to clear it — re-verify identity, provide proof of funds — then resume automatically once they do. Friction lands only where risk does.

How to integrate with Didit

1. Build the workflow. In the Business Console, switch on the rule bundles relevant to your business and tune thresholds. The custom-rule builder is Console-only by design, so compliance reviews every change.
2. Send transactions. POST /v3/transactions/ from your backend as money moves. Use a stable transaction_id for idempotency, and pass vendor_data so transactions link to the user or business entity they belong to.
3. Handle webhooks. Listen for transaction.status.updated to react when an analyst resolves an alert or an AWAITING_USER remediation completes.
4. Work alerts in the Console. Investigate, escalate to a case, and file SARs from the same surface.

Because it's all on the unified /v3/ API, a KYB session can spawn the KYC sessions for its UBOs, those users flow into transaction monitoring, and a flagged transaction can spawn a remediation KYC — one identity-and-fraud platform, end to end.

Frequently asked questions

How much does transaction monitoring cost?

$0.02 per transaction, billed per call with no minimums. AML screening on a flagged party is billed separately at $0.20 per check, and on-chain wallet screening starts at $0.02 per screening with bring-your-own-key.

Does it work for crypto as well as fiat?

Yes. Set currency_kind to fiat or crypto. Crypto transactions can automatically trigger on-chain wallet screening and carry FATF Travel Rule support.

Do I have to build my own case-management tool?

No. Alerts, analyst assignment, investigation states, and the SAR workflow are built into the same product and console.

Can I write my own rules?

Yes. On top of the 11 seeded bundles you can build custom rules with conditions, velocity windows, and aggregations. Rules are managed in the Console so compliance reviews every change.

What is AWAITING_USER auto-remediation?

Instead of a hard decline, a flagged transaction can pause and request a user action — re-verification or proof of funds — then resume automatically once the user clears it.

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.