Continuous Monitoring: Why a Cleared Crypto Screening Can Become a Liability
A wallet that scores clean at onboarding can route funds through a sanctioned mixer three months later, and your system will still show the original green flag. That silent staleness is one of the more underappreciated compliance risks in crypto, and it is now being addressed directly through event-driven continuous monitoring technology designed to rescreen enrolled addresses whenever something material changes.
The Staleness Problem in Crypto Screening
Traditional AML screening was built around a model where risk moved slowly. A periodic review, weekly or monthly, was generally sufficient to catch meaningful changes in counterparty profiles. Crypto does not operate on that cadence. Funds can move across multiple hops within hours, and a wallet's risk profile can shift from negligible to critical between two manual checks.
How a Clean Score Becomes a High-Risk Record
The mechanics are straightforward. At onboarding, a compliance team screens a wallet and records a low risk score, say 0.5 out of 10. That record sits in the system. Weeks or months later, the funds in that wallet move forward to a darknet marketplace. Nothing about the original screening was incorrect at the time it was run. But the wallet is now, by any reasonable assessment, a 10. If no one happens to rescreen it manually, the 0.5 remains the operative figure. The team continues treating a high-risk counterparty as a cleared one.
This is not a hypothetical edge case. It is a structural gap in how most compliance workflows handle post-onboarding monitoring, and it becomes harder to manage as transaction volumes grow. Rescreening every enrolled wallet and transaction continuously by hand is not operationally viable at scale. The only way to close the gap without drowning analysts in work is automation tied to meaningful trigger events.
Two Ways Existing Monitoring Tools Fall Short
Most monitoring approaches available to compliance teams today sit at one of two unhelpful extremes, and understanding where they fail helps clarify what a well-designed solution needs to do differently.
Label-Only Monitoring Misses Transactional Risk
Some tools watch for label changes on connected addresses and fire an alert when a label appears or changes. The limitation is that risk can increase without any label changing at all. A new transaction that routes funds through a high-risk cluster, or a fresh connection to an illicit actor, will not trigger a label-based alert. The wallet's labels remain unchanged, the monitoring system stays silent, and the exposure accumulates invisibly.
Undifferentiated Alerts Create Noise, Not Signal
At the other end, some monitoring systems alert on every label change regardless of materiality. Compliance teams using these approaches report being overwhelmed by notifications that have no bearing on genuine risk changes. When everything is flagged, nothing is prioritised. Analysts spend time triaging low-significance alerts rather than investigating the changes that actually matter, which is a resource problem and an audit-quality problem simultaneously.
How Event-Driven Continuous Monitoring Works
The approach that addresses both failure modes combines two complementary layers: event-driven detection and scheduled rescreening. Together they ensure that risk changes are caught as they happen and that nothing drifts unnoticed over time.
Step One: Event Detection
The system watches enrolled screenings for the specific events that can change a risk outcome: a new or changed label on a screened address or counterparty, or a change in the clusters an address belongs to. Each qualifying event triggers a full rescreen, not a cached lookup. This matters because a full rescreen runs the address against the current state of the attribution graph, capturing transactional changes that a label check would miss.
Step Two: Your Risk Rules, Not a Generic Threshold
The rescreen is scored against the firm's own risk rules rather than a vendor-defined default. This means a change that would be material for a payment institution handling high-volume retail flows can be configured differently from the threshold a crypto-native exchange or a corporate treasury function would apply. Critically, those rules can be updated without raising a support request, so the monitoring logic evolves alongside the firm's own risk appetite and regulatory environment.
Step Three: Notification on Your Terms
Alerts go out by webhook or Slack only when a risk change crosses the criteria the firm has set: a score crossing a defined threshold, a triggered risk rule, a change in risk score magnitude, or a specific screening source. Teams are not notified of changes that fall below their own materiality bar. For firms integrating this into case-management or digital asset accounting software workflows, the webhook output routes only relevant changes into the existing pipeline, avoiding the need to stand up a separate system.
The Scheduled Rescreen Layer
Alongside event detection, every enrolled wallet and transaction is rescreened on a regular schedule as a full recalculation. The two layers are complementary: event detection catches change as it happens, while scheduled rescreening ensures that anything not captured by a discrete trigger event does not drift indefinitely. The combination is designed to give compliance teams confidence that no meaningful change goes unnoticed, while keeping alert volume proportional to actual risk movement.
Compliance Use Cases Across Firm Types
The design accommodates several different operational contexts, each with different constraints on analyst time, alert tolerance, and audit requirements.
High-Volume Processors
Firms processing large numbers of time-sensitive screenings need to react the moment a cleared entity becomes risky. Continuous monitoring keeps risk current without manual review cycles, and configurable webhook output routes only the relevant changes into existing case workflows. This matters particularly for firms managing crypto bookkeeping software integrations where transaction records need to reflect current compliance status, not onboarding-point snapshots.
Smaller Compliance Teams With Audit Obligations
Teams with limited analyst headcount that are nonetheless expected to maintain ongoing, auditable monitoring benefit from a solution that covers the window between scheduled reviews while keeping alert noise low. The audit trail produced by each automated rescreen provides the documented evidence needed when a regulator or auditor asks how a risk decision was made and when.
Payment and Exchange Operations
For operations that need to keep transaction approvals fast without missing risk on pay-ins and pay-outs, configurable risk thresholds support hold-or-release decisions with auditable evidence behind them. This is directly relevant for firms operating under MiCA CASP authorization requirements, where ongoing monitoring obligations attach to the licence from day one. Our earlier coverage of MiCA CASP authorization requirements sets out what those obligations look like in practice.
Corporate Treasuries and DeFi Participants
Entities managing ecosystem addresses or counterparty relationships in decentralised finance can monitor known addresses for meaningful change without manual rescreening. This keeps crypto risk exposure accurate across a portfolio of relationships rather than limiting scrutiny to onboarding moments.
Why Attribution Data Quality Underpins the Whole System
An automated rescreening system is only as useful as the underlying attribution data it draws on. Risk scores produced from shallow or stale blockchain attribution can generate false reassurance just as easily as a manual process that is not run frequently enough. Firms evaluating any continuous monitoring capability should apply the same data quality scrutiny to the rescreening layer that they would apply to the initial screening tool. Our piece on blockchain analytics data quality due diligence covers the specific questions firms should be asking about attribution methodology, coverage, and update frequency.
The value of automated rescreening scales with the breadth and recency of the attribution graph behind it. An event-driven rescreen that runs against outdated cluster data may still miss recent risk connections, even if the trigger mechanism works correctly. This is particularly relevant for EU-based firms where MiCA's ongoing monitoring obligations require that risk assessments reflect current information, not point-in-time snapshots from months earlier.
What This Means for Compliance Records and Audit Readiness
The regulatory expectation across most jurisdictions with developed crypto AML frameworks is not simply that firms screen at onboarding. It is that firms maintain current risk assessments and can demonstrate how those assessments were reached. A compliance record that shows a single onboarding screening with no subsequent monitoring activity is increasingly difficult to defend when a regulator or auditor asks about an entity that was later identified as high-risk.
Continuous monitoring addresses this at the record level: every automated rescreen generates a timestamped, auditable event that documents what was checked, when, what risk rules applied, and what the outcome was. For firms where crypto accounting software or digital asset accounting software sits at the centre of the compliance and reporting workflow, the ability to attach current-as-of risk status to transaction records, rather than onboarding-point scores, reduces the gap between the compliance system of record and the actual risk position of the portfolio.
Source: Elliptic
What is continuous monitoring in crypto AML compliance?
Continuous monitoring refers to automated systems that watch enrolled wallet addresses and transactions for events that can change their risk profile, then rescreen them against the firm's risk rules and alert the compliance team when a material change is detected. It sits between periodic manual reviews to ensure risk assessments remain current.
Why does a cleared screening go stale in crypto?
A screening records risk at the moment it is run. After that point, the wallet can receive funds from newly sanctioned addresses, forward funds to high-risk destinations, or become associated with illicit actors through cluster changes. None of those developments update the original screening record automatically, so the compliance system retains an accurate but outdated picture.
How does event-driven rescreening differ from scheduled rescreening?
Event-driven rescreening fires when a specific trigger occurs: a label change, a cluster reassignment, or a new transaction connection. Scheduled rescreening runs at defined intervals regardless of whether a trigger has occurred. A robust continuous monitoring system uses both: events catch risk as it emerges, and the schedule ensures nothing drifts through gaps between events.
What are the MiCA implications for ongoing monitoring?
Under MiCA, authorised CASPs carry ongoing AML/CFT obligations that require risk assessments to remain current, not limited to onboarding. Firms that rely solely on onboarding screenings without a documented ongoing monitoring process face a compliance gap that regulators in the EU are increasingly focused on. Continuous monitoring with auditable rescreen records directly addresses that requirement.
How should firms evaluate the data quality behind automated rescreening?
The reliability of any continuous monitoring output depends on the attribution data used in the rescreen. Firms should assess the coverage, update frequency, and methodology of the blockchain analytics provider supplying the underlying data, applying the same scrutiny they would to the initial screening tool. A well-designed rescreen against poor attribution data will still produce unreliable risk scores.