A crypto exchange operating across multiple time zones can trigger sanctions liability in a jurisdiction where it holds no licence, employs no staff and has never opened a bank account. That is the defining risk of the current environment. Sanctions exposure for digital-asset businesses does not map onto the geography of corporate presence – it maps onto the geography of transaction flow, user location and counterparty identity. Under the FATF Recommendations (the international AML/CFT standards), virtual asset service providers are expected to screen against sanctions lists as a baseline obligation, not an optional enhancement. The analysis that follows examines how that obligation operates across borders, where the legal gaps emerge and how a cross-border operator structures its response.
Why Is Sanctions Risk Structurally Different for Crypto Businesses?
Sanctions exposure in digital-asset businesses is structurally different from exposure in traditional finance because the asset moves before the compliance check can block it. In conventional payment rails, a correspondent bank sits between sender and receiver and can freeze the transaction in transit. In most blockchain environments, a transaction confirmed on-chain is irreversible – the asset has moved before any post-hoc freeze can act. That asymmetry makes pre-transaction screening not just best practice but the only effective intervention point.
The second structural difference is pseudonymity. A blockchain address is not a name. Connecting a wallet to a sanctioned party requires either a prior KYC (know-your-customer) process that mapped the address to an identity, or on-chain analytics that trace behavioral patterns back to a known entity. Regulators – including OFAC in the United States, the Office of Financial Sanctions Implementation in the United Kingdom and the relevant national competent authorities under the MiCA regime in the European Union – increasingly expect both layers to be in place simultaneously.
Third, the perimeter of potential sanctions liability extends far beyond the operator's registered address. A Dubai-based exchange using a European banking rail, serving users in Asia, and settling in USD stablecoins is simultaneously in scope of VARA oversight, FCA financial-promotion rules, ESMA MiCA expectations and OFAC's extra-territorial reach. Each of those authorities can initiate enforcement. None waits for the others.
The core principle under FATF Recommendation 15 is that virtual asset service providers must apply AML/CFT measures – including sanctions screening – equivalent to those applied by regulated financial institutions. That standard has now been implemented, with varying degrees of rigour, across the leading licensing jurisdictions.
Operators we advise routinely discover that the live sanctions lists they screen against – OFAC SDN, UN Consolidated, EU Consolidated, HM Treasury – are updated on an irregular schedule, sometimes within hours of a geopolitical event. A static list uploaded monthly is not a compliant program. Dynamic, real-time or near-real-time integration with official list feeds is now a baseline expectation in most flagship regimes.
Which Regulatory Regimes Create Direct Sanctions Obligations for VASPs?
Direct sanctions obligations for crypto businesses arise under a combination of primary sanctions law, AML licensing conditions and, increasingly, specific VASP regulatory frameworks in each jurisdiction. The precise obligations differ, but several regimes are consistently relevant for any cross-border operator.
In the United States, OFAC (the Office of Foreign Assets Control) administers the primary federal sanctions program. Its reach is not limited to US-licensed entities. Any transaction that touches USD – including USD-denominated stablecoins issued by US-regulated entities such as Circle (USDC) or Tether (USDT) – brings the transacting parties within OFAC's practical jurisdiction. OFAC has issued specific guidance on digital assets and the expectation that VASPs screen wallet addresses against the SDN List. FinCEN (the Financial Crimes Enforcement Network) separately enforces AML program and suspicious-activity reporting requirements under the Bank Secrecy Act framework, which applies to money-services businesses including crypto businesses with a US nexus.
In the European Union, the MiCA regime administered by ESMA and national competent authorities requires authorised CASPs (crypto-asset service providers) to maintain AML programs that comply with the EU's fourth and fifth Anti-Money Laundering Directives, as subsequently updated. Those directives incorporate EU Consolidated sanctions list screening. The CASP passporting mechanism – which allows a MiCA-authorised entity to operate across all EU and EEA member states – does not reduce the sanctions obligation; it extends it to every member state's enforcement authority.
In Dubai, VARA's rulebooks require licensed virtual asset businesses to screen against both UAE Central Bank sanctions designations and OFAC designations, reflecting the UAE's own FATF mutual evaluation commitments and the presence of significant USD transaction flow through UAE-based operators.
In Singapore, the MAS Payment Services Act regime imposes AML/CFT obligations on licensed digital payment token service providers that include sanctions screening under the MAS Notice on Prevention of Money Laundering and Countering the Financing of Terrorism. The SFC in Hong Kong imposes equivalent obligations on licensed VATPs (virtual asset trading platforms) under its VASP licensing regime.
In our cross-border practice, we consistently find that operators who have a single licensing anchor – say, a MiCA CASP in Lithuania – underestimate the reach of OFAC and the FCA's financial-promotion and AML rules when their user base or transaction flow has a US or UK dimension. The anchor licence defines the home-state regulatory relationship. It does not immunise against every other regime's enforcement reach.
How Does the Travel Rule Interact with Sanctions Screening?
The Travel Rule (the obligation, derived from FATF Recommendation 16, to pass originator and beneficiary identity data alongside a virtual-asset transfer) is both an AML tool and a de facto sanctions-screening mechanism. When a VASP sends a transfer to a counterparty VASP, the Travel Rule requires the sending VASP to transmit the originator's name, account number and address, and the beneficiary's name and account number. The receiving VASP must then screen that data against sanctions lists before making the funds available.
The interaction creates a dual chokepoint. At the sending end, the originator's address and identity are screened before the transfer is initiated. At the receiving end, the transmitted data is screened against the receiving VASP's own lists. A gap in either program creates liability – at the sending end for transmitting a transaction on behalf of a sanctioned party, and at the receiving end for receiving and crediting funds with a sanctioned nexus.
The practical complication is the "sunrise problem." Not every jurisdiction has implemented the Travel Rule on the same schedule. A VASP operating in a jurisdiction that has implemented the rule sends data. A counterparty VASP in a jurisdiction that has not yet fully implemented the rule may not be equipped to receive, parse or screen that data. The sending VASP cannot control the counterparty's compliance posture. What it can control is its own counterparty-VASP due-diligence framework – specifically, whether it has assessed the receiving VASP's AML maturity before routing transfers through it.
Regulators in the leading hubs increasingly expect a formal counterparty-VASP onboarding process: a due-diligence questionnaire, an assessment of the counterparty's AML program, a review of its licensing status and a periodic re-assessment. Where a counterparty operates in a jurisdiction with materially weaker AML standards, enhanced due diligence is typically expected before the relationship proceeds.
In our practice, we have seen Travel-Rule compliance programs that correctly implement the data-transfer mechanics but fail to integrate the output with the live sanctions screening engine. The data arrives, is stored and is never screened. That disconnect is exactly the gap regulators flag in supervisory reviews.
CTA #1: The interaction between the Travel Rule and live sanctions screening is a common gap in otherwise well-structured compliance programs. Map your options with OBOLUS before a supervisory review identifies the disconnect. For a scoped assessment of your current AML architecture, contact OBOLUS at info@oboluslaw.com.
Where Do Cross-border Operators Face the Highest Gap Risk?
Cross-border operators face the highest sanctions-gap risk at the intersection of multiple regimes whose screening expectations differ in timing, list composition and enforcement posture. Four intersection points arise most frequently in practice.
The first is the USD stablecoin channel. A non-US operator routing transactions in USDT or USDC is processing value that moves on blockchain infrastructure where Tether and Circle respectively hold contract-level freeze authority. Both issuers generally act on court order, law-enforcement request or OFAC designation. That means a transaction that clears the non-US operator's own screens can still be frozen at the stablecoin-issuer level if OFAC has designated the counterparty address after the operator's last list update. The operator has clean internal records but the customer cannot access the funds. That gap creates both a client-relationship crisis and a regulatory-reporting obligation.
The second intersection is the unhosted-wallet interface. When a user withdraws funds to a self-custodied wallet, the VASP loses direct visibility of the downstream destination. FATF guidance and most major-hub regulators expect enhanced due diligence for transfers to or from unhosted wallets above a threshold amount. The specific threshold varies by jurisdiction and is set in the applicable regime's implementing rules – operators should consult those rules directly rather than relying on a generic cross-border standard. What is consistent across regimes is the principle: the VASP must be able to establish the beneficial ownership of the unhosted wallet with reasonable confidence before processing a material transfer.
The third intersection is the peer-to-peer or DeFi layer. When a licensed VASP provides a gateway into decentralised protocols, the legal question is whether the VASP is processing a transaction on behalf of the user – and therefore in scope of sanctions screening – or merely providing an interface. Regulators in the United States, the EU and Singapore have each signalled that the determination turns on the degree of control the VASP exercises over the transaction, not on the label the VASP attaches to the service. A "non-custodial" interface that routes transactions through smart contracts the VASP deployed or controls is likely in scope.
The fourth intersection is the correspondent banking relationship. A VASP that banks in one jurisdiction but serves users in another is subject to the AML expectations of both the banking jurisdiction and the service jurisdiction. Banks applying their own enhanced-due-diligence frameworks to crypto-business clients will often ask for evidence of a robust sanctions-screening program as a condition of account maintenance. Failure to demonstrate that program to the bank's satisfaction can result in account closure, which is effectively a de-banking event – even where the VASP holds a valid licence.
Decision Matrix: How Should Different Operator Profiles Structure Their Response?
No single compliance architecture fits every operator profile. The right structure turns on the entity's licensing anchor, its user geography, the asset types it handles and the fiat channels it relies on.
Profile A – a MiCA-authorised CASP with EU users and USD stablecoin settlement: This operator is subject to EU Consolidated list screening under its CASP obligations and to OFAC's practical reach through the stablecoin channel. The architecture should include real-time OFAC SDN screening on every outbound and inbound transfer, a stablecoin-specific risk policy that addresses the freeze-authority gap, and a Travel-Rule solution that integrates with both the EU AML regime's data requirements and OFAC's address-screening expectations. The indicative setup timeline for a programme of this scope is a matter of several months. The key risk is the gap between CASP authorisation and full OFAC integration – typically underestimated.
Profile B – a VARA-licensed exchange in Dubai serving MENA users, banking in UAE: This operator is subject to VARA rulebook requirements, UAE Central Bank sanctions designations and OFAC's reach on USD flows. The AML architecture must integrate UAE-specific sanctions lists alongside the international lists. An additional layer of complexity arises if the user base includes nationals of jurisdictions subject to targeted sanctions – the VASP must document its screening rationale and its decision to serve or not serve users from those jurisdictions. Timeline to a compliant programme is broadly comparable to Profile A, though the VARA supervisory process has specific documentation requirements. The key risk is assuming that UAE licensing resolves OFAC exposure.
Profile C – a BVI-registered entity operating a global token-trading platform: The BVI FSC's VASP Act 2022 imposes AML obligations including sanctions screening. But the primary risk for this profile is extraterritorial reach from the US (OFAC, FinCEN) and the EU (MiCA, where EU users are served). The BVI entity may hold a valid local registration and simultaneously be operating without a required authorisation in the EU or the US if its services reach those markets. Sanctions exposure is therefore compounded by the licensing gap – an enforcement action on sanctions grounds in the US or EU can follow the transaction flow, not the registered address. Indicative risk: high, unless the operator has implemented geo-restriction with technical and legal efficacy.
Profile D – a Singapore MAS-licensed DPT service provider with Asian and US institutional clients: MAS AML/CFT obligations are stringent. The Travel Rule is in force in Singapore. For institutional clients, the KYC framework must reach the ultimate beneficial owners of each client entity. US institutional clients bring OFAC reach directly into the relationship. The architecture here typically requires US legal counsel (or, at a minimum, allied counsel in the US jurisdiction) to assess whether the DPT provider's activities create a US regulatory nexus beyond OFAC screening. The key risk is institutional-client onboarding that meets MAS standards but does not separately assess the US nexus.
What Are the Most Common Structural Mistakes in Crypto Sanctions Programs?
In our cross-border practice, five structural mistakes appear with disproportionate frequency across operator types and jurisdictions.
The first is static list management. Sanctions lists – particularly OFAC's SDN List – are updated without prior notice, often in response to geopolitical events. A program that refreshes its list data daily, weekly or monthly has a window during which a newly designated address can transact freely. Real-time or near-real-time integration with official list feeds is now the expected standard in most flagship regimes.
The second is name-only screening. Screening customer names against sanctions lists without also screening wallet addresses creates a gap that is straightforward to exploit. A sanctioned party operating through an undesignated proxy entity will pass a name-only check. Address screening – using on-chain analytics tools that trace address associations to known sanctioned clusters – closes that gap. The leading forensics tools in the market (Chainalysis, TRM Labs, Elliptic and Asset Reality are names the verified facts registry identifies as operational in this space) are increasingly a compliance baseline expectation, not an advanced feature.
The third is the geographic restriction gap. An operator that geo-blocks users from sanctioned jurisdictions by IP address is applying a control that is circumvented by a VPN in under two minutes. Regulators do not accept IP-block as a sufficient control. The expected standard is a combination of IP screening, KYC data verification (identity document and proof-of-address cross-checked against sanctions risk), payment-method provenance and, for higher-risk users, enhanced due diligence on the source of funds.
The fourth is the lack of a designated MLRO (money laundering reporting officer) with sufficient seniority and real decision-making authority. In most regulated jurisdictions, the MLRO is a legally defined role with personal liability for certain compliance failures. We have seen operators appoint an MLRO who is, in practice, a junior compliance analyst with no access to senior management or the board. When a suspicious-activity report or a sanctions match is identified, the decision chain collapses because the MLRO cannot compel action. That structural failure is itself a regulatory deficiency.
The fifth is the absence of a documented sanctions-breach escalation protocol. Every sanctions program will, eventually, produce a match – whether a true positive, a false positive or a fuzzy match requiring human review. Operators who have not pre-documented what happens next – who is notified, in what timeframe, what transaction action is taken and whether a voluntary disclosure to the relevant authority is required – find themselves making those decisions under time pressure, without legal privilege, and often without counsel. Pre-documenting the escalation protocol is one of the highest-value steps a compliance team can take before a supervisory review.
A Cross-border Sanctions Match: How the Process Unfolded
In a recent matter, a payments company operating under a European AML registration processed a series of outbound USDT transfers to a counterparty wallet. The wallet had not been designated at the time of the initial transaction. Several weeks later, OFAC updated its SDN List to include an address cluster associated with that counterparty. The stablecoin issuer froze the relevant balance on its chain. The payments company had no escalation protocol, no record of having screened the wallet against the then-current list at transaction time and no documented rationale for the counterparty relationship. We were engaged to reconstruct the transaction record, prepare a voluntary-disclosure memorandum for submission to the relevant authority and assist with the counterparty-VASP due-diligence program that the company had not previously implemented. The matter resolved without a formal enforcement action, though the process consumed significant management time and required remediation across the entire AML program.
The lesson is not that the operator acted in bad faith. It is that the gap between initial list screening and the post-designation period was unmanaged – and that a documented re-screening program for live counterparty relationships, run on a regular schedule, would have identified the designation before the stablecoin issuer acted.
CTA #2: If your AML program has not been stress-tested against a sanctions-match scenario – or if a prior application stalled due to compliance gaps – a structured review can identify the exposure before it becomes an enforcement event. Map your options with OBOLUS. Write to info@oboluslaw.com or message t.me/oboluslaw.
A Common Assumption: One Offshore Licence Solves the Problem
A common assumption among early-stage digital-asset operators is that a single offshore licence – a BVI registration, a Cayman VASP registration or a Seychelles entity – provides a sufficient compliance umbrella for a globally accessible platform. It does not. The assumption conflates the regulatory relationship with the home-state regulator with the extraterritorial reach of foreign enforcement authorities.
An offshore registration satisfies the requirement to be registered as a VASP in that specific jurisdiction. It does not satisfy the EU's MiCA CASP authorisation requirement for services marketed to EU residents. It does not satisfy the FCA's financial-promotion rules for services marketed to UK users. It does not satisfy OFAC's expectations for any operator transacting in USD or USD-denominated assets. It does not satisfy MAS licensing requirements for services provided to Singapore-resident retail users.
Each of those authorities assesses jurisdiction based on the reach of the service, not the address of the entity. The FATF Recommendations – which underpin most national VASP regulatory frameworks – are explicit that AML obligations attach to the activity, not to the corporate domicile.
The correct architecture for a multi-market operator is a licence stack: the right authorisation in each jurisdiction where the service is actively marketed or where a material user population sits, supported by AML and sanctions programs calibrated to the most demanding of the applicable regimes. That is a more expensive and time-consuming structure to build than a single offshore registration. It is also the structure that survives a regulatory inquiry.
In our cross-border practice, we map the licence, banking and compliance stack before a client commits to a market entry. The exercise almost always surfaces obligations that the client had not anticipated – and identifies the highest-priority ones to address first.
Self-Assessment: Is Your Sanctions Program Fit for Cross-border Operation?
The following checklist reflects the baseline expectations of the leading licensing and enforcement regimes. It is not a substitute for a legal review of your specific program, but it surfaces the gaps that regulators most commonly identify.
- Does your screening engine integrate real-time or near-real-time feeds from every applicable sanctions list – OFAC SDN, UN Consolidated, EU Consolidated, HM Treasury Consolidated, and any jurisdiction-specific lists relevant to your licence anchor?
- Does your screening cover wallet addresses as well as customer names and entity names?
- Does your Travel-Rule solution transmit and receive originator and beneficiary data in a format your screening engine can process?
- Have you conducted formal due diligence on every counterparty VASP – and documented the results?
- Does your MLRO have documented authority to block a transaction, file a suspicious-activity report and escalate to the board without management override?
- Does your escalation protocol address what happens when a sanctions match is identified – including the timeline for regulatory notification and the decision on voluntary disclosure?
- Have you assessed whether your service, regardless of where the entity is registered, is in scope of US OFAC requirements, EU MiCA AML obligations or FCA financial-promotion rules?
- Do you re-screen live counterparty relationships and wallet addresses against updated sanctions lists on a regular documented schedule?
If the answer to any of the above is "no" or "unsure," the gap exists in the program, regardless of the licence held.
Related at OBOLUS
- AML, Travel Rule and Compliance for Digital-Asset Businesses – full practice overview: AML program design, Travel Rule implementation and regulatory engagement across 70+ jurisdictions.
- Transaction Monitoring Setup in Malta – jurisdiction-specific guide to building a compliant transaction-monitoring program under the MFSA framework.
- Staking Service Legal Framework in Seychelles – analysis of the legal and regulatory position for staking service providers operating under Seychelles law.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 16, requires a virtual asset service provider to collect and transmit the originator's name, account identifier and address – along with the beneficiary's name and account identifier – alongside every qualifying virtual-asset transfer. The receiving VASP must screen that data before crediting the funds. The precise de-minimis threshold and data-field requirements vary by jurisdiction and are set in the applicable implementing rules; operators should consult those rules directly.
Who must act as MLRO for a crypto firm?
A money laundering reporting officer (MLRO) in a regulated crypto business is typically a senior individual with direct access to the board and documented authority to block transactions, submit suspicious-activity reports and engage with the regulator. Most leading licensing regimes – including MiCA CASP authorisations, VARA licences and MAS DPT licences – require the MLRO to be approved or at minimum notified to the regulator. The MLRO carries personal regulatory and, in some jurisdictions, criminal liability for systemic compliance failures. Delegation to a junior function without genuine authority does not satisfy the requirement.
How do regulators audit crypto AML programs?
Regulators in the leading hubs – including ESMA national competent authorities under MiCA, VARA in Dubai, MAS in Singapore and the FCA in the UK – audit AML programs through a combination of supervisory questionnaires, on-site inspections and document requests. They typically assess the adequacy of the policy framework, the effectiveness of the transaction-monitoring and sanctions-screening systems, the MLRO's authority and the quality of suspicious-activity reporting. Gaps in documentation, static list management or a lack of genuine MLRO authority consistently attract adverse findings.
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 architecture that sits around them. Digital assets are the whole of our practice. We map the licence, banking and AML stack across operating, custody and payment layers before clients commit to a structure – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when things go wrong. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design, sanctions-screening architecture and cross-border VASP regulatory compliance.
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.