Transaction monitoring is the operational spine of any digital-asset compliance program. A firm that processes transfers across multiple jurisdictions faces obligations that do not stop at the border: the Travel Rule (the obligation to pass originator and beneficiary data with every qualifying transfer), local AML/CFT (anti-money laundering and countering the financing of terrorism) supervision, and the increasingly harmonized expectations set by FATF Recommendation 15 all converge on how a VASP screens, flags, and reports. Getting the setup wrong is not a technical inconvenience – it is a direct path to enforcement, debanking, and lost operating licences. This page explains how to build a defensible, multi-jurisdictional transaction monitoring architecture and where the avoidable failures typically occur.
The regulated basis for transaction monitoring
Transaction monitoring is a statutory requirement under every major digital-asset regime in force today. Under MiCA and the EU's anti-money laundering directives, a CASP (crypto-asset service provider) must maintain continuous, risk-based monitoring of its business relationships and transactions. The VARA (Virtual Assets Regulatory Authority) rulebooks in Dubai impose parallel requirements across each activity licence – exchange, custody, lending and transfer services. The MAS Payment Services Act in Singapore, the SFC's VASP licensing regime in Hong Kong, and the FCA's cryptoasset registration in the UK all share a common baseline: transaction monitoring must be documented, risk-calibrated, and subject to periodic review by a designated compliance officer.
The FATF Recommendations, and specifically Recommendation 15 on virtual assets, underpin national legislation across the major hubs. That global baseline is structural: it shapes not just what a VASP must do, but what a correspondent bank, a liquidity provider, or an institutional counterparty will expect to see before it opens an account or clears a settlement. In our practice, the monitoring gap is one of the first things a banking partner flags during onboarding due diligence – not the regulator.
The regulatory basis is therefore threefold: the home-jurisdiction licence obligation, the cross-border Travel Rule data obligation, and the informal but equally binding expectations of the financial institutions a VASP depends on for rails.
What a cross-border setup actually requires
A monitoring program designed for one jurisdiction and transplanted globally is the most common structural failure we see. Each regime applies its own risk categories, threshold triggers, and reporting obligations. The EU applies unified rules across member states under MiCA, but individual national competent authorities retain supervisory discretion during the transition period. VARA in Dubai applies activity-specific rulebooks, so the monitoring obligations for an exchange licence differ from those for a custody licence. The AIFC's AFSA in Kazakhstan takes a principles-based approach that expects documented calibration of the rule set to the firm's actual risk profile.
The practical consequence is that a single monitoring configuration – one rule set, one risk-scoring model, one alert threshold – cannot satisfy all of these obligations simultaneously. The setup must be layered:
- A base rule set aligned to the strictest applicable regime (typically the EU or UK)
- Jurisdiction-specific overlays for each hub where the firm is licensed or where it serves users
- A documented rationale explaining why each overlay departs from the baseline and on what risk basis
- A cross-border escalation protocol identifying which MLRO or local compliance officer owns each alert type
We regularly advise operators who assumed their EU CASP authorisation covered their entire user base, including users based in jurisdictions where local supervision applies independently. It does not. Where a user base is genuinely cross-border, the monitoring architecture must address each relevant jurisdiction on its own terms.
For a scoped review of your current monitoring configuration against the regimes that apply to your user base, contact OBOLUS at info@oboluslaw.com. The process above describes the standard architecture. Your entity structure, licensing profile, and counterparty mix change the analysis materially. Map your options.
How does Travel Rule integration fit into transaction monitoring?
The Travel Rule is not a separate compliance workstream – it is a data-flow obligation that sits inside the transaction monitoring architecture and must be designed as part of it, not bolted on afterward. Under the FATF framework, a VASP (virtual asset service provider) must collect and transmit originator and beneficiary information on qualifying transfers to the next institution in the chain. The threshold for that obligation, and the exact data fields required, vary by jurisdiction and remain subject to local implementation rules.
The monitoring implications are significant. A firm cannot meaningfully flag a transaction as suspicious if it does not know who the counterparty is. Travel Rule compliance and transaction monitoring are therefore mutually reinforcing: without the data the Travel Rule requires, the monitoring system is working with incomplete inputs. Conversely, a monitoring alert on a Travel Rule-covered transfer may require the originator data to be escalated to the local financial intelligence unit – the two outputs must be coordinated in real time.
In practice, the interoperability problem is acute. A VASP sending a transfer to a counterparty on a different Travel Rule messaging protocol must resolve the format mismatch before the monitoring system can log the completed data set. Most of the leading protocols – including those that align to the TRUST and TRISA frameworks – are not universally adopted. A monitoring setup that treats unresolved Travel Rule data as a clean transaction is a supervisory gap waiting to be discovered.
We have seen regulators in both the EU and the ADGM/FSRA environment specifically examine the link between Travel Rule data completeness and monitoring quality during supervisory reviews. A documented reconciliation process – logging when Travel Rule data was requested, when it was received, and how the monitoring system was updated – is increasingly expected.
How does KYC feed the monitoring rule set?
KYC (know-your-customer) data is the static foundation on which transaction monitoring operates dynamically. A monitoring system that runs on transaction volume and wallet addresses alone, without reference to the KYC risk classification of the account holder, will generate alerts that are either unactionable or operationally unsustainable. The connection between the onboarding risk assessment and the monitoring rule calibration is a design choice – and an auditable one.
The connection works in both directions. A customer classified as high-risk at onboarding should trigger a lower monitoring threshold and more frequent review. A transaction that falls outside the expected profile for a customer's stated business purpose – an exchange operator suddenly receiving transfers consistent with retail remittance – should trigger a KYC refresh, not just a monitoring alert. The AML compliance program must document both the initial calibration and the process for updating it.
Under MiCA and the VARA rulebooks, risk classification is expected to be dynamic. A static onboarding score that never changes is not a defensible program. In our practice, the disconnect between the KYC platform and the transaction monitoring platform is one of the most frequently cited findings in a compliance gap analysis. They are often procured separately, maintained by different teams, and never formally integrated at the data layer.
What are the most common transaction monitoring mistakes in cross-border operations?
The failure modes in cross-border transaction monitoring are well-documented in supervisory findings across the leading hubs, and they cluster around five recurring patterns.
First, miscalibrated thresholds. Rule sets are copied from a reference template and never adjusted to the firm's actual transaction profile. A VASP processing primarily institutional transfers runs the same alert rules as one processing high-frequency retail volume. The result is either alert fatigue (too many low-value flags) or blind spots (institutional transfers that exceed reasonable thresholds pass unchallenged).
Second, blockchain analytics tools are deployed without documented governance. The output of a Chainalysis or TRM Labs risk score feeds directly into a monitoring alert, but there is no written policy explaining how the firm interprets those scores, what action a given score requires, and who has authority to override. Regulators – particularly the FSRA and the FCA – treat undocumented reliance on third-party tools as a governance gap, not a compliance solution.
Third, the monitoring program is designed for the licensing jurisdiction but not for the jurisdictions where users are located. A firm licensed in Malta under the transitional MFSA regime may serve users across the EU and in jurisdictions where separate local obligations apply. The monitoring setup addresses the MFSA's expectations only.
Fourth, the SAR (suspicious activity report) filing process is not connected to the monitoring alert workflow. Alerts are reviewed and closed without a documented decision trail. When a supervisor asks for the file supporting a decision not to file a SAR, the answer is an informal email chain.
Fifth, the program is never tested. Annual audits of AML programs are mandated under most flagship regimes. Transaction monitoring specifically – the rule set, the alert population, the investigation outcomes – must be reviewed by a party with sufficient independence from the day-to-day compliance function. Many operators treat this as a legal box-tick rather than an operational stress test.
Which monitoring architecture fits your profile?
The right setup depends on entity structure, licence profile, and the risk characteristics of the user base. The following decision framework identifies the primary variables.
Profile A – Single-jurisdiction CASP, institutional counterparties only. A firm holding one EU CASP authorisation under MiCA and transacting exclusively with institutional counterparties that are themselves regulated entities can operate a relatively lean monitoring architecture. The risk-scoring model can apply simplified due diligence categories for counterparties subject to equivalent AML obligations. Travel Rule data flows are typically bilateral and pre-agreed. The monitoring priority is on transaction-size anomalies and counterparty-risk changes. Timeline to a defensible setup: a matter of weeks, assuming KYC data is clean and the Travel Rule protocol is agreed with counterparties in advance.
Profile B – Multi-jurisdiction operator, retail and institutional user mix. A firm licensed in Dubai under VARA, passporting activity into the EU under MiCA, and serving users in Singapore and Hong Kong faces overlapping obligations across four distinct regimes. The monitoring architecture requires a base rule set, three jurisdiction-specific overlays, a unified alert-management workflow that can route flags to the correct MLRO in each jurisdiction, and a Travel Rule integration that handles at least two major messaging protocols. KYC data must be stored in a format accessible to each overlay. Timeline to a defensible multi-regime setup: several months, assuming data infrastructure exists and local compliance officers are in place.
Profile C – DeFi-adjacent or on-chain business. A firm with on-chain exposure – a protocol-facing gateway, a non-custodial trading interface, or a staking service – faces the question of how transaction monitoring applies where the firm does not hold custody of assets. The answer turns on what activity is regulated in each jurisdiction. Under MiCA, the regulatory perimeter for on-chain activities is evolving. Under VARA and the ADGM/FSRA regime, on-chain activity that constitutes a regulated function triggers the monitoring obligation regardless of the technical architecture. The monitoring setup must be scoped against the regulated perimeter, not the technical custody model.
A micro-matter from recent practice: In a recent compliance review, a payment company operating under an EU CASP authorisation had deployed a transaction monitoring system calibrated entirely to its home-state competent authority's expectations. It served users in two additional jurisdictions with distinct local AML obligations. We identified three alert-rule gaps, an unresolved Travel Rule data protocol mismatch, and an SAR workflow that had no documented escalation path for cross-border alerts. The remediation plan was completed before a scheduled supervisory review, and no enforcement action followed.
If your monitoring setup has not been tested against the full scope of your jurisdictional obligations, a structured gap analysis is the right first step. Write to info@oboluslaw.com or reach us at t.me/oboluslaw. If a prior application stalled or a banking relationship was closed for AML reasons, a second read of your monitoring architecture can surface the structural reason and the route forward. Map your options.
Self-assessment: is your monitoring program defensible?
The following checklist reflects the baseline expectations of supervisors across the EU, the UAE, Singapore, and Hong Kong. It is not exhaustive and does not replace a formal audit, but it identifies the most commonly cited gaps.
- Is the monitoring rule set documented, version-controlled, and reviewed at least annually?
- Are alert thresholds calibrated to the actual transaction profile of the firm, not a generic template?
- Is the KYC risk classification of each customer formally connected to the monitoring threshold applied to that customer?
- Is Travel Rule data completeness tracked as a monitoring input, not a separate data silo?
- Is there a documented escalation path for cross-border alerts identifying the responsible MLRO in each jurisdiction?
- Is reliance on third-party blockchain analytics tools documented, with written policies for score interpretation and override authority?
- Is the SAR decision-making process recorded, with a documented rationale for each decision not to file?
- Has the monitoring program been independently tested in the past twelve months?
A common assumption in the market is that a single offshore VASP licence is sufficient to serve a global user base. It is not. Every jurisdiction where a firm operates, or where its users are located, applies its own AML monitoring expectations. The offshore licence addresses the home regulator. The monitoring obligation follows the activity.
Related at OBOLUS
Related at OBOLUS
- AML & Travel Rule compliance for digital-asset businesses – the full scope of our compliance, AML and Travel Rule practice across jurisdictions
- Sanctions screening for crypto – institutional clients – structuring a defensible sanctions screening program alongside transaction monitoring
- VARA licence application in Luxembourg – jurisdiction-specific licensing analysis with AML and monitoring implications
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, rooted in FATF Recommendation 15, requires a VASP to collect and transmit identifying information about the originator and beneficiary of a virtual asset transfer to the next institution in the payment chain. The precise data fields required, the threshold at which the obligation is triggered, and the accepted transmission protocols vary by jurisdiction. Non-compliance is an AML deficiency, not merely a technical oversight, and is treated accordingly by supervisors across the EU, UAE, Singapore, and Hong Kong.
Who must act as MLRO for a crypto firm?
A MLRO (money laundering reporting officer) is a mandatory senior appointment under the AML regimes of every major licensing jurisdiction, including MiCA in the EU, VARA in Dubai, the MAS Payment Services Act in Singapore, and the FCA's cryptoasset registration in the UK. The MLRO must be a named individual with sufficient seniority, authority, and independence to receive internal suspicious activity disclosures and make SAR filing decisions. Some regimes permit the role to be outsourced under defined conditions; others require the MLRO to be a local resident. The applicable rule turns on the licence jurisdiction.
How do regulators audit crypto AML programs?
Supervisors across the major hubs – including ESMA-aligned national competent authorities, VARA, the FSRA, and the FCA – audit AML programs through a combination of document review, system access, and interview. They typically request the AML risk assessment, the monitoring rule set and its documented calibration rationale, a sample of alert investigations and SAR decisions, Travel Rule data logs, and the MLRO's annual report. The quality of the documentation is as important as the underlying controls. Verbal explanations of undocumented processes are not a substitute for written records during a supervisory examination.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on AML compliance, transaction monitoring architecture, Travel Rule integration, and the licensing and regulatory programs that sit around them, across more than seventy jurisdictions. We map the compliance stack – monitoring, KYC, sanctions, and Travel Rule – across operating, custody, and payment layers before a client commits to a build or a market entry. Digital assets are the whole of our practice. To discuss your monitoring program, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialist in multi-jurisdictional AML program design and transaction monitoring governance for digital-asset businesses.
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.