Crypto businesses operating across borders face a sanctions exposure that no single jurisdiction's screening list fully captures. The Travel Rule (the obligation to pass originator and beneficiary data with every qualifying virtual-asset transfer) and national AML compliance regimes create layered, sometimes contradictory obligations that shift with each new regulatory action. A firm that screens only against one country's designated-persons list while routing transfers through three more is not compliant – it is a liability waiting to crystallize.
This page maps the legal basis for cross-border sanctions screening in digital-asset businesses, the process a well-structured program must follow, and the common mistakes that draw regulatory scrutiny. It is written for operators who already understand blockchain mechanics and need the compliance answer.
The Regulated Basis: Why One List Is Never Enough
Cross-border sanctions screening for crypto is not a single regulatory obligation – it is the intersection of multiple, independently enforceable regimes that apply simultaneously based on entity location, user location, settlement currency and correspondent banking relationships.
A VASP (virtual asset service provider) licensed in the EU under MiCA (the Markets in Crypto-Assets Regulation) must screen against EU consolidated sanctions lists administered by national competent authorities and coordinated through ESMA. If that same VASP clears USD settlements through a US correspondent bank, it is simultaneously within reach of OFAC (the US Office of Foreign Assets Control) designation lists and secondary-sanctions exposure. If it serves users in the UAE, VARA (the Virtual Assets Regulatory Authority) expects compliance with UAE Cabinet Resolution sanctions obligations. None of these regimes defers to the others.
The FATF Recommendation 15 regime – which established the Travel Rule as an international standard for virtual-asset transfers – requires member jurisdictions to impose AML and sanctions obligations on VASPs equivalent to those applied to financial institutions. Most flagship licensing hubs have now transposed this into domestic law: MiCA in the EU, the Payment Services Act in Singapore under MAS, the VASP licensing regime under the SFC in Hong Kong, and the VARA rulebooks in Dubai. The result is a global floor, not a ceiling.
In our cross-border practice, we see operators surprised by the extraterritorial reach of OFAC in particular. A VASP with no US entity, no US users and no US banking can still be sanctioned if it processes a transaction in USD-denominated stablecoins involving a designated party. The currency of settlement, not the domicile of the entity, often determines which sanctions regime is triggered.
For a scoped assessment of your firm's screening obligations across the jurisdictions where you operate, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis significantly. Map your options.
What a Compliant Screening Program Actually Looks Like
A compliant sanctions-screening program for a cross-border digital-asset business has five structural components, each of which regulators in the leading hubs now audit independently.
The first is list coverage. The program must pull from every sanctions list that is enforceable against the firm given its entity structure, banking relationships and user geography. For most internationally active VASPs, this means at minimum: OFAC SDN and consolidated lists, EU consolidated sanctions list, UN Security Council consolidated list, and the domestic list of every jurisdiction in which the firm holds a licence or processes transactions. A single API feed from a commercial screening vendor may not cover all of these – operators we advise routinely discover gaps between what their vendor provides and what their regulators expect.
The second component is wallet screening, which differs from counterparty screening. Screening the customer's identity at onboarding is necessary but not sufficient. The firm must also screen the blockchain addresses involved in each transaction against known-malicious address databases maintained by forensics providers such as Chainalysis, TRM Labs, Elliptic and Asset Reality. VARA, MAS and the FCA have each issued guidance making clear that address-level screening is expected for high-risk transaction categories.
The third component is Travel Rule data collection and transmission. Under the Travel Rule, a VASP originating a qualifying transfer must collect and transmit originator and beneficiary data to the beneficiary VASP before or simultaneously with the transfer. The data threshold above which this obligation applies varies by jurisdiction – the FATF standard sets a baseline but individual regimes diverge in how they implement the de-minimis. This creates a cross-border problem: the originating VASP's jurisdiction may exempt a transfer that the beneficiary jurisdiction treats as subject to full Travel Rule obligations. The conservative approach – which regulators increasingly expect – is to screen and transmit regardless of which side of the threshold a transfer falls on.
The fourth component is a KYC framework (know-your-customer framework) calibrated to risk. Politically exposed persons, high-risk jurisdictions and unusual transaction patterns each require enhanced due diligence. MiCA and the VARA rulebooks both impose risk-based customer due diligence obligations that extend well beyond initial onboarding.
The fifth component is transaction monitoring – the ongoing surveillance of transaction patterns for red flags including structuring, rapid layering across multiple wallets, and mixing activity. Transaction monitoring that is tuned only for fiat thresholds and not for on-chain behavioral patterns is a gap that regulators have found consistently in enforcement examinations.
How Does the Travel Rule Work Across Different Jurisdictions?
The Travel Rule is technically straightforward within a single jurisdiction and genuinely complex the moment a transfer crosses a border between two regimes that have implemented it differently.
The core obligation – pass originator and beneficiary data with the transfer – is consistent with FATF Recommendation 15. But implementation diverges on three axes: the data threshold, the data fields required, and the technical protocol accepted for transmission.
In the EU under MiCA, the Travel Rule applies to all crypto-asset transfers regardless of value, eliminating the de-minimis that some other jurisdictions retain. The required data fields align with the EU Funds Transfer Regulation extended to crypto. In Singapore under MAS, the Payment Services Act regime sets its own threshold. In Hong Kong under the SFC's VATP licensing regime, the expectation tracks the FATF standard with local supervisory guidance layered on top. In the UAE, VARA's rulebooks impose Travel Rule obligations as part of the broader AML and CFT (counter-terrorist-financing) compliance expectations for licensed activity.
The cross-border complexity arises when the originating VASP is in a jurisdiction that has not implemented the Travel Rule domestically, or when the beneficiary VASP is in a jurisdiction with no Travel Rule regime at all. In those cases, the licensed VASP on the regulated side of the transfer must decide how to handle the gap. Most major regulators expect their licensees to apply the higher standard regardless of whether the counterpart VASP can reciprocate.
We have seen this create operational problems for operators running multi-jurisdictional custody arrangements where the entity holding keys and the entity processing transfers sit in different licensing hubs. The question of which entity's Travel Rule obligation applies – and to which transfers – is not always answered by reading the two regimes side by side.
A micro-matter from our recent practice: a payments company operating exchange and custody functions through two separate licensed entities in different jurisdictions sought guidance on their intra-group transfer obligations. The entities were related parties, but each held a distinct VASP licence under a different regime. We analyzed the Travel Rule application to intra-group flows under both frameworks and structured a compliant data-transmission protocol that satisfied both regulators without creating duplicative customer-disclosure obligations. The outcome was a documented internal policy that the firm could present to each supervisor independently.
Banking Rails, Sanctions and the Cross-Border Pressure Point
The intersection of crypto sanctions screening and correspondent banking is where enforcement exposure concentrates for most international digital-asset businesses.
A VASP's bank account is the most fragile link in its compliance chain. Correspondent banks apply their own sanctions screening to transactions flowing through their rails – and their screening standards often exceed the VASP's domestic regulatory requirements. A crypto firm that is fully compliant with its licensing jurisdiction's AML program can still have its banking terminated if the correspondent bank's automated screening flags a pattern the bank's compliance team treats as elevated risk.
This is not hypothetical. Operators we advise have experienced account closures triggered not by any regulatory finding but by a correspondent bank's risk-appetite decision following a routine transaction review. The closure is rarely explained in detail, and the path to restoring banking – or finding a replacement – requires demonstrating to the new bank that the screening program is robust enough to satisfy the bank's own correspondent-banking compliance standards, not just the VASP's regulatory minimum.
The practical answer is to design the AML compliance program to the most demanding standard in the chain – typically the OFAC standard for USD transactions, the EU standard for EUR transactions – and to document that calibration explicitly. Banks examining a VASP's compliance program want to see list coverage, wallet screening, a clear escalation procedure for hits, and evidence that the MLRO (money-laundering reporting officer) function has real authority within the firm.
The cross-border dimension also affects stablecoin transactions specifically. Tether (USDT) and Circle (USDC) hold contract-level freeze and blacklist authority over their issued tokens. Both issuers act on court orders, law-enforcement requests and OFAC designations. A VASP that processes a sanctioned-party transaction in USDT faces the possibility that the tokens are frozen at the issuer level regardless of what the VASP's own compliance program concludes. This is a secondary enforcement mechanism that sits outside the regulatory-supervision chain and operates on a shorter timeline.
What Are the Most Common Sanctions Screening Mistakes in Crypto?
Enforcement patterns across the leading supervisory jurisdictions reveal a consistent set of screening failures that draw regulatory action.
The first is treating list screening as a one-time onboarding check. Sanctions lists update continuously – OFAC adds designations with no advance notice, the EU consolidated list updates with geopolitical events, and UN Security Council additions are reflected immediately in domestic list obligations. A VASP that screens a customer at onboarding and not again is compliant at a single point in time and potentially non-compliant from the moment the next list update is published.
The second mistake is misunderstanding the relationship between KYC and sanctions screening. KYC establishes who the customer is. Sanctions screening determines whether doing business with that customer is legally permissible. They are connected processes but not the same process, and the failure mode is treating a passed KYC check as a proxy for a clean sanctions screen. It is not.
The third common failure is inadequate beneficial ownership screening. A VASP that screens the customer's name but not the ultimate beneficial owner – the individual with controlling interest – can onboard a sanctioned party who sits one entity-layer away from the contractual counterparty. MiCA, the VARA rulebooks and MAS guidance each require beneficial ownership identification as a component of customer due diligence, not an optional enhancement.
The fourth failure pattern is a screening program that is technically functional but operationally disconnected from the firm's business decisions. We regularly see VASPs where the compliance team generates alerts that are reviewed and cleared by analysts without meaningful escalation criteria, and where the MLRO is informed of findings but has no authority to halt a transaction pending review. Regulators examining these programs treat the absence of escalation authority as a structural deficiency, not a documentation gap.
A common assumption is that a single offshore licence – held in a jurisdiction with a lighter AML posture – is sufficient to serve customers globally and shelter the business from the more demanding sanctions regimes. This assumption is demonstrably wrong. The applicable sanctions regime is determined by where the customer is, where the funds flow, what currency is used for settlement, and what correspondent banking relationships the firm maintains. None of these are determined solely by the entity's domicile.
Which Screening Architecture Fits Which Operator Profile?
The right sanctions-screening architecture depends on the firm's licence structure, product set and geographic reach. There is no single answer – the analysis turns on the intersection of those three variables.
Profile A: EU-licensed exchange (MiCA CASP) serving European retail and institutional users, USD settlement through a European correspondent bank. The minimum program covers the EU consolidated sanctions list, OFAC SDN (because of USD settlement exposure), and UN Security Council lists. The Travel Rule obligation under MiCA applies to all transfers regardless of value. Wallet screening is expected as standard for retail and institutional transaction flows. Transaction monitoring must be calibrated for on-chain patterns, not only fiat thresholds. The MLRO must hold meaningful authority and report directly to senior management. Timeline to implement a compliant program from scratch: a matter of weeks to months depending on existing infrastructure.
Profile B: VARA-licensed operator in Dubai serving GCC and Asian institutional clients, multi-currency settlement. The program must cover UAE Cabinet Resolution lists, OFAC (for any USD-denominated activity), EU consolidated list (for EUR activity), and UN Security Council lists. VARA's rulebooks impose risk-based customer due diligence and enhanced due diligence for higher-risk client categories. Travel Rule obligations apply under VARA's AML framework. The multi-currency settlement profile means that the screening program must be calibrated to each currency corridor's applicable sanctions regime, not just the firm's domestic list.
Profile C: Singapore MAS-licensed DPT service provider with a global institutional client base and USD, EUR and stablecoin settlement. The Payment Services Act regime imposes AML and CFT obligations that include Travel Rule compliance. The stablecoin settlement profile adds the issuer-level freeze risk described above. The program must address OFAC, MAS AML notices, EU consolidated list and UN Security Council lists. Beneficial ownership identification is expected at onboarding and on a periodic refresh cycle. Transaction monitoring must include on-chain behavioral analytics, not only rule-based fiat screening.
Across all three profiles, the decisive variable is not the jurisdiction of the licence – it is the combination of settlement currency, user geography and banking relationships. Operators we advise on multi-hub structures frequently find that the highest-standard applicable regime is not their primary licence jurisdiction but their correspondent bank's home jurisdiction.
If a prior compliance program stalled an application or triggered account closure, a second review can identify the structural reason and the path forward. Contact OBOLUS at info@oboluslaw.com or message us at t.me/oboluslaw. Map your options.
Self-Assessment: Is Your Screening Program Ready for a Regulatory Examination?
A regulatory examination of an AML compliance program typically begins with document requests and proceeds to transactional testing – regulators pull a sample of transactions and trace the screening steps applied to each.
The questions that determine pass or fail in an examination are consistent across the leading supervisory jurisdictions. Can the firm produce a written AML policy that accurately describes its screening program as it is actually operated? Does the list coverage documented in the policy match the lists actually used in the screening system? Is the MLRO role filled by a qualified individual with documented authority and a clear escalation path to the board? Is there a written Travel Rule policy that addresses both outbound and inbound transfers, including the firm's approach to counterpart VASPs that cannot transmit Travel Rule data?
Beyond the document review, regulators in the EU, UAE and Singapore have each moved toward transactional testing as a standard examination tool. This means the firm's transaction monitoring system is tested against a sample of historical transactions to determine whether the system would have detected the pattern and whether the alert would have been escalated and resolved appropriately.
Operators we advise who have undergone this level of examination consistently identify the same pre-examination gaps: wallet screening was present but not documented in the AML policy; the MLRO's authority was described in the policy but not reflected in operational procedures; Travel Rule data collection was conducted but storage and transmission were not aligned with the regulatory requirement; and transaction monitoring rules were fiat-denominated thresholds not translated into on-chain behavioral equivalents.
Each of these gaps is fixable before an examination. None of them is fixable during one.
Related at OBOLUS
- AML & Travel Rule compliance for digital-asset businesses – the practice overview covering our full compliance mandate for VASPs and token issuers
- Sanctions screening for crypto in Panama – jurisdiction-specific guidance on Panama's AML regime and screening obligations
- Sanctions screening for regulated crypto entities – service-level guidance for firms already holding a VASP or CASP licence
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP originating a virtual-asset transfer to collect specified originator and beneficiary information and transmit it to the beneficiary VASP before or simultaneously with the transfer. The precise data fields and the value threshold above which the obligation applies vary by jurisdiction. Most major licensing hubs – including EU MiCA, Singapore's Payment Services Act and the VARA regime in Dubai – have now transposed the Travel Rule into their domestic AML frameworks. A VASP on the licensed side of a cross-border transfer is generally expected to apply its home jurisdiction's standard regardless of whether the counterpart VASP operates under an equivalent regime.
Who must act as MLRO for a crypto firm?
An MLRO (money-laundering reporting officer) must be a senior individual within the firm who holds documented authority to escalate, delay or halt transactions pending a compliance review and to make suspicious-activity reports to the relevant financial intelligence unit. Most licensing regimes – including MiCA, the VARA rulebooks and the MAS Payment Services Act framework – require the MLRO to be approved or notified to the regulator and to hold relevant AML qualifications. Outsourcing the MLRO function entirely to an external provider is generally not accepted as satisfying the regulatory expectation; the individual must have genuine authority within the firm's governance structure.
How do regulators audit crypto AML programs?
Regulatory examinations of crypto AML programs typically proceed in two phases. The first is document review: the regulator requests the written AML policy, the Travel Rule policy, MLRO appointment records, training logs and a sample of suspicious-activity reports. The second phase is transactional testing, now standard practice in the EU, UAE and Singapore: the regulator pulls a sample of historical transactions and traces the screening steps applied to each, testing whether the firm's transaction monitoring system would have detected and escalated relevant patterns. Firms that maintain accurate, operationally consistent documentation consistently perform better in examination than firms whose written policies do not match their actual screening workflow.
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 AML, Travel Rule and sanctions compliance that sit around them. Digital assets are the whole of our practice. We map the compliance 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. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border AML compliance, sanctions screening architecture and Travel Rule implementation 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.