How transaction monitoring works

Submit transactions, rules evaluate them in real time, and risky ones raise alerts and cases - $0.02 per screened transaction.

#Where it sits

Identity verification answers "who is this?" at onboarding. Transaction monitoring answers "is this activity normal?" afterwards. They're separate products on the same platform, and a regulated business usually needs both - onboarding checks alone tell you nothing about what a customer does once they're in.

#Where it is in the console

Open Transaction monitoring & Travel Rule in the sidebar. Its tabs are Overview (your transaction analytics: count, average amount, volume and the rules triggered), Transactions, Rules, Crypto monitoring (greyed out where it isn't available yet), Travel Rule and Settings, plus a link to Events. See products and what they include.

On Transactions, the views split what needs you (Needs review) from the rest (All, Declined, and Ready to accept and Flagged where they're available). Click a transaction for a preview that explains why it was held, declined or passed, with its risk and timeline, and decide right there: Approve releases it, and Change status changes a decision already taken. Hold and Block from the preview, and Open case, are rolling out and may be greyed out for you. Select several to act on them together. Press Sample transaction in More actions, in Sandbox, to watch a rule fire without wiring anything up.

Where case management is available, cases opened from transactions are listed under Case management → Cases in the same panel. See working with cases.

#The flow

1. Submit the transaction

   Your backend sends the transaction as it happens, with your own identifier (txn_id), the amount, currency, direction, and the parties involved.

2. Rules evaluate it

   Your configured rules run in real time - thresholds, velocity checks, counterparty checks, and any custom logic. The transaction comes back with a status, a score, and a severity.

3. Alerts and cases

   Transactions that trip a rule raise alerts. Alerts group into cases so an analyst works a customer's pattern rather than isolated events.

4. Webhooks keep you in sync

   transaction.created fires with the initial verdict; transaction.status.updated fires whenever it changes afterwards - analyst action, remediation, a blocklist match, or a provider update.

#Rules are the product

Everything useful about transaction monitoring is in the rules, and they're yours to configure. Broadly they cover:

• Amount thresholds - single transactions above a limit.
• Velocity - many transactions in a window, or a total crossing a limit.
• Structuring patterns - repeated amounts just under a reporting threshold.
• Counterparty risk - who is on the other side.
• Direction - inbound and outbound treated differently, which they usually should be.
• Geography - jurisdictions in your risk assessment.

Didit ships a rules library as a starting point. Treat it as a starting point: a rule set that isn't tuned to your product's normal behaviour will either alert on everything or nothing. See the rules library.

#Fiat and crypto

Rules cover both fiat and crypto flows. If you're configuring crypto monitoring and the rule inputs read as fiat-oriented, that's worth raising with your Didit contact rather than working around - the shape of what you need to express matters more than forcing it into a field that nearly fits.

Crypto brings a second dimension: the address on the other side has its own on-chain risk profile. That's wallet screening. See wallet screening and crypto.

#Linking transactions to verified identities

The value of monitoring multiplies when a transaction is attributable to a verified person. Use consistent identifiers - vendor_data for the user, vendor_business_data for a business - so a transaction, its alerts, and the identity behind it resolve to the same entity. Without that, you're monitoring anonymous flows.

#Statuses and your own state

Transaction statuses are their own set, separate from verification session statuses. Don't reuse your KYC mapping for them. See transaction statuses.

#What it costs

Each of these is billed on its own line. A Travel Rule transfer is billed on its own $0.02 line instead of the standard screening fee, never both. See Travel Rule.

#If wallet screening or a feature looks unavailable

Some monitoring capabilities are enabled per organization. If the console shows a feature as unavailable or coming soon and you need it, ask support to confirm what's enabled on your account rather than assuming it's a configuration you've missed.

#Regulatory reporting

If your obligation includes filing suspicious activity reports, Didit's case management can produce regulatory reports from a case. Which report formats and which regulators are supported is a factual question for your Didit contact - don't design a filing process around an assumption. See regulatory reports.