Sanctions Screening for Crypto: Where the Legal Lines Are Drawn

A crypto exchange processes tens of thousands of transactions daily. Somewhere in that flow, a wallet controlled by a designated individual attempts to move funds. The question is not whether the firm has a sanctions policy – it almost certainly does. The question is whether that policy is calibrated precisely enough to catch the transaction, withstand regulatory scrutiny, and hold up if the matter goes to enforcement. Sanctions compliance for digital-asset businesses operates at the intersection of the Travel Rule (the obligation to pass originator and beneficiary data with a transfer), traditional AML frameworks, and on-chain forensics – and getting the calibration wrong draws consequences that move faster than in any other compliance domain. This analysis maps where the legal lines are drawn, where they are still being drawn, and what operators must do now.

Why Sanctions Screening for Crypto Is Categorically Different

Blockchain's pseudonymous architecture means a sanctioned actor does not present as a named person with a passport – they present as an address, and that address may be several hops removed from the original designation. Traditional sanctions screening matches a name against a list. Crypto sanctions screening must also match a wallet against a set of known addresses, trace the provenance of incoming funds, and assess whether a counterparty institution has adequate controls of its own. The two tasks are not equivalent, and regulators know it.

The US Office of Foreign Assets Control (OFAC) was among the first regulators to make this explicit. When OFAC designated the Tornado Cash mixing protocol and associated wallet addresses, it signalled that the relevant unit of analysis is the address, not the legal person – a position that remains legally contested but operationally binding for US-nexus businesses. Separately, the Financial Action Task Force (FATF) Recommendation 15 framework, which underpins most jurisdictions' virtual-asset compliance regimes, treats virtual asset service providers (VASPs) as obliged entities with the same sanctions-screening duties as traditional financial institutions.

The legal consequence is this: a VASP that applies only name-based screening – without address-level checks and without transaction-graph analysis – is, in most leading jurisdictions, operating a materially incomplete program. The gap between nominal compliance and effective compliance is where enforcement actions originate.

OFAC's designation of wallet addresses as sanctioned property has established a cross-jurisdictional precedent that other regulators – including the UK's FCA, the EU's competent authorities under MiCA, and VARA in Dubai – have acknowledged in their own supervisory expectations, even where their domestic sanctions lists differ in scope.

For a scoped assessment of your current screening architecture, contact OBOLUS at Map your options. The standard path described above may look different depending on your entity's jurisdictions, user base, and counterparty relationships.

What Does the Regulatory Perimeter Actually Cover?

Sanctions obligations for crypto businesses derive from multiple overlapping sources, and the perimeter is not always drawn in the same place by each authority. Under the MiCA regime, crypto-asset service providers (CASPs) authorised in an EU member state carry the same sanctions compliance obligations as other financial-sector entities, enforced by the relevant national competent authority in coordination with ESMA. The regime does not relax the obligation for smaller operators – it extends it across the entire CASP licence category.

In the UAE, VARA's rulebooks set explicit expectations for address screening, risk-based customer due diligence, and transaction monitoring as conditions of a virtual asset licence. An operator licensed under VARA that fails to screen against consolidated UN sanctions lists, as well as UAE-specific designations, faces supervisory action under VARA's enforcement mandate. The ADGM's FSRA in Abu Dhabi applies an equivalent standard within its own framework.

The UK FCA, under the Money Laundering Regulations, requires registered cryptoasset businesses to maintain controls that are effective against the specific risks presented by the asset class – which the FCA has consistently interpreted to include wallet-address screening in addition to name-based checks. The FCA's supervisory track record includes deregistration of crypto firms that could not demonstrate adequate systems.

Three structural conclusions follow. First, the "obliged entity" perimeter is now wide: exchanges, custodians, peer-to-peer platforms, DeFi front-ends with a legal operator, and increasingly certain stablecoin issuers all fall within it in one or more jurisdictions. Second, the standard is outcomes-based in most regimes – it is not sufficient to have a policy; the policy must work. Third, the cross-border dimension is acute: a firm serving users in the EU, the UAE, and the UK simultaneously must satisfy three distinct – and sometimes diverging – sanctions screening expectations at once.

How Does Address Screening Actually Work – and Where Does It Break Down?

Address screening involves checking a wallet against known sanctions designations in real time, before a transaction is executed or funds are credited. This is mechanically simpler than it sounds and legally more demanding than most operators realise. The practical mechanics involve three distinct checks, each with its own failure mode.

The first is direct address matching – comparing the counterparty wallet against OFAC's SDN list, the EU consolidated list, the UN Consolidated Sanctions List, and equivalent national lists. The failure mode here is latency: designation lists are updated without advance notice, and a firm that screens only at onboarding – rather than continuously and at the point of every transaction – will have gaps.

The second is cluster analysis – identifying wallets that are controlled by, or closely associated with, a designated address even if they are not themselves designated. On-chain forensics tools assign a risk score based on transaction graph analysis, giving an operator a probabilistic view of exposure. The failure mode is over-reliance on a single vendor's cluster methodology, which may lag new attribution data or diverge from a regulator's own analysis in an enforcement context.

The third is counterparty VASP screening – assessing whether the institutional counterparty on the other side of a transaction (in a Travel Rule context, the originating VASP or beneficiary VASP) has adequate sanctions controls of its own. This is the least mature area of practice. Most operators ask for a counterparty questionnaire at onboarding; far fewer have a mechanism for ongoing monitoring or for acting on adverse changes in a counterparty's regulatory status.

In our cross-border practice, the breakdown most commonly occurs at the third check. A well-resourced operator has a strong direct-screening tool, a credible cluster-analysis vendor, and then materially weaker oversight of the institutional counterparties through which their exposure is actually transmitted.

The Travel Rule Interaction: Screening Is Not Enough Without Data

The Travel Rule sits alongside sanctions screening rather than inside it, but the two are operationally inseparable. Under the FATF Recommendation 15 framework, a VASP must collect and transmit originator and beneficiary data for transfers that meet or exceed the applicable threshold in its jurisdiction. The data collected to satisfy the Travel Rule is also the data that feeds a sanctions screen – and if the data is missing, incomplete, or falsified, the screen cannot function.

This creates a specific legal risk that is still underappreciated. A firm may have a technically sound screening tool and an adequate counterparty list, but if its Travel Rule implementation does not capture clean originator data at the point of transfer, it is effectively operating the screen against incomplete inputs. A regulator examining the program will find not one deficiency but two: a Travel Rule gap and a sanctions-screening gap, often charged separately.

The EU's transfer-of-funds regulation, extended to crypto-assets under the MiCA architecture, applies this principle across all EEA-licensed CASPs. Singapore's MAS has applied equivalent expectations under the Payment Services Act DPT regime. The UK FCA has indicated in supervisory guidance that Travel Rule compliance and sanctions screening will be assessed together in AML reviews.

Operators we advise routinely discover that their Travel Rule and sanctions workflows were built by different teams, with different vendors, and without a unified data model. The outputs do not reconcile. When the regulator asks to trace a flagged transaction through the full compliance chain, the firm cannot produce a coherent account. That inability – rather than any underlying intent – is often what converts a supervision inquiry into a formal enforcement matter.

If a prior compliance review identified a gap in your Travel Rule or screening architecture, a second-opinion engagement can surface the structural cause and the remediation path. Write to OBOLUS at Map your options to scope that work.

Where Sanctions Regimes Conflict Across Borders

A digital-asset business operating across multiple jurisdictions does not face one sanctions regime – it faces several simultaneously, and they do not always agree. This is the hardest compliance problem in the space, and it does not have a clean legal resolution.

Consider the practical tension. OFAC's sanctions list is the most expansive in global financial services. It designates entities that neither the EU nor the UK has sanctioned, and it applies to US persons and to transactions with a US nexus – a concept that, in digital assets, can extend to use of US-based infrastructure, dollar-denominated stablecoins, or US counterparties, regardless of where the VASP is licensed. A CASP licensed under MiCA, operating from a member state with no US entity or office, may nonetheless have OFAC exposure through USDT flows or US-incorporated DeFi protocols.

The reverse tension also applies. Certain jurisdictions maintain sanctions lists that conflict with OFAC or EU designations. A firm serving users across these jurisdictions faces a genuine legal dilemma: following one list may, in edge cases, constitute non-compliance with another. This is not a theoretical concern. Operators we advise have encountered it in structuring their counterparty policies for specific corridors, particularly where emerging-market banking partners are involved.

The standard industry response – screen against all lists, apply the most restrictive outcome – is defensible as a general posture but does not resolve every case. It also creates operational friction that, if poorly managed, generates over-blocking of legitimate users. Regulators in the major hubs increasingly expect a documented rationale for the list hierarchy a firm applies, not merely a statement that it screens broadly.

The practical answer for a multi-jurisdictional operator is a written sanctions policy that explicitly addresses list hierarchy, documents the legal basis for each list inclusion, assigns responsibility for maintaining currency, and provides a decision tree for conflict cases. That document is what the regulator reads first when an inquiry arrives.

DeFi, Smart Contracts, and the Unresolved Legal Question

The sharpest legal line currently being drawn in sanctions compliance concerns decentralised protocols. When OFAC designated Tornado Cash, it applied the designation to smart-contract addresses – immutable code deployed on a public blockchain. The legal question is whether interacting with a designated smart contract constitutes a sanctions violation, and if so, what a front-end operator must do to avoid it.

That question has not been definitively resolved across all relevant jurisdictions, and the litigation contesting certain aspects of the original designation is ongoing. What is clear is the regulatory direction of travel: authorities in the US, EU, and UK are extending sanctions analysis to the infrastructure layer of DeFi, not just to the legal-entity layer. A CASP or similar regulated operator that routes transactions through a sanctioned protocol – even unknowingly – faces a potential enforcement posture that does not depend on intent.

The practical implication for a protocol operator with a legal entity is stark. If the business controls a front-end interface – a website, an app, an API – it is a regulated entity in most leading jurisdictions, regardless of the protocol's decentralisation. That front-end must screen. The screening must catch not only directly sanctioned counterparties but also transactions routing through designated infrastructure.

Roman Levitt, our technology and DeFi counsel, has noted a consistent pattern: DeFi operators invest heavily in smart-contract security audits and almost nothing in compliance architecture, until a regulator or an enforcement agency arrives. At that point, the absence of a documented screening program is treated as wilful non-compliance rather than a technical oversight. The distinction matters enormously in an enforcement context.

ESMA and national competent authorities under MiCA have indicated that legal operators of DeFi interfaces will be treated as CASPs where the regulatory threshold is met. VARA has taken a similarly broad view of what constitutes a virtual-asset activity within its perimeter. These positions are not yet fully codified, but they represent the operating assumption under which regulators are currently conducting supervision.

Decision Matrix: Which Screening Architecture Matches Your Profile?

No two crypto businesses face identical sanctions risk, and a screening program that is adequate for a retail exchange serving EU users may be materially insufficient for an OTC desk with institutional counterparties across multiple corridors. The following profiles illustrate the key divergence points.

Profile A – Retail exchange licensed under MiCA: The primary exposure is direct-address screening of incoming and outgoing wallet addresses against EU consolidated, UN, and OFAC lists, combined with Travel Rule data collection and transmission. The critical risk is latency in list updates and over-reliance on KYC data that was accurate at onboarding but has since changed. A continuous monitoring capability – not just a point-in-time check – is the minimum standard regulators expect. Timeline to build an adequate architecture: a matter of weeks for the core tooling; an ongoing operational commitment thereafter.

Profile B – Institutional OTC desk with cross-border counterparties: The direct-address risk is lower (counterparties are known entities) but the counterparty-VASP risk is substantially higher. The firm must assess whether its institutional counterparties have adequate screening programs, maintain that assessment on a periodic basis, and have a documented procedure for suspending a counterparty relationship if their regulatory status deteriorates. The Travel Rule obligation is more complex because transfers may involve multiple jurisdictional hops. The key risk is a counterparty-mediated sanctions breach that the firm could not have detected with name-only screening.

Profile C – DeFi front-end operator with a legal entity: The screening obligation attaches to the front-end, not the protocol. The firm must screen users at the point of wallet connection, implement address-level checks, and maintain logs sufficient to demonstrate compliance to a regulator. The key risk is protocol-level exposure – routing through designated infrastructure even where the end-user passes the screen. Allied counsel in the relevant jurisdiction should be engaged to assess the specific regulatory perimeter before launch.

Profile D – Stablecoin issuer (ART or EMT under MiCA): The issuer must screen at the point of issuance and redemption, and must also assess exposure through its reserve management operations. The reserve-custodian and banking relationships introduce their own sanctions risk. The key risk is a concentration of reserve assets in a sanctioned issuer or through a banking partner with weak controls. The MiCA regime and the EU transfer-of-funds rules both apply to this profile.

How a Screening Gap Escalated to Enforcement: An Anonymized Account

In a recent matter, a payments company licensed as a VASP in a leading EU jurisdiction approached us after receiving a supervisory inquiry from its national competent authority. The firm had invested in a well-regarded address-screening tool and passed its initial AML audit. The regulator's inquiry was triggered not by a known sanctions breach but by a transaction-monitoring alert that flagged unusual volume patterns in a specific corridor.

On review, the gap was not in the direct-address screen – that was functioning correctly. The gap was in the counterparty-VASP layer. The firm had onboarded an institutional counterparty at a point when that counterparty was not yet subject to any designation. Eighteen months later, a beneficial owner of the counterparty was added to a national designation list. The firm's onboarding questionnaire had not been refreshed. The ongoing monitoring procedure was manual and quarterly, not automated. Three transfers had occurred in the intervening period.

We advised on the voluntary disclosure process, assisted in preparing the remediation plan, and mapped the Travel Rule data chain for the transactions in question. The regulator's outcome was a formal remediation requirement rather than a financial penalty – in part because the firm could demonstrate that the screening tool itself was sound and that the gap was in the process layer, not in the firm's intent. The matter resolved within a single supervisory cycle. The remediation required rebuilding the counterparty-monitoring workflow with automated triggers linked to the sanctions list update feed.

The lesson is not that the firm was negligent. It is that a point-in-time compliance architecture – however well built at inception – decays unless it is continuously maintained. The regulator's expectation is not a static program; it is a living one.

A Common Assumption That Creates Unnecessary Risk

A common assumption among operators entering the digital-asset space is that a single offshore licence, combined with a generic AML policy, is sufficient to serve clients across multiple jurisdictions without engaging separately with each applicable sanctions regime. This assumption is wrong in almost every material respect, and acting on it is one of the more reliable paths to enforcement exposure.

The logic behind it is understandable. A Cayman Islands or BVI-registered entity may not be subject to OFAC's direct jurisdiction, and its licensing jurisdiction may have a narrower sanctions list than the US. If the firm does not touch the US financial system and has no US persons involved, the OFAC nexus may genuinely be limited. But the firm's stablecoin flows almost certainly pass through a US-issuer smart contract. Its banking counterparty is almost certainly a correspondent-banking participant subject to US sanctions compliance expectations. Its institutional clients – funds, exchanges, custodians – may themselves be US-nexus entities.

The practical effect is that most digital-asset businesses have OFAC exposure regardless of where they are licensed. They also have EU exposure if they serve any EU users, and FCA exposure if they serve UK users. The offshore licence does not displace these obligations. It merely means there is no local regulator supervising compliance with them – until the regulator with jurisdiction over the relevant users, transactions, or counterparties decides to act.

We have seen firms discover this structure for the first time in response to a regulatory inquiry rather than in their own counsel's advice. The cost differential is significant.

Related at OBOLUS

• AML and Travel Rule compliance for digital-asset businesses – the full practice overview across licensing, monitoring and cross-border obligations
• MLRO and compliance officer requirements under BaFin – what the senior compliance function requires in Germany's regulated framework
• Sanctions screening for regulated crypto entities – the scoped service offering for VASPs and CASPs building or auditing their screening program

If your compliance architecture has not been reviewed since your licence was granted, or if a supervisory inquiry has already arrived, the time to act is before the next regulatory checkpoint, not after it. To pressure-test your program before you commit to a structure, message OBOLUS via Map your options.

FAQ

What does the Travel Rule require from a VASP?

The Travel Rule, derived from FATF Recommendation 15 and implemented differently across jurisdictions, requires a virtual asset service provider to collect the name, account reference, and identifying information of both the originator and beneficiary of a virtual-asset transfer above the applicable threshold, and to transmit that data to the receiving institution. The obligation applies to both the sending and receiving VASP. Failure to collect or transmit compliant data is an independent compliance breach from any sanctions failure, but the two are often found together in regulatory examinations.

Who must act as MLRO for a crypto firm?

Most leading jurisdictions require a licensed virtual-asset business to appoint a designated Money Laundering Reporting Officer (MLRO) – a senior individual with responsibility for the firm's AML/CFT program, internal suspicious activity reporting, and regulatory liaison. The function must be filled by a person with sufficient seniority, competence, and independence to act without commercial pressure. Regulators including the FCA, VARA, MAS, and national competent authorities under MiCA require evidence that the MLRO role is genuinely staffed and operationally active, not a nominal appointment.

How do regulators audit crypto AML programs?

Regulators typically examine four areas: the written policy framework (policies, procedures, risk assessments); the technical controls (screening tools, transaction monitoring, alert management); the governance record (MLRO reports, board sign-off, staff training logs); and a sample of transaction decisions – particularly alerts that were reviewed and closed without action. In our practice, the most common finding is a gap between the written policy and the operational record: the policy states a procedure that is not reflected in the actual system logs. That discrepancy is treated as a control failure, regardless of the underlying intent.

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 that sit around them. Digital assets are the entirety of our practice. We map the compliance, licence, and sanctions stack across operating, custody, and payment layers before you commit to a structure – because the cost of a late discovery is always higher than the cost of early advice. To discuss your situation, contact info@oboluslaw.com.

By Roman Levitt, Technology & DeFi Counsel – specialising in compliance architecture, DeFi regulatory exposure, and the interaction between on-chain protocol mechanics and sanctions screening obligations.

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.