Sanctions screening for digital-asset businesses is not simply a matter of checking a name against a list. For any firm operating across borders – an exchange routing orders through multiple liquidity venues, a custodian holding assets for institutional clients in different regulatory zones, a payments layer processing stablecoin transfers at scale – the screening obligation is structural. It runs through entity design, wallet policy, transaction monitoring architecture and the Travel Rule (the obligation to pass originator and beneficiary data with a transfer). Get the structure wrong and the compliance program fails before the first suspicious transaction is filed.
With VASP supervision tightening across the major hubs and sanctions regimes expanding to cover digital-asset activity directly, the cost of a structural gap is not an administrative fine. It is a frozen correspondent banking relationship, a regulatory licence suspension or – at the extreme – a criminal referral. In our practice, we regularly advise firms that built technically capable screening tools and then discovered the tools were pointed at the wrong layer of the business. The problem was never the software. It was the architecture.
This analysis works through the structuring question from first principles: what the applicable regimes require, where the cross-border tension sits, how a decision matrix for screening architecture should be built, and what the common failure modes look like in practice.
Why Sanctions Screening Is a Structural Question, Not a Vendor Question
Effective sanctions screening in crypto begins with a clear answer to one question: which legal entity, in which jurisdiction, bears the compliance obligation at each point in the transaction flow. The answer is rarely a single entity. A group with a CASP authorisation under MiCA for EU customer onboarding, a VARA-licensed entity in Dubai for regional distribution, and an offshore custody vehicle will carry overlapping – and sometimes conflicting – screening obligations derived from three separate regulatory regimes.
The FATF framework, including Recommendation 15 on virtual assets, establishes the baseline. Every jurisdiction that has implemented the FATF standards – which now covers most financial-action-task-force member states – requires virtual asset service providers (VASPs, the class of business that transfers, exchanges or otherwise deals in virtual assets for others) to screen counterparties against applicable sanctions lists. But the lists themselves differ. The EU Consolidated List administered through ESMA-aligned national competent authorities, the US OFAC SDN List administered through the Department of the Treasury, the UK Consolidated Sanctions List maintained by the FCA's supervisory peers, and the UAE lists published under VARA's regulatory regime do not always match. A wallet address sanctioned by OFAC may not yet carry an equivalent designation in the EU regime.
The structuring challenge is therefore: build a compliance architecture that satisfies the most demanding applicable regime at each transaction layer, without creating an unworkable operational bottleneck. Operators we advise routinely discover this requires a layered entity map, not a single compliance function.
Which Regimes Govern – and How They Interact
The screening obligation for a crypto firm derives from the regulatory regime that governs its licensed activities, overlaid by the sanctions jurisdiction of the currencies it moves and the location of its counterparties. These are not the same analysis.
Under MiCA, an authorised CASP is subject to the EU's AML framework as applied to crypto-asset service providers. The relevant national competent authority – for example, the Bank of Lithuania for a Lithuania-registered entity, or the MFSA in Malta – supervises AML/CFT obligations including sanctions screening. The EU's AML framework follows a risk-based approach: screening must be commensurate with the risk profile of the business, the customer base and the asset classes handled. For a euro-denominated stablecoin payments operator, that risk profile is high by default.
In the UAE, VARA's rulebooks impose express screening requirements on licensed entities operating in mainland Dubai. These obligations run in parallel with the UAE's own sanctions regime, which includes lists published by the UAE Executive Office for Control and Non-Proliferation. A VARA-licensed exchange must therefore screen against both UAE-specific lists and, if it also moves USDT or USDC at any point, the practical reach of OFAC. The reason is operational: Tether and Circle hold contract-level freeze and blacklist authority over their issued tokens, and both issuers generally act on OFAC designations. An exchange that routes sanctioned addresses through its order book, even inadvertently, may find those positions frozen at the token layer before the compliance team has flagged the transaction.
In Singapore, the Monetary Authority of Singapore's Payment Services Act regime applies its own AML/CFT notices to Digital Payment Token service licensees. The MAS notices require screening against Singapore's domestic sanctions list and extend to beneficial ownership verification for counterparty wallets where risk indicators are present. For a firm holding both an MAS licence and a CASP authorisation, the obligation to screen runs concurrently across both regimes – and the data retention requirements differ.
The practical implication is this: a firm operating across even two of these regimes cannot run a single undifferentiated screening pass. It needs entity-level mapping of which screen applies at which step, who owns the obligation, and how conflicts are resolved when the lists diverge.
Contact OBOLUS at info@oboluslaw.com for a scoped assessment of your sanctions architecture across operating jurisdictions. The process above describes the standard path. Your facts – the entity structure, the user base, the asset classes – change the analysis. Map your options.
The Travel Rule and Sanctions: The Data Intersection
The Travel Rule creates a data flow that is simultaneously the most powerful sanctions-screening tool available to VASPs and the most legally complex to implement across jurisdictions. Under the FATF-derived Travel Rule obligation, a VASP initiating a transfer must collect, verify and transmit originator and beneficiary data to the receiving VASP. At the moment of transmission, both VASPs are in possession of the counterparty's identity – which is precisely the data required to run a meaningful sanctions screen.
The structural problem is that Travel Rule implementation is uneven. The EU's AML-framework provisions, the Singapore MAS notices, the FCA's MLR-based expectations and the VARA rulebooks all impose Travel Rule obligations, but the de-minimis thresholds, the data fields required and the technical messaging protocols accepted differ across these regimes. A transfer that is below the threshold triggering the Travel Rule in one jurisdiction may be above it in another. Where the originating and receiving VASPs sit in different jurisdictions with different threshold levels, the question of which rule governs the data-sharing requirement is genuinely contested.
In our cross-border practice, we have seen this create a specific failure mode: a firm screens all Travel Rule messages that arrive – but receives no Travel Rule message for below-threshold transfers from a counterparty VASP in a lower-threshold jurisdiction. The receiving firm then processes the transfer without a sanctions check on the originator data, because the data was never transmitted. The solution is not to wait for data that may never arrive; it is to build a risk-based supplementary screening obligation at the wallet level, triggered when no Travel Rule message is received within the expected protocol window.
This requires the compliance architecture to treat the absence of a Travel Rule message as a risk signal, not as an operational default. Regulators in the leading hubs increasingly expect this posture in AML program documentation.
Wallet-Level Screening Versus Entity-Level Screening: A Decision Matrix
The question of where to run the primary sanctions screen – at the wallet address level or the counterparty entity level – turns on the business model, the regulatory regime and the asset class. There is no single correct answer, and firms that treat this as an either/or choice typically end up with gaps.
Profile A – Retail Exchange (high volume, pseudonymous counterparties). The primary screening obligation runs at the wallet level on deposit and withdrawal. Entity-level screening runs at onboarding against the customer's verified identity and at periodic review. The risk of a sanctioned address appearing in the wallet pool is meaningful; the blockchain forensics layer – using tools such as those provided by the forensics community – assigns risk scores by address history and cluster. A transfer flagged by forensics but not on a named sanctions list still warrants enhanced-due-diligence review before processing. The MiCA CASP authorisation and VARA rulebooks both contemplate this layered approach.
Profile B – Institutional Custody (lower volume, identified counterparties). Entity-level screening dominates. Counterparties are verified legal entities with disclosed beneficial owners. Wallet screening supplements rather than leads. The key structural issue is that the custody entity may hold assets on behalf of a fund that in turn holds interests for underlying investors; a beneficial-ownership chain that passes through an opaque vehicle without look-through creates a sanctions gap at the sub-fund level. Regulated custody under the FSRA in ADGM or under the SFC in Hong Kong requires documented look-through procedures.
Profile C – Stablecoin Payments Layer (real-time, cross-border, high-frequency). Both layers must run in near-real time. Entity-level screening at counterparty onboarding, wallet-level screening at each transfer, and Travel Rule message screening for originator data all operate simultaneously. The operational challenge is latency: a synchronous sanctions hold on a stablecoin transfer that is expected to settle in seconds creates a customer-experience and liquidity problem. The architecture question is whether to run asynchronous screening with a hold-and-release mechanism or to front-load screening to the session initiation. The answer depends on the applicable regulatory expectation and the firm's risk appetite.
Profile D – DeFi Protocol Interface / Aggregator. The most contested profile. Where a business provides a front-end interface to on-chain liquidity – without holding client assets or acting as a counterparty – the extent of the sanctions screening obligation is jurisdiction-specific and subject to ongoing regulatory development. Under MiCA, a CASP providing exchange services is clearly in scope. An interface that merely routes transactions without custodying assets sits in a grey zone that the relevant national competent authorities have not uniformly resolved. In our practice, we advise erring toward coverage rather than relying on an exclusion that has not been formally confirmed by the relevant regulator.
The Cross-Border Conflict: When Two Regimes Disagree
A firm holding licences in two jurisdictions whose sanctions regimes conflict faces a genuine legal dilemma. A customer that is not designated under the EU Consolidated List but is an OFAC-designated person cannot be lawfully served by the firm's US-dollar-touching activities – even if the firm has no US nexus in a corporate-law sense. OFAC's secondary-sanctions reach extends to non-US persons dealing in US-dollar-denominated assets or using US correspondent banks, and stablecoins pegged to the US dollar bring that reach directly into any business that moves them.
The structural response, which we have developed with operators across multiple licensing jurisdictions, is a regime-priority map: for each transaction type, a documented rule specifying which sanctions list governs when the lists conflict. The general principle – state the most restrictive applicable list as the controlling standard – is easy to articulate but difficult to operationalize when transaction speeds are measured in seconds.
One practical approach is to build a unified sanctions database that aggregates all applicable lists and screens against the union rather than any single list. This overcomplies relative to any single regime's minimum requirement but eliminates the conflict entirely at the transaction level. The cost is a higher false-positive rate. Managing that rate requires a fast-turnaround human review process – the function of the firm's MLRO (Money Laundering Reporting Officer) and the compliance team sitting behind the automated layer.
In a recent matter, a payments company operating across an EU CASP authorisation and a Gulf-jurisdiction licence encountered precisely this conflict when a counterparty VASP appeared on a newly issued US designation list but not on the EU list. The firm had no protocol for the inter-regime conflict and processed the transfer. The resulting regulatory inquiry required a full retrospective AML review and a remediation plan filed with the relevant competent authority. The cost – in management time, legal fees and supervisory goodwill – substantially exceeded what a documented conflict-resolution protocol would have required to build.
If your cross-border structure has not been stress-tested against a sanctions-list conflict scenario, write to OBOLUS at info@oboluslaw.com. A prior gap in your AML architecture is not disqualifying – but it does require a documented remediation path. Map your options.
The MLRO Function in a Multi-Entity Group
Each regulated entity in a multi-jurisdiction group typically requires its own locally appointed MLRO, with the authority and resource to discharge the obligation in that jurisdiction. This is a structural point that founders and general counsel frequently underestimate when designing the group architecture.
Under the MiCA regime, the CASP authorisation requires a designated AML compliance officer with sufficient seniority, resource and independence. The Bank of Lithuania, the MFSA and other national competent authorities have each set supervisory expectations on the MLRO's authority and reporting lines. A group MLRO based in a non-EU jurisdiction does not automatically satisfy the local requirement for a CASP authorisation in the EU.
In practice, this creates a choice: appoint a local MLRO in each licensed entity (resource-intensive but regulatory-clean), or appoint a single group MLRO and document a delegation and reporting structure that satisfies each applicable regime. The second path is achievable – and is the model used by many well-run multi-jurisdictional groups – but requires careful legal documentation and regulator engagement at the outset.
The MLRO's role in sanctions compliance goes beyond oversight. In a fast-moving sanctions environment, the MLRO must have authority to freeze outgoing transfers pending a sanctions review, to escalate to senior management, and to make voluntary disclosures to the relevant financial intelligence unit without management interference. Building that authority into the group structure before a crisis arises is the difference between a firm that manages a sanctions hit and one that compounds it.
Common Mistakes in Crypto Sanctions Architecture
The most consequential structural errors in crypto sanctions compliance are not technical failures. They are design failures that no amount of software can fix after the fact.
The first is screening at the wrong layer. A firm that screens customer identities at onboarding but not at the wallet or transfer level will miss a sanctioned address that appears post-onboarding – through a wallet-address change, a counterparty substitution or a new OFAC designation issued after the customer relationship began. The compliance obligation is continuous, not point-in-time.
The second is failing to screen the Travel Rule data itself. When a VASP receives a Travel Rule message containing originator or beneficiary information, that data is a fresh set of identity fields that must be screened before the transfer is processed. In our practice, we have reviewed AML programs that screened incoming wallet addresses but processed Travel Rule messages without running the embedded name fields against the sanctions lists. The omission is not obvious at the program-design stage, which is why it recurs.
The third is relying on a single commercial screening tool without a documented calibration policy. Screening tools use fuzzy matching and risk-scoring algorithms. The threshold at which a match is flagged for human review is a compliance decision, not a vendor default. A firm that accepts the vendor's out-of-the-box threshold without testing it against its own customer population and sanctions-list composition has outsourced a regulatory judgment to a software vendor. Regulators under MiCA, the VARA rulebooks and the MAS AML notices increasingly expect documented evidence that the threshold was set deliberately and reviewed periodically.
The fourth – and the one that creates the most acute cross-border legal exposure – is the assumption addressed in the following section.
Objection: A Single Offshore Licence Is Enough to Serve Clients Globally
A common assumption among early-stage crypto businesses is that a BVI VASP registration or a Cayman CIMA licence covers global operations from a sanctions-compliance standpoint. It does not. It never has.
An offshore registration satisfies the registration requirement of the BVI Financial Services Commission or the Cayman Islands Monetary Authority in respect of that entity's activities within those regimes. It does not substitute for the AML/sanctions-screening obligations imposed by the regimes where the firm's customers are located, where the firm's banking lives, or where the assets it moves are denominated.
A VASP serving EU customers without a MiCA CASP authorisation is in breach of the MiCA regime, regardless of its offshore registration. A VASP moving USDT without OFAC-compliant screening is exposed to US secondary-sanctions risk, regardless of whether it has any US entity or US customers. A VASP marketing to UK residents without FCA registration under the Money Laundering Regulations is in breach of UK financial-promotion rules.
The sanctions dimension compounds the licensing dimension. An offshore entity with thin compliance infrastructure – a nominal MLRO, a generic AML policy, a screening tool set to a low-sensitivity threshold – is precisely the structure that FATF grey-listing scrutiny and correspondent bank de-risking decisions are designed to pressure. When the banking relationship is withdrawn, the firm discovers that the offshore licence did not protect the operating account.
We map the licence, banking and compliance stack across operating, custody and payment layers before a client commits to a structure. That process surfaces the conflicts between regimes – and the pressure points where a sanctions event would have the most acute operational impact – before they become enforcement matters.
Self-Assessment Checklist for Sanctions Architecture
The following questions are not legal advice for your specific situation. They are the questions a competent regulator will ask on a supervisory visit. If your compliance team cannot answer each of them clearly and with documented evidence, the gap is structural rather than operational.
- Has your firm produced a written entity-level map of which sanctions regimes apply to which entity and which transaction type?
- Is the primary sanctions screen run at wallet level, entity level, or both – and is that decision documented with a risk-basis rationale?
- Does your Travel Rule workflow include a sanctions screen on the originator and beneficiary data fields in each incoming message?
- Is the screening tool's match-threshold setting documented, with evidence of periodic review by the MLRO?
- Does your inter-regime conflict protocol specify which list governs when the EU, US and UAE lists diverge on a given designation?
- Does the MLRO have documented authority to freeze a transfer unilaterally, without management approval, pending a sanctions review?
- Has the beneficial-ownership chain for institutional counterparties been verified to a level that a regulator in your most demanding licensing jurisdiction would accept?
- Are sanctions screening logs retained for the period required by the most demanding applicable regime – not the shortest one?
In our cross-border practice, a firm that can answer all eight of these questions with documentary evidence is in a materially stronger position than one that answers them verbally and then looks for the policy document.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – the practice overview covering the full compliance, KYC and AML framework for VASPs.
- Regulator AML audit defence – the structuring angle – analysis of how to prepare for and respond to a supervisory AML review.
- Sanctions screening for regulated entities – the service page for scoped sanctions-architecture engagements.
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 initiating a transfer to collect verified originator information and the beneficiary's identity, and to transmit that data to the receiving VASP before or alongside the transfer. The specific data fields required and the de-minimis threshold above which the obligation is triggered vary by jurisdiction. The receiving VASP must also screen the transmitted data before processing. Compliance requires both a technical messaging solution and a sanctions-screening step applied to the transmitted identity fields.
Who must act as MLRO for a crypto firm?
Each regulated entity in a crypto group typically requires a locally appointed Money Laundering Reporting Officer (MLRO) with documented seniority, independence and resource sufficient to discharge the obligation under the applicable regime. Under MiCA's CASP authorisation, the national competent authority – such as the Bank of Lithuania or the MFSA – supervises the MLRO function. Under VARA in Dubai and the MAS Payment Services Act in Singapore, equivalent senior compliance officer obligations apply. A group MLRO based in a non-regulated jurisdiction does not automatically satisfy a local statutory appointment requirement. The MLRO's authority to freeze transfers and make disclosures must be documented in the firm's compliance structure.
How do regulators audit crypto AML programs?
Supervisory AML audits of crypto firms – whether conducted by a national competent authority under MiCA, VARA, the FCA, or MAS – typically review: the firm's written AML/CFT policy and its alignment with the applicable regime; the calibration and testing record for screening tools; Travel Rule implementation and data-transmission logs; MLRO authority and escalation records; suspicious activity reporting; and beneficial-ownership verification for higher-risk counterparties. Regulators increasingly expect documented evidence of periodic testing, not just the existence of a policy. A gap between the written program and the operational record is the most common finding in supervisory reviews we have seen in practice.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across more than 70 jurisdictions, on disputes and on-chain asset recovery across more than 25 forums, and on the tax, banking and compliance obligations that sit around them. Digital assets are the whole of our practice. We map the licence, banking and compliance stack across operating, custody and payment layers before you commit – surfacing sanctions and AML structural gaps before they become enforcement matters. We advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialising in compliance architecture, Travel Rule implementation and sanctions-screening structures for cross-border 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.