Operating a digital-asset business without a properly configured transaction monitoring program is not a compliance gap — it is a regulatory liability that can freeze your banking, trigger enforcement and end your business before it scales. For early-stage founders, the window between launch and a regulator's first examination is shorter than most expect. Transaction monitoring is the operational backbone of any AML (anti-money laundering) compliance program, and regulators across every major licensing hub now treat its absence as a prima facie failure of the applicable regime. This page maps the regulated basis, the build process, the cross-border complications and the decisions that separate a defensible program from a checkbox exercise.
Why Transaction Monitoring Is Not Optional for Early-Stage Founders
Every VASP (virtual asset service provider) operating under a regulated regime — whether that is MiCA through ESMA and the national competent authorities, the VARA rulebooks in Dubai, the Payment Services Act administered by MAS in Singapore, or the VASP licensing regime overseen by the SFC in Hong Kong — is required to implement risk-based transaction monitoring as a condition of authorisation. This is not discretionary. FATF Recommendation 15 and its accompanying guidance for virtual assets set the international baseline, and every flagship jurisdiction has transposed that baseline into its domestic regime.
For a founder raising a seed round or preparing a licence application, the timing matters acutely. Regulators increasingly conduct pre-authorisation interviews that probe the AML framework in detail. A transaction monitoring system that exists only on paper — no configured rules, no alert workflow, no review log — will not satisfy that scrutiny. Worse, banking partners now conduct their own AML due diligence on crypto clients. An absence of a live monitoring program is one of the most common reasons a correspondent bank relationship is declined or terminated.
The cross-border dimension compounds this. A founder incorporated in the BVI, licensed through the AIFC in Kazakhstan and serving users in the EU must satisfy the monitoring expectations of multiple regimes simultaneously. The strictest applicable standard governs in practice, and that standard is set by whoever controls the banking or the licence that the business cannot afford to lose.
Operating without the right programme risks enforcement, frozen rails and lost banking. In our practice, we have seen early-stage businesses lose payment-processor access within weeks of launch because their AML documentation did not withstand a counterparty's due-diligence review. The cost of remediation at that stage far exceeds the cost of building correctly from the start.
To map what your specific build requires before you commit to a licence or a banking partner, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts — the entity structure, the user base, the product — change the analysis entirely.
What Does a Compliant Transaction Monitoring Program Actually Require?
A compliant transaction monitoring program rests on four interdependent pillars: a documented risk assessment, calibrated detection rules, a structured alert-review workflow and a record-keeping regime that survives regulatory examination. Each pillar is a discrete deliverable, and each must be proportionate to the business's risk profile — not copied from a template designed for a different entity type.
The risk assessment is the foundation. It identifies the money-laundering and terrorist-financing risks specific to the business: the product set, the customer types, the geographies served, the transaction methods and the channels used. Under MiCA and the applicable FATF guidance, this assessment must be documented, dated and revisited at meaningful intervals. A static PDF filed at incorporation and never reviewed will not survive an audit.
Detection rules translate that risk assessment into operational logic. At minimum, a well-configured program monitors for velocity anomalies, structuring patterns, high-risk geography exposure, sanctions-list hits and behavioural deviation from a customer's stated profile. The calibration question — what threshold triggers an alert — is where most early-stage programs fail. Thresholds set too low produce alert fatigue that operationally overwhelms a small team. Thresholds set too high miss the patterns regulators expect to be caught.
The alert-review workflow determines what happens when a rule fires. Who reviews the alert? Within what timeframe? What documentation does the reviewer complete? When does the alert escalate to the MLRO (money laundering reporting officer)? When does it produce a suspicious activity report filed with the financial intelligence unit? Each of these steps must be defined in a written procedure and must be followed in practice. Regulators look at the gap between the written procedure and the actual log.
Record-keeping requirements vary by regime but the direction of travel is uniform: longer retention periods, more granular transaction data and audit-ready formatting. Under the applicable provisions of MiCA and the VASP regimes in the leading hubs, records must typically be maintained in a form that permits reconstruction of any transaction on regulatory demand.
The Travel Rule: How It Intersects With Transaction Monitoring
The Travel Rule (the obligation under FATF Recommendation 16 to pass originator and beneficiary data alongside a virtual-asset transfer) is operationally inseparable from transaction monitoring for any VASP that transfers assets between counterparties. A monitoring program that does not account for Travel Rule compliance is structurally incomplete.
The practical intersection is this: a transfer flagged by your monitoring program as anomalous may also be a transfer on which Travel Rule data was not received from the originating VASP. That combination — an alert plus a data failure — is the highest-risk scenario from a regulatory standpoint. Your program needs a documented procedure for how each case is handled.
The data-threshold question — at what transfer value does the Travel Rule obligation attach — varies by jurisdiction and is set in the applicable domestic provisions. Do not assume a single global threshold applies. A VASP serving EU-resident users under MiCA, processing transfers that also touch Singapore and Hong Kong, faces the requirements of each of those regimes and must apply the most demanding standard where the rules conflict.
Choosing a Travel Rule solution (the technical protocol used to transmit originator/beneficiary data between VASPs) is a procurement decision with compliance consequences. The solution must be interoperable with the counterparty VASPs your business is likely to transact with, must retain data in the format your regulator expects and must integrate with your core transaction monitoring platform without creating data gaps.
How Do You Build a Transaction Monitoring Program From Scratch?
Building a transaction monitoring program from scratch follows a defined sequence of steps, each of which is a distinct decision point with legal and operational consequences. Skipping or conflating steps is the most common source of programs that pass initial review but fail under sustained regulatory examination.
Step 1: Complete the business-risk assessment. Before selecting any technology or writing any rule, document the risk profile of the specific business. Product type, customer segments, jurisdictions served, transaction volumes and the expected behavioural norms of the customer base all feed this assessment. The output is a written risk matrix that will anchor every subsequent calibration decision.
Step 2: Define the control architecture. Decide what categories of activity the monitoring program must detect, and in what priority order. A stablecoin transfer business has a different detection mandate than a spot exchange or a custody platform. Define the rule set, the threshold logic and the alert-tiering structure before touching a vendor contract.
Step 3: Select and configure the technology. The market for transaction monitoring tooling in digital assets is active. The selection criterion is fit-for-purpose configuration, not brand recognition. The system must ingest on-chain transaction data, apply the defined rule set, generate alerts in a reviewable queue and produce audit-ready logs. Integration with your KYC (know-your-customer) framework is mandatory — alerts without customer context cannot be reviewed meaningfully.
Step 4: Write the operating procedures. The alert-review workflow, the escalation matrix, the SAR-filing procedure and the record-keeping protocol must all be documented in a form that a new team member can follow and that a regulator can audit. These documents are not boilerplate — they are the operational translation of your risk assessment into daily practice.
Step 5: Appoint and brief the MLRO. The MLRO must be identified by name, have the authority to file suspicious activity reports and have the practical resources to fulfil the role. In many regimes, the regulator must approve or be notified of the MLRO appointment. Brief the MLRO on the configured system before it goes live.
Step 6: Conduct a pre-launch test. Run the configured system against a sample of representative transaction data — real or simulated — and confirm that the rules fire as designed. Document the test and its results. This documentation serves two purposes: it validates the configuration and it demonstrates to a regulator that the program was tested before deployment.
Step 7: Establish a review and recalibration cycle. Transaction monitoring is not a static installation. Business growth, new products, new customer types and evolving risk typologies all require periodic recalibration. Schedule formal reviews at defined intervals, document them and update the risk assessment when the business profile changes materially.
In a recent matter, a digital-payments startup preparing for a MAS application in Singapore had configured its monitoring rules against transaction thresholds drawn from a different jurisdiction's regime. The mismatch was identified during our pre-application review. We assisted in recalibrating the rule set against the applicable Payment Services Act framework and restructuring the alert-review workflow. The application proceeded without the delay that a regulator's own identification of the error would have caused.
Cross-Border Complications: What Happens When Your Business Spans Multiple Regimes?
A transaction monitoring program designed for a single-jurisdiction business is almost always inadequate for a multi-jurisdiction operation, and most digital-asset businesses are multi-jurisdiction from day one. The entity may be licensed in one hub, banked in another and serving users across a third regulatory perimeter. Each layer carries its own monitoring expectations.
The EU's MiCA regime requires CASPs to maintain monitoring systems calibrated to the EU risk environment, including the Travel Rule data standards applicable within the EEA. A CASP passporting across member states cannot simply replicate the monitoring configuration of its home-state authorisation if the risk profile of the passported activity differs materially. ESMA's guidance on AML under MiCA is expected to set detailed supervisory expectations, and national competent authorities have historically diverged on how they assess compliance.
In Dubai, VARA's rulebooks impose activity-specific monitoring obligations. A firm holding both an exchange and a custody activity licence must address the monitoring requirements of each activity line separately. The DIFC, which sits adjacent to VARA's mainland scope, operates its own regulatory perimeter under the DFSA. A business operating in both zones cannot treat them as a single compliance environment.
For a founder building a business that touches Singapore via MAS, Hong Kong via the SFC's VATP regime and the EU via MiCA simultaneously, the practical answer is a layered program: a common core architecture with jurisdiction-specific rule sets and procedure overlays. This is more expensive to build initially, but it is far less expensive than rebuilding after a regulator's finding.
The banking dimension is a separate cross-border pressure. Correspondent banks and payment processors impose their own AML standards on crypto clients — standards that may exceed the minimum required by the applicable licence regime. A program that satisfies VARA's rulebook may not satisfy the due-diligence requirements of a European correspondent bank. In our practice, we regularly advise founders to build to the banking partner's standard, not only the regulator's, to avoid the disruption of account closure after launch.
If your business spans more than one jurisdiction and you need a monitoring architecture that holds across all of them, write to us at info@oboluslaw.com. If a prior application stalled or an account was closed, a second read can surface the structural reason and the route back.
What Are the Most Common AML Mistakes Early-Stage Founders Make?
The most common mistakes in early-stage AML programs follow a recognisable pattern — not because founders are careless, but because the compliance literature is generic and the operational reality of a digital-asset business is specific.
Mistake 1: Treating the risk assessment as a one-time filing. A risk assessment written at incorporation and never revisited is the AML equivalent of a smoke detector with a dead battery. Regulators under MiCA, through VARA and via MAS each expect the assessment to reflect the current business. A product expansion, a new customer segment or a change in the jurisdictions served can each trigger a material change in risk profile that requires a formal update.
Mistake 2: Calibrating thresholds from a template. Every business has a unique transaction pattern. Thresholds borrowed from a generic template — or from a different business type — will either generate unworkable alert volumes or miss the patterns the regulator expects to be caught. The calibration exercise must be grounded in the specific customer and transaction data of this business.
Mistake 3: Separating KYC from transaction monitoring. A monitoring alert that cannot be resolved against customer identity and risk-category data cannot be reviewed meaningfully. The two systems must be integrated. A customer risk score from the KYC workflow should inform the monitoring rule sensitivity applied to that customer's transactions.
Mistake 4: Appointing a nominal MLRO without resources. The MLRO must have the authority, the information access and the practical time to review alerts and make filing decisions. A founder who appoints a compliance officer in name but routes all alert decisions through the CEO in practice has not met the MLRO requirement. This is a direct regulatory exposure in every major regime.
Mistake 5: Ignoring the Travel Rule until the regulator asks. A common assumption is that the Travel Rule only matters at scale. In practice, the obligation attaches from the first qualifying transfer. A business that has been transferring assets between wallets without collecting or transmitting originator/beneficiary data has a remediation problem, not just a future compliance task.
Decision Matrix: Which Program Architecture Fits Your Profile?
The right monitoring architecture is not universal. It depends on the business model, the licence type, the user base and the banking relationships in play. The following profiles illustrate the decision logic.
Profile A: A single-jurisdiction VASP at early stage, pre-revenue, applying for a first licence. The immediate requirement is a documented risk assessment, a defined rule set, a written alert-review procedure and an identified MLRO. The technology layer need not be elaborate at this stage, but it must be live and configured before the licence application is filed. The key risk is under-documentation — building a system that works operationally but is not described in a form the regulator can assess. Timeline to a defensible program: typically a matter of weeks with focused effort.
Profile B: A multi-jurisdiction operator, licensed in one hub, expanding into a second. The existing program must be assessed against the second regime's requirements before expansion begins. In our experience, the most common gap is Travel Rule interoperability — the existing Travel Rule solution may not be accepted by VASPs or regulators in the new jurisdiction. A gap analysis followed by a targeted recalibration is the standard path. Timeline varies by jurisdiction and the extent of the existing program's documentation.
Profile C: A crypto-native startup that has been operating under a registration or exemption and is now seeking a full licence. The regulator will expect the monitoring program to have been operating effectively during the pre-licence period. Any historical gaps — unconfigured rules, unreviewed alerts, missing SAR filings — will need to be identified, documented and remediated before the application. In this profile, the risk of a regulatory finding during the application process is highest. A pre-application audit of the existing program is essential.
Profile D: A fund or institutional operator processing high-value, low-frequency transactions. The monitoring challenge here is different from a retail exchange. Rule sets calibrated for volume may miss the patterns relevant to a fund — large single transactions, counterparty concentration, unusual settlement timing. The program must be calibrated to the specific risk typologies of institutional digital-asset activity, and the MLRO function must have the expertise to assess those patterns.
In each profile, the cross-border angle — where the entity sits, where its users are and where its banking lives — shapes the final architecture. A program that satisfies the regulator in one column of that matrix may not satisfy the others.
How OBOLUS Structures the Engagement
We approach transaction monitoring setup as a structured engagement with defined deliverables, not an open-ended retainer. The process begins with a scoping call under NDA, in which we map the business model, the licence position, the jurisdictions in scope and the existing compliance infrastructure. From that call, we produce a written scope of work with fixed deliverables and a stated timeline.
The core deliverables for an early-stage build typically include: a business-risk assessment specific to the entity; a written AML policy and monitoring procedure; a rule-set specification for the chosen technology platform; a Travel Rule gap analysis; and a pre-launch review of the configured system against the applicable regulatory expectations. Where the engagement requires allied counsel in a specific jurisdiction — for example, to verify the applicable SAR-filing requirements or to confirm the MLRO appointment process — we coordinate that directly.
We have seen the alternative: founders who purchase a compliance software licence, complete a vendor-provided template and submit it with a licence application — only to receive a request for further information that delays the authorisation by months. The template may satisfy the software vendor's compliance checklist. It rarely satisfies the regulator's examiner.
Our pricing model uses transparent fixed-scope packages. We do not quote a number in this article — the right scope depends on your specific facts, and quoting a number without knowing those facts would be misleading. What we can say is that the cost of a properly scoped engagement is a fraction of the cost of remediation after an adverse regulatory finding or a banking relationship loss.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – full practice overview covering KYC frameworks, AML policy and regulatory obligations across regimes
- Sanctions screening for regulated crypto entities – how to configure and maintain a sanctions-screening program that satisfies OFAC, EU and VARA expectations
- Transaction monitoring setup for institutional clients – the architecture and regulatory expectations for high-value, low-frequency digital-asset operations
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary information alongside a virtual-asset transfer. The applicable FATF guidance sets the international baseline, and each licensing jurisdiction has transposed that baseline into its domestic regime with jurisdiction-specific data-threshold requirements. The obligation attaches from the first qualifying transfer — there is no general exemption for low-volume or early-stage operators. Failure to comply is a regulatory breach in every major hub, including under MiCA, the VARA rulebooks and the MAS Payment Services Act framework.
Who must act as MLRO for a crypto firm?
The MLRO (money laundering reporting officer) is the individual responsible for overseeing the firm's AML program, reviewing alerts and deciding whether to file suspicious activity reports with the relevant financial intelligence unit. Most regulated regimes require the MLRO to be a named individual with the authority and resources to fulfil the role independently. In some jurisdictions, the regulator must approve or be notified of the appointment. A nominal appointment without genuine operational authority does not satisfy the requirement and creates direct personal and corporate liability.
How do regulators audit crypto AML programs?
Regulators typically audit a crypto AML program by reviewing the documented risk assessment, the configured rule set and its calibration rationale, the alert-review log, SAR-filing records and the MLRO's decision trail. They compare the written procedures against the actual operational record. The most common finding is a gap between what the policy document describes and what the monitoring system's logs show actually happened. Interview of the MLRO and compliance team is standard practice. Under MiCA and the VARA rulebooks, ongoing supervisory reporting obligations mean the audit relationship is continuous, not periodic.
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 tax, banking and compliance that sit around them. Digital assets are the entirety of our practice, and we act only for businesses. We map the licence, monitoring and compliance stack across operating, custody and payment layers before you commit — so the architecture holds when the regulator examines it. To discuss your situation, contact info@oboluslaw.com or message us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst — specialising in AML program architecture, transaction monitoring configuration and VASP regulatory compliance across the EU, Gulf and Asia-Pacific hubs.
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.