Institutional operators in digital assets face a sanctions screening obligation that is simultaneously a legal requirement, a banking precondition and a reputational line in the sand. A custody platform that onboards a counterparty subject to OFAC, UN or EU designations does not merely face a regulatory fine – it risks losing its correspondent banking relationships, triggering asset freezes and exposing its executives to personal liability. The question is not whether to screen; it is whether the screening program will hold up under regulatory scrutiny across every jurisdiction in which the business touches users, assets or settlement rails.
Sanctions screening for crypto for institutional clients requires a program that covers wallet-level controls, Travel Rule (the obligation to pass originator and beneficiary data with each virtual asset transfer) compliance, ongoing transaction monitoring and cross-border legal mapping – not a single static list check at onboarding. As regimes converge on the MiCA (Markets in Crypto-Assets Regulation) model and VASP supervision tightens across the major hubs, the gap between a defensible program and a checkbox exercise is widening. This page sets out the regulated basis, the process, the cross-border interaction and the profile-specific decisions that determine whether your compliance architecture will survive the next supervisory review.
What is the regulated basis for sanctions screening in digital assets?
The obligation to screen for sanctions exposure sits at the intersection of two distinct legal regimes: anti-money laundering law and the primary sanctions frameworks that bind financial intermediaries in each operating jurisdiction. For digital-asset businesses, those layers are cumulative, not alternative.
At the international baseline, FATF Recommendation 15 requires that VASPs (virtual asset service providers) apply AML/CFT controls equivalent to those expected of traditional financial institutions. Every major hub has transposed this into domestic law. Under MiCA and the ESMA supervisory framework, a CASP (crypto-asset service provider) authorised in the EU must maintain a compliance function capable of screening against EU restrictive measures in real time. The equivalent obligations apply under VARA in Dubai, under the MAS Payment Services Act regime in Singapore, under the SFC VATP licensing regime in Hong Kong and under FinCEN/OFAC requirements in the United States.
The practical consequence is that a business with entities in multiple jurisdictions – or with users in jurisdictions it has not formally licensed into – is subject to several overlapping screening obligations simultaneously. OFAC's reach extends to any transaction that touches the US financial system or a US person, regardless of where the VASP is incorporated. EU restrictive measures apply to any EU-nexus transaction. VARA expects its licensees to screen against UAE Cabinet decisions as well as UN designations. These are not theoretical exposures.
In our cross-border practice, we regularly advise operators who assumed that their EU CASP authorisation resolved their US exposure, or that their VARA licence covered their Abu Dhabi-facing business. Neither assumption is correct. The regulatory perimeter for sanctions is defined by transaction flow, counterparty location and settlement currency – not entity domicile alone.
The process above describes the standard path. Your specific entity structure, user base geography and settlement currency change the analysis substantially. For a scoped assessment of your sanctions screening obligations across your operating jurisdictions, contact OBOLUS at info@oboluslaw.com.What does an institutional-grade sanctions screening program actually cover?
An institutional-grade program covers four distinct screening layers, each of which addresses a different vector of sanctions exposure in digital-asset markets.
The first layer is entity screening at onboarding: checking legal entities, beneficial owners, authorised signatories and controlling persons against designated party lists – OFAC SDN, EU consolidated list, UN Security Council lists, HM Treasury UK sanctions list and applicable national lists in every operating jurisdiction. For institutional counterparties, this includes screening the fund, the management company and the ultimate beneficial owners. A single-list approach fails at this layer.
The second layer is wallet and address screening: using blockchain analytics to check counterparty wallet addresses against known sanctioned addresses and high-risk clusters. Tether (USDT) and Circle (USDC) maintain contract-level freeze authority on their issued tokens and generally act on OFAC designations or law-enforcement requests. An operator that receives or transmits funds from a sanctioned address – even unknowingly – faces exposure. The forensic tooling required here (Chainalysis, TRM Labs, Elliptic and comparable platforms) is a functional requirement, not a differentiator.
The third layer is Travel Rule data screening: the obligation to collect, verify and transmit originator and beneficiary data with each qualifying transfer means the compliance function must screen not only the transferring entity but also the beneficiary institution and, where the Travel Rule threshold triggers, the underlying individuals. FATF's Travel Rule applies to VASPs; domestic implementation varies on the applicable de-minimis threshold, but the data-collection obligation is broadly uniform across the flagship hubs.
The fourth layer is ongoing transaction monitoring: real-time or near-real-time review of transaction patterns against a risk-based typology framework, with escalation procedures for hits against sanctions lists and for transactions involving jurisdictions subject to comprehensive embargoes. For institutional clients transacting at volume, automated monitoring with human review protocols is the expected standard.
We have seen institutions arrive with robust entity-screening procedures that contained no wallet-level controls at all – a gap that blockchain analytics firms and regulators can identify in the first hour of a review. The reverse is also common: strong on-chain analytics with no structured Travel Rule data collection, leaving the operator exposed to FATF-based enforcement even where no sanction was actually breached.
How does Travel Rule compliance interact with sanctions screening?
The Travel Rule and sanctions screening are legally distinct obligations, but they share infrastructure and failure points that make them functionally inseparable for institutional operators.
Under the FATF-derived Travel Rule, a VASP must pass originator and beneficiary data – name, account number or wallet address and, at higher thresholds, identifying information – to the next institution in a transfer chain. The practical effect is that sanctions screening must happen twice: once on the originator's side before transmission and once on the beneficiary's side on receipt. A failure at either point creates regulatory exposure for the institution that processed the transfer.
The cross-border complexity here is significant. ESMA and the EU Transfer of Funds Regulation apply to CASPs operating under MiCA. The MAS in Singapore applies the Travel Rule under the Payment Services Act. The FCA in the UK applies its own version under the MLR. Japan's FSA, working alongside the JVCEA self-regulatory body, applies a Travel Rule framework calibrated to the Japanese market. These regimes are broadly aligned to the FATF standard but differ in threshold, data-field requirements and the treatment of transfers to unhosted wallets.
For an institutional operator moving assets between its own entities across jurisdictions – an EU CASP transmitting to a Singapore-licensed entity and onward to a VARA licensee in Dubai – every leg of that chain triggers the applicable Travel Rule in the originating jurisdiction. Each leg also requires a sanctions screen against the relevant lists for that jurisdiction. The compliance architecture must handle this automatically; manual processes at institutional volumes are not defensible.
In our practice, we regularly advise on the legal mapping exercise that precedes Travel Rule implementation: identifying which entities are VASPs under which regime, which transfers are subject to which threshold, and which data fields must be retained. That mapping is a prerequisite to selecting a Travel Rule solution – not something that can be delegated to a technology vendor without legal input.
What are the most common sanctions compliance failures at institutional crypto firms?
The most common failure is scope compression: treating sanctions screening as a subset of KYC rather than as a parallel, independently regulated obligation with its own enforcement regime and its own evidentiary standard.
The second failure is geographic tunnel vision. An operator licensed by VARA in Dubai may screen rigorously against OFAC and UAE Cabinet designations but miss the EU consolidated list entirely – despite having European institutional investors or Euro-denominated settlement flows. OFAC's jurisdictional reach extends to dollar-denominated transactions anywhere in the world, including stablecoin transfers denominated in USDC or USDT where Circle or Tether operates under US law.
The third failure is static list management. Sanctions designations are added and removed continuously. A compliance function that refreshes its screening lists on a weekly or monthly cycle is not meeting the real-time screening expectation that most major regulators now articulate, including under MiCA. Institutional-grade programs run continuous screening against live feeds.
The fourth failure is the absence of an escalation and de-listing procedure. When a transaction generates a hit – whether a true positive, a false positive against a name-alike or a wallet cluster association – the program must have a documented escalation path to a qualified MLRO (Money Laundering Reporting Officer), a decision record and, where required, a Suspicious Activity Report or equivalent filing. Regulators in the FSRA's Abu Dhabi framework, the MAS regime and the FCA's MLR regime all expect to see documented escalation histories in a supervisory review.
The fifth failure is the myth that a single offshore registration resolves the compliance obligation. A fund domiciled in the Cayman Islands under CIMA's VASP Act still faces OFAC exposure on any dollar-denominated transaction, EU restrictive measures on any EU-investor-facing activity and the FATF Travel Rule on any transfer to or from a VASP in a FATF member state. The Cayman registration is one layer of the stack, not the whole of it.
Which sanctions screening architecture is right for your profile?
The right architecture depends on the operator's entity structure, transaction type, counterparty base and the jurisdictions in which it holds licences or touches users. The following profiles illustrate the decision points in practice.
Profile A – EU-authorised CASP with institutional clients globally: The primary obligation is MiCA/ESMA compliance, but OFAC exposure is likely through dollar-denominated stablecoin flows and US-person counterparties. The architecture requires EU-list plus OFAC real-time screening, a Travel Rule solution compliant with the EU Transfer of Funds Regulation, wallet-level analytics and an MLRO function with documented escalation. Timeline to implement a defensible program: measured in weeks for legal mapping, followed by a technology procurement and integration cycle. The key risk is under-screening non-EU counterparties who interact through the platform.
Profile B – VARA licensee in Dubai with institutional custody and prime brokerage: VARA's rulebooks require AML/sanctions controls calibrated to UAE Cabinet decisions and UN designations, plus the FATF Travel Rule. If the entity also has a DIFC presence or is transacting with FCA-regulated counterparties in the UK, the FCA's financial-promotion and MLR rules layer on top. The architecture requires multi-list screening, VARA-specific documentation and a Travel Rule solution capable of handling Arabic-language UBO data. The key risk is the assumption that the UAE has no OFAC exposure – which is incorrect for any dollar-denominated transaction.
Profile C – Singapore MAS-licensed DPT service provider with cross-border institutional flows: The MAS Travel Rule applies to qualifying DPT transfers. Wallet-level screening and KYC on counterparty VASPs are expected. Where the operator is transacting with Japanese institutions, the FSA and JVCEA framework adds a layer. The key risk is unhosted wallet treatment: MAS has specific expectations for transfers to and from wallets not held at a regulated VASP, which differ from the EU approach under MiCA.
Profile D – Fund structured in Cayman/BVI with digital-asset NAV: The fund itself may not be a VASP, but its administrator, custodian and prime broker are. Sanctions screening at the fund level focuses on investor-side onboarding and counterparty-level due diligence. The key risk is that the fund assumes its service providers' compliance covers its own investor-level obligations. It does not. CIMA's VASP Act requires the registered entity to maintain its own compliant AML program.
If your structure has features of more than one profile above, the compliance architecture must address every applicable regime – not the most convenient one. To map the sanctions and Travel Rule stack for your build, write to OBOLUS at info@oboluslaw.com.Who runs the compliance function – and what does a regulator expect to see?
Every regulated VASP or CASP in the major licensing hubs must designate a qualified individual as the MLRO (Money Laundering Reporting Officer) – or its local equivalent – responsible for the day-to-day operation of the AML/sanctions program and for Suspicious Activity Report filings.
The MLRO function is a regulatory requirement under the FCA's MLR regime, under VARA's rulebooks, under the MAS Payment Services Act framework and under MiCA as implemented by national competent authorities. The FSRA in Abu Dhabi and the AFSA in the AIFC in Kazakhstan each apply comparable requirements. The MLRO must be a natural person, typically approved or notified to the regulator, with demonstrable competence in AML/CFT and sanctions compliance in the relevant jurisdiction.
In practice, we see two failure patterns at this layer. The first is nominating a compliance officer who covers AML nominally but has no digital-asset-specific training and no documented understanding of blockchain transaction monitoring or wallet-level screening. The second is structuring the MLRO as a shared-services function across multiple group entities without independent authority at the regulated entity level – a structure that supervisors in the major hubs have consistently questioned on examination.
Regulators audit AML programs by reviewing the documented risk assessment, the sanctions list refresh protocol, the escalation history, the MLRO's decision records and the outcomes of prior suspicious-transaction reviews. A program with strong policies but no evidence of live operation fails that review.
A micro-matter from our recent practice illustrates the stakes. A fund administrator in a common-law offshore jurisdiction had maintained a VASP registration under its national VASP regime but had never operationalised the compliance function. When it sought correspondent banking from a European institution, the bank's due-diligence team requested three years of MLRO reports, escalation logs and sanctions-screening evidences. There were none. We were engaged in the weeks before the banking deadline to build the retrospective compliance record, implement a live screening solution and produce the MLRO documentation the bank required. The banking relationship was secured, but the compressed timeline imposed significant cost that a proactive program would have avoided.
A common assumption: "Our technology vendor handles the compliance obligation."
A common assumption among institutional operators is that procuring a blockchain analytics platform or a Travel Rule solution transfers the legal compliance obligation to the technology vendor. It does not.
Technology vendors provide data and tooling. The legal obligation – under MiCA, under VARA, under the MAS Payment Services Act, under the FCA's MLR framework and under OFAC – sits with the regulated entity. The compliance function is responsible for configuring the tool to the applicable legal standard, for acting on its outputs, for documenting its decisions and for maintaining the program over time as lists change, as the business changes and as regulatory expectations develop.
We structure compliance mandates to cover the legal mapping layer – which obligations apply, to which entities, in which jurisdictions – and the implementation layer: the program design, the MLRO support and the documentation architecture that a supervisor expects to see. Technology selection follows legal mapping; it does not replace it.
Related at OBOLUS
Related at OBOLUS
- AML & Travel Rule for Digital Asset Businesses – the full practice overview covering every AML and Travel Rule service OBOLUS provides across jurisdictions.
- MLRO and Compliance Officer Function in Japan – FSA/JVCEA – jurisdiction-specific guidance on the compliance officer role under Japan's FSA and JVCEA self-regulatory framework.
- Sanctions Screening for Crypto for Regulated Entities – the counterpart service page addressing sanctions screening obligations for regulated (rather than institutional buy-side) entities.
FAQ
What does the Travel Rule require from a VASP?
Under the FATF-derived Travel Rule, a VASP must collect and transmit originator and beneficiary information – including name, account or wallet address and, above applicable thresholds, additional identifying data – to the next institution in a virtual-asset transfer chain. The obligation applies on both the sending and receiving sides. Domestic implementation varies in threshold and data-field requirements across jurisdictions, including the EU Transfer of Funds Regulation under MiCA, the MAS Payment Services Act framework, the FCA's MLR and the FSA/JVCEA regime in Japan.
Who must act as MLRO for a crypto firm?
A regulated VASP or CASP in the major hubs must designate a named natural person as the Money Laundering Reporting Officer – or the local equivalent. The MLRO must demonstrate AML/CFT and sanctions competence relevant to the jurisdiction. Most regulators, including the FCA, VARA, MAS and national competent authorities under MiCA, require the MLRO to be approved or notified before taking the role. The individual is personally responsible for SAR filings and for the day-to-day operation of the AML program.
How do regulators audit crypto AML programs?
Supervisors – including national competent authorities under MiCA, the FSRA in Abu Dhabi, VARA and MAS – typically audit AML programs by reviewing the documented risk assessment, sanctions list refresh procedures, transaction monitoring alert histories, MLRO decision logs and the outcomes of prior escalations. A program with strong written policies but no evidence of live operation consistently fails supervisory review. Regulators increasingly expect contemporaneous records of screening decisions, not retrospective reconstructions.
About OBOLUS
OBOLUS is an independent digital-asset law boutique acting exclusively for businesses. We advise exchanges, custodians, token issuers and institutional funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the AML, sanctions and Travel Rule compliance that sit around them. We structure licensing, banking and compliance as one mandate rather than three disconnected workstreams – mapping the full obligation stack before our clients commit capital or apply for a licence. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialist in multi-jurisdictional VASP compliance architecture, sanctions screening programs and AML frameworks for institutional digital-asset operators.
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.