An established virtual asset service provider operating across multiple jurisdictions faces a different compliance reality than a startup seeking its first registration. The transaction monitoring obligation – the continuous, automated screening of on-chain and off-chain activity for suspicious patterns – is not a box checked at authorization. It is a live operational system that regulators in every leading hub now examine in granular detail. Operating without a properly configured program exposes the business to enforcement action, terminated banking relationships and, in the most serious cases, licence revocation. The regime is tightening, and regulators across the EU under MiCA, the UAE under VARA, Singapore under the Payment Services Act administered by MAS, and the UK under the FCA are aligning on what a defensible program looks like.
This page sets out the legal basis for transaction monitoring obligations, the practical architecture of a compliant program, the cross-border complications that arise when your entity, users and banking sit in different jurisdictions, and the specific steps OBOLUS takes when designing or remediating a monitoring program for an operator already in market.
What is the regulated basis for transaction monitoring?
Transaction monitoring is mandatory for any entity caught by VASP (virtual asset service provider) definitions under the FATF Recommendations, which have been implemented – with varying specificity – across every jurisdiction that matters for institutional digital-asset business. Under the FATF framework, a VASP must identify, assess and manage the risks arising from its customer base and transaction flows on an ongoing basis. That obligation is not satisfied by onboarding checks alone. It requires a documented, calibrated system that flags anomalies in real time or near-real time.
The regimes that matter most for established operators each approach the requirement from the same baseline but with distinct emphases. Under MiCA and the national AML frameworks of EU member states, a CASP (crypto-asset service provider) carries full AML/CFT obligations aligned with the EU's AML directives, with the national competent authority and ESMA providing supervisory oversight. VARA in Dubai requires activity-specific compliance programs for each licensed service line, with explicit expectations around transaction monitoring calibration documented in its rulebooks. MAS in Singapore applies risk-based monitoring requirements to Digital Payment Token service licensees under the Payment Services Act. The FCA in the UK applies its own Money Laundering Regulations to registered cryptoasset businesses, with transaction monitoring forming a core component of an adequate AML program.
In each case, the regulatory expectation is the same in substance: the system must be calibrated to the operator's actual risk profile, must generate meaningful alerts, must have a documented escalation path, and must be subject to regular review. A system installed three years ago and never adjusted is, in the eyes of a reviewing regulator, a system that does not meet the standard.
Transaction monitoring under MiCA's CASP framework and equivalent regimes is not a technology question alone – it is a legal design question. The rules, thresholds and escalation logic embedded in the system must be defensible under the applicable regulatory regime, which means the legal team must be involved before the tool is configured, not after.
For a scoped assessment of your transaction monitoring architecture, contact OBOLUS. The process above describes the standard obligation. Your entity structure, user geography and banking relationships change the analysis materially. Map your options.
What does a compliant transaction monitoring program actually contain?
A defensible transaction monitoring program for an established operator has six identifiable components, each with a legal dimension that cannot be delegated entirely to technology vendors.
The first is a documented risk assessment. Before any rule is written or threshold set, the operator must assess the risk profile of its customer segments, geographic exposure, product lines and transaction types. This assessment drives everything downstream. A custody-only operator has a different risk profile from an exchange offering leveraged derivatives to retail-adjacent clients. A program calibrated for one is inadequate for the other. The risk assessment must be updated whenever the business model, user base or regulatory environment changes materially – which, for most established operators, means at minimum annually.
The second component is rule and typology configuration. The monitoring system must be populated with alert rules that reflect both the regulator's published typologies and the operator's own risk assessment. In our practice, we see operators relying on default vendor configurations without adjusting them for their specific business – a pattern that generates high false-positive volumes, desensitizes compliance staff and creates gaps around the transaction types most relevant to the operator's actual risk. VARA's rulebooks, MiCA's CASP guidance and the FATF virtual asset red-flag indicators all provide a starting library; the operator must translate those into specific rule logic.
Third is the alert management workflow. An alert generated and not reviewed is worse than no alert at all – it creates documentary evidence of a failure to act. The program must define who reviews alerts, at what time horizon, what the escalation path is when an alert cannot be resolved at the first level, and how decisions are recorded. The MLRO (money laundering reporting officer) sits at the apex of this chain, with responsibility for Suspicious Activity Reports where the alert resolves to a reportable suspicion.
Fourth, Travel Rule integration. The Travel Rule (the FATF obligation requiring VASPs to pass originator and beneficiary identifying information alongside a virtual asset transfer) interacts directly with transaction monitoring. When a transfer arrives without compliant originator data, that gap is itself a risk signal that must be captured in the monitoring program. Under MiCA's CASP regime and equivalents in Singapore and the UAE, the Travel Rule obligation and the transaction monitoring obligation must be treated as a single risk management system, not two parallel processes.
Fifth, blockchain analytics integration. On-chain monitoring tools – drawing on the capabilities of forensic analytics platforms – must be configured to screen wallet addresses against sanctions lists, identify counterparty risk and trace transaction origin. The legal question is not which platform to use; it is what the operator is legally required to do with the output and how that output feeds the alert workflow.
Sixth, governance and audit readiness. The program must be documented to a standard that withstands a regulatory examination. That means a written AML policy, a board-approved risk appetite statement, documented rule rationale, alert review records, and a record of periodic program reviews. Regulators in all leading hubs have moved from reviewing policies on paper to examining operational records of how the program functioned over time.
How does cross-border operation complicate transaction monitoring?
Cross-border complexity is where established operators most frequently encounter gaps between their documented program and their operational reality. An operator licensed in one jurisdiction but serving users in others faces a layered obligation: it must meet the standard of the licensing jurisdiction and, in many cases, must also satisfy the AML expectations of the jurisdiction where its users reside, where its banking counterparts sit, and where its correspondent rails clear.
Consider a CASP authorized under MiCA in an EU member state but with a significant user base in the GCC. The MiCA-aligned monitoring program may meet the EU standard. But if the operator's banking rails run through a correspondent bank with its own AML compliance expectations, and if those users generate transaction patterns that trigger the correspondent's own monitoring system, the operator faces scrutiny from an institution applying a different risk standard. Banking termination by a correspondent that flags the operator's transaction profile is one of the most common and operationally damaging outcomes we see in practice.
The interaction between the Travel Rule and cross-border transaction flows creates a further layer. Where a transfer passes between a VASP in a MiCA jurisdiction and a counterparty VASP operating under a different regime – VARA in Dubai, MAS in Singapore, or a lighter-touch offshore framework – the originating VASP may be sending compliant Travel Rule data to a counterpart that is not equipped to receive and process it. That gap creates a risk management failure on both sides. In our practice, we advise operators to conduct a counterparty VASP assessment program that runs in parallel with the transaction monitoring program, identifying the Travel Rule capability of each material counterpart.
Sanctions exposure is another cross-border variable. The OFAC sanctions list, the EU consolidated sanctions list and the UK sanctions regime each apply to different sets of designated entities and jurisdictions, and the overlap is imperfect. An operator with users in multiple geographies must configure its screening to capture all applicable sanctions regimes, not only the one that corresponds to its licensing jurisdiction. In the Seychelles, for instance, the sanctions-screening obligation has its own local contours that differ from a pure FATF-standard implementation – a point we examine in detail in our guidance on sanctions screening for crypto in Seychelles.
What are the most common transaction monitoring failures regulators find?
Regulators examining established operators' AML programs consistently identify a set of recurring failures. These are not exotic edge cases – they are the gaps that appear in examinations across VARA, MiCA-supervised entities, MAS-licensed firms and FCA-registered businesses.
The first is static rule sets. A firm that configured its monitoring system at the time of registration and has not materially updated it since is running a program that no longer reflects its risk profile. Business growth, new product lines, new customer segments and new transaction patterns all create new risks that the original rule set did not contemplate. Regulators increasingly require evidence that rule sets are reviewed and updated on a documented schedule.
The second is threshold miscalibration. Thresholds set too high miss real risk. Thresholds set too low generate alert volumes that the compliance team cannot manage, leading to systematic alert suppression – which is itself a regulatory finding. Calibration requires analysis of actual transaction data, not a theoretical exercise.
The third is Travel Rule data gaps as unmonitored risk events. Many operators process incoming transfers with missing or incomplete originator information and treat the gap as a data quality issue rather than a risk event. Under the applicable FATF-aligned regimes, a transfer received without compliant originator data is a risk signal that must be assessed and, where appropriate, reported. Programs that do not capture this category systematically fail a material part of the monitoring obligation.
The fourth is inadequate documentation of alert disposals. An alert reviewed and closed with a one-line note – "customer identified; no action" – is not adequately documented. Regulators want to see the reasoning: what was the transaction, what was the risk indicator, what information was reviewed, and why was no suspicious activity report filed. The documentation standard has increased materially in every major hub over the last several years.
The fifth is failure to integrate on-chain and off-chain monitoring. Operators who run blockchain analytics for wallet screening but do not route the output into the alert management workflow are operating two separate systems that do not talk to each other. A wallet flagged in the blockchain analytics platform but not routed through the standard alert workflow may never reach the MLRO.
In a matter handled in recent months, a digital-asset exchange operating in a leading EU jurisdiction came to us after its national competent authority issued a remediation notice following an examination. The regulator had identified that the firm's monitoring rules had not been updated since its initial authorization under the prior national VASP regime and did not reflect the heightened standards of its new CASP authorization under MiCA's transitional provisions. We conducted a full program gap analysis, revised the rule architecture, redesigned the alert escalation workflow and prepared the regulatory response. The remediation submission was accepted within the examination period, and the firm's CASP authorization was preserved.
Which operators need the most urgent remediation?
Not every established operator faces the same level of monitoring risk. The urgency of remediation depends on the intersection of regulatory exposure, transaction volume and program maturity.
Profile A is the high-volume exchange or custodian that has grown rapidly since its initial authorization. The monitoring program was designed for a smaller, simpler business. Transaction volumes have increased significantly, new customer segments have been onboarded and new product lines have launched – none of which were reflected in a program refresh. This profile carries the highest regulatory risk. A remediation program should begin with a gap analysis against current regulatory expectations in the licensing jurisdiction, followed by rule set redesign and threshold recalibration. Timeline: a matter of weeks for the gap analysis; several additional months for full implementation and testing, depending on complexity.
Profile B is the operator that has recently re-licensed from a lighter-touch offshore regime to a MiCA-authorized EU entity, a VARA-licensed Dubai entity or an MAS-licensed Singapore entity. The legacy monitoring program was designed to meet a lower standard. The new regime expects a materially more sophisticated program. This profile needs a complete program rebuild, not a patch. The cross-border angle is acute: the operator may also be managing a transition period during which legacy structures remain in place alongside the new authorization.
Profile C is the established operator in a stable jurisdiction whose program is broadly current but which has not been tested against a regulatory examination scenario. This profile benefits from a structured examination readiness review: a simulation of how the program would perform under regulatory scrutiny, identification of documentation gaps and a triage of any rule logic that would not survive close examination. Timeline is shorter; the work is targeted rather than wholesale.
If your structure falls into Profile A or Profile B, the time to act is before the next examination cycle, not after a finding. Write to us at info@oboluslaw.com or reach our compliance desk via t.me/oboluslaw. If a prior program review stalled or a banking relationship was terminated, a second read can surface the structural reason and the route forward. Map your options.
How does OBOLUS structure a transaction monitoring engagement?
OBOLUS approaches a transaction monitoring mandate as a legal design project, not a technology procurement exercise. The distinction matters: the legal framework must be established before the tool can be properly configured, and the legal framework must be revisited whenever the regulatory environment or the business changes.
We structure a monitoring setup or remediation engagement in four phases.
The first phase is a regulatory mapping exercise. We identify every jurisdiction in which the operator has regulatory exposure – the licensing jurisdiction, the jurisdictions of material user concentration, and the jurisdictions through which banking and settlement flows. We map the monitoring obligations that apply in each, noting where they diverge and where a single program design can satisfy multiple standards.
The second phase is the risk assessment review or build. We either review the existing documented risk assessment against current regulatory expectations or, where none exists, build one from the operator's business data. This document is the legal foundation of the entire program: everything downstream must trace back to it.
The third phase is rule architecture and workflow design. Drawing on the risk assessment, the applicable regulatory typologies and the operator's actual transaction data, we specify the rule logic, thresholds and alert categories that the monitoring system must implement. We also design the alert management workflow: who reviews, at what time horizon, how escalation reaches the MLRO, and how decisions are recorded. This phase produces specifications that the operator's technology team or vendor can implement directly.
The fourth phase is governance documentation and examination readiness. We draft or revise the AML policy, the monitoring program governance document, the MLRO mandate and the board risk appetite statement. We then run an examination readiness review: a structured assessment of how the program and its documentation would perform under regulatory scrutiny.
Throughout all phases, we integrate the Travel Rule. A monitoring program that does not account for Travel Rule data gaps as risk signals is incomplete under every leading regulatory standard. Our compliance, AML and Travel Rule practice covers the full spectrum of these obligations – see our AML and Travel Rule practice overview for the broader picture.
Self-assessment: Is your monitoring program examination-ready?
The following questions reflect the standard a competent regulatory examination team will apply. An honest "no" or "unsure" to any of them signals a gap worth addressing before the examination arrives.
- Is your risk assessment documented, dated and has it been reviewed within the past twelve months?
- Does the risk assessment reflect every material change to your business since it was last updated – new products, new customer segments, new geographies?
- Are your monitoring rules documented with written rationale for each threshold?
- Can you demonstrate that alert volumes are manageable and that no alert is systematically suppressed or auto-closed without human review?
- Is Travel Rule data completeness captured as a monitored risk category, with a defined response to incoming transfers with missing originator information?
- Does your on-chain analytics output route directly into your alert management workflow, or does it sit in a separate system?
- Are alert disposal decisions documented to a standard that would satisfy a reviewing regulator – not just a closure notation, but a reasoned record?
- Has your MLRO filed at least one Suspicious Activity Report in the past review period, or has the absence of filings been affirmatively documented as a risk-based decision?
- Does your program account for the AML expectations of every jurisdiction in which you have material regulatory exposure, not just your licensing jurisdiction?
- Has your program been independently reviewed within the past twelve to twenty-four months?
For institutional operators, our institutional-client-focused monitoring guidance provides additional depth on the specific challenges that arise for institutional-grade transaction flows – see our analysis of transaction monitoring setup for institutional clients.
A common assumption worth addressing directly
A common assumption among operators who have been in the market for several years is that their existing monitoring program – which passed the regulator's initial authorization review – is sufficient for ongoing supervision. This assumption is incorrect, and it is among the most consequential mistakes we see in established businesses.
Initial authorization reviews examine whether a program exists and whether its design is plausible. Ongoing supervision examines whether the program actually functions as documented, whether it has kept pace with the business and whether its outputs – alert volumes, SAR filings, rule revision history – are consistent with a business of the operator's profile. These are materially different standards. A program that cleared authorization three years ago may not survive an examination today.
The second assumption worth addressing is the belief that transaction monitoring is primarily a technology decision. The technology implements the legal design. If the legal design is wrong – if the risk assessment is stale, if the rules do not reflect current typologies, if the Travel Rule interface is not treated as a monitoring input – the technology cannot compensate. We structure licensing, banking and compliance as one mandate rather than three disconnected workstreams, because the failure modes in each area compound each other.
Related at OBOLUS
- AML and Travel Rule practice for digital-asset businesses – the full scope of our compliance advisory across 70+ jurisdictions
- Sanctions screening for crypto in Seychelles – jurisdiction-specific sanctions obligations and their interaction with AML monitoring
- Transaction monitoring setup for institutional clients – monitoring architecture for institutional-grade transaction flows and counterparty risk
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – derived from FATF Recommendation 16 as applied to virtual assets – requires a VASP to collect and transmit identifying information about the originator and beneficiary of a virtual asset transfer to the receiving VASP. The specific data fields, the threshold at which the obligation triggers and the technical means of transmission vary by jurisdiction. Under MiCA's CASP regime, MAS in Singapore and VARA in Dubai, the obligation applies to all transfers above the applicable threshold; transfers below it carry reduced requirements. Non-compliance with Travel Rule obligations is treated as a material AML deficiency by all leading regulators, and gaps in incoming Travel Rule data must be captured as risk signals in the monitoring program.
Who must act as MLRO for a crypto firm?
Most regulated VASP regimes require the appointment of a named MLRO (money laundering reporting officer) who is responsible for overseeing the AML program, reviewing escalated alerts, making suspicious activity report decisions and interfacing with the regulator on AML matters. The MLRO must typically be a natural person, meet the regulator's fit-and-proper standard, and in many jurisdictions must be resident in – or closely accessible to – the licensing jurisdiction. The MLRO carries personal regulatory accountability. Regulators across the EU under MiCA-aligned regimes, under VARA and under MAS requirements have each made MLRO accountability a focus of supervisory attention. The role cannot be filled by a compliance policy document or a vendor.
How do regulators audit crypto AML programs?
Regulators in the leading hubs – including national competent authorities under MiCA, VARA in Dubai and MAS in Singapore – examine AML programs through a combination of documentary review and operational testing. They will request the written AML policy, the risk assessment, the monitoring system's rule set with documented rationale, alert review records covering a specified period, records of suspicious activity report decisions (including decisions not to file), and evidence of program governance including board sign-off on risk appetite. Increasingly, regulators also request raw alert data to assess whether alert volumes and disposal patterns are consistent with the operator's risk profile. An examination that finds a gap between the documented program and the operational record is a materially more serious finding than a documentation deficiency alone.
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 compliance, AML and Travel Rule obligations that sit around them. We map the licence stack across operating, custody and payment layers before you commit – and we structure licensing, banking and compliance as one mandate rather than three disconnected workstreams. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design, transaction monitoring architecture and cross-border regulatory compliance for established digital-asset operators.
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.