Cutting AML false positives without missing real risk

Most AML programmes do not have a detection problem. They have a triage problem wearing a detection problem's clothes. When nine alerts in ten are noise, the tenth gets the same thirty seconds of attention as the rest.

Why crypto monitoring generates so much noise

Two causes, and they compound.

The first is inherited logic. Many crypto programmes run rules adapted from correspondent banking — round-number thresholds, velocity counts, jurisdiction flags. On-chain, these fire constantly for entirely benign reasons: a market maker's rebalancing looks like structuring, a bridge contract looks like a high-velocity counterparty, an exchange hot wallet touches everything.

The second is binary treatment of exposure. A rule that fires whenever an address has any path to a mixer will fire on a very large share of active addresses, because at four or five hops nearly everything connects to nearly everything. Exposure is a gradient. Treating it as a boolean manufactures noise at industrial scale.

Measure precision before you tune anything

You cannot improve what you have not instrumented. Four numbers, reported monthly:

Metric	Definition	Why it matters
Precision	Escalated alerts ÷ total alerts	The honest headline. Track per rule, not just overall
Alert-to-SAR rate	SARs filed ÷ total alerts	Ties monitoring to outcomes rather than activity
Median time to disposition	Alert raised → decision recorded	Rising median is the earliest sign of fatigue
Backlog age at 90th percentile	Age of the oldest 10% of open alerts	The number an examiner will ask for

Report precision per rule. Aggregate precision hides the two or three rules generating most of the noise, and those rules are almost always where the entire problem lives. In most portfolios we have looked at, fewer than five rules produce more than half the false positives.

Tune on evidence, not on volume

The lazy fix is to raise the threshold until the queue is manageable. It works, in the sense that alert count falls — and it removes true positives in the same proportion, because a blunt threshold has no idea which alerts were the good ones. Tune on the dimensions that actually carry information instead.

Hop distance

Direct exposure to a sanctioned address and five-hop exposure are different facts. Encode them differently: direct exposure blocks, one to two hops reviews, three or more hops informs a risk band without raising an alert. This single change is usually the largest available reduction in alert volume.

Exposure share

An address that received 0.2% of its inflow from a risky service is not the same as one that received 60%. Weight by share of value, not by presence of a path. Set a floor — a fraction of a percent at three hops is background noise in any active network.

Attribution confidence

If your provider publishes confidence per attribution, use it. A 0.95-confidence darknet-market attribution deserves an alert; a 0.4-confidence cluster guess deserves a note on the profile. Firms that treat every attribution as equally certain are choosing to be wrong in both directions at once. This is why we expose confidence on every finding rather than collapsing it into a single number — the reasoning is in what a wallet risk score measures.

Suppress patterns, not addresses

Whitelisting individual addresses does not scale and quietly becomes a risk in itself — nobody remembers why an entry was added, and nobody removes it. Suppress patterns instead, with an expiry and an owner:

• Known-entity contracts. Bridges, DEX routers and hot wallets belonging to attributed services, suppressed by entity rather than by address.
• Customer-baseline behaviour. A market maker's rebalancing pattern, suppressed against that customer's own established profile.
• Background exposure. Sub-threshold indirect exposure beyond a hop limit, suppressed globally with the limit written into policy.

Every suppression needs a named owner, a documented rationale, an expiry date and a review. An unreviewed suppression list is where a real alert goes to die, and an examiner reading it will draw exactly that conclusion.

Tuning that you cannot explain to an examiner is not tuning. It is a decision to see less, recorded nowhere.

What good looks like

A well-tuned on-chain monitoring stack tends to show a similar shape: precision materially above legacy rule-based baselines, a stable median disposition time, a backlog that clears within its stated window, and a suppression list small enough that a human can read it in one sitting. AI-assisted triage helps here — it cuts manual review and speeds response — but it helps by ranking and summarising evidence for a human, not by deciding. The analyst still owns the disposition.

The thing worth internalising is that false positives are not a cost of doing compliance. They are a design outcome, and design outcomes can be changed.