Sanctions screening is a non-negotiable compliance obligation for every regulated entity touching digital assets. Under the Travel Rule (the FATF obligation requiring virtual asset service providers to pass originator and beneficiary data with every qualifying transfer), under MiCA's CASP authorisation regime, under VARA's activity-based rulebooks, and under the UK FCA's Money Laundering Regulations registration, the expectation is identical: screen before you onboard, screen at the point of transaction, and screen continuously against consolidated sanctions lists. Firms that treat this as a box-checking exercise – rather than a live risk-control function – face enforcement, account termination and, in the most serious cases, criminal exposure for senior management. This page sets out the regulated basis, the practical process, the cross-border pressure points, and how OBOLUS supports regulated entities in building screening programs that satisfy multi-jurisdictional review.
What is the regulated basis for crypto sanctions screening?
Every major licensing regime imposes sanctions screening as a distinct obligation, sitting alongside but separate from broader AML compliance (anti-money laundering) duties. The requirement derives from two converging sources: national sanctions law (which applies to all persons and entities within a jurisdiction regardless of sector) and sector-specific VASP or CASP rules that translate the FATF Recommendations into binding operational standards. Under MiCA, a CASP authorisation requires an applicant to demonstrate a functioning compliance program, which regulators interpret to include real-time screening against EU consolidated sanctions lists and the UN consolidated list. Failure at authorisation stage is common; failure post-authorisation triggers supervisory action.
The VARA regime in Dubai takes a similar line. Activity-based licences under VARA each carry compliance conditions that address sanctions screening explicitly. Regulators in the UAE – both VARA on the mainland and the FSRA within ADGM – treat the absence of a documented screening methodology as a material deficiency, not a minor gap. In our practice, we see applications stall precisely because the compliance manual describes a process that the underlying technology cannot actually execute.
Outside the EU and UAE, the regulatory picture is consistent in direction if varied in detail. The FCA's MLR registration for UK cryptoasset businesses requires firms to demonstrate adequate AML and sanctions controls. The MAS Payment Services Act licensing in Singapore sets expectations for KYC and screening that mirror FATF standards. The SFC's VASP licensing regime in Hong Kong, the AFSA framework in the AIFC, and the CIMA regime in the Cayman Islands all incorporate sanctions screening as a threshold compliance condition. The principle is universal: the licence is a permission to operate, not a waiver of the obligation to screen.
What does sanctions screening actually mean for a crypto business?
Effective sanctions screening for a crypto regulated entity has three distinct layers, each with its own technical and legal requirements. The first is name-based screening: checking counterparty names, beneficial owners and controlling persons against applicable sanctions lists at onboarding and at periodic intervals thereafter. The second is wallet-address screening: checking blockchain addresses against known sanctioned addresses published by OFAC, the EU, HMRC's OFSI and other competent authorities, as well as against addresses flagged by forensic tools. The third is transaction monitoring: real-time or near-real-time pattern analysis to detect transactions that may involve sanctioned actors or jurisdictions, even where the address itself does not appear on a published list.
Name-based screening is a known discipline that most compliance teams understand. Wallet-address screening is the dimension that distinguishes crypto sanctions compliance from its TradFi equivalent, because blockchain addresses are pseudonymous: a sanctioned person may use any number of addresses, and published lists lag operational reality. Forensic tooling from providers such as those active in the blockchain analytics space helps bridge that gap, but the tooling must be integrated into the transaction workflow, not run as a periodic offline check.
Transaction monitoring in the crypto context intersects with Travel Rule obligations. Where a VASP must pass originator and beneficiary data with a qualifying transfer, that data also constitutes the input for a screening check on the receiving side. A firm that routes Travel Rule data through one system and runs sanctions checks through another – without a documented reconciliation step – creates a structural gap that regulators and auditors will find quickly. We regularly advise clients on the architecture that closes this gap before an examination opens it.
For a scoped assessment of your screening program's coverage and gaps, contact OBOLUS at info@oboluslaw.com. The process above describes the standard framework. Your entity type, user geography and product mix change the analysis materially. Map your options
Why does cross-border operation amplify sanctions risk?
A crypto firm that operates across jurisdictions is subject to multiple, sometimes overlapping sanctions regimes simultaneously, and the obligations do not simply stack – they interact in ways that require active management. A CASP authorised in an EU member state and passporting across the EU/EEA must screen against the EU consolidated list. If that same firm onboards US persons or processes USD-denominated transactions, OFAC's reach is triggered regardless of where the entity sits. If the firm offers services in the UAE, VARA compliance conditions and UAE federal sanctions obligations apply in parallel.
The cross-border dimension is sharpest in three scenarios. First, a firm headquartered in one jurisdiction but banking in another: the bank's own compliance program may generate a suspicious activity flag on a transaction the firm considers clean, because the bank is screening against a different list or using different risk-scoring criteria. Second, a firm serving users in high-risk jurisdictions: FATF-listed jurisdictions attract enhanced due diligence requirements under most licensing regimes, and a VASP that fails to apply those requirements uniformly across its user base – regardless of where it is licensed – is exposed. Third, a firm that uses a correspondent banking or payment rail relationship: the correspondent's compliance obligations flow through to the VASP, and a sanctions hit in the correspondent's screening can terminate a banking relationship without notice.
In our cross-border practice, we see firms underestimate the OFAC extraterritorial reach problem most often. OFAC's jurisdiction is not limited to US persons or US soil. Any transaction that touches a US financial institution, clears in USD or involves a US-listed entity can bring a firm within OFAC's enforcement perimeter regardless of where that firm is licensed. The practical consequence: a firm with a clean VARA licence and no US presence may still face OFAC exposure if it processes USDT settlements through a correspondent with US nexus.
What are the most common sanctions screening failures regulators find?
Regulators across the leading licensing hubs have converged on a consistent list of deficiencies when they examine crypto AML and sanctions programs. Understanding these failure patterns is the fastest way to assess the risk profile of an existing program.
- List coverage gaps. A firm screens against one or two lists – often only the UN consolidated list and one domestic list – but omits others that apply given its user geography. An EU-licensed firm that omits the EU consolidated list, or a firm with UK users that omits OFSI, is non-compliant by definition.
- Static wallet screening. Running a wallet-address check only at account opening, without re-screening when a new address is submitted for withdrawal or when a published list is updated, creates a window of exposure that regulators treat as a systemic failure.
- Ownership and control blind spots. Screening the named counterparty but not the beneficial owner chain. Under most KYC regimes, a beneficial owner is any person holding a defined ownership or control threshold; failing to screen that layer is a routine examination finding.
- No escalation protocol. A screening alert that is cleared by a junior analyst without a documented escalation pathway and a senior sign-off creates liability for the firm and, in some jurisdictions, for individual managers.
- Travel Rule data not feeding the screening workflow. As noted above, originator and beneficiary data collected under Travel Rule obligations is also screening input. Firms that keep these workflows separate routinely miss matches.
- Outdated sanctions lists. Lists are updated without regular cadence; a firm that pulls a batch update weekly rather than daily or in real time may be operating on stale data during an update window.
The consequence of any of these deficiencies is not merely regulatory. A single undetected sanctions breach can result in the termination of banking relationships, the freezing of balances held by a payments processor, and in the US context, civil monetary penalties from OFAC that are calculated per transaction regardless of whether the firm was aware of the sanction.
What governance structure does a regulated crypto entity need?
Effective sanctions and AML governance requires three structural elements that regulators in every major hub now treat as baseline: a designated compliance officer or Money Laundering Reporting Officer (MLRO), a written compliance program, and a testing and audit function that sits independent of the first-line compliance team.
The MLRO role carries personal liability in most licensing regimes. Under the FCA's MLR framework, under VARA's compliance conditions and under MAS requirements, the MLRO is a named, approved individual who is responsible for the firm's compliance with AML and sanctions obligations. That individual must have the authority, the budget and the direct board access to escalate concerns and propose remediation. Regulators assess the MLRO's suitability as part of the licence application; a nominee who lacks practical crypto-AML experience is a common application failure point.
The written compliance program must address sanctions screening specifically – not as a sub-paragraph of a general AML policy, but as a documented methodology that specifies the lists screened, the frequency, the tooling used, the alert-management workflow and the escalation path. ESMA and national competent authorities under MiCA have signalled that a generic TradFi compliance template repurposed for a CASP application is unlikely to satisfy the authorisation standard. The crypto-specific elements – wallet screening, Travel Rule integration, blockchain analytics – must be visible in the documentation.
The testing function is where many firms fall short. Periodic internal audit of the sanctions program – testing alert quality, reviewing cleared alerts against current lists, stress-testing the escalation workflow – is not optional. Regulators increasingly expect a documented audit trail that demonstrates the program is live, not just written down.
If a prior compliance build stalled an application or generated a regulatory query, a structured second read can identify the gap and the route to resolution. Write to us at info@oboluslaw.com or map your options here.
A matter in practice: remediation before a supervisory review
In a recent compliance engagement, a payments-focused exchange holding a licence in a Gulf jurisdiction was notified of an upcoming supervisory review by its regulator. The firm's sanctions screening program had been built on a name-based list model without wallet-address screening or Travel Rule data integration. We conducted a gap analysis against the applicable rulebook requirements, identified three structural deficiencies – static list coverage, no beneficial-owner screening layer, and a Travel Rule workflow that ran parallel to rather than through the sanctions check – and supported the remediation of all three before the review window opened. The regulator's examination found no material deficiency in the sanctions function. The firm retained its licence and its primary banking relationship.
Which screening model is right for your entity profile?
The right sanctions screening architecture depends on the entity type, the product mix and the jurisdictions in play. A decision framework by operator profile helps clarify the fit.
Profile A – Single-jurisdiction exchange, retail and institutional users, one primary banking relationship. The minimum viable screening model covers name-based onboarding screening against all applicable domestic and international lists, real-time wallet-address screening at deposit and withdrawal, and a daily list-update cadence. Travel Rule data must feed the screening workflow. An internal MLRO with designated authority is the governance minimum. Key risk: list-update lag and the absence of enhanced due diligence triggers for high-risk user profiles.
Profile B – Multi-jurisdiction CASP with EU passporting, USD settlement rails and a user base in FATF-monitored jurisdictions. The screening architecture must cover EU, UN, OFAC, OFSI and any jurisdiction-specific lists relevant to the user base. Wallet-address screening must be real-time, not batch. Enhanced due diligence protocols must be triggered automatically for users from listed jurisdictions. The Travel Rule integration must be bilateral: screening the inbound counterparty VASP as well as the end user. Key risk: OFAC extraterritorial exposure through USD settlement and the failure to apply enhanced due diligence consistently across the user base.
Profile C – Custodian or fund administrator, institutional clients only, cross-border custody of tokenised assets. The screening model focuses on entity-level KYC with deep beneficial-owner screening and periodic re-screening against a broader list stack that includes sector-specific designations (e.g., export control lists). Transaction volume is lower; alert quality matters more than alert throughput. The MLRO function should sit at or near board level given the institutional risk profile. Key risk: beneficial-owner screening gaps where client structures include intermediate holding layers across multiple jurisdictions.
In each profile, the common thread is integration: a screening program that lives in separate systems from the onboarding, Travel Rule and transaction monitoring functions creates seams that regulators and, in the event of a breach, enforcement authorities will find. We map the full compliance architecture, not just the screening layer in isolation.
A common assumption that deserves correction
A common assumption among operators entering their first regulated jurisdiction is that a single offshore licence, typically obtained in a lightly supervised hub, is sufficient to serve clients globally. That assumption is wrong in two directions. First, most licensing regimes define the regulated activity by reference to where the service is received or where the user is located, not only where the firm is incorporated. A firm with a Cayman VASP registration that actively markets to EU residents, processes transactions for UK users or settles in USD through a US correspondent bank is likely subject to MiCA, FCA and OFAC requirements in addition to CIMA's rules – whether or not it has sought authorisation in those jurisdictions. Second, the sanctions screening obligation does not follow the licence; it follows the transaction. Every transfer, regardless of the entity's licensing status, is subject to the sanctions laws of the jurisdiction whose currency, infrastructure or users are involved. Operating without the right licence, or with a licence that does not match the actual user base, exposes the business to enforcement, frozen banking rails and, in the most serious cases, loss of the licence itself.
Self-assessment checklist for regulated entities
- Is your sanctions list coverage documented, and does it include every list applicable to your user geography and settlement currency?
- Is wallet-address screening real-time at the point of each deposit and withdrawal, not only at onboarding?
- Does your Travel Rule data workflow feed directly into your sanctions screening system, or does it run on a separate track?
- Is beneficial-owner screening applied at the depth required by your primary licensing regime and any secondary jurisdictions in play?
- Is your MLRO a named, approved individual with documented authority, budget and board access?
- Is there a written escalation protocol for sanctions alerts, with senior sign-off requirements and a documented audit trail?
- How frequently are your lists updated? Daily or real-time updates are increasingly the regulatory expectation.
- Has your sanctions program been independently audited in the past twelve months?
- Does your compliance program address OFAC extraterritorial reach if you settle in USD or serve US persons?
- Is your compliance documentation crypto-specific, or does it repurpose a TradFi template without addressing wallet screening, blockchain analytics or the Travel Rule?
Any "no" in this list is a material compliance gap. In our practice, firms that work through this checklist before a regulatory examination or a banking relationship review are significantly better positioned than those that encounter these questions for the first time from an examiner.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – the full practice overview across sanctions, KYC and transaction monitoring
- Sanctions screening for crypto in Australia under AUSTRAC – jurisdiction-specific obligations for AUSTRAC-registered entities
- Crypto exchange setup in Australia under AUSTRAC – licensing, registration and compliance baseline for Australian operators
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 15 and implemented across most major licensing regimes, requires a VASP (virtual asset service provider) to collect, verify and transmit originator and beneficiary information with every qualifying virtual asset transfer. The required data typically includes names, account identifiers and, for higher-value transfers, address and identification details. The threshold at which the obligation activates varies by jurisdiction and should be confirmed against current local implementing rules. Non-compliance is treated as an AML deficiency, not a technical breach.
Who must act as MLRO for a crypto firm?
A Money Laundering Reporting Officer (MLRO) must be a named, senior individual with genuine authority over the firm's AML and sanctions function. Most licensing regimes – including the FCA's MLR framework, VARA's compliance conditions and the MAS Payment Services Act – require the MLRO to be approved by or notified to the regulator. The individual must have relevant experience, access to the board, and the operational authority to escalate concerns and enforce remediation. A nominee MLRO with no practical crypto-compliance background is a common application and examination failure point.
How do regulators audit crypto AML programs?
Regulatory examinations of crypto AML programs typically combine document review, transaction-sample testing and interviews with compliance personnel. Examiners will request the written compliance program, risk assessment, sanctions list coverage documentation, records of alert management and escalation, and evidence of periodic independent audit. In the crypto-specific context, examiners increasingly test wallet-address screening methodology and Travel Rule data integration. A firm that can produce a clean, dated audit trail – showing that alerts were reviewed, cleared by a named individual and escalated where required – is materially better positioned than one that can only produce the policy document.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on AML compliance, sanctions screening, Travel Rule implementation and licensing across more than seventy jurisdictions and on disputes and on-chain asset recovery across more than twenty-five forums. Digital assets are the whole of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before a client commits to a structure. To discuss your sanctions program, a regulatory examination, or the cross-border compliance architecture for a new build, contact info@oboluslaw.com or reach us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialises in cross-border AML program design, sanctions screening architecture and VASP compliance across EU, Gulf and Asia-Pacific 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.