Operating a virtual asset service provider (VASP) – an entity that exchanges, transfers, or safeguards digital assets on behalf of others – without a defensible transaction monitoring program is no longer a second-order compliance risk. Regulators across the leading hubs are treating monitoring gaps as primary findings: accounts get frozen, licences get suspended, and banking relationships collapse before a business has time to remediate. This page explains what transaction monitoring setup under heightened scrutiny requires, why generic off-the-shelf tooling routinely fails the standard, and how OBOLUS structures a defensible program for businesses operating across multiple jurisdictions.
The short answer: heightened scrutiny – the enhanced due-diligence standard that applies when a customer or transaction presents elevated risk – demands a monitoring architecture that is calibrated, documented, and demonstrably proportionate to the specific risk profile of the business. Under MiCA and the national regimes converging on it, under the VARA rulebooks in Dubai, under the MAS Payment Services Act regime in Singapore, and under FATF Recommendation 15 globally, a monitoring program is auditable: regulators do not merely want to see that a system exists; they want to see the logic behind it. Getting that logic wrong at the design stage compounds into every subsequent audit cycle.
This page maps the regulatory basis, the build process, the most common structural mistakes, the cross-border interaction with banking and the Travel Rule, and the practical decision points that shape the right setup for your business.
What is Heightened Scrutiny in a Digital-Asset AML Context?
Heightened scrutiny is the enhanced monitoring and due-diligence obligation that activates when standard controls are insufficient for the risk presented. Under FATF Recommendation 15 and the domestic regimes implementing it – including MiCA's AML obligations as applied by ESMA and national competent authorities, VARA's Customer Due Diligence rulebook, and the MAS Notice on Prevention of Money Laundering for DPT service providers – a VASP must apply enhanced measures to customers and transactions that meet defined risk thresholds. The obligation is not binary; it scales with the risk indicator and the business model.
In practice, heightened scrutiny applies across several dimensions. A customer presenting politically exposed person (PEP) status triggers it automatically in most regimes. A transaction from or to a high-risk jurisdiction, a mixing service, or a counterparty wallet flagged by a chain-analytics tool also triggers it. So does unusual transaction velocity, structuring patterns, or a mismatch between declared business purpose and actual activity. The monitoring system must be capable of detecting each trigger, routing it to the right review queue, and generating a record that shows the compliance team acted proportionately.
What separates a defensible heightened-scrutiny program from a checkbox exercise is the calibration layer: the rules, thresholds, and risk-score weightings that sit beneath the user interface of any monitoring platform. Off-the-shelf systems ship with generic parameters. Regulators in the leading hubs – particularly the FCA in the UK and VARA in Dubai – have made clear through supervisory communications that a VASP cannot simply accept vendor defaults and call it done. The calibration must reflect the business's own customer base, product set, and geographic exposure.
The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis. For a scoped assessment of your current monitoring setup, contact OBOLUS at Map your options.
The Regulatory Basis: Which Regimes Require What?
Every major licensing regime now mandates a transaction monitoring program as a condition of authorisation, and the standard has hardened materially over the past two years as regulators have moved from framework-building to active supervision. Understanding which regime applies – and where they overlap – is the first design decision.
Under MiCA and the EU's broader AML architecture, CASPs (Crypto-Asset Service Providers) are subject to the same AML obligations as other obliged entities under the applicable EU AML directives, as they are phased into the scope of the framework. The practical effect is that a CASP authorised in Lithuania, Malta, or any other EU member state must maintain a monitoring system capable of identifying and escalating suspicious transactions in real time, and must document the rationale for every escalation decision. Passporting across the EU does not dilute this obligation – each jurisdiction where the CASP operates may impose additional supervisory expectations.
In Dubai, the VARA Virtual Asset Issuance Rulebook and the Compliance and Risk Management Rulebook set out explicit expectations on transaction monitoring as part of the broader risk-based AML program. VARA has signalled in its supervisory posture that monitoring systems will be tested during examinations, not merely evidenced by policy documentation. The ADGM's FSRA, governing the Abu Dhabi financial free zone, applies a similar risk-based standard under its own framework.
In Singapore, the MAS Notice on Prevention of Money Laundering and Countering the Financing of Terrorism for digital-payment-token service providers establishes a detailed baseline that includes transaction monitoring as a named requirement, with explicit guidance on risk-based calibration. MAS has historically been among the more prescriptive regulators on AML documentation quality, and in our cross-border practice we consistently see Singapore-licensed clients face the most detailed questionnaire on monitoring logic during licence renewal.
In the UK, the FCA registration under the Money Laundering Regulations makes transaction monitoring a live supervisory issue. The FCA's published findings from its AML supervisory visits to registered crypto businesses have called out inadequate monitoring as a recurring theme. A firm that cannot demonstrate alert coverage, escalation logic, and senior-management sign-off on threshold calibration faces material risk at renewal.
Across all these regimes, the Travel Rule – the obligation to transmit originator and beneficiary information with a virtual-asset transfer – intersects directly with transaction monitoring. The monitoring system must be capable of identifying Travel-Rule-covered transfers, flagging missing or deficient data, and holding or suspending transfers where required. Building the Travel Rule into the monitoring architecture at the design stage is substantially less expensive than retrofitting it after an examination finding.
How Do You Build a Defensible Transaction Monitoring Program?
A defensible transaction monitoring program is built in five stages, each of which produces an auditable output that survives regulatory review. The stages are sequential, but the documentation they generate is cumulative: each layer builds on the last, so design errors made early propagate into every subsequent cycle.
Stage one is the risk assessment. Before any system is selected or configured, the business must complete a written risk assessment that maps its customer types, product set, transaction corridors, and jurisdictional exposure. This document becomes the justification for every threshold and rule that follows. Regulators do not expect a one-size-fits-all assessment; they expect a document that is specific to the business. A custody-only operator has a materially different risk profile from a spot exchange serving retail users in multiple jurisdictions, and the risk assessment must reflect that difference.
Stage two is system selection and baseline configuration. Most VASPs use a specialist chain-analytics or transaction-monitoring platform. The selection must be documented: what was evaluated, why the chosen platform was adequate for the identified risk profile, and what its coverage limitations are. Crucially, the baseline configuration – the default alert thresholds, the jurisdictional risk weightings, the wallet-screening lists – must be reviewed and adjusted against the risk assessment. Accepting vendor defaults without documented review is among the most common findings in FCA and VARA supervisory visits.
Stage three is the calibration and tuning process. Calibration means setting the parameters that determine when the system generates an alert. Too broad, and the compliance team is buried in false positives that degrade the quality of review. Too narrow, and genuine risk passes through. The calibration record must show the rationale for every material threshold: why a particular velocity limit was chosen, what data was used to set it, and who approved it. ESMA guidance on CASP supervision emphasises that calibration decisions are audit targets.
Stage four is the alert-handling and escalation workflow. The monitoring system generates alerts; the workflow determines what happens next. Every alert must be routed, reviewed within a defined timeframe, and either closed with a documented rationale or escalated to the MLRO (Money Laundering Reporting Officer) for a suspicious activity report decision. The workflow must be written into policy, trained into the operations team, and tested through periodic table-top exercises. Regulators in the leading hubs – including AFSA in Kazakhstan and the SFC in Hong Kong – expect to see evidence of testing, not just documentation of process.
Stage five is the review and governance cycle. A monitoring program that was adequate at launch degrades as the business grows, as the product set changes, and as the threat environment evolves. The governance cycle must include a scheduled review of alert volumes, a tuning review when the business makes a material change, and an annual independent review of the program as a whole. The review must be documented and presented to senior management or the board; the sign-off record is a supervisory exhibit.
In a recent engagement, a digital-asset lending business had onboarded a well-regarded monitoring platform but had not adjusted any of the vendor defaults for its specific counterparty profile – primarily institutional borrowers in three jurisdictions. During an MLRO-transition review, the compliance gap surfaced: the alert rules were calibrated for a retail-exchange model, and the institutional-flow patterns were generating near-zero alerts. OBOLUS conducted a full calibration review, rebuilt the threshold and rule set against the actual transaction data, and produced the documentation package for the incoming MLRO. The result was a program that reflected the business's actual risk profile and could withstand a supervisory visit.
What Are the Cross-Border Challenges in Transaction Monitoring?
A VASP operating across more than one jurisdiction faces a monitoring challenge that domestic operators do not: the monitoring program must satisfy multiple regulatory standards simultaneously, and those standards do not always align. Getting this right requires mapping the monitoring obligations layer by layer, not assuming that the most stringent standard covers all others.
The first cross-border tension is jurisdictional risk weighting. The list of countries designated as high-risk for AML purposes differs between the EU's framework (applied under MiCA), FATF's published lists, and the domestic lists maintained by VARA, MAS, and the FCA. A monitoring system calibrated only to the FATF list will miss country-risk alerts required by one or more of those domestic regimes. The monitoring configuration must incorporate all applicable lists and document the source and review date for each.
The second tension is the Travel Rule threshold question. The data-transmission obligation that the Travel Rule imposes applies to transfers above a defined threshold, but that threshold varies by jurisdiction and the specific implementing rules are subject to ongoing revision. Operators we advise routinely encounter the practical problem of a transfer that triggers Travel Rule obligations in the destination jurisdiction but not in the originator's jurisdiction. The monitoring system must be capable of identifying these asymmetric cases and applying the higher standard or flagging them for manual review.
The third tension involves the interaction between on-chain monitoring and traditional financial crime controls. A VASP that also holds a payment institution licence or a money transmission authorisation – common for businesses operating across digital and fiat rails – must demonstrate that its transaction monitoring program covers both. Regulators increasingly examine the gap between the on-chain monitoring tool and the core-banking or payment-processing system; alerts generated in one environment that are not visible in the other create a governance blind spot that supervisors treat as a program failure.
The fourth cross-border consideration is banking. Correspondent banks and the EMIs (electronic money institutions) that service crypto businesses apply their own transaction monitoring to the fiat flows they process on behalf of VASPs. A VASP whose on-chain monitoring generates suspicious activity reports at a rate that is not visible to its bank – because the bank operates in a different jurisdiction and cannot see the chain-analytics output – is exposed to account termination when the bank's own monitoring flags the aggregate flows. We have seen this pattern repeatedly: a well-designed on-chain program does not protect the banking relationship unless the VASP can communicate, in terms the bank understands, why flagged flows were reviewed and cleared.
If a prior application stalled or a banking relationship closed unexpectedly, a structural review can identify the monitoring gap and the route forward. Write to OBOLUS at Map your options.
What Are the Most Common Mistakes in Transaction Monitoring Setup?
The mistakes that recur across supervisory examinations and enforcement actions fall into a predictable set, and most of them are structural rather than operational – meaning they cannot be fixed by hiring more compliance staff; they require rebuilding the program architecture.
The first and most common mistake is treating monitoring as a technology procurement rather than a legal and operational design exercise. The platform matters less than the logic behind it. A firm that spends significant budget on a best-in-class analytics tool, then uses it with default settings and no written calibration rationale, will fail a regulatory examination that a firm with a more modest tool and a rigorous calibration record will pass.
The second mistake is the absent or inadequate risk assessment. Transaction monitoring rules must be traceable back to a documented risk assessment. When a regulator asks why a particular threshold was set, "the vendor recommended it" is not a defensible answer. The risk assessment is the foundation; without it, every subsequent calibration decision is unsupported.
The third mistake is siloing the monitoring function from the rest of compliance. The monitoring system does not operate in isolation: it interacts with the KYC framework at onboarding, with the Travel Rule program on transfers, and with the sanctions screening layer on every transaction. Firms that maintain these as separate programs with no cross-feed between alert systems create gaps that regulators find quickly.
A common assumption in the market is that a monitoring program approved by one regulator will satisfy all others. This is incorrect. The FATF standard under Recommendation 15 sets a floor, not a ceiling. Each domestic regime layered above it adds requirements, and the specific expectations of VARA, the FCA, and MAS are materially different in scope, documentation depth, and examination frequency. A program designed for one hub must be reviewed before it is extended to another.
The fourth mistake is governance atrophy: the program was adequate at launch and was never tuned. Monitoring systems that are not periodically calibrated degrade in effectiveness as transaction patterns change. Regulators in the leading hubs now ask specifically when the monitoring system was last tuned and what data was used to drive the tuning decision. The absence of a calibration log is itself a finding.
Which Transaction Monitoring Setup Is Right for Your Business Profile?
The right monitoring architecture depends on the business model, the jurisdictional footprint, and the stage of regulatory engagement. The following profiles illustrate the decision logic; they are not exhaustive, and every situation requires individual analysis.
Profile A: Early-stage VASP seeking its first licence in a single EU jurisdiction under MiCA. The primary instrument is a calibrated monitoring program built against a documented risk assessment, integrated with the KYC framework and the Travel Rule program from the outset. The timeline from initial scoping to a regulatorily presentable program is typically a matter of weeks, not months, if the risk assessment is completed in parallel with the system selection. The key risk at this stage is underestimating the documentation depth the national competent authority will expect at the authorisation stage.
Profile B: Established VASP holding a licence in one hub, expanding to a second jurisdiction (e.g. adding a VARA licence to an existing MiCA-authorised operation). The primary task is a gap analysis: the existing monitoring program must be reviewed against VARA's requirements, and any gaps must be closed and documented before the VARA application is submitted. VARA's examination of the monitoring program during the authorisation process is detailed; a program that satisfied the prior regulator may require material re-calibration. The key risk is assuming that the existing program transfers without modification.
Profile C: Digital-asset business operating across both on-chain and fiat payment rails, holding or seeking a payment institution licence alongside a VASP registration. The monitoring architecture must cover both rails, with alert feeds that communicate between the on-chain monitoring tool and the payment-processing system. The cross-jurisdictional Travel Rule interaction is typically the most complex element. This profile benefits most from a legal review of the monitoring architecture before system build, because retrofitting cross-rail alert communication after build is expensive and operationally disruptive.
Profile D: VASP facing a regulatory examination or a banking relationship under pressure. This is a remediation engagement rather than a build engagement. The immediate priority is a rapid audit of the existing monitoring program against the relevant regulatory standard, identification of the material gaps, and production of a remediation roadmap that can be presented to the regulator or the bank. In our cross-border practice, we have consistently found that a well-structured remediation roadmap – presented proactively rather than in response to a formal finding – materially changes the supervisory dynamic.
Related at OBOLUS
- AML & Compliance for Digital Asset Businesses – the full practice overview covering AML, Travel Rule and KYC program design across hubs
- Travel Rule Compliance Program for Early-Stage Founders – practical guidance on Travel Rule implementation for VASPs at the licensing stage
- Payment Institution Licensing for Regulated Entities – structuring the payment layer alongside your digital-asset licensing stack
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – the obligation under FATF Recommendation 16 to transmit originator and beneficiary information alongside a virtual-asset transfer – requires a VASP to collect, verify, and pass defined identifying data to the receiving VASP for transfers above the applicable threshold. The precise threshold varies by jurisdiction and implementing regime. Compliance requires both a technical messaging capability and a policy for handling transfers where the counterparty VASP cannot or does not provide the required data. Both elements must be documented and tested.
Who must act as MLRO for a crypto firm?
Under most major licensing regimes – including MiCA as applied by EU national competent authorities, VARA in Dubai, and the FCA in the UK – a VASP must appoint a named Money Laundering Reporting Officer (MLRO) who holds senior management responsibility for the AML program. The MLRO must be of sufficient seniority to escalate concerns to the board and must have direct access to all transaction monitoring data and suspicious activity report decisions. Regulators increasingly scrutinise the MLRO's qualifications, independence, and capacity to perform the role alongside other responsibilities.
How do regulators audit crypto AML programs?
Regulators across the leading hubs – including the FCA, VARA, and MAS – examine AML programs through a combination of document review, system walk-throughs, and transaction testing. In a typical examination, the regulator will request the risk assessment, the monitoring system calibration log, a sample of alerts and their disposition records, suspicious activity report statistics, and evidence of MLRO governance. Examination teams increasingly ask to see the alert logic directly in the monitoring system, not merely in policy documents. Programs that exist only on paper do not survive this format of review.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the AML, Travel Rule and monitoring programs that regulators examine at authorisation and throughout the supervised lifecycle. Digital assets are the entirety of our practice. We map the licence, monitoring and payment stack across operating, custody and payment layers before you commit – so that the program you build is one that survives the examination it was designed for. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialist in AML program architecture and transaction monitoring design for VASPs across EU, UAE and Asia-Pacific licensing regimes.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.