Sanctions compliance failures are not abstract regulatory risk for a crypto operator. They are the precursor to frozen bank accounts, de-listed wallets, enforcement referrals and, increasingly, civil litigation brought by counterparties whose funds were either blocked or – worse – processed when they should not have been. As regulators in the leading hubs tighten sanctions screening (the real-time and batch process of matching wallet addresses, counterparty identities and transaction flows against designated-persons lists) obligations for digital-asset businesses, the gap between a screening programme that satisfies an auditor and one that survives a dispute is wider than most general counsel realize.
This analysis examines sanctions screening for crypto businesses through the lens of what actually goes wrong in litigation and enforcement proceedings. It draws on the AML compliance and Travel Rule obligations that sit around screening, maps the cross-border exposures that arise when an entity is licensed in one jurisdiction but serves users in another, and sets out a decision framework for operators who need to know whether their current programme is litigation-ready – not just audit-ready.
Why Sanctions Screening Is a Disputes Trigger, Not Just a Compliance Box
Sanctions screening failures become disputes triggers in two distinct ways: they generate enforcement action by regulators, and they generate civil claims between private parties. Both pathways are accelerating. The mechanics of on-chain settlement mean that a transaction which clears a screener today may still be traceable to a designated entity days later, when a more thorough forensic pass is run. That latency creates exposure that is qualitatively different from the traditional financial-crime risk a bank faces. A VASP – a virtual asset service provider, meaning any business that exchanges, transfers, safekeeps or administers digital assets for clients – cannot assume that a clean screen at the time of execution eliminates its liability.
In our cross-border practice, we regularly advise operators who discover this distinction only after a dispute has commenced. The pattern is consistent: a sanctions screening programme was built to satisfy the onboarding and ongoing AML/CFT audit cycle, but it was not stress-tested against the scenario in which a counterparty challenges the operator's compliance decisions in court. The two design requirements are not the same. Audit readiness asks whether the right lists were checked. Litigation readiness asks whether the right lists were checked, at the right moment, with a documented rationale, and with a defensible escalation path when the result was ambiguous.
The key distinction is between screening as a binary pass/fail gate and screening as an evidence-producing process. Operators who treat it as the former are exposed in both enforcement proceedings and civil litigation.
The Applicable Regimes: A Cross-Border Map
No single sanctions regime governs a digital-asset business that operates across borders. The operative question is not which jurisdiction licensed the VASP, but which sanctions lists apply to each transaction, counterparty and asset flow. The answer is almost always plural.
Under MiCA (the EU's Markets in Crypto-Assets Regulation, supervised by ESMA and national competent authorities), a CASP – a crypto-asset service provider, the MiCA equivalent of a VASP – is subject to EU sanctions law as a matter of EU-wide passportable authorisation. That means a CASP authorised in Lithuania or Malta and passporting into France, Germany or the Netherlands must screen against EU consolidated lists across every activity, not just in its home member state. The passporting mechanic, which is a genuine commercial advantage, carries a corresponding compliance footprint that many operators underestimate when choosing a launch jurisdiction.
Outside the EU, VARA (the Virtual Assets Regulatory Authority in Dubai) imposes its own AML/CFT rulebooks on licensed entities operating in mainland Dubai. ADGM's FSRA (Financial Services Regulatory Authority in Abu Dhabi) does the same for entities in the Abu Dhabi Global Market. Neither regime displaces the possibility that US primary or secondary sanctions – administered by OFAC, the Office of Foreign Assets Control – apply concurrently, because US sanctions have extraterritorial reach over USD-denominated settlements and over entities with US persons in their ownership or management chain. MAS (the Monetary Authority of Singapore) and the SFC (Securities and Futures Commission in Hong Kong) each apply their own sanctions frameworks in parallel with, not instead of, OFAC's reach.
The FCA (Financial Conduct Authority) in the UK administers a domestic sanctions regime post-Brexit that mirrors EU lists in many respects but diverges in others. A VASP registered under the UK's Money Laundering Regulations and serving UK clients must screen against the UK consolidated list, not the EU list – even if it is also subject to EU law. Dual-list screening is not optional; it is the baseline for any operator with a cross-border user base.
FATF Recommendation 15, the global baseline for virtual-asset AML/CFT obligations, does not itself specify which sanctions lists apply, but it anchors the expectation that VASPs conduct ongoing monitoring and apply proportionate controls. The Travel Rule (the obligation to pass originator and beneficiary identification data with a virtual-asset transfer, per FATF standards) intersects with sanctions screening because the data that the Travel Rule generates – counterparty name, wallet address, identity verification – is precisely the data that feeds a sanctions match. A Travel Rule programme that does not integrate with the screening system is, in practice, incomplete.
How Does a Sanctions Match Become a Legal Dispute?
A sanctions match generates a legal dispute in one of three patterns, and understanding which pattern applies changes the legal strategy.
The first pattern is regulatory enforcement. A regulator – ESMA's national competent authority under MiCA, VARA, the FCA, MAS, or FinCEN in a US nexus matter – identifies, through examination or a suspicious-activity report, that a VASP processed a transaction involving a designated person or entity without having screened, or screened inadequately. Enforcement outcomes range from fine to licence suspension. The VASP's best defence is documentary: a complete screening log, a documented escalation, a record of the decision made when a potential match was flagged, and evidence of prompt remediation.
The second pattern is civil litigation by a counterparty. A customer or trading counterparty whose assets were frozen – or whose account was closed following a false positive – brings a claim that the VASP acted in breach of contract, negligently, or in breach of applicable statutory duty. Here the VASP needs to demonstrate that its screening programme was legally required, proportionate and correctly applied. A screening system that over-blocks legitimate transactions is not legally neutral: it generates its own liability.
The third pattern is claims by third parties who were harmed by a failure to screen. This is the emerging frontier. As on-chain forensics improve, counterparties who received assets that can be traced to a sanctioned source are seeking to hold the intermediary VASP liable for facilitating the transfer. England and Wales, the DIFC Courts and Singapore have each shown a willingness to consider novel theories of intermediary liability in digital-asset matters. The CFAAR (Crypto Fraud and Asset Recovery network, launched in London in September 2021) has been a forum for developing exactly these arguments.
In our practice, we have seen all three patterns. The operators best positioned to defend them are those who treated the screening programme as a legal-evidence system from inception, not as a compliance artefact.
To map your programme's litigation exposure and identify the structural gaps, contact OBOLUS at info@oboluslaw.com. The process above describes the standard risk pattern. Your entity structure, user base geography and banking rails change the specific analysis materially. Map your options.
What Does a Litigation-Ready Screening Programme Require?
A litigation-ready screening programme has six structural characteristics that a purely audit-driven programme often lacks. Each characteristic corresponds to a question that opposing counsel or an enforcement examiner will ask.
First, list coverage that matches the operator's actual exposure. The list of sanctions designations an operator must screen against should be determined by a legal analysis of its nexus to each sanctions jurisdiction – not by a vendor's default bundle. An operator with no US nexus may be correct to conclude that OFAC's full list is not a legal obligation; an operator with USD settlement rails or a US investor certainly cannot make that argument. Documenting this analysis is as important as the screening itself.
Second, wallet-address screening, not just name screening. The identity-based KYC framework (know-your-customer identity verification) that a VASP applies at onboarding is necessary but not sufficient. On-chain addresses associated with designated entities are often not registered under the designated entity's own name. The most effective screening programmes run wallet-address checks against published OFAC and equivalent designation data, independently of the KYC name match. Tether (USDT) and Circle (USDC) each hold contract-level freeze authority over their issued tokens and generally act on law-enforcement or OFAC designation; an operator whose screening programme did not catch an exposure that a stablecoin issuer subsequently froze will face hard questions about why.
Third, transaction monitoring that is genuinely ongoing. The transaction monitoring obligation – continuous review of transaction patterns for signs of sanctions evasion, layering and unusual flows – must be parameterised to catch patterns, not just point-in-time matches. A customer screened clean at onboarding may be flagged six months later when a forensics platform identifies the wallet cluster. The screening programme must log and respond to that subsequent event.
Fourth, a documented false-positive escalation path. When a potential match is flagged, the decision about whether to block, freeze, report or release must be documented with a rationale. A decision log that reads "reviewed and cleared" without a named reviewer and a stated basis for clearance is legally indefensible. Regulators in the leading hubs – VARA, the FCA, MAS, and national competent authorities under MiCA – have each made clear in supervisory guidance that a screening system's value is in its governance, not just its coverage.
Fifth, Travel Rule data integration. The data flowing through a Travel Rule process – originator name, originator account, beneficiary name, beneficiary account – is sanctions-relevant data. A VASP that maintains separate workflows for Travel Rule compliance and sanctions screening is creating a structural gap. The originator data received from a sending VASP in a Travel Rule message should automatically trigger a sanctions check before the incoming transfer is credited.
Sixth, a periodic legal review that is not just a vendor audit. Screening vendors provide technical coverage reports. They do not provide legal opinions on whether the coverage satisfies the operator's regulatory obligations in each jurisdiction. That assessment requires legal input. Operators who rely exclusively on vendor certifications to demonstrate compliance have, in our experience, the most significant gaps when a dispute surfaces.
Contrasting Positions: Rule-Based vs. Risk-Based Screening
A genuine tension exists in how regulators and compliance professionals approach sanctions screening design, and it maps directly onto how disputes get resolved.
The rule-based position holds that sanctions screening should produce a deterministic output: every name and address on every applicable list is checked against every transaction and counterparty, and a match triggers a mandatory block. This approach minimises the risk of regulatory enforcement for failure to screen a designated person. It maximises the risk of false positives and the associated civil liability for incorrect blocking.
The risk-based position, which FATF Recommendation 15 anchors and which MiCA's CASP regime, VARA, and MAS each operationalize in their AML/CFT rulemaking, holds that screening intensity should be proportionate to the risk profile of the customer, the transaction and the asset. A retail transfer below the Travel Rule data threshold in a low-risk corridor receives a different treatment than a large cross-border transfer from a jurisdiction on an enhanced-scrutiny list. This approach requires more sophisticated governance but is more defensible in both regulatory and civil proceedings – provided the risk-based decisions are documented.
In practice, the distinction is not binary. The operators who perform best across enforcement and litigation are those who apply rule-based screening as the floor and risk-based analysis as the escalation layer. The screening log shows what was checked; the escalation record shows how judgment was applied when the automated check produced an ambiguous result.
A common assumption among operators expanding into new markets is that if the home-jurisdiction regulator is satisfied with the screening programme, cross-border exposure is managed. That assumption does not survive contact with a US nexus matter, a dual-listed designation, or a civil claim brought in an English court by a counterparty asserting that the VASP ought to have known. The cross-border legal analysis is not optional; it is the foundation of the programme's defensive value.
The Cross-Border Reality: Where Sanctions Exposure Compounds
Sanctions exposure compounds at the intersection of three axes that digital-asset businesses routinely underestimate: the jurisdiction where the entity is licensed, the jurisdictions whose nationals and residents use the platform, and the jurisdiction where settlement or banking occurs.
An operator licensed by VARA in Dubai and banking through a correspondent that clears USD in New York is, in every practical sense, subject to OFAC's sanctions regime – regardless of where its legal entity sits. An operator licensed under MiCA in Malta, passporting across the EU, and serving a user base that includes individuals in sanctioned territories faces national-competent-authority enforcement in every member state into which it has passported. A VASP registered with the BVI FSC under the VASP Act 2022 and operating a non-custodial exchange with global reach faces extraterritorial sanctions risk from every jurisdiction whose nationals use the platform, because digital-asset transfers do not stop at borders.
In a recent matter, we advised a payments company that had structured its VASP operations across two hubs to take advantage of distinct licensing regimes. The client's screening programme was compliant in both home jurisdictions. When a transaction flow involving a wallet cluster linked to a sanctioned entity was identified by a forensics platform, the client faced simultaneous regulatory inquiries in both jurisdictions. The issue was not the screen itself – it had flagged the cluster – but the escalation documentation between the two entities was incomplete. We worked through the remediation protocol, supported the regulatory response process and documented the post-incident programme improvements. The matter was resolved without formal enforcement action.
The lesson is architectural. Sanctions screening is a group-level function, not an entity-level checkbox. Where a business operates through multiple licensed entities – a common structure for operators seeking to optimize the licence, custody and payment layers – the screening programme must be designed to function coherently across all of them.
Decision Matrix: Which Operator Profile Faces Which Risk
Different operator profiles face materially different sanctions-screening risks. The following framework maps the four most common profiles to their primary exposure and the programme design response.
Profile A – EU-passported CASP (MiCA authorisation). Primary risk: multi-jurisdiction enforcement by national competent authorities in passported states, particularly if the home-state NCA is less active than NCAs in larger member states. Programme response: EU consolidated list screening as the floor, dual-screening for any UK or US nexus, and a documented passporting-jurisdiction legal analysis that maps each NCA's enforcement posture. Timeline sensitivity: under MiCA the passporting notification process is measured in weeks; the compliance programme must be operational before passporting commences.
Profile B – VARA-licensed exchange with global user base. Primary risk: OFAC extraterritorial reach through USD banking rails and the risk of serving users in sanctioned territories. Programme response: IP and identity-based geo-restriction supplemented by wallet-address screening against OFAC SDN and equivalent lists; documented legal analysis of the US nexus question. The VARA regime's own AML/CFT rulebooks require a programme that the VARA examinations team can trace end-to-end.
Profile C – BVI or Cayman-domiciled fund or issuer with OTC trading activity. Primary risk: investor-level sanctions exposure (a fund accepting capital from a designated entity is itself at risk) and the secondary-sanctions risk that attaches to dealings with parties connected to sanctioned jurisdictions. Programme response: investor-level KYC framework and ongoing monitoring, not just onboarding checks; legal review of the fund documents' representations and warranties on sanctions compliance.
Profile D – MAS-licensed DPT service provider with Asia-Pacific reach. Primary risk: concurrent exposure to MAS's own sanctions regime and OFAC's reach for any USD-denominated activity; the SFC in Hong Kong and JVCEA oversight in Japan create additional layers for operators with multi-market activity. Programme response: MAS-specific list coverage as the home-jurisdiction floor; a legal mapping exercise for each market in the Asia-Pacific footprint before the market is opened to users.
If you are pressure-testing your programme design against your actual exposure profile, write to OBOLUS at info@oboluslaw.com. If a prior screening failure or enforcement inquiry has already surfaced, our disputes desk is the right starting point. Map your options.
The MLRO Function and Why Its Design Matters in Disputes
The MLRO (Money Laundering Reporting Officer) function sits at the centre of both the sanctions screening governance structure and the litigation risk map. Every major licensing regime – MiCA/CASP, VARA, ADGM/FSRA, MAS's Payment Services Act framework, the FCA's MLR regime, FINMA's requirements in Switzerland – requires a designated MLRO or equivalent senior compliance function. The MLRO is responsible for the SAR (Suspicious Activity Report) filing decisions, for the escalation documentation that governs screening outcomes, and for the sign-off on risk-based clearances.
In a dispute – whether regulatory enforcement or civil litigation – the MLRO's decisions are the primary documentary record. A well-designed MLRO function produces a paper trail that demonstrates proportionality, legal awareness and consistent application of policy. A poorly designed function produces a gap in the record that enforcement counsel and plaintiffs' lawyers will fill with adverse inferences.
For early-stage operators, the question of whether the MLRO must be an employee or may be outsourced to a third-party compliance consultant is jurisdiction-specific. VARA's rulebooks set specific expectations about the MLRO's seniority and access. The FCA expects the MLRO to be a named approved person under the MLR regime. MAS sets its own seniority and independence expectations. What is consistent across regimes is that the MLRO must have genuine authority – not just a title – and must be positioned to escalate to the board without commercial interference. Operators who staff this function as a box-checking role rather than a senior governance position are building litigation risk into the architecture of their business.
How Regulators Audit Crypto AML Programs: What to Expect
Regulatory audits of crypto AML programmes are increasingly convergent in their methodology, even as the specific requirements vary by regime. Understanding what an examiner is looking at changes how a programme should be documented.
VARA, the FCA, MAS and national competent authorities under MiCA each approach an AML/CFT examination as an evidence-gathering exercise. They are not primarily checking whether the operator has a policy document. They are testing whether the policy is operationally real: whether the screening system was running at the relevant times, whether the escalation path was used, and whether the MLRO's decisions were documented with a legal rationale.
In practice, an examiner will request screening logs for a sample period, ask to trace a specific transaction from receipt through to the screening outcome, and interview the MLRO about the decision logic for any flagged item that was cleared. A screening system that produced no escalations over an extended period will attract scrutiny: the examiner will ask whether the system was generating matches that were being silently closed, or whether the calibration was set so permissively that genuine risk was passing undetected.
The cross-border dimension adds complexity. An operator subject to examination by both VARA and a European NCA in the same period – possible for a group with dual-licensed entities – will face questions that are not identical, because the two regimes have different documentation expectations. A group-level screening policy that is drafted to satisfy both sets of expectations is not a luxury; it is a necessity for any operator with a multi-hub presence.
Forensics tools – platforms such as those used in the CFAAR network context, drawing on on-chain analytics to trace wallet clusters and identify exposure – are increasingly used by regulators as part of the examination process. An operator whose internal programme has not used comparable tools cannot credibly argue that it had no basis to identify an exposure that a regulator subsequently identifies with those tools. The standard against which the programme is measured is not the standard that existed when the programme was designed; it is the standard that existed when the transaction occurred, assessed against the capabilities available at that time.
Related at OBOLUS
- AML & Travel Rule compliance for digital-asset businesses – our full-service practice covering FATF-aligned programmes and multi-jurisdiction AML design.
- Sanctions screening for crypto in Poland – jurisdiction-specific analysis of Polish VASP obligations under MiCA and national AML law.
- Sanctions screening for regulated crypto entities – our scoped service for exchanges, custodians and issuers needing litigation-ready programme design.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary identification data – including names, account identifiers and, where required, physical addresses or national identity numbers – alongside a virtual-asset transfer. The threshold above which the obligation applies varies by jurisdiction. The data generated by Travel Rule compliance feeds directly into sanctions screening and AML transaction monitoring, making the two obligations operationally inseparable. Receiving VASPs must also verify the data they receive and screen it against applicable sanctions lists before crediting the transfer.
Who must act as MLRO for a crypto firm?
Every licensed VASP or CASP is required under the applicable regime – whether MiCA, VARA, the FCA's MLR framework, MAS's Payment Services Act requirements or equivalent – to designate a senior individual as its money laundering reporting officer. That person must have genuine authority to escalate suspicious-activity reports and sanctions decisions to the board, independent of commercial pressure. Whether the role may be outsourced or must be held by an employee varies by jurisdiction. The MLRO's documented decisions are the primary record in any regulatory examination or litigation.
How do regulators audit crypto AML programs?
Regulators – including VARA, national competent authorities under MiCA, the FCA and MAS – audit crypto AML programmes by examining screening logs, tracing individual transactions through the full compliance workflow, interviewing the MLRO, and testing whether escalation decisions were documented with a legal rationale. The absence of escalations over a sustained period will itself attract scrutiny. Increasingly, examiners use on-chain forensics tools to identify exposures independently, then test whether the operator's programme would have caught the same exposure. The benchmark is the capability that was available at the time, not the capability that was used.
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 sanctions, AML and Travel Rule compliance programmes that sit around them. Digital assets are the entirety of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before you commit to a structure. To discuss your situation, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specialist in the intersection of on-chain mechanics and compliance programme design for digital-asset businesses operating across multiple licensing regimes.
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.