AML Transaction Monitoring for Crypto: A Practical Guide
How AML transaction monitoring works in crypto: rules vs behavioural models, on-chain versus fiat monitoring, tuning alerts to cut false positives, and what regulators expect from your system.
Last updated: 29 July 2026
Most compliance teams do not fail their audit because they lack a transaction monitoring system. They fail because the system they bought generates ten thousand alerts a month, four analysts triage the loudest two hundred, and nobody can explain to an examiner why the other 9,800 were closed.
AML transaction monitoring is the control that watches customer activity after onboarding and flags what looks like money laundering, sanctions evasion, or fraud. In crypto it has to do that across two very different data domains at once: conventional fiat rails and a public blockchain. This guide covers how it actually works, the design decisions that determine whether it produces signal or noise, and what regulators expect to see.
Educational only, not legal or compliance advice. Confirm your obligations with qualified counsel in your jurisdiction.
What is AML transaction monitoring?
AML transaction monitoring is the continuous review of customer transactions against expected behaviour and known risk patterns, in order to detect and report suspicious activity. It is the operational half of an AML programme: KYC establishes who someone is at onboarding, and monitoring asks whether what they subsequently do is consistent with that.
The regulatory basis is the requirement to conduct ongoing due diligence on the business relationship and to file suspicious activity reports. In practice that means three obligations: detect anomalous activity, investigate it, and document the outcome either way. The third is the one firms most often under-build, and the one examiners test hardest.
Why crypto monitoring is a different problem
Traditional bank monitoring reads an internal ledger: your own records of your own customers' transfers. Crypto monitoring has to reconcile that with a public ledger you do not control.
| Traditional | Crypto | |
|---|---|---|
| Data source | Internal core banking records | Internal records plus public blockchain data |
| Counterparty identity | Named institution on both sides | An address, sometimes attributable to an entity |
| Settlement speed | Hours to days, reversible | Minutes, irreversible |
| Retrospective view | Limited to your own history | Full history of every address, forever |
| Core question | Is this payment unusual for this customer? | That, plus: where has this money been? |
The last row is the important one. A blockchain gives you something banking never had: complete, permanent transaction history for any counterparty. That is a genuine analytical advantage, and it is why crypto transaction monitoring leans so heavily on fund-flow tracing rather than only on behavioural thresholds.
The irreversibility cuts the other way, though. A bank can often claw back a wire. Once a withdrawal confirms on-chain, monitoring that fires afterwards has documented a loss rather than prevented one. This is why pre-transaction screening matters as much as post-transaction alerting.
How monitoring systems actually work
Rules-based detection
The foundation is deterministic rules: thresholds and patterns encoded as logic. Common examples include structuring (many transfers just below a reporting threshold), rapid in-and-out movement of funds, dormant accounts suddenly transacting at volume, and transfers to or from high-risk jurisdictions.
Rules are transparent and easy to explain to a regulator, which matters more than it sounds. Their weakness is that they are static: anyone who learns your thresholds can transact just under them.
Behavioural and anomaly models
The complement is statistical. Instead of asking whether a transaction crosses a fixed line, these models ask whether it is unusual for this customer, given their own history and their peer group. A 50,000 dollar transfer is unremarkable for an institutional account and highly anomalous for a retail user who has never exceeded 500.
These catch novel patterns that rules miss, at the cost of explainability. If your model cannot articulate why it flagged something, your analysts cannot defend the decision. The realistic architecture is both: rules for the known and the auditable, models for the unknown.
On-chain analytics
The crypto-specific layer. Rather than examining the transaction in isolation, analytics traces where the funds came from and where they go, attributing addresses to entities: exchanges, mixers, darknet markets, ransomware operators, sanctioned services.
The output is exposure rather than a binary verdict. "These funds are two hops from a sanctioned exchange, via a mixer" is a materially different alert from "large deposit received." Platforms such as Crystal Intelligence provide this attribution and tracing alongside real-time monitoring, which is what turns a raw blockchain record into a usable risk signal.
Screening at the gate
Because on-chain settlement is final, the highest-value control runs before a transaction executes: screening deposit and withdrawal addresses against sanctions lists and risk databases at the point of the request. Our guide to sanctions screening software covers this layer in detail.
The false positive problem
This is where most programmes actually live or die. Industry-wide, the overwhelming majority of AML alerts are closed without a report being filed. A 95% false-positive rate is not unusual, and every one of those alerts consumed analyst time.
The failure mode is predictable. Thresholds get set conservatively because nobody wants to be the person who tuned down a rule that later missed something. Alert volume outgrows the team. Analysts start closing alerts quickly to clear the queue. Quality drops precisely because volume was meant to increase safety.
What actually helps:
- Segment customers before you set thresholds. One rule set applied to retail and institutional users guarantees noise on one side and blindness on the other.
- Tune against outcomes, not intuition. Track which rules produce filed reports and which produce only closures. A rule that has never contributed to a report in twelve months is a candidate for retirement, and you should document that reasoning.
- Risk-score rather than binary-flag. Ranking alerts lets a finite team work the most probable cases first.
- Consolidate related alerts. Fifteen alerts on one customer over three days is one investigation, not fifteen.
- Measure analyst time per alert. If it is falling, that is usually a warning rather than a productivity gain.
The honest framing: an untuned system is not a conservative choice. It converts a detection control into a queue-clearing exercise, and examiners increasingly recognise the pattern.
What regulators expect
Requirements vary by jurisdiction, but the recurring themes are consistent.
- Risk-based calibration. Your monitoring should reflect a documented assessment of your own risks, not a vendor default. Be able to explain why your rules are your rules.
- Coverage of all products. Every asset, chain, and rail your customers can use needs to be in scope. Gaps in coverage are a common finding.
- Timeliness. Detection has to be fast enough to act on. Weekly batch review of an irreversible settlement layer is difficult to defend.
- Documented investigation. Every alert needs a decision, a rationale, and an identifiable decision-maker. An undocumented correct decision looks identical to a wrong one.
- Independent testing. Model validation and periodic tuning reviews, performed by someone other than the team that built the rules.
- Record retention. Alerts, investigations and reports kept for the statutory period and retrievable on request.
Monitoring also connects directly to the Travel Rule: counterparty data received with an inbound transfer is an input to your risk assessment, and missing or inconsistent data is itself a monitoring signal.
Choosing a system
Beyond the feature list, the questions that separate vendors:
- Does it monitor on-chain and fiat activity in one case file, or two disconnected systems?
- How quickly does a newly designated sanctions address propagate into live screening?
- Can your compliance team modify rules without a vendor engineering ticket?
- What is the demonstrated false-positive rate on data resembling yours? Insist on a proof of concept using your own transaction history.
- Does the audit trail satisfy your examiner, or only your operations team?
- Which chains are actually covered, at what depth of entity attribution?
Monitoring and non-custodial DeFi
A clarification worth making. AML transaction monitoring is an obligation of regulated intermediaries: exchanges, custodians, payment providers, and other businesses that hold customer funds or execute transactions on their behalf.
JewelSwap is non-custodial. Across MultiversX, Sui and Radix, users interact with smart contracts directly from wallets they control, and the protocol does not hold user assets or process transactions for them. There is no customer account base to monitor because there are no customer accounts. That is an architectural fact rather than a compliance position, and it changes the moment any business builds custody, fiat on-ramps or brokerage on top. Our AML compliance guide for exchanges and VASPs covers the full programme those businesses need.
Frequently asked questions
What is AML transaction monitoring?
The continuous review of customer transactions against expected behaviour and known risk patterns to detect potential money laundering, sanctions evasion or fraud. It covers detecting anomalous activity, investigating it, and documenting the outcome whether or not a report is filed.
How is crypto transaction monitoring different from traditional AML?
Crypto monitoring reconciles internal records with public blockchain data. It gains complete counterparty transaction history and fund-flow tracing, which banking never had, but loses reversibility: once a transfer confirms on-chain it cannot be recalled, so pre-transaction screening carries more weight.
Why do AML systems generate so many false positives?
Because thresholds are usually set conservatively and applied across customer types that behave very differently. Rates above 90% are common. The fix is segmenting customers before setting thresholds, tuning rules against whether they actually produce filed reports, and risk-ranking alerts rather than treating them as binary.
Is rules-based or AI-based monitoring better?
Neither alone. Rules are transparent and defensible to a regulator but static and easy to transact around. Behavioural models catch novel patterns but are harder to explain. Effective systems run both, using rules for known typologies and models for anomaly detection.
How quickly must monitoring detect suspicious activity?
Requirements vary, but the practical standard for crypto is that detection must be fast enough to act before settlement is final. Because on-chain transfers are irreversible, screening at the point of request is generally more valuable than alerting after the fact.
Do DeFi protocols need transaction monitoring?
Monitoring obligations attach to regulated intermediaries holding customer funds or transacting on their behalf. A genuinely non-custodial protocol has no customer accounts to monitor. Businesses that add custody, fiat on-ramps or brokerage on top of DeFi do fall in scope.
Keep reading
