For an early-stage crypto founder, the gap between "we have a compliance policy" and "we have a compliance program that will survive regulatory scrutiny" is where enforcement actions begin. Sanctions screening – the obligation to check counterparties, wallet addresses and transaction flows against designated-person and restricted-jurisdiction lists – sits at the intersection of AML compliance (anti-money laundering obligations), the Travel Rule (the requirement to pass originator and beneficiary data with a virtual asset transfer), and the KYC framework that every regulated virtual asset service provider must maintain. Getting this wrong at the seed stage costs far more than getting it right from day one.
The regulated basis is clear across the major hubs. Whether your entity is licensed under MiCA via a EU national competent authority, registered under the FCA's money laundering rules in the UK, or operating within the VARA regime in Dubai, the expectation is identical: a documented, risk-based sanctions screening program that runs before onboarding, on a rolling basis, and at the point of each material transaction. The remainder of this page maps the process, the cross-border reality, and the structural mistakes that trip up founders before their first regulatory review.
Why Sanctions Screening Is Not Optional for Crypto Founders
Sanctions screening is a hard legal obligation, not a best-practice aspiration – and the obligation attaches the moment you handle value on behalf of a third party, regardless of licence stage. Under FATF Recommendation 15, virtual asset service providers are treated as financial institutions for AML and counter-proliferation purposes. Every major regime – MiCA, VARA, the MAS Payment Services Act, the FCA's registration requirements, the BVI FSC's VASP Act – incorporates that baseline. Regulators do not grant a grace period to early-stage businesses on sanctions compliance; the clock starts when the first user funds a wallet.
The practical risk is asymmetric. A single transaction touching a sanctioned address can expose the business to enforcement action across multiple jurisdictions simultaneously. In our practice, we see founders who launched a product on the assumption that their payment processor or custody partner handled screening downstream. That assumption is incorrect. Each entity in the transaction chain carries its own obligation. Delegation to a third party does not extinguish your firm's exposure.
Loss-aversion framing matters here. The cost of a properly scoped sanctions screening program at the seed stage is a fraction of the legal cost of responding to a regulatory inquiry, a banking termination notice, or a frozen settlement account. The decision is financial, not merely legal.
What the Travel Rule Adds to the Sanctions Obligation
The Travel Rule – the obligation to pass originator and beneficiary data with each virtual asset transfer above the applicable threshold – is now live in every leading digital-asset jurisdiction. Under MiCA and its implementing measures, under the MAS regime in Singapore, under the VARA rulebooks, and under the UK's updated transfer-of-funds rules, a VASP must collect, verify and transmit identifying information alongside each qualifying transfer. The specific de-minimis threshold varies by jurisdiction and regime – check current implementing measures – but the structural requirement is consistent.
For a founder building a remittance product, an exchange or a custody service, the Travel Rule intersects directly with sanctions screening. You cannot comply with the Travel Rule without first knowing who your counterparty is; and you cannot discharge your sanctions obligation without screening the data you have collected under the Travel Rule. The two programs are operationally co-dependent. A KYC framework that collects identity data but does not feed it into a screening workflow is incomplete.
The cross-border dimension compounds this. A transfer between a user in the EU and a counterparty wallet on a non-VASP platform in a third country triggers questions about the "unhosted wallet" provisions now active under MiCA. VARA has its own transfer-monitoring expectations for cross-border flows. The MAS regime in Singapore requires Travel Rule data to flow even where the receiving VASP is in a jurisdiction that has not yet implemented the rule. Early-stage founders building a multi-market product must design their data architecture to satisfy the most demanding applicable requirement – not the lowest common denominator.
For a scoped assessment of your Travel Rule and sanctions architecture, contact OBOLUS at info@oboluslaw.com. The process above describes the standard obligation. Your facts – the entity structure, the user jurisdictions, the transfer counterparties – change the analysis materially.
The Components of a Defensible Sanctions Screening Program
A defensible program has five structural elements, each of which a regulator will test on inspection.
First, list coverage. The program must screen against the relevant designated-person lists – OFAC's SDN list, EU consolidated sanctions, UN Security Council designations, and the domestic list of the licensing jurisdiction. For a dual-licensed entity operating under both MiCA and VARA, that means maintaining access to and updating from multiple list sources simultaneously. A program that screens only against one list is not compliant in the others.
Second, wallet-address screening. Unlike traditional finance, crypto transactions expose blockchain addresses that can themselves be screened against known illicit wallets using on-chain forensic tools. Regulators in the leading hubs increasingly expect wallet-address risk scoring as a supplement to name-based screening. The tools used for this – VASP identification, risk-tier assignment, clustering analysis – are part of the transaction monitoring infrastructure, not a separate exercise.
Third, real-time and retrospective screening. Onboarding screening is necessary but insufficient. List updates occur continuously; a customer who was clean at onboarding may appear on a newly designated list six months later. The program must include a rolling re-screening process for the existing customer base, triggered by list updates, not merely by customer-initiated events.
Fourth, documented escalation and alert disposition. Every alert generated by the screening tool must be triaged, documented and resolved. Regulators audit the alert log as closely as the policy document. An undocumented alert disposition – even one that correctly concluded "false positive" – is an audit finding. The MLRO (money laundering reporting officer) or compliance officer must sign off on material dispositions.
Fifth, periodic independent review. Most regimes require the program to be subject to audit – either by internal audit, an external reviewer, or both – at a frequency tied to the firm's risk profile. A high-volume exchange faces a tighter review cycle than a low-volume OTC desk. Document the review cycle, execute it, and retain the reports.
What Common Mistakes Do Early-stage Founders Make With Sanctions Compliance?
The most costly mistake is conflating KYC with AML. Collecting a passport and a proof of address is identity verification; it is not sanctions screening, transaction monitoring, or a Travel Rule program. Founders who invest heavily in a KYC onboarding flow and neglect the downstream monitoring layer present regulators with a firm that looks compliant on the surface and is not underneath.
The second mistake is geographic scoping. A founder incorporated in the BVI serving users in Germany, Singapore and the UAE is not operating under one legal regime; they are operating under four simultaneously. Each jurisdiction where a user is resident, where a transaction settles, or where a banking relationship sits may impose its own AML and sanctions obligations. In our cross-border practice, we regularly advise founders who assumed that their offshore incorporation was a compliance proxy. It is not.
The third mistake – and the one that generates the fastest enforcement response – is relying on a vendor's screening tool without owning the program. Purchasing a SaaS compliance tool is a procurement decision, not a compliance decision. The tool must be configured to the firm's specific risk profile, its list coverage verified, its alert thresholds calibrated, and its outputs reviewed by a qualified person. A tool left on default settings, generating alerts that no one reviews, is a liability documentation trail, not a program.
A fourth pattern we observe regularly: founders who appoint an MLRO as a nominal compliance function without giving that person authority, budget or access to transaction data. The MLRO role under most regimes is personal and carries individual accountability. An MLRO who cannot stop a transaction is not an MLRO; they are a named individual being set up for personal regulatory exposure.
Decision Matrix: Which Program Structure Fits Your Founder Profile?
Not every early-stage business needs the same configuration. The right structure depends on licence stage, transaction volume, user geography, and banking infrastructure.
Profile A – pre-licence, building toward a single EU jurisdiction under MiCA. The priority is designing the program to meet CASP authorisation requirements from inception. That means a documented risk assessment, a written AML/CFT policy, a Travel Rule data architecture (even before the first live transfer), and an MLRO appointment on record before the application is filed. The programme does not need to be large; it needs to be demonstrably risk-based and auditable. Timeline to a defensible program at this stage is typically a matter of weeks.
Profile B – live product, multi-market user base, operating under an interim registration or pending a full licence. The immediate priority is gap analysis: which lists are you screening against, at which points in the transaction lifecycle, and who is reviewing alerts. The Travel Rule obligation is live. The cross-border transfer-monitoring requirements of MAS, VARA, or whichever regime governs your user base must be mapped and operationalized. A program remediation engagement at this stage typically runs in parallel with a licence application, not after it.
Profile C – venture-backed, scaling, adding custody or lending to an exchange product. Each new regulated activity adds a new AML surface. A custody business screens differently from an exchange; a lending desk adds counterparty risk assessments to the workflow. The program must be modular enough to extend to new activities without a full rebuild. This is also the stage where an independent AML audit becomes a regulatory expectation, not just a good idea.
How Does Sanctions Compliance Interact With Banking and Payment Rails?
Banking is where a weak sanctions program becomes immediately visible. Correspondent banks and payment processors conduct their own screening of crypto businesses they serve; a crypto firm whose transaction flows include unresolved alerts, unexplained wallet clusters or Travel Rule data gaps will find its accounts reviewed, restricted or terminated. Banking termination is one of the fastest-moving operational risks for an early-stage crypto business, and it is almost always a compliance symptom, not a commercial one.
We have seen this pattern repeatedly. A founder builds a product, banks with an EMI or a crypto-friendly correspondent, and receives a termination notice citing "risk appetite" without further explanation. The underlying cause, in most cases, is that the bank's own AML monitoring flagged the crypto firm's transaction patterns and found no auditable compliance program to mitigate the concern. The solution is not to find a new bank; it is to build a program the current bank can rely on.
The Travel Rule creates a specific banking interaction. Where a VASP routes fiat legs of crypto transactions through a correspondent bank, the bank will expect to see Travel Rule data flowing correctly on the virtual asset leg. A mismatch between the on-chain transfer data and the fiat settlement record is a flag. Early-stage founders building hybrid crypto-fiat products must architect the data flows from inception – retrofitting Travel Rule compliance onto a live transaction infrastructure is significantly more expensive than building it in at the start.
If a banking relationship has already been terminated or a compliance gap has been identified, OBOLUS can assess the structural cause and map the route forward. Write to us at info@oboluslaw.com or message t.me/oboluslaw. A second read on a stalled program frequently surfaces a fixable structural issue rather than an intractable one.
Micro-Matter: Travel Rule Gap Identified Before Licence Application
In a recent pre-licensing engagement, a payments technology company preparing a CASP application under MiCA approached us after their external auditor flagged a material gap: the firm's transaction data architecture did not support Travel Rule data transmission for transfers between their platform and third-party VASP wallets. The application was weeks from submission. We conducted a focused gap analysis against the applicable transfer-of-funds requirements, identified the specific data fields missing from the outbound transfer payload, and worked with the firm's engineering team to specify the remediation. The corrected architecture was documented and included as a supporting annex to the application. The application proceeded on schedule without the regulator raising a Travel Rule deficiency. The firm's MLRO had a defensible audit trail from the point of identification through to resolution.
A Common Assumption: "Our Offshore Entity Covers the Compliance Obligation"
A common assumption among early-stage founders is that incorporating in an offshore jurisdiction with a crypto-friendly regulatory posture – the BVI, the Cayman Islands, or a similar hub – means that only that jurisdiction's AML requirements apply. This is not correct, and it is the most consequential myth in early-stage crypto compliance.
The jurisdiction of your entity's incorporation determines your primary regulatory obligations. But the jurisdiction of your users, the jurisdiction where your transactions settle, the jurisdiction of your banking relationships, and the jurisdiction where your VASP counterparties are licensed all impose concurrent obligations. FATF's mutual evaluation process – and the corresponding domestic implementation by each assessed jurisdiction – means that a VASP serving EU-resident users from a BVI entity is within the reach of MiCA's requirements for travel rule data and AML standards, regardless of where the corporate seat sits. VARA in Dubai, MAS in Singapore, and the FCA in the UK each take the same position on extraterritorial reach.
In our practice, we map the full jurisdictional footprint of an early-stage business – not just the domicile – before recommending a compliance program structure. The program that a BVI-incorporated, EU-user-serving, Singapore-banked exchange actually needs is materially more complex than what the BVI VASP Act alone requires. Ignoring that complexity does not make it go away; it concentrates it into a single enforcement event.
Self-Assessment: Is Your Program Ready for Regulatory Review?
The following questions reflect the standard inspection criteria applied by regulators in the leading VASP hubs. A "no" or "unsure" answer at any point identifies a gap requiring attention before an application or a regulatory interaction.
- Do you screen against OFAC, EU consolidated sanctions, UN designations, and the domestic list of every jurisdiction where you hold a licence or registration?
- Is wallet-address screening integrated into your onboarding and transaction monitoring workflow, not run as a separate manual process?
- Do you have a documented, tested alert disposition process – including escalation paths and MLRO sign-off thresholds?
- Is your customer base re-screened on list updates, not only at onboarding?
- Does your Travel Rule data architecture support outbound and inbound data transmission for transfers above the applicable threshold in every jurisdiction where you operate?
- Have you documented the jurisdictional scope of your AML obligations – including the jurisdictions of your users and banking relationships, not only your entity domicile?
- Has your program been reviewed by a qualified independent person or function within the past twelve months?
- Does your MLRO have the authority, budget and data access to discharge the role – not merely the title?
If the answer to any item above is "no" or "we plan to address this," that is the starting point for a scoped compliance engagement.
Related at OBOLUS
- AML & Travel Rule Compliance for Digital Asset Businesses – the full practice overview covering AML program design, Travel Rule implementation and regulatory engagement across 70+ jurisdictions.
- Travel Rule Compliance Program in Jersey – jurisdiction-specific analysis of Travel Rule obligations under the Jersey framework and how they interact with a cross-border VASP structure.
- Sanctions Screening for Crypto: Regulated Entities – a deeper look at sanctions screening obligations for licensed VASPs facing regulatory inspection or programme remediation.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a virtual asset service provider to collect, verify and transmit originator and beneficiary identifying information alongside each qualifying virtual asset transfer. The obligation applies at the point of transfer, not only at onboarding. The specific data fields and de-minimis threshold vary by jurisdiction – check the implementing measures under MiCA, MAS, VARA or whichever regime applies – but the structural requirement is consistent: data must travel with the funds, and the receiving VASP must be able to verify it.
Who must act as MLRO for a crypto firm?
The MLRO (money laundering reporting officer) is the senior individual accountable for the firm's AML and counter-terrorism financing program. Most regimes require the MLRO to be approved or at least notified to the regulator, to be sufficiently senior to have genuine authority over compliance decisions, and to have access to all transaction data necessary to discharge the role. In practice, an MLRO who lacks authority to stop or escalate a transaction is not meeting the regulatory expectation. Early-stage founders should appoint the MLRO before the first live transaction, not at the point of licence application.
How do regulators audit crypto AML programs?
Regulators in the leading hubs – including ESMA's national competent authorities under MiCA, VARA in Dubai and the FCA in the UK – audit crypto AML programs by examining the written policy, the risk assessment, the alert log, the MLRO decision records and the Travel Rule data architecture. Inspectors look for evidence that the program is operational, not merely documented. A policy that exists in writing but is not reflected in actual alert dispositions and transaction data is a finding. The audit trail – from list update through alert triage through MLRO sign-off – must be retrievable and coherent.
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, sanctions screening and Travel Rule programs that regulators inspect. Digital assets are the whole of our practice. We map the licence stack, the compliance architecture and the banking across operating, custody and payment layers as one mandate – not three disconnected workstreams. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design, sanctions screening architecture and Travel Rule implementation for early-stage and growth-stage virtual 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.