Established crypto operators – exchanges carrying material transaction volumes, custodians holding client assets, and payment businesses routing cross-border stablecoin flows – face a compliance environment where a missed sanctions hit is no longer merely a regulatory finding. It is a banking event. Correspondent banks that detect a single screened-entity transaction have frozen entire institutional rails within hours. The question is not whether sanctions screening (the real-time or batch process of checking counterparty identities and wallet addresses against government-published sanctions lists) is required: every flagship regime now mandates it. The question is whether the program sitting inside your business will survive the audit that follows the next enforcement wave.
This page sets out the regulatory basis, the screening architecture regulators actually expect, and the specific failure points that surface in programs built for compliance on paper rather than compliance in practice. We address the cross-border reality – because the entity, the users and the banking rails almost never sit in the same jurisdiction – and we offer a decision matrix for operators deciding between in-house build, vendor deployment and hybrid counsel oversight.
The regulated basis for sanctions screening in digital-asset businesses
Sanctions screening for crypto operators is not a matter of regulatory preference. Under the FATF (Financial Action Task Force) Recommendation 15 framework, virtual asset service providers are treated as obliged entities with the same fundamental obligations as traditional financial institutions: they must not deal with sanctioned persons, entities or jurisdictions. National regulators – VARA in Dubai, the FCA under the UK Money Laundering Regulations, ESMA and national competent authorities under MiCA, MAS in Singapore, the SFC in Hong Kong – each implement this obligation through their own supervisory rulebooks, but the baseline is universal.
What differs across regimes is the granularity demanded. Some regulators expect daily batch screening against an approved list universe. Others require real-time wallet-level screening on every transaction. MiCA's CASP authorisation regime aligns with EU financial-sanctions law, which requires immediate and continuous screening. VARA's rulebooks carry explicit sanctions-compliance obligations as a condition of licence maintenance, not merely as an AML add-on. MAS, under the Payment Services Act, subjects Digital Payment Token licensees to the Monetary Authority of Singapore (Targeted Financial Sanctions) Notices. None of these regimes treats sanctions screening as optional for an established operator.
The cross-border dimension is where programs most often break. An exchange licensed in one EU member state and passporting under MiCA still faces the OFAC (Office of Foreign Assets Control) risk if US-dollar-denominated stablecoins move through its settlement layer. UK-listed entities face OFSI (Office of Financial Sanctions Implementation) obligations. A Cayman-domiciled fund whose sub-custodian banks in Switzerland picks up FINMA expectations layered onto the Cayman VASP Act regime. In our practice, operators almost always underestimate how many sanctions-law jurisdictions they are simultaneously operating in.
Contextual bridge: The standard path above describes the minimum regulatory position. Your actual exposure – shaped by which fiat rails you use, where your institutional counterparties bank, and where your beneficial owners are domiciled – shifts the analysis materially.
To map your full sanctions-law exposure before the next compliance review, contact OBOLUS at info@oboluslaw.com. An initial scoped assessment takes place under NDA. Map your options
What does effective sanctions screening actually look like for a crypto operator?
Effective sanctions screening for an established crypto business has three distinct layers: entity screening, wallet screening, and transaction monitoring – and regulators increasingly treat the absence of any one layer as a gap, not merely a gap in degree.
Entity screening is the process of checking the identities of customers, beneficial owners, counterparty businesses and counterparty officers against published sanctions lists – principally OFAC's Specially Designated Nationals list, the EU Consolidated List, HM Treasury's Financial Sanctions List, the UN Security Council Consolidated List, and relevant national lists. For an established operator, this must operate at onboarding and on a refresh cycle that captures new designations. Regulators expect the refresh to be frequent enough that a designation made on Monday morning does not survive to Tuesday's batch run without a hold.
Wallet screening is the layer most often misconfigured in established operator programs. The dominant approach is to screen deposit and withdrawal addresses against a proprietary or vendor-maintained list of addresses associated with sanctioned entities or high-risk actors. The better blockchain analytics vendors – Chainalysis, TRM Labs, Elliptic – maintain these lists and update them as on-chain forensic evidence is gathered. But an operator that screens only its own customer wallets, and not the intermediate wallets in a multi-hop transaction, has a program that will fail the OFAC standard. OFAC's guidance on virtual currency is clear that jurisdiction extends to any transaction that involves a US-nexus, regardless of where the exchange sits or what currency denomination the tokens carry.
Transaction monitoring sits across the top of both layers. A monitoring program calibrated only for AML typologies – structuring, layering, smurfing – will not catch a sanctions event unless the ruleset explicitly covers exposure to sanctioned jurisdiction IP addresses, high-risk cross-chain bridge activity, or counterparty-mixer interaction. In our cross-border practice, we have reviewed programs where the AML monitoring was technically sophisticated but the sanctions-specific rules had never been tuned beyond the out-of-the-box vendor defaults.
What are the most common sanctions-screening mistakes in established crypto programs?
The three failure points we see most consistently are: list coverage that is narrower than the operator's actual jurisdictional exposure; screening logic that operates at onboarding only; and a governance gap between the compliance function that runs the screen and the business function that processes the exception.
On list coverage: an operator with EU CASP authorisation that screens only the EU Consolidated List is legally compliant for its EU-regulated activity. But if that operator accepts deposits via a US-bank correspondent and distributes to counterparties through a UK-licensed custodian, its effective list universe must include OFAC and OFSI. Regulators, during an examination, look at the actual fund-flow map and ask which sanctions regimes a reasonable operator in that position ought to have screened against. The answer is almost never a single list.
On screening cadence: onboarding-only screening was the industry standard in an earlier era. It is no longer adequate. A customer who passes onboarding screening in January may be designated in March. The FCA's MLR expectations, VARA's rulebooks, and MAS guidance all contemplate ongoing monitoring that would surface this. Regulators describe this as "continuous" or "periodic" – the practical implementation is a scheduled re-screen run at a frequency matched to the volatility of the relevant lists.
On governance: the exception-management process is where programs most visibly collapse under examination. Screening produces hits – some genuine, many false positives. A genuine hit that is escalated to a compliance officer who lacks clear authority to freeze an account or reject a transaction, pending legal sign-off, is a gap. We regularly advise businesses on drafting the internal escalation matrix that closes this loop: who makes the freeze decision, on what authority, with what documentation and within what response window.
A fourth failure point specific to crypto: the assumption that a wallet-level screen at deposit is sufficient. Regulators and enforcement agencies are increasingly focused on the source-of-funds chain behind a deposit address, not just the address itself. A depositing wallet that is itself clean may be two hops from a sanctioned entity. Vendors now offer "indirect exposure" scoring. A program that ignores this will look inadequate to a post-event examiner.
How does the Travel Rule interact with a sanctions screening program?
The Travel Rule (the FATF obligation requiring VASPs to pass originator and beneficiary identification data with every qualifying virtual asset transfer) and a sanctions screening program are not separate compliance workstreams. They are architecturally linked, and the gap between them is one of the most significant structural vulnerabilities in established operator programs.
Under the Travel Rule, a VASP receiving a transfer must be able to verify that the originating VASP is itself a regulated, non-sanctioned entity. Where the originating VASP sits in a jurisdiction with no effective VASP regime – or where it is on a watch list – the receiving VASP's handling of that transfer is a sanctions-risk event, not merely a data-completeness gap. FATF's guidance on the Travel Rule explicitly addresses the treatment of transfers from or to VASPs in non-compliant jurisdictions.
In practice, this means the Travel Rule data – originator name, account number/address, beneficiary name, account number/address, and the originating VASP's identity – must feed into the sanctions screening workflow. The originator name and the originating VASP name each require a sanctions-list check. The originating VASP requires a counterparty due diligence check against a VASP registry or a commercial database. These steps must happen before the transfer is processed, not as a post-settlement compliance note.
Cross-border complexity intensifies here. The Travel Rule threshold – the minimum transfer value above which originator and beneficiary data must be sent – varies by jurisdiction. Some regimes have set a de minimis equivalent in their domestic currency; others apply a zero threshold. An established operator routing transfers between, for example, an EU-regulated CASP and a Singapore-licensed MPI must satisfy both regimes simultaneously. Aligning the data fields, the screening checks and the exception-management escalation across both requires a protocol that has been deliberately designed for the cross-border case, not retrofitted from a single-jurisdiction template.
How should an established operator structure its sanctions compliance across multiple licensing jurisdictions?
For an operator licensed in two or more jurisdictions – a common position for a European exchange with a MENA regulatory presence or an APAC platform with a Singapore DPT licence and a Hong Kong VATP application in process – the sanctions architecture question is one of centralisation versus local adaptation.
The centralised model runs a single global screening engine against a consolidated list set, with local parameters layered in at the jurisdictional level. The advantage is consistency: every transaction is screened against the same baseline universe. The risk is that a global engine that is not configured with local nuance can generate excessive false-positive rates in markets where naming conventions, transliteration variability and local-language character sets are not adequately handled. In our cross-border practice, we have seen centralised programs that work well in English-language markets and perform poorly in screening Arabic, Russian or Chinese names against the same engine.
The local adaptation model maintains jurisdictional compliance teams that run screening against locally mandated lists, with a central compliance function setting the minimum standards. This is more resilient to jurisdictional variation but creates a consolidation risk: no one is looking across the full entity map to detect a customer who passes the local screen in jurisdiction A but would fail the combined screen if jurisdictions A and B were assessed together.
The architecture we typically advise for established operators with a multi-jurisdiction presence combines a global baseline – the union of all applicable lists – with jurisdictional overlays and a central exception-reporting line to a single designated compliance function. Governance documentation must make clear which entity is the responsible MLRO for which regulated activity, and how escalations move between jurisdictions when a hit affects activity in more than one.
Banking and fiat-rail sanctions exposure requires a separate but integrated policy layer. Correspondent banks conduct their own OFAC screening on USD-denominated settlement. If the exchange's own screen misses a hit and the correspondent catches it, the result is account suspension. We have worked with operators where a correspondent-bank de-risking event was the first indication that the internal screening program had a gap. That is the worst possible discovery mechanism.
Contextual bridge: If a banking de-risking event has already occurred, or if a regulatory examination has raised questions about the adequacy of your screening program, a structured external review can identify the structural reason and map the remediation path before a formal finding is issued.
To commission a scoped review of your sanctions compliance architecture, write to OBOLUS at info@oboluslaw.com or reach us at t.me/oboluslaw. Map your options
Which sanctions-screening approach fits which operator profile?
The right screening architecture depends on the operator's regulatory footprint, transaction volume, asset types and institutional counterparty base. The following decision matrix sets out four operator profiles and the typical compliance posture each demands.
Profile A – Single-jurisdiction retail exchange with a CASP authorisation under MiCA: A daily batch entity screen against the EU Consolidated List plus OFAC is the regulatory floor. Wallet-level screening at deposit and withdrawal via an integrated blockchain analytics vendor is expected under MiCA and should be treated as standard. The Travel Rule requires a counterparty-VASP due diligence protocol for cross-border transfers. Timeline to configure this from scratch runs from several weeks to a few months depending on the vendor integration path. Key risk: underestimating OFAC exposure where EUR-USD exchange activity creates a US nexus.
Profile B – Multi-jurisdiction exchange with EU, MENA and APAC licences: A centralised global engine with jurisdictional overlays is appropriate. The list universe must cover at minimum: EU Consolidated List, OFAC SDN, HM Treasury (if UK banking rails are used), UN Consolidated List, and the domestic lists of each regulating jurisdiction. Governance must designate a global MLRO with cross-border authority. Timeline to architect and validate a multi-jurisdiction program from an existing single-jurisdiction base is typically measured in months. Key risk: list-coverage gaps at the intersection of jurisdictions and governance ambiguity on multi-jurisdictional hits.
Profile C – Institutional OTC desk or custodian serving professional clients: Entity screening at onboarding is table stakes. Continuous re-screening against a defined refresh cycle is necessary given client-designation risk. Counterparty due diligence – checking the regulated status and sanctions exposure of institutional counterparties, not just individual clients – is a differentiating requirement at this level. Key risk: counterparty VASP or broker with a sanctions exposure that only emerges post-onboarding.
Profile D – Stablecoin issuer or payment business routing cross-border flows: The highest-risk screening environment. Every transaction leg carries potential OFAC, OFSI and jurisdictional sanctions exposure. Real-time wallet screening and real-time entity screening against a multi-list universe is the operational standard expected by regulators in this segment. The Travel Rule data must feed into screening in real time. Key risk: a sanctioned-entity deposit that is processed before the screen completes, triggering an issuer freeze event and a regulatory notification obligation simultaneously.
A self-assessment checklist for established crypto operators
Before a regulatory examination or a banking due-diligence request arrives, operators should be in a position to answer each of the following questions with documented evidence, not a verbal assurance.
- Does the list universe reflect every jurisdiction in which you are licensed, where your users are domiciled, and where your banking and settlement rails are maintained – not merely the jurisdiction in which your primary regulator sits?
- Is entity screening continuous, with a re-screen cadence matched to list-update frequency – not onboarding-only?
- Does wallet screening cover indirect exposure (hop analysis) as well as direct address matching?
- Is the Travel Rule data-capture and screening workflow integrated – so that originator and originating VASP names are screened before a transfer is processed?
- Is the exception-management escalation matrix documented, with clear authority at each level, response-time standards, and a freeze-and-hold protocol that can be executed without legal sign-off delay?
- Has the program been independently tested or reviewed in the last twelve months, including the false-positive rate and the governance response to genuine hits?
- Are your banking partners' due-diligence requirements understood, and does your internal program meet those requirements – not merely your regulatory minimum?
A common assumption in the market is that a single offshore licence, paired with a basic AML policy document, is sufficient to operate globally and satisfy every banking relationship. It is not. Regulators in the leading hubs – VARA, MAS, the FCA, ESMA's national competent authorities – are examining the substance of the program, not the existence of a policy. The checklist above represents the substance standard an established operator is expected to meet.
A practical illustration
In a recent compliance-review engagement, a payments business operating under a European CASP authorisation and a MENA regulatory licence discovered, during pre-examination preparation, that its wallet screening was configured to check deposit addresses only at the point of the deposit – and was not re-checking those same addresses against updated vendor lists when withdrawals were requested. In the interval between deposit and withdrawal, two addresses had received indirect exposure scores that would have triggered a review. We redesigned the screening trigger logic to operate at both event points, updated the escalation matrix to cover cross-jurisdictional hits, and coordinated the documentation the client needed to present to its primary regulator. The examination proceeded without a formal finding on the screening program.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – the full practice overview covering AML obligations, KYC frameworks and compliance architecture across major regimes.
- Defending a regulatory AML audit: the disputes angle – how enforcement findings become disputes and how to structure a legal defence when a regulator has opened a file.
- Sanctions screening for regulated crypto entities – a companion service page covering screening requirements for entities under formal prudential supervision.
FAQ
What does the Travel Rule require from a VASP?
Under FATF Recommendation 15, a VASP must pass identifying information about the originator and the beneficiary – including names, account identifiers and, where applicable, address data – alongside every qualifying virtual asset transfer. The receiving VASP must verify that the originating VASP is itself regulated and not sanctioned. The data-transmission obligation applies at the threshold set by the relevant national regime; thresholds vary across jurisdictions. The Travel Rule obligation runs alongside, and feeds into, the sanctions-screening workflow: originator names must be checked before the transfer is processed.
Who must act as MLRO for a crypto firm?
Most regulated regimes require a designated Money Laundering Reporting Officer (MLRO) – a senior individual within the licensed entity with authority to make and receive suspicious-activity reports and to oversee the AML and sanctions-compliance program. The MLRO must be approved or notified to the relevant regulator in many jurisdictions, including under the FCA's MLR regime and under MiCA-aligned national regimes. For a multi-jurisdiction operator, the governance question of which MLRO carries authority for which regulated activity – and how cross-border hits are escalated – must be documented and tested, not left to informal practice.
How do regulators audit crypto AML programs?
Regulators audit crypto AML programs through a combination of document reviews, data extracts and supervised walkthroughs of the live system. Examiners will typically request the program policy document, the list-universe specification, evidence of re-screen cadence, a sample of genuine hits and the documented escalation outcome for each, transaction-monitoring rule sets and tuning logs, and the Travel Rule counterparty due-diligence records. Programs that exist only as policy documents, without operational evidence that the program runs as documented, consistently receive the most adverse findings. A well-maintained audit trail is not a procedural nicety – it is the primary defense.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the compliance, AML and Travel Rule architecture that regulators and banking partners expect. We map the licence stack across operating, custody and payment layers before you commit – and we structure licensing, banking and tax as one mandate rather than three disconnected workstreams. Digital assets are the whole of our practice. To discuss your sanctions-screening program or compliance posture, contact info@oboluslaw.com.
To pressure-test your sanctions-screening program before the next examination or banking due-diligence request, message us via t.me/oboluslaw or write to info@oboluslaw.com. Map your options
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML compliance architecture, sanctions-program design and Travel Rule implementation for multi-jurisdiction crypto 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.