Crypto businesses operating across borders face a sanctions environment that has grown materially more complex. Sanctions screening for crypto under heightened scrutiny is no longer a checkbox — it is an operational and legal obligation that cuts across every layer of the business: the entity, the user, the counterparty wallet, and the stablecoin issuer. Under the Travel Rule (the obligation to pass originator and beneficiary data alongside a virtual asset transfer), under FATF Recommendation 15 governing virtual assets, and under the national AML/CFT regimes that flow from both, a gap in screening is a gap in your licence. This page maps the legal basis, the process, the common failure points, and the cross-border complications that catch operators without specialist counsel.
The standard path below describes how a well-structured crypto business builds and maintains a sanctions-screening programme. Your facts — the entity jurisdiction, the user base geography, the settlement rails, and the stablecoin exposure — change the analysis at every step. To map the compliance architecture for your build, contact OBOLUS at info@oboluslaw.com.
Why "Heightened Scrutiny" Changes the Compliance Calculus
Heightened scrutiny in the sanctions context means a regulator or correspondent bank has flagged a business, a product type, or a geographic nexus as carrying elevated sanctions risk — warranting controls that go beyond standard name-screening. For crypto firms, that designation has become routine rather than exceptional.
The reason is structural. A virtual asset service provider (VASP) typically serves users in multiple jurisdictions from a single licensed entity, settles through stablecoin rails that themselves have issuer-level freeze authority, and processes transfers that are pseudonymous by design. FATF's guidance on virtual assets — particularly Recommendation 15 — explicitly requires enhanced due diligence where a VASP relationship carries higher risk. Correspondent banks, which remain the gateway to fiat on- and off-ramps, apply their own heightened-scrutiny overlays on top of the regulatory floor, and they pull relationships without notice when those overlays are not satisfied.
In our practice, we see the following triggers most frequently: a VASP operating from a jurisdiction that is itself on an FATF grey or black list; a product that touches privacy-enhancing protocols; a user base with significant volume from high-risk countries; and a legal structure that involves multiple entities with unclear beneficial ownership. Each trigger increases both the regulatory expectation and the due-diligence load on banking partners.
Operating under heightened scrutiny without a programme calibrated to that designation — rather than to the baseline — is one of the fastest routes to enforcement and account closure simultaneously.
What Is the Legal Basis for Crypto Sanctions Screening?
Sanctions screening obligations for crypto businesses derive from three interlocking sources: national autonomous sanctions regimes, multilateral frameworks, and AML/CFT licensing conditions. The interaction of these three is where most compliance programmes fail to achieve full coverage.
At the multilateral level, FATF Recommendation 15 and the associated guidance for virtual assets and VASPs establish the expectation that VASPs will screen customers, transactions, and counterparties against applicable sanctions lists, and that enhanced measures apply in higher-risk scenarios. Every jurisdiction that has implemented a VASP licensing regime — including under MiCA in the EU, the VARA regime in Dubai, the MAS Payment Services Act in Singapore, the SFC VASP regime in Hong Kong, and the FCA's anti-money laundering registration in the UK — incorporates this expectation either directly or by reference.
National autonomous regimes add a further layer. A VASP licensed in an EU member state screens against EU autonomous sanctions designations, UN consolidated lists, and the domestic lists of the member state. A VASP with US users or US dollar settlement rails faces OFAC jurisdiction, which applies to US-nexus transactions regardless of where the firm is incorporated. The AFSA regime within the AIFC in Kazakhstan incorporates UN and domestic sanctions lists. The ADGM's FSRA in Abu Dhabi similarly applies UAE federal sanctions alongside the UN framework.
The cross-border consequence: a VASP with one licence can face four or more parallel screening obligations depending on its user geography, settlement rails, and stablecoin issuers. A compliance programme that covers only the licensing jurisdiction's list fails the others — and the correspondent bank will find out before the regulator does.
How Do You Build a Sanctions Programme That Satisfies Heightened Scrutiny?
A sanctions programme adequate for heightened scrutiny requires five operational layers, each of which must be documented and periodically tested. The documentation requirement is not a formality — under the major AML inspection frameworks, the absence of written policy is itself a finding.
First, list coverage. The programme must identify every sanctions list applicable to the business given its entity jurisdiction, user geography, and settlement nexus. For most multi-jurisdiction VASPs this means the UN Consolidated List, OFAC's Specially Designated Nationals list, EU consolidated financial sanctions lists, and the lists of one or more additional competent authorities. The list universe should be reviewed whenever the firm opens a new user corridor or adds a new settlement rail.
Second, wallet-level screening. Name-screening is necessary but not sufficient for crypto. The business must also screen wallet addresses — both at onboarding and in real time as transactions are processed — against blockchain analytics databases that track addresses linked to designated persons, sanctions-evasion typologies, darknet market clusters, and mixer services. Under MiCA and the VARA rulebooks, a VASP is expected to demonstrate transaction monitoring that detects these patterns; under the FATF virtual asset guidance, it is implicit in the general risk-based approach. In our cross-border practice, we regularly advise operators whose KYC framework is strong but whose wallet screening is limited to a single vendor list — a gap that regulators and correspondent banks increasingly identify on first inspection.
Third, the Travel Rule data layer. Every originating VASP must transmit originator and beneficiary identifying information alongside transfers above the applicable de-minimis threshold. The Travel Rule interacts with sanctions screening because the transmitted data creates the pool from which sanctions hits are identified on the beneficiary side. A VASP that receives a transfer without the required Travel Rule data — a "sunrise problem" scenario — must have a policy for how to handle that transfer before processing it. Accepting a transfer without counterparty data and without a sanctions check is a compliance failure under most flagship regimes.
Fourth, enhanced due diligence triggers. The heightened-scrutiny programme must define exactly which customer or transaction profiles automatically escalate to enhanced due diligence: PEP relationships, high-risk jurisdiction nexus, privacy-coin transactions, transfers from unhosted wallets above defined thresholds, and relationships flagged by blockchain analytics as high-risk. Triggers must be documented, tested, and updated as the firm's risk profile evolves.
Fifth, hit management and escalation. A screening match — whether on a name list or a wallet address — requires a clear escalation path to the MLRO (Money Laundering Reporting Officer, the designated individual responsible for AML oversight within the firm), a documented assessment, a defensible decision, and, where required, a suspicious transaction report. The speed and quality of that escalation is what a regulator examines when a hit was not blocked in time.
What Cross-Border Complications Do Multi-Jurisdiction VASPs Face?
For a business sitting between two or more licensing hubs — say, a VARA-licensed Dubai entity settling through USDC rails with a European user base — the legal question turns on which screening obligations apply simultaneously and how conflicts between them are resolved.
The most acute conflict is jurisdictional scope. OFAC's reach extends to transactions with a US nexus, and that nexus is broadly construed: US dollar settlement, a US correspondent bank, a US beneficial owner in the VASP's cap table, or a US-resident user can each be sufficient. A VASP that believes its non-US licence immunises it from OFAC exposure has misread the regime. This is one of the most persistent myths in the market, and it is the reason correspondent banks — which are subject to OFAC directly — impose their own screening requirements on VASP clients regardless of where the VASP is licensed.
Stablecoin rails add a further dimension. Tether (USDT) and Circle (USDC) both hold contract-level freeze authority over their issued tokens and generally act on law enforcement designation or OFAC action. A VASP that processes a transaction involving a designated wallet may find the settlement leg frozen at the issuer level — after the fiat leg has moved. The operational risk is significant, and the legal exposure under the applicable AML regime is separate from the economic loss. The programme must therefore include pre-settlement screening of stablecoin addresses, not post-settlement remediation.
Banking relationships create a third vector. Correspondent banks apply their own Enhanced Due Diligence frameworks to VASP clients, typically requiring evidence of list coverage, wallet screening methodology, Travel Rule compliance posture, and MLRO governance. In our practice, we have seen operators who passed their licensing jurisdiction's AML review lose their banking relationship within six months because the bank's internal heightened-scrutiny policy set a higher bar. The two frameworks are not the same and cannot be satisfied by one document.
A VASP with significant volume from FATF grey-listed jurisdictions faces a compounding problem: the regulator expects enhanced due diligence for those users, the bank expects enhanced due diligence for that user base, and the Travel Rule requires counterparty data that may be unavailable or unreliable from correspondents in those same jurisdictions. Managing all three simultaneously requires a programme designed for that overlap, not three separate policies that do not speak to each other.
To pressure-test your sanctions programme against the banking and regulatory exposure points specific to your structure, write to info@oboluslaw.com.
What Are the Most Common Failures in Crypto Sanctions Programmes?
The failure modes in crypto sanctions programmes are specific and recurring. Recognising them early is less costly than remedying them under regulatory scrutiny.
The first is list lag: a sanctions list is updated — a new designation is published by OFAC or the EU — and the VASP's screening system is not configured to update automatically. In the hours between designation and system update, a transaction processes that should have been blocked. In the stablecoin context, that transaction may be irreversible at the blockchain level even if the issuer subsequently freezes the wallet. The solution is a contractual SLA with the screening vendor requiring near-real-time list synchronisation and documented testing at defined intervals.
The second is wallet address coverage gaps. Many compliance programmes screen names and passport numbers at onboarding but screen wallet addresses only on deposit, not on withdrawal. Withdrawal destinations — particularly to unhosted wallets — require screening against the same blockchain analytics datasets that flag sanctioned addresses and darknet-linked clusters. The VARA rulebooks and the FATF virtual asset guidance both implicitly require this; the FCA's supervisory expectations for UK-registered firms increasingly reflect it.
The third is inadequate Travel Rule reconciliation. A VASP that receives Travel Rule data from a counterparty VASP and routes it to a separate system from its sanctions-screening workflow creates a data silo. The originator data that should feed the screening engine sits in a compliance database that does not talk to the transaction-monitoring system. The result is a theoretical Travel Rule compliance posture that delivers no actual sanctions-detection benefit.
The fourth — and most significant when it comes to heightened scrutiny specifically — is a programme calibrated to the standard risk tier when the regulator or bank has flagged the firm as high-risk. Standard transaction monitoring thresholds, standard EDD triggers, and standard escalation timelines are not adequate under a heightened-scrutiny designation. The programme must be expressly recalibrated when the designation changes, and the recalibration must be documented.
Decision Matrix: Which Screening Architecture Fits Which Operator?
Different operator profiles require different programme architectures. The matrix below describes the dominant profiles we encounter and the structural implications for each.
Profile A: EU-licensed CASP under MiCA, servicing retail users across the EEA, settling in USDC. This operator screens against EU consolidated lists, UN lists, and — because of USDC — must satisfy OFAC nexus risk even without a US licence. The Travel Rule applies across EEA transfers with a de-minimis threshold set by the applicable national transposition. The programme requires near-real-time list updates, wallet-level screening on both deposit and withdrawal, and a Travel Rule data architecture that integrates with the sanctions-screening layer. Timeline to build a compliant programme from scratch is typically a matter of months, not weeks, given the technical integration requirements.
Profile B: VARA-licensed Dubai exchange, significant volume from high-risk jurisdictions, correspondent bank in a third country. This operator faces VARA's own AML rulebook, UAE federal sanctions obligations, UN lists, and — if the correspondent bank is a US institution or a European bank with its own OFAC overlay — effectively a fourth screening layer. The heightened-scrutiny designation is almost automatic given the user base geography. The programme must include enhanced due diligence for high-risk-country users, a blockchain analytics workflow that covers FATF grey-list typologies, and documentation sufficient to satisfy both VARA on inspection and the correspondent bank's own VASP due-diligence questionnaire.
Profile C: BVI-registered fund with digital-asset exposure, no direct user business, assets held through a third-party custodian. This operator does not run its own VASP programme but remains subject to CIMA's AML framework and, if the custodian is a US institution, OFAC nexus risk through the custodian. The key compliance question is whether the fund's own KYC framework captures beneficial ownership in a way that satisfies the custodian's heightened-scrutiny requirements. The risk is downstream: a custodian that terminates the relationship because the fund's compliance posture does not meet its internal standard, with no regulatory warning as a precursor.
Profile D: Growth-stage VASP with a single EU licence seeking to onboard institutional counterparties. Institutional counterparties — prime brokers, OTC desks, custodians — conduct their own due diligence on the VASP before onboarding. That due diligence typically includes a review of the sanctions programme, the MLRO's credentials, the Travel Rule solution, and the blockchain analytics vendor stack. A programme that was built to satisfy the licensing application but has not been updated since is unlikely to pass an institutional counterparty review without remediation.
Objection Handler: "Our Offshore Licence Covers All Our Users"
A common assumption among early-stage crypto operators is that a single offshore licence — from a low-friction jurisdiction with a light-touch AML framework — is sufficient to serve a global user base. It is not.
A licence from a jurisdiction with a less-developed AML regime does not immunise the VASP from the obligations that attach to its users, its settlement rails, or its banking relationships. OFAC jurisdiction follows the US-nexus test, not the VASP's incorporation address. MiCA applies to crypto-asset service providers offering services to EU residents regardless of where the CASP is established. The MAS in Singapore asserts jurisdiction over digital payment token services directed at Singapore users.
More practically: a correspondent bank evaluating a VASP client applies its own compliance standard — which is typically aligned to the most demanding regime in its own regulatory footprint — as a condition of the relationship. An offshore licence that does not meet that standard results in account refusal, not account opening.
The structural consequence of this myth playing out in practice is predictable: the VASP operates for some months, the banking relationship is terminated when the bank's enhanced due diligence review identifies the gap, and the operator faces a retrofit exercise under time pressure. We map the licence, banking, and compliance stack as a single mandate before the operator commits, specifically to avoid that sequence.
How Does MLRO Governance Support a Heightened-Scrutiny Programme?
The MLRO is the individual at the centre of sanctions compliance. Under the AML frameworks of every major VASP licensing regime — MiCA, VARA, MAS, FCA, SFC — the firm must appoint a natural person with the seniority, resources, and independence to discharge the MLRO function effectively.
Under heightened scrutiny, the governance requirements intensify. The MLRO must have direct access to transaction monitoring outputs, a clear escalation path to the board or executive committee, and documented authority to file suspicious transaction reports without prior approval from the business line. In our cross-border practice, the most common governance deficiency we identify is an MLRO who has the title but not the operational independence — typically because the role is held by a senior business executive rather than a dedicated compliance professional.
Regulators in the leading hubs increasingly expect the MLRO to be resident in the licensing jurisdiction or demonstrably accessible to the local regulator. VARA's rulebooks specify fitness and propriety requirements for the compliance function. The MFSA under the transitional VFA framework and — going forward — the MiCA CASP authorisation in Malta have similar expectations. A nominee MLRO who cannot demonstrate operational involvement in the programme is a finding waiting to happen.
In a recent compliance matter, a payments company operating under a dual-jurisdiction licence had appointed an MLRO who was resident in a third country and had no documented access to the transaction monitoring system. When the correspondent bank requested evidence of MLRO oversight as part of its enhanced due diligence review, the documentation could not be produced. We restructured the compliance function and documented the oversight chain; the banking relationship was retained, and the regulator's subsequent supervisory review did not identify a governance deficiency.
Self-Assessment: Is Your Programme Ready for Heightened Scrutiny?
The following checklist does not replace a legal review, but it identifies the questions a regulator or correspondent bank will ask at first inspection.
- Does the programme expressly identify every sanctions list applicable to the firm given its entity jurisdiction, user geography, and settlement rails — including OFAC where US-nexus risk exists?
- Is wallet-level screening applied at both deposit and withdrawal, with automated updates from a blockchain analytics vendor whose list is synchronised to within hours of a new designation?
- Does the Travel Rule data architecture feed directly into the sanctions-screening workflow, so that originator and beneficiary data from incoming transfers is screened before settlement?
- Are EDD triggers defined, documented, and set at a level appropriate to the firm's heightened-scrutiny designation — not to the standard-risk baseline?
- Does the MLRO have documented operational independence, resident access to transaction monitoring outputs, and an escalation path to the board that does not pass through the business line?
- Has the programme been tested by a third-party review within the past twelve months — not just self-assessed?
- Does the compliance documentation package answer the correspondent bank's VASP due-diligence questionnaire, not only the regulator's licensing conditions?
If the answer to any of the above is uncertain, the gap is worth addressing before the next regulatory or banking review rather than after.
If a prior programme review identified deficiencies, or if a banking relationship is under threat, contact OBOLUS at info@oboluslaw.com for a scoped compliance assessment.
Related at OBOLUS
- Compliance, AML & Travel Rule for Digital Asset Businesses – the full practice overview covering AML, Travel Rule and compliance architecture
- MLRO and Compliance Officer Function – Legal Counsel – structuring and supporting the MLRO role for regulated crypto firms
- Sanctions Screening for Crypto – Regulated Entities – sanctions screening obligations for already-licensed VASPs and CASPs
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect and transmit originator and beneficiary identifying information alongside virtual asset transfers above the applicable de-minimis threshold. The obligation applies to both the sending and receiving VASP. Under FATF Recommendation 15, this data must be made available to competent authorities on request. Most flagship regimes — MiCA, VARA, MAS, and the FCA registration — incorporate Travel Rule obligations either directly or through AML/CFT licensing conditions. A VASP that receives a transfer without the required counterparty data must have a documented policy for handling the gap before processing the transaction.
Who must act as MLRO for a crypto firm?
Every regulated crypto firm must appoint a natural person as its MLRO — the individual responsible for receiving internal suspicious activity disclosures, assessing them, and filing reports with the relevant financial intelligence unit. The MLRO must have seniority, operational independence, and documented access to the firm's transaction monitoring outputs. Under the VARA rulebooks, the MFSA's VFA/MiCA framework, and the FCA's AML registration requirements, the MLRO must satisfy fitness and propriety criteria set by the regulator. A nominee MLRO without operational involvement is a governance deficiency that regulators in the leading hubs identify on supervisory inspection.
How do regulators audit crypto AML programs?
Regulators audit crypto AML programmes through a combination of document review, transaction-data sampling, and interviews with the MLRO and senior management. Inspection focus areas typically include: the completeness of sanctions list coverage, the integration between Travel Rule data and transaction monitoring, the documentation of EDD triggers and escalation decisions, and the independence of the MLRO function. Under MiCA, VARA, MAS, and the SFC VASP regime, regulators have authority to request system access and to test screening tools directly. A programme that is well-designed on paper but lacks testing records and documented hit-management decisions will not pass inspection even if no actual breach has occurred.
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 sits around them. We structure licensing, banking and compliance as one mandate rather than three disconnected workstreams — so that the programme satisfies both the regulator and the correspondent bank. Digital assets are the whole of our practice. To discuss your sanctions screening programme or compliance posture, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst — specialising in AML/CFT programme architecture, sanctions screening design, and Travel Rule compliance for multi-jurisdiction VASPs.
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.