Setting up transaction monitoring for a crypto business is not a discretionary compliance exercise. Every jurisdiction that has implemented FATF-aligned VASP (virtual asset service provider) rules requires some form of automated transaction monitoring as part of the mandatory AML/CFT program. Regulators from ESMA under the MiCA (Markets in Crypto-Assets Regulation) regime to the MAS (Monetary Authority of Singapore) under the Payment Services Act are accelerating supervisory scrutiny. A firm that cannot demonstrate a calibrated, documented monitoring system faces enforcement, rail suspension or, in the worst case, licence revocation. This guide walks through each step of the build, from legal baseline to audit readiness.
Why Transaction Monitoring Is Non-Negotiable for Crypto Businesses
Transaction monitoring is the operational backbone of any AML/CFT program. Under the Travel Rule (the obligation to pass originator and beneficiary data alongside a virtual-asset transfer), a VASP cannot simply move value and reconcile later. Every transfer, every wallet interaction and every counterparty relationship generates data that regulators expect to be screened in near-real time.
FATF Recommendation 15 – which addresses virtual assets and VASPs – requires that firms apply risk-based monitoring proportionate to the nature and scale of their business. VARA in Dubai, the FSRA within the ADGM in Abu Dhabi, and the SFC in Hong Kong have each embedded this expectation into their VASP rulebooks. Failure is not a theoretical risk. Regulators in the leading hubs have escalated enforcement against firms that deployed static rule sets and never reviewed them.
Operating without calibrated monitoring exposes a business to frozen correspondent-banking relationships, regulatory notices demanding urgent remediation, and personal liability for the MLRO (Money Laundering Reporting Officer). The business case for a proper build is stark. The cost of remediation after a supervisory finding typically exceeds the cost of a well-designed initial program by a significant multiple.
In our practice, we regularly advise businesses that arrive with a generic monitoring tool licensed from a vendor but with no documented rationale for the thresholds chosen, no governance record and no Travel Rule data-sharing workflow. That configuration is not a defence. It is a liability.
The process above describes the standard path. Your facts – the entity structure, the user base geography and the banking counterparties – change the analysis. For a scoped assessment of your monitoring obligations, contact OBOLUS at Map your options.
Step 1: Establish the Legal Baseline Across Every Jurisdiction Where You Operate
The first step is to identify every jurisdiction that asserts supervisory authority over your activities, not just where your entity is incorporated. A CASP authorised under MiCA in one EU member state and passporting across the EEA faces ESMA-level expectations plus any national competent authority guidance. A VASP registered with the FCA under the Money Laundering Regulations in the UK also faces FCA financial-promotion rules and separate transaction-reporting obligations. The entity jurisdiction and the service jurisdiction are rarely the same.
Map each regulated activity – exchange, custody, transfer/settlement, lending – against the applicable regime in each market. The VARA rulebooks in Dubai take an activity-based approach. The MAS Payment Services Act in Singapore distinguishes between major payment institution and standard payment institution tiers, each carrying different monitoring thresholds. The BVI FSC under the VASP Act 2022 and CIMA in the Cayman Islands each impose their own AML/CFT standards, which align broadly with FATF but contain jurisdiction-specific reporting obligations.
The common mistake at this step is treating the incorporation jurisdiction as the only relevant regime. A Cayman-incorporated fund whose investors wire from Singapore and whose custody sits in the ADGM is already operating across three regulatory perimeters. Monitoring rules from each must be satisfied simultaneously.
Document the legal baseline in a jurisdiction matrix. For each row, record the regulator name, the applicable AML framework, the Travel Rule threshold (noting that this figure requires current verification per jurisdiction), and the reporting forum. This document becomes the governance anchor for every subsequent configuration decision.
Step 2: Classify Your Transaction Types and Assign Risk Scores
Effective transaction monitoring begins with a defined transaction typology, not a vendor's default rule set. Each category of transaction your business processes carries a different risk profile, and the monitoring configuration must reflect that explicitly.
Common categories for a crypto exchange or custodian include: fiat-to-crypto on-ramps, crypto-to-fiat off-ramps, peer-to-peer crypto transfers between user wallets, withdrawal to self-hosted wallets, transfers to counterparty VASPs, and DeFi protocol interactions. Each category generates a different set of red-flag indicators. A withdrawal to a self-hosted wallet above a defined volume threshold and to an address associated with a privacy protocol warrants a different automated response than a routine internal transfer between segregated custody wallets.
Risk scoring at the transaction level should integrate at minimum: the counterparty address risk classification from your blockchain analytics tool, the jurisdictional risk of the destination, the customer risk tier established in the KYC (Know Your Customer) framework at onboarding, and the velocity pattern relative to the customer's declared activity profile.
Blockchain analytics providers whose capabilities are relevant to this step include tools capable of assigning entity labels and risk scores to on-chain addresses. We regularly work alongside forensic partners in this space. The key point is that the analytics output must feed directly into your case management system – not sit in a separate portal reviewed only on demand.
The common mistake here is over-relying on a single risk signal. A transaction may pass an address-risk screen but still warrant review if the velocity, the fiat value converted or the destination jurisdiction creates a combined risk score above your documented alert threshold. Calibrate for combinations, not single variables.
Step 3: Select and Configure Your Monitoring Technology Stack
Technology selection for transaction monitoring must follow the risk assessment, not precede it. A vendor chosen before the business understands its transaction typology and risk appetite will invariably be misconfigured from the first day of deployment.
The core stack typically comprises: a blockchain analytics integration (for on-chain address screening and transaction tracing), a rules engine (for threshold-based automated alerts), a case management module (for analyst workflow, decision records and escalation), and a Travel Rule messaging solution (for originator/beneficiary data exchange with counterparty VASPs). In some regulated environments, notably under MiCA and VARA, the data architecture of this stack must itself be auditable and defensible in a regulatory examination.
Configuration requires written rationale for every threshold and rule. If your rules engine flags transfers above a given fiat-equivalent value for enhanced review, the calibration document must record why that threshold was chosen, how it maps to your customer risk profile, and when it was last reviewed. Regulators do not accept a vendor's standard settings as a substitute for an institution-specific calibration decision.
The cross-border dimension of this step is significant. If your platform operates across multiple jurisdictions, Travel Rule messaging standards may differ. The FATF threshold for Travel Rule obligations is set at a level that varies by jurisdiction per current legislation, and some markets impose lower de-minimis levels. Your Travel Rule solution must be capable of applying jurisdiction-specific logic dynamically, not a single global rule that inevitably underperforms in some markets.
The common mistake at this step is treating technology deployment as the end of the process. It is the beginning of an ongoing governance cycle. The stack must be calibrated, tested against synthetic scenarios, and reviewed at documented intervals.
Step 4: Define Your Alert Management and Escalation Workflow
A monitoring system that generates alerts without a structured workflow for resolving them provides no regulatory protection. The alert management process is itself a regulated function in most major frameworks. Regulators auditing an AML program examine not only whether alerts were generated but whether they were resolved promptly, by a qualified person, with a documented rationale.
The workflow must specify: who receives an alert (the first-line analyst or a dedicated compliance team), the time limit for first-line review (typically documented in business hours, not days), the decision criteria for closing an alert without escalation, the criteria that trigger escalation to the MLRO, and the process for filing a SAR (Suspicious Activity Report) or its jurisdictional equivalent.
The MLRO function requires particular attention. Under most regulated regimes – including those supervised by the FCA, the Bank of Lithuania under the MiCA transition and VARA in Dubai – the MLRO must be a named, approved individual with appropriate authority and independence within the organisation. The MLRO is not an administrative role. This individual is legally responsible for the quality of the firm's SAR filings and must have direct board-level access.
For businesses operating across multiple jurisdictions, the multi-jurisdictional escalation map must address which SAR filing goes to which financial intelligence unit. FATF-aligned regimes designate national FIUs for SAR receipt, but the practical reporting path, the form and the timing are jurisdiction-specific. A single-stream escalation workflow is inadequate for a cross-border operator.
The common mistake at this step is structuring the MLRO role as a part-time or outsourced function without documented access rights, decision authority and a defined communication channel to senior management. Some regulators have issued public notices specifically on inadequate MLRO arrangements. The role must function in substance, not merely on an organisation chart.
If a prior compliance build stalled or a regulator has raised concerns about your monitoring workflow, a second read of the program can surface the structural gap and the route to remediation. To map the licence, banking and compliance stack for your build, write to OBOLUS at Map your options.
Step 5: Implement Travel Rule Data Collection and Sharing
The Travel Rule obligation requires a VASP to collect and transmit originator and beneficiary information for virtual-asset transfers that meet the applicable threshold, and to verify that information where risk warrants it. This is not a future obligation in the major hubs – it is current law under MiCA, under VARA, under the MAS Payment Services Act, and under the applicable VASP provisions in the UK, Switzerland and the BVI.
Implementing Travel Rule compliance involves three operational layers: data collection at transaction origination (capturing originator name, account details and jurisdiction), counterparty VASP verification (confirming that the receiving VASP is also subject to Travel Rule obligations and has an equivalent program), and data transmission in a format compatible with your Travel Rule messaging solution and the counterparty's.
The interoperability problem is real. Different VASP ecosystems use different messaging protocols. A Travel Rule solution that works within one protocol network cannot automatically exchange data with a counterparty on a different protocol. Regulators acknowledge the interoperability challenge but do not exempt firms from compliance while the market evolves. In our experience, firms that have not mapped their counterparty VASP universe and tested their messaging integration before go-live face material gaps on day one of operation.
The cross-border note at this step is critical. Where a transfer is directed to a self-hosted wallet – one not associated with a regulated VASP – the applicable rules differ by jurisdiction. Some regimes require enhanced due diligence or enhanced risk assessment for non-custodial wallet interactions. Others impose direct restrictions. Your Travel Rule workflow must include a self-hosted wallet policy that maps to each relevant jurisdiction's requirements.
The common mistake is assuming that a Travel Rule tool handles compliance automatically. It does not. It provides a data channel. The obligation to verify originator information, to exercise judgment on high-risk transfers and to maintain records rests with the firm, not the vendor.
Step 6: Build the Governance Record – Policies, Testing and Periodic Review
A monitoring system without a maintained governance record is, from a regulatory standpoint, almost the same as no monitoring system at all. Regulators auditing an AML program expect to see a written AML policy, a business-risk assessment, a documented calibration rationale for every monitoring rule, records of alert dispositions, SAR filing logs, and evidence of periodic program review.
The governance record is not bureaucracy for its own sake. It is the legal defence of the firm and of the MLRO personally. When a regulator or an external auditor reviews the program – whether in a routine supervision cycle or following an incident – the governance record is the primary evidence examined. A technically sophisticated monitoring stack with poor documentation is a high-risk configuration. A modest stack with excellent documentation and clear review cycles is significantly more defensible.
Periodic program review should be structured against three triggers: a scheduled annual review at minimum, a triggered review when a new product or service is launched or when a new jurisdiction is entered, and an event-driven review when a material alert leads to a SAR filing or when the firm receives a regulatory notice. Each review must produce a documented outcome – not merely a confirmation that the review occurred, but a record of what was tested, what was found and what was changed or affirmed.
Testing is a specific governance requirement in the stronger regulatory environments. This involves running the monitoring system against synthetic or historical transaction data designed to replicate known red-flag patterns. If the system fails to generate an alert on a synthetic high-risk transaction, the configuration is deficient. That deficiency must be corrected and the correction documented before the next audit cycle.
In a recent matter, a payments company entering a new regulated market had deployed transaction monitoring based on its existing configuration without conducting a jurisdiction-specific calibration review. When the local regulator requested evidence of a documented risk assessment and threshold rationale for the new market's activity profile, the firm had no responsive document. We worked through the remediation on an expedited basis, producing a jurisdiction-specific addendum to the AML policy, a revised calibration record and a Travel Rule workflow that addressed the local de-minimis rules. The matter resolved without formal enforcement action.
Decision Matrix: Which Monitoring Build Fits Which Operator?
Not every crypto business has the same monitoring obligation, and the right architecture depends on the business profile. The following outlines the principal decision branches.
A startup exchange with a limited user base in a single regulated market will typically require a basic monitoring stack: a blockchain analytics feed integrated with a rules engine, a light case management module, a named MLRO and a documented AML policy. The Travel Rule obligation applies immediately upon reaching the applicable threshold. The governance cycle can be annual with event-driven triggers. The key risk at this profile is under-resourcing the MLRO and over-relying on vendor defaults without a documented calibration rationale.
A scaling cross-border operator – a custody provider or exchange that has passported across the EU under MiCA, maintains a VARA licence in Dubai and holds a DPT service licence under the MAS Payment Services Act – carries a materially different obligation. Three separate regulatory perimeters, each with distinct Travel Rule thresholds, SAR filing requirements and audit cycles, demand a governance architecture that is jurisdictionally segmented and centrally coordinated. The MLRO must have jurisdiction-specific deputies or compliance officers in each regulated entity, with clear escalation lines and an integrated case management system that preserves the audit trail across jurisdictions.
A tokenisation platform or DeFi-adjacent structure faces an additional layer of complexity. Where the platform interacts with non-custodial wallets or protocol-level transactions, the regulatory perimeter of the monitoring obligation is less clearly defined and is actively evolving. MiCA, VARA and the SFC's VASP regime each address this differently. The safest posture is to apply full monitoring to all on-ramp and off-ramp activity, maintain a documented policy on DeFi interactions and review it each time a new protocol is added to the product set.
A Common Assumption That Needs Correcting
A persistent assumption among operators entering the crypto market is that a single offshore licence – typically a registration in a lighter-touch jurisdiction – is sufficient to serve a global client base without full AML/monitoring obligations in the markets where clients actually sit.
This is incorrect, and the misunderstanding can be costly. The regulatory obligation for transaction monitoring follows the activity, not just the entity. Where a VASP provides services to users in the EU, it is subject to MiCA. Where it serves users in the UK, the FCA's regime applies. Where it onboards clients in Singapore, the MAS expects compliance with Payment Services Act obligations. An offshore registration addresses only the jurisdiction of incorporation – it does not neutralise the regulatory reach of the jurisdictions where the services are consumed.
Regulators in the leading hubs have specifically addressed extraterritorial reach in their guidance. ESMA has published supervisory expectations for CASPs that provide services into the EU without a physical presence. The FCA has issued warnings to unregistered firms marketing to UK persons. VARA has articulated clear rules on what constitutes a "virtual asset activity" subject to its regime, including activities conducted remotely into Dubai.
The practical consequence is that a firm relying on a single registration must conduct a thorough analysis of whether that registration satisfies the monitoring and reporting obligations in every market where it has clients. In our practice, we have seen enforcement actions initiated not in the jurisdiction of registration but in the jurisdiction of the client base. The offshore registration offered no protection in those proceedings.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – Full-scope AML/CFT counsel across the VASP compliance lifecycle.
- Custody rules after recent exchange failures – How segregation and safeguarding obligations evolved after high-profile insolvencies.
- Economic substance for licensed VASPs in El Salvador – Substance requirements and what they mean for a licensed VASP in that jurisdiction.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect and transmit the name, account details and jurisdiction of both the originator and the beneficiary for covered virtual-asset transfers. The specific threshold at which the obligation applies varies by jurisdiction – it requires current verification against the applicable rules in each market where the VASP operates. Compliance involves data collection, counterparty verification and a compliant messaging channel for data transmission to the receiving VASP.
Who must act as MLRO for a crypto firm?
An MLRO (Money Laundering Reporting Officer) must be a named, senior individual with genuine authority and independence within the firm, approved by the relevant regulator in each jurisdiction that requires the role formally. The MLRO is legally responsible for the quality of suspicious-activity reports and must have direct access to senior management. An outsourced or part-time arrangement without documented authority and clear escalation rights is unlikely to satisfy supervisory expectations in the leading regulated hubs.
How do regulators audit crypto AML programs?
Regulators auditing a crypto AML program typically examine the written AML policy and business-risk assessment, the documented calibration rationale for monitoring rules, alert disposition records, SAR filing logs, and evidence of periodic program review. They may test the system against red-flag scenarios and interview the MLRO directly. In cross-border structures, each regulated entity may face a separate audit by its own competent authority. A governance record that is current, calibrated and jurisdiction-specific is the primary defence.
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 every regulated activity. We map the licence, monitoring and banking stack across the operating, custody and payment layers before you commit – and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when matters escalate. 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/CFT program design, Travel Rule implementation and cross-border VASP compliance across MiCA, VARA, MAS and aligned 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.