Building a SAR Workflow Without a Separate Case Tool

A rule firing is the easy part. What happens after — the alert, the investigation, the escalation, the decision to file a Suspicious Activity Report — is where most compliance operations actually live, and where most of the cost hides. The typical setup stitches three things together: a monitoring vendor that produces alerts, a separate case-management tool that holds the investigation, and a manual SAR process that often ends in a spreadsheet and a PDF. Data gets re-keyed between systems, the audit trail fragments, and analysts spend their day switching tabs.

Didit's Transaction Monitoring API ships the whole workflow in one product. When a rule fires, an alert opens; alerts group into cases; analysts are assigned; and the SAR is filed from the same console where the alert was raised. There's no separate case tool to license, integrate, or reconcile — and the transactions that feed it cost $0.02 each.

This guide walks the workflow from a tripped rule to a filed SAR.

Key takeaways

• Alerts open automatically when a rule fires and move through a defined lifecycle: OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, DISMISSED.
• Cases group related alerts, carry priority and severity, and track an investigation through OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, and RESOLVED.
• Analysts are assigned to alerts and cases, so ownership and performance are measurable.
• SAR filing lives in the same console as the alert — no export to a separate tool, no re-keyed data.
• The AWAITING_USER path lets an analyst push an alert back to the user for remediation instead of resolving it manually.
• $0.02 per transaction, no minimums. AML screening on a flagged party is billed separately at $0.20.

What the case-management workflow does

Transaction monitoring produces signals; case management turns them into defensible decisions. Every alert in Didit carries a source — rule-triggered, provider-triggered, or analyst-created — and a status that reflects where it sits in the investigation. An analyst opens the alert, reviews the transaction and the rules that fired, and decides: dismiss it as a false positive, resolve it, escalate it into a case, push it back to the user, or move it toward a SAR.

Cases are the container for anything bigger than a single alert. Several alerts on the same user — a velocity spike on Monday, a sanctioned-counterparty hit on Wednesday — group into one case that holds the whole picture, with its own priority and severity. The case is what an investigator works, and the case is what documents the firm's decision.

Why it matters

Regulators don't just expect you to detect suspicious activity — they expect you to investigate it and report it, and to show a clean audit trail of how you got from alert to decision. A fragmented stack works against you on every count. Re-keying data between a monitoring vendor and a case tool introduces errors. A spreadsheet SAR process is impossible to audit and slow to defend. And every integration seam is a place where an alert can fall through.

Collapsing the stack into one product fixes the operational and the regulatory problem at once. The alert, the investigation, the analyst who owned it, and the SAR all live in the same record. The audit trail is continuous because nothing leaves the system. And the cost scales with transactions, not with per-seat licenses for a case tool you also have to maintain.

Technical details

When a rule fires on a transaction, the response carries the status and an alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

The transaction itself is created against the unified /v3/ API, idempotent on a transaction_id you control:

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_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Alert statuses. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, or terminate at RESOLVED or DISMISSED.

Case statuses. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Webhooks. Subscribe to transaction.created and transaction.status.updated so your systems stay in sync as an analyst moves an alert through the workflow.

Price. $0.02 per transaction. AML screening run on a flagged party during an investigation is billed separately at $0.20.

From alert to filed SAR

1. Alert opens. A rule fires, the transaction goes IN_REVIEW, and an alert opens in OPEN state with the triggering rules attached.
2. Analyst picks it up. The alert moves to INVESTIGATING and is assigned to an analyst, who reviews the transaction history, the velocity context, and any AML screening.
3. Escalate or remediate. The analyst groups related alerts into a case, or pushes the alert to AWAITING_USER so the customer can clear it with proof of funds or a re-verification.
4. Decide on a SAR. If the activity warrants reporting, the alert moves to PENDING_SAR, the SAR is prepared in the same console, and on filing the alert moves to SAR_FILED.
5. Close out. Alerts that don't warrant action resolve as DISMISSED (false positive) or RESOLVED. The whole trail — who decided what, when — stays on the record.

Because alerts can move to AWAITING_USER, the investigation and the auto-remediation loop share the same surface: an analyst can hand a borderline alert back to the user rather than burning time on it, and the alert resumes automatically once the user responds.

Use cases

• Fintech — group velocity, structuring, and sanctions alerts on a single account into one case before deciding on a SAR.
• Crypto — investigate alerts raised by wallet-screening exposure alongside on-chain velocity in the same case file.
• Lending — work fraud-pattern alerts (mule, synthetic identity) through to a documented decision without a second tool.
• Marketplaces — consolidate refund-abuse and chargeback alerts on a seller into a case, then file or dismiss.
• iGaming — manage responsible-gaming and AML alerts in one workflow, with analyst ownership and an audit trail.

How to integrate with Didit

1. Switch on your bundles. In the Business Console, enable the rule bundles that fit your business so alerts open against the right typologies.
2. Send transactions. POST /v3/transactions/ as money moves, with a stable transaction_id and vendor_data linking each to its user or entity.
3. Work alerts in the Console. Investigate, assign analysts, group alerts into cases, and file SARs — all from the same surface.
4. Sync with webhooks. Listen for transaction.status.updated so your own systems reflect alert and case state changes.

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

Do I need a separate case-management tool?

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

What states does an alert move through?

OPEN, INVESTIGATING, AWAITING_USER, PENDING_SAR, SAR_FILED, RESOLVED, and DISMISSED. Cases move through OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, and RESOLVED.

Can I assign alerts to specific analysts?

Yes. Alerts and cases are assigned to analysts, so ownership is clear and performance is measurable.

Where is the SAR filed?

In the same console where the alert was raised. There's no export to a separate tool and no re-keyed data, which keeps the audit trail continuous.

What does it cost?

$0.02 per transaction, billed per call with no minimums. AML screening run on a flagged party during an investigation is billed separately 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.