The 11 Transaction Monitoring Rule Bundles, Explained

A transaction monitoring engine is only as good as the rules running inside it. Start from a blank rulebook and you spend months encoding structuring thresholds, velocity windows, and sanctions logic before you catch your first suspicious payment. Worse, you get the policy subtly wrong and either drown analysts in false positives or miss the patterns that matter.

Didit's Transaction Monitoring API ships with 11 rule bundles already built. You switch on the ones that fit your business, tune their thresholds in the Console, and add your own rules on top. Every transaction is scored in real time against every active rule and resolves to one of four statuses — APPROVED, IN_REVIEW, DECLINED, or AWAITING_USER — at $0.02 per transaction.

This guide walks through all 11 bundles: what each catches, the patterns it scores, and how to tune it.

Key takeaways

• 11 built-in bundles cover finance, AML/CTF, anomaly detection, FATF red flags, device intelligence, fraud, crypto monitoring, crypto screening, responsible gaming, e-commerce, and a fully custom bundle.
• You don't start from scratch. Each bundle is a curated set of rules you switch on and tune, not code you write.
• Every rule has an action — add to the risk score, change the status, add tags or notes, or add a party to a list — so policy is declarative and reviewed in the Console.
• Rules run in real time against the unified /v3/ API; transactions resolve to APPROVED, IN_REVIEW, DECLINED, or AWAITING_USER.
• $0.02 per transaction, pay-per-call, no minimums. AML screening on a flagged party is billed separately at $0.20 per check.

What the rule bundles are

A bundle is a themed group of rules. Rather than expose hundreds of individual rules, Didit organizes them around the risk a given business actually faces — a neobank turns on Finance and AML/CTF, a crypto exchange adds Crypto monitoring and Crypto screening, an iGaming operator adds Responsible gaming. The bundles overlap deliberately: a sanctioned counterparty is caught by AML/CTF whether the payment is fiat or crypto.

Inside each bundle, individual rules carry conditions (amount thresholds, counterparty attributes, jurisdiction lists), optional velocity windows, and an action. The action is what makes the engine declarative: a rule can add to the transaction's risk score, change its status to IN_REVIEW or DECLINED, attach tags or notes for an analyst, or add the party to a list for future scrutiny.

Why it matters

Regulators expect monitoring that is risk-based and documented. The EU AML directives, the FATF recommendations, and equivalent regimes worldwide all require regulated firms to detect and report suspicious activity — and to show their working. A pile of bespoke rules in application code is hard to audit and harder to change without a deploy.

Bundles solve both problems. Because they are curated against known typologies, you start with coverage on day one instead of month three. Because they are managed in the Console rather than shipped in code, compliance reviews every threshold change, and the rulebook is auditable by design.

Technical details

Transactions are created against the unified /v3/ API. Each is idempotent on a transaction_id you control, 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_4d21a8",
    "category": "finance",
    "amount": 9700,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T11:04:00Z",
    "subject": { "vendor_data": "user_8842", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" },
    "payment_method": "BANK_TRANSFER"
  }'

The engine evaluates the transaction against every active rule across every active bundle and returns the status plus the rules that triggered, tagged with their bundle:

{
  "transaction_id": "txn_4d21a8",
  "status": "IN_REVIEW",
  "risk_score": 58,
  "triggered_rules": [
    { "name": "Threshold avoidance", "bundle": "Finance", "action": "ADD_SCORE" },
    { "name": "High velocity — sender 24h count", "bundle": "Anomaly detection", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_91bc02"
}

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 bundles, one by one

1. Finance — the core fiat-payments bundle. Catches structuring (splitting a large sum into smaller payments to dodge a reporting threshold), large single transactions, and threshold avoidance. Tune the reporting threshold to your jurisdiction (€10,000 in much of the EU) and set the margin below it that you treat as suspicious.

1. AML/CTF — anti-money-laundering and counter-terrorist-financing. Catches cumulative volume over a window, rapid in-and-out movement, exposure to sanctioned parties, PEP exposure, and transactions touching high-risk jurisdictions. Tune the jurisdiction lists and the cumulative-volume windows. When a party trips a sanctions or PEP rule, you can chain AML screening at $0.20 per check.

1. Anomaly detection — behavioral outliers. Catches velocity spikes, dormant-account reactivation, and amounts or counterparties that deviate from a user's established pattern. Tune the velocity windows (count, sum, distinct) and the sensitivity of the baseline.

1. FATF — patterns aligned to FATF red-flag indicators for money laundering and terrorist financing. Use it as a regulator-facing layer on top of Finance and AML/CTF; tune which red-flag families apply to your products.

1. Device intelligence — device-fingerprint and session-risk signals attached to a transaction. Catches a single device behind many accounts, mismatched geolocation, and other session anomalies. Tune the weight these signals add to the risk score.

1. Fraud prevention — first-party and third-party fraud typologies: mule patterns, multi-accounting, and account-takeover signals. Tune the mule-network thresholds and how aggressively takeover signals change the status.

1. Crypto monitoring — on-chain transaction patterns for crypto flows. Works with currency_kind: "crypto" and a direction. Tune the exposure thresholds that move a transaction from IN_REVIEW to DECLINED.

1. Crypto screening — wallet risk and source-of-funds exposure. Set currency_kind: "crypto" with a direction 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).

1. Responsible gaming — for iGaming operators. Catches deposit-velocity spikes, suspicious limit changes, and bonus abuse, using the gambling_bet, gambling_limit_change, and gambling_bonus_change categories. Tune deposit-velocity windows and the limit-change patterns you treat as a harm signal.

1. E-commerce — chargeback and refund-abuse patterns for marketplaces and merchants. Tune the refund-velocity and chargeback-ratio thresholds.

1. Custom — your own rules built on top of the rest. Express conditions, velocity windows (count, sum, distinct), and any of the standard actions. Use it for product-specific typologies the seeded bundles don't cover.

How tuning works

Tuning happens in the Business Console, not in code. For each active rule you set the thresholds, the velocity windows, and the action — and the change is reviewed there before it goes live. That keeps compliance in control of policy and gives you an audit trail of every change. Because rules score in real time, you can dial sensitivity up during a known fraud wave and back down afterwards without a deploy.

Use cases

• Fintech — Finance + AML/CTF + Anomaly detection cover structuring, cumulative volume, and velocity spikes across deposits, transfers, and withdrawals.
• Crypto — Crypto monitoring + Crypto screening add on-chain pattern detection and automatic wallet screening on counterparty addresses.
• Lending — Anomaly detection + Fraud prevention catch synthetic-identity and mule patterns in disbursements and repayments.
• Marketplaces — E-commerce + Fraud prevention catch refund abuse, chargeback rings, and multi-accounting.
• iGaming — Responsible gaming + Anomaly detection catch deposit-velocity spikes, limit-change abuse, and bonus abuse.

How to integrate with Didit

1. Pick your bundles. In the Business Console, switch on the bundles that fit your business and tune their thresholds.
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.created and transaction.status.updated to keep your ledger in sync as analysts resolve alerts.
4. Add custom rules. Layer the Custom bundle on top for typologies unique to your product.

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 have to use all 11 bundles?

No. Switch on only the bundles relevant to your business and tune their thresholds. The rest stay off.

Can I write my own rules?

Yes. The Custom bundle lets you build rules with conditions, velocity windows, and aggregations on top of the 11 seeded bundles. Rules are managed in the Console so compliance reviews every change.

How much does it 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.

How do the bundles handle crypto?

Set currency_kind to crypto with a direction. Crypto monitoring scores on-chain patterns and Crypto screening can automatically run wallet screening on the counterparty address.

Where do I change a threshold?

In the Business Console. Rule changes are made and reviewed there rather than shipped in code, which keeps the rulebook auditable.

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.