What breaks when organisations rely only on transaction volume thresholds to detect crypto laundering networks?

Why This Matters for Security Teams

Transaction volume thresholds are attractive because they are simple to configure, easy to explain, and convenient for alert tuning. The problem is that laundering networks are rarely optimised for loudness. They are optimised for continuity, layering, and plausible movement across accounts, chains, and service types. That means a rule focused only on size can miss the actual laundering path even when the overall scheme is active and coordinated. Current guidance suggests aligning detection to risk indicators, not just event magnitude, and mapping control coverage to NIST Cybersecurity Framework 2.0 functions such as Detect and Respond.

For compliance, the failure is not merely that some alerts are noisy. It is that low- and mid-volume transactions can still satisfy the full laundering lifecycle when they are distributed across many wallets, intermediaries, and cash-out points. In practice, teams that rely on thresholds alone often discover the problem only after a cluster of accounts has already been used for layering, rather than through intentional typology-led monitoring.

How It Works in Practice

Effective crypto laundering detection starts by treating transaction size as one signal among many. Transaction volume can help prioritise alerts, but it should not be the primary logic for identifying suspicious behaviour. Investigators generally need to combine value thresholds with address risk, hop count, entity clustering, timing patterns, source and destination exposure, and behavioural links to known typologies such as structuring, peel chains, mixer usage, rapid in-and-out movement, and repeated interaction with cash-out venues.

In mature programmes, this typically means:

• Scoring addresses and counterparties by exposure, not just transaction value.
• Tracing flows through intermediary wallets to identify layering patterns.
• Grouping activity into networks so repeated small transfers are viewed as a campaign.
• Combining rules with graph analytics to surface relationships that thresholds miss.
• Using case management to preserve typology evidence for AML review and escalation.

This is also where identity and access controls matter. When wallets, VASPs, or internal investigation tools are accessed by staff, service accounts, or automation, the monitoring stack should follow least privilege and strong session controls. NIST SP 800-207 Zero Trust Architecture is relevant here because it reinforces continuous verification for systems and users handling sensitive financial intelligence. Where operational controls are being mapped, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a practical baseline for monitoring, access enforcement, and auditability.

These controls tend to break down when analysts lack entity resolution across wallets and exchanges because the same laundering network appears as unrelated low-value events.

Common Variations and Edge Cases

Tighter volume logic often reduces false positives, but it also raises the risk of missing deliberately fragmented activity, so organisations must balance operational efficiency against typology coverage. The best practice is evolving rather than settled, especially where laundering behaviour crosses fiat rails, DeFi services, and custodial platforms.

Edge cases matter. High-volume activity is not always suspicious, and low-volume activity is not always benign. A legitimate treasury flow can look large but routine, while a laundering cell can stay below thresholds by splitting transfers across time, assets, and accounts. The reverse also happens: some fraud patterns produce sudden spikes that look abnormal but are not laundering. This is why current guidance favours layered detection, human review, and network context over any single threshold.

For firms operating in regulated environments, the detection model should also be consistent with wider financial crime controls and alert governance. If the programme is integrated into a broader risk stack, teams should ensure that transaction monitoring, investigation workflows, and escalation criteria are documented and testable. Where customer or counterparty identity is in scope, the control model should also support traceability from wallet activity back to verified identities or risk-rated entities, because volume alone cannot explain intent.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on network logs to detect Shadow AI?
• What breaks when organisations rely on legacy DLP for AI workflows?
• What breaks when organisations rely on passwords and OTPs for high-risk access?
• What breaks when organisations rely only on observability for AI governance?