What transaction monitoring means in digital-asset compliance
Transaction monitoring – the systematic review of payment flows to detect suspicious activity – sits at the operational core of every regulated digital-asset business. Under the FATF Recommendations, including Recommendation 15 on virtual assets, any VASP (virtual asset service provider) must maintain a risk-based transaction monitoring program as a non-negotiable condition of continued operation. The practical design of that program, however, differs significantly across the regimes that govern digital-asset businesses in the major licensing hubs. A monitoring setup calibrated for one jurisdiction may leave material gaps in another.
With VASP supervision tightening across every major hub – from ESMA's implementation of MiCA (the EU's Markets in Crypto-Assets Regulation) to VARA's rulebooks in Dubai and the MAS Payment Services Act regime in Singapore – the question is no longer whether to build a transaction monitoring program but how to build one that satisfies each regime a business touches. This analysis contrasts the monitoring expectations across the leading jurisdictions, identifies where requirements diverge, and maps the practical decisions an operator must make before – not after – an audit letter arrives.
The sections below move from the regulatory baseline to jurisdiction-specific expectations, then to cross-border complexity, practical build decisions, the common failure points we see in practice, and finally a decision matrix by operator profile. A single anonymized matter illustrates how a monitoring gap surfaces in a real enforcement context.
The FATF baseline: what every regime inherits
Every major regime begins with the same international standard. FATF Recommendation 15 requires jurisdictions to apply AML/CFT obligations to VASPs equivalent to those applied to financial institutions. The baseline elements are consistent: customer risk scoring, transaction-level monitoring, threshold-triggered alerts, suspicious activity reporting, and record retention. No jurisdiction that participates in FATF mutual evaluations may lawfully exempt a VASP from these obligations.
The Travel Rule – the obligation to pass originator and beneficiary identifying data with a virtual asset transfer – is a direct extension of that baseline. FATF guidance specifies that the obligation applies above a defined monetary threshold, though the precise threshold is set by each jurisdiction and varies. In our cross-border practice, the most common monitoring gap we identify is not the absence of a Travel Rule mechanism but the failure to align the threshold and the data fields with the specific rules of every jurisdiction into which a firm is licensed or from which it receives transfers.
The FATF framework is the ceiling for international expectations but not the floor for domestic ones. Several regimes impose obligations that go further – more granular risk-rating methodologies, shorter suspicious-transaction report deadlines, or technology-specific requirements that FATF guidance does not yet address. Operators who assume parity across jurisdictions are routinely surprised at examination.
For a scoped review of your AML program against the specific regimes you are operating under, contact OBOLUS at info@oboluslaw.com. The process above describes the standard international baseline. Your facts – the entity structure, the user base, the asset types – change the analysis materially. Map your options
How MiCA and ESMA frame transaction monitoring in the EU
Under MiCA, a CASP (crypto-asset service provider) authorised in an EU member state must operate a transaction monitoring program that satisfies both the MiCA authorisation conditions and the national AML legislation implementing the EU's Anti-Money Laundering directives. ESMA and the European Banking Authority have jointly published guidance that shapes supervisory expectations for CASPs across the bloc, though national competent authorities retain day-to-day supervisory authority.
The practical implication is layered. A CASP passporting services from Lithuania across the EU does not operate under a single monitoring standard. The home-state regulator – in that case, the Bank of Lithuania – supervises the core authorisation, but host-state AML rules apply to activity conducted in each member state. This creates a matrix of monitoring obligations that a single-jurisdiction compliance setup cannot satisfy. Firms that rely on a Lithuanian or Maltese authorisation to serve EU-wide clients without mapping host-state AML requirements are operating with a structural gap.
Under the MiCA CASP regime, whitepaper and governance obligations are harmonised at EU level, but AML monitoring expectations retain national variance until the EU's forthcoming unified AML authority (AMLA) assumes direct supervisory competence over the largest cross-border operators. Until that transition completes, the monitoring program must be designed to satisfy the most demanding national standard within the CASP's operating footprint.
What does VARA require from a transaction monitoring program in Dubai?
VARA – the Virtual Assets Regulatory Authority – publishes activity-specific rulebooks that set out explicit compliance expectations for each licensed activity, including custody, exchange and transfer services. The VARA regime requires a risk-based transaction monitoring program that addresses the specific characteristics of virtual asset flows: pseudonymity, finality, cross-chain bridging and the use of privacy-enhancing protocols.
In our practice, VARA's expectations are among the most operationally detailed in the region. The authority expects a documented monitoring methodology, alert review workflows with defined escalation paths, and a Travel Rule implementation plan that addresses both the technical standard and the handling of transfers where the counterpart VASP is unhosted or operating in a non-FATF-compliant jurisdiction. Firms entering the Dubai market from a jurisdiction with lighter-touch monitoring requirements frequently underestimate the build cost.
A material distinction between VARA and the EU MiCA regime is jurisdictional scope. VARA governs mainland Dubai and does not extend to the DIFC financial free zone, which operates under its own regulatory perimeter. A business with entities in both zones must maintain monitoring programs that satisfy both VARA and the DIFC's framework. We regularly advise on entity structuring decisions where this dual-zone exposure determines how monitoring infrastructure is allocated across the corporate group.
Singapore, Hong Kong, and the APAC divergence in monitoring expectations
The two leading APAC digital-asset hubs share a common-law heritage and FATF membership but have taken materially different regulatory approaches to transaction monitoring for VASPs. The divergence matters for any business building a regional structure that spans both.
Under the MAS Payment Services Act, holders of a Digital Payment Token (DPT) service licence are subject to AML/CFT notices that specify monitoring program requirements in considerable detail. MAS has been explicit in supervisory communications that it expects technology-supported transaction monitoring – not manual review alone – for any operator above a defined scale. The authority's enforcement posture is well-documented: several DPT licensees have received direction on monitoring deficiencies without that direction becoming public enforcement action, which means the actual supervisory standard is stricter than published guidance alone suggests.
In Hong Kong, the SFC's VASP licensing regime imposes transaction monitoring requirements through the anti-money laundering ordinance and the SFC's conduct expectations. The Hong Kong regime places particular emphasis on the monitoring of transfers involving unhosted wallets and on the detection of layering through decentralised exchange protocols. Operators we advise who hold or are seeking both MAS and SFC authorisation must maintain monitoring rule sets calibrated to each authority's specific risk typologies, which differ in the treatment of DeFi interaction and NFT transactions.
The practical cost of running separate, jurisdiction-specific monitoring configurations within a single technology platform is significant. We have seen firms attempt to run a single global rule set with jurisdiction-tagged thresholds. This approach works at the alert-generation layer but creates problems at the review and reporting layer, where regulatory expectations about suspicious transaction report content, timing and format diverge sharply between MAS and SFC.
The UK FCA and Swiss FINMA: contrasting philosophies
The UK FCA and Swiss FINMA represent contrasting regulatory philosophies on transaction monitoring, both of which have influenced global standards.
Under the FCA's cryptoasset registration regime, firms registered under the Money Laundering Regulations must demonstrate a transaction monitoring program that meets the MLR standard applied to all regulated firms – a standard shaped by years of financial-services enforcement. The FCA has published specific guidance on cryptoasset AML expectations and has withdrawn or refused registration where monitoring was found to be inadequate. A notable feature of the UK approach is the FCA's expectation that monitoring systems be subject to regular independent testing, with test results documented and available for examination.
FINMA in Switzerland operates through a principles-based framework. The regulator's token taxonomy – distinguishing payment, utility and asset tokens – shapes the AML obligations that attach to a given service. Firms affiliated with a FINMA-recognised self-regulatory organisation (SRO) must comply with the SRO's AML rules, which incorporate FATF standards. In our experience, FINMA's monitoring expectations are less prescriptive at the technology level than VARA's or MAS's, but the principles-based approach demands documented risk assessments that justify the chosen monitoring methodology. The documentation burden is equivalent; only its form differs.
What does a cross-jurisdiction transaction monitoring gap look like in practice?
A monitoring gap in a multi-jurisdiction structure typically surfaces not from a single deficiency but from the interaction of individually defensible choices that are collectively inadequate for one or more of the regimes a firm operates under.
In a recent matter, a digital-asset exchange licensed in two jurisdictions – one EU and one APAC – was operating a unified monitoring platform configured to the EU standard. The APAC regulator's examination identified that the platform's rule set did not capture a category of cross-chain transfers that the APAC regime had specifically flagged in a supervisory circular issued after the firm's initial licensing. The firm's compliance team was unaware of the circular; no process existed to track post-licensing regulatory communications from the APAC authority. We were instructed to conduct a gap analysis, map the remediation steps required for each regime, and assist with the regulatory response. The matter resolved without formal sanction, but the remediation exercise – rebuilding alert rules, retraining review staff, producing back-tested alert data – consumed a significant portion of the compliance budget for that quarter.
The lesson is structural. A transaction monitoring program must be treated as a living document with a formal update cycle tied to regulatory communications from every jurisdiction in which the business is licensed or materially active. The moment of examination is the wrong time to discover that a jurisdiction's expectations evolved after the initial build.
If a prior application stalled, a regulatory examination is pending, or your monitoring program has not been stress-tested against every jurisdiction you operate in, write to info@oboluslaw.com. A second read can surface the structural reason for the gap and the route to remediation. Map your options
Building the monitoring stack: technology, governance, and the Travel Rule
A compliant transaction monitoring setup has three interdependent layers: the technology layer, the governance layer, and the Travel Rule layer. Weakness in any one undermines the other two at examination.
At the technology layer, regulators across the major hubs expect automated monitoring tools capable of real-time or near-real-time alert generation on transaction flows that match defined risk typologies. The specific typologies differ by jurisdiction – VARA's rulebooks, the MAS AML notices and the FCA's guidance each define risk categories that do not map perfectly onto one another. A single-vendor platform can address this through jurisdiction-specific rule profiles, but the rule profiles must be maintained and updated as each regulator's expectations evolve. Firms using off-the-shelf tools without customisation are running a risk that typically becomes visible only at examination.
At the governance layer, every major regime requires a designated compliance function. The MLRO (Money Laundering Reporting Officer) role is a formal position in virtually every jurisdiction – not merely an internal designation but a regulatory appointment that may require pre-approval. The MLRO is personally responsible for the adequacy of the monitoring program and for suspicious transaction reporting decisions. In multi-jurisdiction structures, firms frequently operate with a single MLRO covering all entities. This structure requires careful analysis: some regulators require the MLRO to be locally based or locally approved, creating a need for jurisdiction-specific appointees even where group oversight is centralised.
The Travel Rule layer requires a mechanism to transmit originator and beneficiary data with every qualifying virtual asset transfer. The practical challenge is counterpart readiness. A VASP that has implemented a FATF-aligned Travel Rule solution faces a different problem from a VASP whose counterparts have not: how to handle transfers where the receiving VASP cannot receive or process structured data. Regulators in mature jurisdictions expect a documented policy for these "sunrise problem" transfers rather than a blanket suspension of outbound transfers. The policy must be jurisdiction-specific where threshold and data-field requirements diverge.
Decision matrix: which monitoring build fits which operator profile?
The right monitoring architecture depends on the operator's licensing footprint, asset scope and transaction volume. The following profiles illustrate the principal decision branches.
Single-jurisdiction CASP (EU, MiCA-authorised, no cross-border passporting). This profile requires a monitoring program calibrated to the home-state NCA's expectations and the EU AML directives. The Travel Rule obligation applies to all transfers above the applicable threshold. Governance can be centralised. Technology investment can be focused on a single rule set, with a lighter update cycle. The principal risk is underestimating the host-state AML variance as the passport is exercised over time.
Dual-hub operator (EU + UAE or EU + APAC). This profile requires separate rule sets for each jurisdiction, a Travel Rule implementation covering both regimes' thresholds and data fields, and either a local MLRO in each hub or a documented analysis of whether a shared MLRO satisfies local requirements. Timeline for a full dual-hub monitoring build is typically measured in months, not weeks, when testing cycles are included. The principal risk is divergence between the two rule sets over time as each regulator issues new guidance.
Global exchange (multiple jurisdictions, including VARA, MAS, SFC, FCA, and EU). This profile requires a purpose-built compliance infrastructure with jurisdiction-specific monitoring profiles maintained on a single platform, a Travel Rule solution capable of satisfying the most demanding jurisdiction's requirements, and a regulatory intelligence function tracking supervisory developments in each hub. Governance structures at this scale typically involve local compliance officers in each major jurisdiction reporting into a group MLRO function. The investment is substantial, but it is the minimum viable posture for a business seeking to maintain its licensing in all major hubs simultaneously.
Offshore entity serving cross-border retail (BVI, Cayman, or equivalent). This profile carries the highest regulatory risk. A common assumption – addressed in the next section – is that an offshore registration alone manages AML exposure. In practice, every jurisdiction where users are located may impose AML obligations on the firm irrespective of where it is incorporated. Monitoring requirements extend to user location, not only entity location.
A common assumption: that an offshore licence is enough
A common assumption in the market is that registering a VASP in a lighter-touch offshore jurisdiction – the BVI, the Cayman Islands, or a jurisdiction with minimal AML enforcement history – is sufficient to manage global compliance exposure. This assumption is incorrect in almost every scenario involving material user bases in regulated jurisdictions.
The AML obligations of the EU, the UK, Singapore and Hong Kong are not satisfied by an operator's offshore status. Where a firm is marketing to EU residents, the EU AML directives may treat it as subject to local obligations regardless of where the entity is registered. Where a firm is receiving deposits from UK persons, the FCA's financial-crime rules may apply through the financial-promotion and money-laundering regime. MAS has been explicit that operating a DPT service from an offshore entity into Singapore without a Payment Services Act licence exposes the operator to enforcement action.
The compliance-by-location principle – that AML obligations follow the user, not only the entity – is a direct consequence of FATF's expectations and national implementing legislation. A monitoring program built only to satisfy an offshore registration standard will, by definition, not satisfy the obligations that arise from serving users in major regulated markets. We map the full obligation matrix before clients commit to a structure, precisely because the cost of retrofitting a monitoring program after enforcement contact is multiples of the cost of building it correctly at the outset.
Self-assessment: before the audit
Operators who want to pressure-test their monitoring program before a regulatory examination should work through the following questions. Each maps to a common gap we identify in practice.
Is the monitoring rule set formally mapped to the specific requirements of each jurisdiction in which the business is licensed or materially active – not only the jurisdiction of incorporation? Has the rule set been updated to reflect regulatory guidance issued after the initial licensing date? Is the Travel Rule implementation documented with jurisdiction-specific threshold and data-field specifications? Is the MLRO appointment formally documented and, where required, pre-approved by the relevant regulator? Does the MLRO function receive regular regulatory intelligence updates covering all operating jurisdictions? Is there a documented policy for handling unhosted wallet transfers and for counterpart VASPs that cannot receive structured Travel Rule data? Have suspicious transaction report procedures been tested against the format and timing requirements of each relevant jurisdiction?
A no to any of these questions identifies a gap that a regulator will identify at examination with considerably more consequence.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – our full practice covering AML program design, Travel Rule implementation and regulatory examination support across 70+ jurisdictions.
- AML audit defence in Abu Dhabi Global Market (ADGM) – jurisdiction-specific guidance on defending AML findings before the FSRA in Abu Dhabi's financial free zone.
- Correspondent banking access in Ireland – how digital-asset firms establish and maintain banking relationships in a leading EU jurisdiction.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect and transmit identifying information about the originator and beneficiary of a virtual asset transfer – typically name, account details and, in some jurisdictions, address or identification number – to the receiving VASP with each qualifying transfer. The obligation applies above a monetary threshold that varies by jurisdiction. Non-compliance exposes the VASP to regulatory sanction in every jurisdiction that has implemented the FATF standard, which now includes all major licensing hubs. A compliant implementation requires both a technical solution and a documented policy for transfers where the counterpart VASP cannot receive structured data.
Who must act as MLRO for a crypto firm?
The MLRO (Money Laundering Reporting Officer) is a formally designated senior individual responsible for overseeing the firm's AML program and for making suspicious transaction report decisions. Most major regulatory regimes require the MLRO to be a named individual subject to regulatory approval or notification. In multi-jurisdiction structures, some regulators require local MLRO appointments rather than accepting a group-level appointee. The MLRO carries personal responsibility for the adequacy of the monitoring program, which means the role requires both technical knowledge of transaction monitoring and familiarity with the specific reporting obligations of every jurisdiction the firm operates in.
How do regulators audit crypto AML programs?
Regulators across the major hubs – including VARA, MAS, the FCA, ESMA's national competent authorities and the SFC – typically audit AML programs through a combination of desk-based document review and on-site or remote examination. Examiners request the firm's AML policy, its risk assessment, its monitoring rule set documentation, alert review records, suspicious transaction report logs and Travel Rule implementation evidence. The examination will test whether the program was designed to the applicable standard and whether it has been maintained as regulatory expectations evolved. Deficiencies found at examination may result in direction, remediation requirements, licence conditions or, in serious cases, enforcement action.
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, compliance and Travel Rule programs that sit around them. Digital assets are the whole of our practice. We map the licence and monitoring stack across operating, custody and payment layers before you commit – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when things go wrong. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border AML program design, transaction monitoring architecture and VASP regulatory compliance across EU, MENA and APAC 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.