Monitoring Fiat and Crypto in One Rule Engine

Most firms that touch both fiat and crypto run two monitoring stacks: a traditional rules engine for bank transfers and card payments, and a separate on-chain analytics tool for wallets. The two never quite line up. A user who deposits fiat and withdraws crypto has their risk picture split across two systems, two alert queues, and two vendors — and the laundering pattern that crosses the fiat-crypto boundary is exactly the one neither system sees whole.

Didit's Transaction Monitoring API scores both in the same engine. A single currency_kind field — fiat or crypto — tells the engine what it's looking at. Fiat payments run against the fiat rule bundles; crypto flows can automatically trigger on-chain wallet screening on the counterparty address; and for Virtual Asset Service Providers (VASPs), the same engine carries FATF Travel Rule support. One product, one alert queue, one price: $0.02 per transaction.

This guide explains how the engine handles both currency kinds and what crypto unlocks.

Key takeaways

• One currency_kind field — fiat or crypto — routes a transaction to the right rules in the same engine.
• Crypto flows can trigger on-chain wallet screening automatically on the counterparty address, checking exposure to sanctioned entities, darknet markets, mixers, ransomware, and stolen funds.
• FATF Travel Rule support is built in for VASPs — originator and beneficiary data exchange with obligation tracking.
• Fiat and crypto share one alert queue and one case workflow, so a user's full risk picture lives in one place.
• Wallet screening starts at $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).
• $0.02 per transaction for monitoring, no minimums. AML screening on a flagged party is billed separately at $0.20.

What "one engine for both" means

The engine doesn't treat crypto as a bolt-on. A transaction carries a currency_kind of fiat or crypto, and the rule bundles know what to do with each. Fiat payments run against Finance, AML/CTF, Anomaly detection, Fraud prevention, and the rest. Crypto flows additionally engage Crypto monitoring (on-chain pattern detection) and Crypto screening (wallet risk and source-of-funds exposure).

Crucially, the velocity windows, the case management, the SAR workflow, and the four statuses — APPROVED, IN_REVIEW, DECLINED, AWAITING_USER — are shared. A user who moves money across both rails has one risk picture, not two. An analyst works one queue. And a structuring pattern that fragments across fiat deposits and crypto withdrawals is visible because both halves land in the same engine.

Why it matters

The regulatory perimeter has converged. The EU's MiCA framework brings crypto-asset service providers under AML obligations comparable to traditional finance, and the FATF Travel Rule applies to virtual-asset transfers the way the wire-transfer rule applies to fiat. Firms operating across both rails are expected to monitor both to the same standard — and to see the whole customer, not two fragments.

Running two stacks works against that. Reconciling alerts across vendors is manual and error-prone, the audit trail fragments at the seam, and you pay twice. A unified engine gives regulators what they want — one coherent monitoring program across both rails — and gives you one integration, one alert queue, and one bill.

Technical details

Fiat and crypto transactions hit the same endpoint on the unified /v3/ API; the currency_kind field is what differs. A crypto transfer adds a direction so the engine knows whether to screen an inbound or outbound counterparty address:

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_cd55a1",
    "category": "finance",
    "amount": 12000,
    "currency": "USDC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T16:40:00Z",
    "subject": { "vendor_data": "user_9120", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL", "wallet_address": "0x9f...c4a1" }
  }'

When the counterparty address carries exposure, the response reflects it:

{
  "transaction_id": "txn_cd55a1",
  "status": "IN_REVIEW",
  "risk_score": 73,
  "triggered_rules": [
    { "name": "Wallet exposure — mixer", "bundle": "Crypto screening", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_d1c6f3"
}

Wallet screening. Set currency_kind: "crypto" with a direction and the engine can automatically run on-chain wallet screening on the counterparty address. It starts at $0.02 per screening with bring-your-own-key (Crystal or Merkle Science).

Travel Rule. For VASPs, the same engine carries FATF Travel Rule support — originator and beneficiary data exchange with obligation tracking, and dedicated travel-rule statuses including COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, and EXEMPT.

Webhooks. Subscribe to transaction.created and transaction.status.updated to keep both rails in sync.

Price. $0.02 per transaction. Wallet screening from $0.02 per screening (BYOK). AML screening on a flagged party billed separately at $0.20.

Crypto, wallet screening, and the Travel Rule

For crypto flows, two things happen automatically when you set currency_kind: "crypto" with a direction:

• On-chain wallet screening. The engine can screen the counterparty address against on-chain risk — sanctioned entities, darknet markets, mixers, ransomware, and stolen funds — and feed the result into the same risk score and status. Pre-transfer screening on an address lets you decide before an outbound transfer settles.
• FATF Travel Rule. For transfers between VASPs, the engine handles originator and beneficiary data exchange and tracks the obligation through its own travel-rule statuses, so the compliance step rides along with the transaction instead of living in a separate process.

Both feed the shared case workflow: a wallet-exposure hit or a stalled Travel Rule obligation opens an alert in the same queue as a fiat structuring flag, and an analyst works it the same way.

Use cases

• Crypto exchanges & on/off-ramps — fiat deposits and crypto withdrawals monitored in one engine, with automatic wallet screening on outbound addresses.
• Neobanks adding crypto — one monitoring program across both rails instead of bolting on a second vendor.
• VASPs — Travel Rule originator/beneficiary exchange carried inside the same transactions you already monitor.
• Payment platforms — stablecoin settlement screened on-chain alongside fiat rails in one alert queue.
• Marketplaces with crypto payouts — seller payouts in crypto screened for wallet exposure before funds release.

How to integrate with Didit

1. Switch on the right bundles. In the Business Console, enable the fiat bundles plus Crypto monitoring and Crypto screening, and configure Travel Rule if you're a VASP.
2. Send both rails. POST /v3/transactions/ with currency_kind set to fiat or crypto; add a direction and counterparty wallet_address for crypto.
3. Let crypto screen automatically. Crypto transactions can trigger on-chain wallet screening on the counterparty address — bring your own Crystal or Merkle Science key.
4. Work one queue. Investigate fiat and crypto alerts in the same case workflow, and listen for transaction.status.updated to stay in sync.

Because it's all on the unified /v3/ API, a KYC user, a KYB entity, and both their fiat and crypto transactions live on one platform — one identity-and-fraud platform, end to end.

Frequently asked questions

How does the engine tell fiat and crypto apart?

The currency_kind field — fiat or crypto — routes the transaction to the right rules in the same engine.

Does crypto get wallet-screened automatically?

Yes. 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.

Is the FATF Travel Rule supported?

Yes. For VASPs, the same engine carries Travel Rule support — originator and beneficiary data exchange with obligation tracking and dedicated travel-rule statuses.

Do fiat and crypto share one alert queue?

Yes. Both currency kinds feed the same case management, SAR workflow, and four statuses, so a user's full risk picture lives in one place.

What does it cost?

$0.02 per transaction for monitoring, no minimums. Wallet screening starts at $0.02 per screening with bring-your-own-key, and AML screening on a flagged party 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.