Crypto businesses operating across borders face a sanctions compliance environment that is both technically complex and rapidly tightening. A virtual asset service provider (VASP) that clears a counterparty through one regulator's screening list and ignores three others is not compliant – it is exposed. Sanctions screening for crypto is not a software problem; it is a legal architecture problem that boards must own. This analysis sets out the contrasting regulatory positions, the cross-border friction points, and the practical lessons that separate programs that hold up under audit from those that collapse under enforcement.
Why Boards Own the Sanctions Problem – Not Just Compliance
Sanctions liability in digital-asset businesses attaches at the entity level, not just the compliance desk. Under the OFAC (Office of Foreign Assets Control) regime in the United States, a strict-liability standard applies: a transaction that touches a sanctioned address or a designated counterparty creates exposure regardless of intent. The FCA (Financial Conduct Authority) in the United Kingdom takes a similar posture under its financial-crime framework, expecting board-level accountability for sanctions governance. ESMA and national competent authorities implementing MiCA are building the same expectation into the CASP authorisation framework: a senior manager must own financial-crime risk.
In our practice, we consistently find that boards underestimate the surface area. A VASP is not screening one list. It is managing exposure across OFAC's SDN list, the EU consolidated sanctions list, the UK financial sanctions register, and – depending on where its banking relationships sit – additional lists maintained by the UAE, Singapore's MAS, and others. Each list has different update cadences. Each has different de-listing procedures. Running a single consolidated screening tool without a protocol for resolving conflicts between lists is a governance gap that regulators notice.
The cross-border reality compounds this. A European entity with custody infrastructure in the ADGM may be subject to FSRA expectations on top of EU obligations. A firm licensed under VARA in Dubai and banking in Singapore sits simultaneously under VARA rulebook requirements, MAS payment-services expectations, and – if it touches US-dollar settlement rails – OFAC's strict-liability standard. That overlap is not theoretical. We see it in every cross-border structuring mandate we advise on.
The first practical lesson for boards is structural: sanctions screening must be governed as a multi-list, multi-jurisdiction obligation with a named senior individual who owns the gap analysis. A compliance officer who screens against one list and escalates to no one is not a governance structure.
To map which sanctions regimes apply to your current structure, contact OBOLUS at info@oboluslaw.com. The process above describes the standard multi-jurisdiction stack. Your facts – the entity domicile, the user base's geography, the banking rails – change the analysis materially. Map your options before the audit arrives.
What the Regulatory Patchwork Actually Looks Like in 2025
No single global sanctions authority governs digital assets, and that absence of harmonization is itself a compliance risk. The FATF's Recommendation 15 – which extends AML/CFT obligations to virtual assets and VASPs – provides a baseline, but FATF is a standard-setter, not an enforcer. Enforcement is domestic, and the domestic regimes diverge on important details.
In the United States, FinCEN governs AML obligations for money-services businesses, while OFAC holds the sanctions mandate. The two agencies coordinate but operate under different legal standards. FinCEN's rule-based AML program requires risk-based screening; OFAC's strict liability standard requires comprehensive screening, full stop. A crypto firm that treats sanctions as just another AML sub-process has miscategorized the risk.
Under MiCA, the EU's CASP regime tasks national competent authorities with supervising AML programs. The underlying AML obligation derives from the EU's Anti-Money Laundering Directives, now transitioning to a directly applicable AML Regulation. ESMA has issued guidance on supervisory convergence, but the practical standard varies between member states. A CASP passporting from Lithuania will face different supervisory intensity in the Netherlands than at home. Boards need to understand that a MiCA passport opens markets; it does not homogenize the AML expectation.
VARA's rulebooks in Dubai take a particularly granular approach. Each licensed activity carries its own compliance obligations, and the VARA framework expects real-time transaction monitoring alongside sanctions screening – not an end-of-day batch process. The FCA's MLR registration regime in the UK, now one of the more demanding onboarding processes in the world, similarly expects evidence of live monitoring capability, not just policy documentation.
In our practice, the businesses that perform best in regulatory examinations are those that have mapped each jurisdiction's screening expectation against a single master obligation matrix, then built their technical stack to satisfy the most demanding requirement. That approach is more expensive to build. It is far less expensive than a remediation order.
How the Travel Rule Intersects with Sanctions Screening
The Travel Rule – the obligation to pass originator and beneficiary data with a virtual-asset transfer – creates a direct feed into sanctions screening that many compliance programs handle poorly. The mechanics are straightforward in principle: when a VASP sends a transfer, it must transmit identifying information about the originator; when it receives one, it must obtain information about the beneficiary. That information is then the primary input for sanctions screening at the counterparty level.
The failure mode is a sequencing error: releasing or completing a transfer before the Travel Rule data has been received and screened. Under the FATF standard, the obligation applies to transfers at or above the applicable threshold in each jurisdiction. That threshold varies – a fact the registry records as jurisdiction-specific and requiring current verification – but the principle does not. Transfers that move faster than the compliance workflow are sanctions exposure in motion.
The technical challenge is real. Travel Rule data passes between VASPs using emerging messaging protocols – IVMS101 being the widely adopted data standard – but not all counterparty VASPs are on the same platform. A transfer to an unhosted wallet adds another layer: the beneficiary is not a VASP at all, which means no automated data exchange exists. The VASP must collect and verify beneficiary information through another channel. Regulators under both the VARA framework and the FCA's MLR expectations have signaled that "the counterparty didn't support Travel Rule messaging" is not a defense.
In cross-border transfers, the intersection of Travel Rule data and sanctions screening also raises a data-protection tension. Transmitting personal data about a European data subject to a counterparty VASP in a third country may engage the GDPR's transfer restrictions. That conflict between AML obligations and data-protection obligations is not resolved at the regulatory level; it must be managed at the program level. Operators we advise build a data-minimization protocol that satisfies the Travel Rule floor while limiting the personal data transmitted to what is strictly necessary.
What Screening Technology Can and Cannot Do
Blockchain analytics tools – including platforms widely used in the market for address-risk scoring – are necessary but not sufficient for a defensible sanctions program. Their output is probabilistic. An address may receive a medium-risk score because it transacted two hops from a flagged cluster, not because the address holder is a designated person. Acting mechanically on a risk score without a human review process creates two simultaneous problems: over-blocking legitimate customers and under-investigating genuine red flags.
Regulators in the leading hubs increasingly expect documented decision logic behind every screening action. The MAS in Singapore, the FCA in the UK, and VARA in Dubai have each, in their published guidance and supervisory communications, moved toward an outcomes-based standard. The question is not whether you ran the address through a tool. The question is whether your firm understood what the tool returned and acted proportionately.
Address-screening tools also have a coverage problem: they work on addresses that exist. A sanctioned actor using a freshly generated wallet – or routing through a privacy-enhancing protocol – will not appear on any existing flag list. This is why sanctions programs must layer address screening with counterparty-level screening (name, entity, jurisdiction), behavioral transaction monitoring, and, in high-risk corridors, enhanced due diligence on the economic purpose of the transaction. No single tool covers all four layers.
The micro-matter below illustrates what a layered program catches that a single-tool program misses.
In a recent compliance review, a digital-asset exchange had deployed address-screening software but relied entirely on its output for sanctions clearance. In a matter that came to our attention earlier this year, a cluster of transactions passed the address screen because the wallets involved were new. However, a behavioral monitoring review – triggered by an unusual pattern of inbound stablecoin movements – identified a connection to a jurisdiction subject to comprehensive sanctions. The exchange had no protocol for escalating behavioral flags to its sanctions team. We assisted in building the escalation matrix and the documented decision log that the regulator subsequently reviewed. No enforcement action followed. The lesson: a program with a single control layer is not a program.
Contrasting Jurisdictional Approaches: Where the Tensions Are Sharpest
The sharpest compliance tension for a cross-border VASP is the gap between the OFAC strict-liability standard and the risk-based approach adopted by most other jurisdictions. Under a risk-based standard – the model embedded in the FATF recommendations and adopted by MiCA, the MAS regime, and the VARA framework – a proportionate response to a lower-risk transaction is compliant even if it is not exhaustive. Under OFAC's strict-liability standard, proportionality is not a defense.
For a VASP that processes US-dollar-denominated stablecoin transactions, OFAC's standard applies even if the firm has no US entity, no US users, and no US banking relationship. The dollar clearing creates the nexus. Boards need to understand this point precisely: OFAC jurisdiction can attach to a non-US VASP through the currency of the transaction, not just the location of the firm. We have advised on structural decisions – choice of settlement currency, choice of stablecoin issuer – specifically to manage this exposure.
A second tension exists between the EU's AML obligations and the ADGM/FSRA framework in Abu Dhabi. Both are demanding. Both follow a broadly risk-based model. But the FSRA's expectations on customer due diligence for high-value transfers and the EU's AML Regulation's thresholds for enhanced due diligence differ in ways that require a firm to run two parallel CDD protocols for the same transaction type depending on where the counterparty sits. In our cross-border practice, this is one of the most common structural inefficiencies we identify – and one of the most straightforward to fix with a unified CDD policy that satisfies both floors simultaneously.
A third tension is between the BVI FSC's VASP Act expectations and the substance requirements that banking counterparties now apply before opening an account. A BVI-registered VASP may satisfy its domestic regulator's screening expectations. A Tier 1 bank reviewing the same firm's AML program will apply its own internal standard, which often mirrors OFAC and FCA expectations regardless of where the firm is licensed. Boards that treat banking as a downstream problem after licensing is resolved consistently run into this.
If your current structure creates a compliance gap between your licensed jurisdiction and the regimes that govern your banking rails or settlement currency, contact OBOLUS at info@oboluslaw.com. A second read of the structure can surface the conflict and the route to resolution. Map your options before the bank makes that decision for you.
Decision Matrix: Which Profile Faces Which Risk
Sanctions screening risk is not uniform across operator types. The analysis below describes the key profiles, the primary exposure, and the governance priority for each.
A centralized exchange processing high volumes of retail and institutional trades faces its greatest exposure at the withdrawal-request layer. The moment a user initiates an on-chain transfer, the exchange becomes the originating VASP for Travel Rule purposes and must screen the destination address and any available beneficiary information simultaneously. The governance priority is a documented, time-stamped screening log for every outbound transfer, with a clear escalation path for borderline hits. Indicative processing time for a well-built program is measured in seconds at the automated tier; escalated reviews should resolve within a defined service-level window, typically hours.
A custodian holding assets on behalf of institutional clients faces a different profile. The transaction frequency is lower, but the asset values are higher and the counterparty relationships are long-term. The key risk is a change in a customer's sanctions status after onboarding – a designation that occurs mid-relationship. The governance priority is ongoing screening of the entity and its beneficial owners against updated sanctions lists on a defined cadence, not just at onboarding. Relying on the initial KYC screen for a multi-year custody relationship is a recognized supervisory weakness.
A token issuer conducting a public or private offering faces a concentrated screening requirement at the point of allocation. The CASP-equivalent obligations under MiCA and the analogous requirements under the VARA framework both expect that token purchasers are screened before allocation, not after. A whitepaper-based offering that screens investors on a best-efforts basis post-closing is not compliant with either regime. The governance priority is a pre-allocation screening protocol with documented results, integrated into the subscription process.
A DeFi protocol with a front-end operator occupies the most contested part of the regulatory environment. Where a protocol is sufficiently decentralized, the VASP definition may not attach. But the operator of a front-end interface – the entity that deploys the website and controls the user access point – is increasingly in scope. Regulators under MiCA and the VARA framework have signaled that front-end control creates obligations. The governance priority for such a business is a legal opinion on VASP classification before launch, not after a regulator raises the question.
Building a Defensible Sanctions Program: The Board-Level Checklist
A defensible sanctions program is one that survives a regulatory examination, a banking review, and – in the worst case – a civil or criminal inquiry. Building it requires more than technology procurement. It requires governance, documentation, and a tested escalation structure.
The first element is a multi-list screening obligation matrix that maps every jurisdiction where the firm operates, banks, or settles to its applicable sanctions list and update cadence. This is a legal document, not a compliance spreadsheet. It must be maintained and reviewed when the firm's footprint changes.
The second element is a named senior individual ownership structure. A Money Laundering Reporting Officer (MLRO) is the statutory role in most regulated jurisdictions, but the MLRO cannot be the sole accountability point for sanctions. The board must receive a periodic sanctions-risk report that goes beyond AML statistics and addresses the firm's exposure to each sanctions regime it touches.
The third element is a documented decision log for every screening action that results in a hit, a potential match, or a manual override. The log must record who reviewed the result, what information was used, what determination was made, and why. Regulators under the FCA, MAS, and VARA frameworks have all cited the absence of decision documentation as a primary deficiency in enforcement outcomes.
The fourth element is a Travel Rule data-completeness protocol that refuses to release transfers until originator and beneficiary data has been received, validated for format, and screened. The protocol must address the unhosted-wallet scenario and the counterparty-VASP-not-connected scenario with explicit documented procedures, not general guidance.
The fifth element is a periodic testing program – not self-assessment, but adversarial testing. An independent review that runs test transactions, checks escalation workflows, and verifies that the screening output actually reaches a human with authority to act is the only way to know whether the program works. Regulators in the leading hubs are increasingly commissioning their own testing. Boards that test first have the remediation time.
The sixth element is a cross-border gap review conducted whenever the firm adds a new jurisdiction, a new banking relationship, or a new asset type. Each addition may bring a new sanctions regime into scope. The review should be conducted before the change is implemented, not after the first transaction clears.
A Common Assumption the Data Does Not Support
A common assumption among operators building for multiple markets is that licensing in a reputable jurisdiction satisfies the sanctions-screening expectation for all markets where the firm operates. It does not. Licensing determines which regulator has jurisdiction over the firm. Sanctions law determines which screening obligations attach to each transaction. These are different legal questions with different answers, and conflating them is the most consistent governance error we see in cross-border digital-asset businesses.
A related assumption is that a strong KYC framework at onboarding is a substitute for ongoing transaction monitoring and sanctions screening. Regulators explicitly reject this view. Onboarding KYC establishes the identity of the customer at a point in time. Sanctions designations occur continuously. A customer who was clean at onboarding may be designated six months into the relationship. The obligation to detect and respond to that change is ongoing, not a one-time exercise.
The practical consequence of both assumptions is an AML program that performs well during the initial licensing examination and degrades over time as the business grows, the counterparty network expands, and the regulatory environment evolves. The firms we advise that maintain consistently strong compliance records treat the program as a living document subject to a defined review cycle, not a fixed artifact submitted with the licence application.
Related at OBOLUS
- Compliance, AML and Travel Rule for Digital-Asset Businesses – the full practice overview covering AML program design, Travel Rule implementation and ongoing supervisory support.
- KYC and Onboarding Framework: The Structuring Angle – how the legal structure of your entity affects your KYC obligations and what to build before you onboard the first customer.
- Sanctions Screening for Crypto – Service Page for Regulated Entities – scoped advisory mandates for sanctions-program design, gap review and board-level reporting.
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 originator and beneficiary identifying information alongside any virtual-asset transfer at or above the applicable threshold for its jurisdiction. The receiving VASP must obtain and verify that information before completing the transaction. Non-compliance is a primary supervisory concern for regulators under MiCA, the VARA framework, MAS and the FCA. Exact thresholds vary by jurisdiction and should be confirmed against current local legislation.
Who must act as MLRO for a crypto firm?
In most regulated jurisdictions – including under the FCA's MLR regime, the VARA framework, and MiCA's national implementation – a Money Laundering Reporting Officer (MLRO) must be a named, fit-and-proper senior individual approved by or notified to the relevant regulator. The MLRO is accountable for the firm's AML and sanctions program. In a cross-border structure, the firm may need a separate MLRO in each regulated entity. The MLRO cannot be a shared or outsourced function without explicit regulatory permission in the relevant jurisdiction.
How do regulators audit crypto AML programs?
Regulators at the FCA, MAS, VARA and comparable authorities conduct AML examinations through a combination of documentation review, system access, transaction-sample testing, and interviews with the MLRO and senior management. They typically test whether the written program matches the technical implementation, whether screening logs are complete and accurate, and whether escalation procedures have been applied in practice. Firms that fail examinations most often do so not because a policy is missing but because the documentation of actual decisions is absent or inconsistent with the stated policy.
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. We map the compliance, AML and sanctions obligation stack across operating, custody and payment layers before you commit – and we structure those workstreams as one mandate, not three disconnected engagements. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Glen Sorensen, Disputes & Recovery Analyst – specializing in cross-border sanctions exposure, crypto-asset tracing, and the legal architecture of AML programs for regulated 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.