EU Travel Rule, AML, Sanctions & DAC8 — CASP Compliance 2026

TFR implementation reality — uniform on paper, varied in practice

EU Travel Rule under Regulation (EU) 2023/1113 (TFR) went operational 30 December 2024 alongside MiCA. As an EU Regulation, TFR is directly applicable across all member states without national transposition. The core obligations are uniform.

Operational reality through 2025-2026 reveals real variation in member-state implementation. NCA supervisory engagement intensity differs. Operational expectations differ. Guidance specificity on ambiguous interpretation questions differs. Operators serving multiple EU member states face materially different operational reality in each major market.

This guide starts with that member-state survey, then works through the rest of the financial-crime stack a CASP carries alongside its MiCA authorisation: the self-hosted wallet rules under the TFR, the FATF Recommendation 16 standard the TFR implements, the AMLR + AMLA package landing in 2027, DAC8 crypto-asset tax reporting from 2026, sanctions screening, and GDPR. They sit in different rulebooks but they share the same customer data and the same onboarding flow, run by the same operations team — so it pays to plan them together rather than as eight separate projects.

The TFR framework baseline

Before surveying member-state variations, the TFR framework baseline:

Originator and beneficiary information required on all crypto-asset transfers between CASPs regardless of value:

• Originator: name, account number (or wallet address), address (or other identifier)
• Beneficiary: name, account number (or wallet address)

No de minimis exemption — unlike traditional Travel Rule for fiat transfers, EU TFR has no value threshold below which information requirements waive. All transfers in scope.

Self-hosted wallet enhanced obligations — transfers above EUR 1,000 to/from self-hosted wallets require enhanced due diligence:

• Verification of beneficial owner of self-hosted wallet
• Transaction-graph analysis on wallet provenance
• Risk-assessment framework
• Documentation of enhanced due diligence

Record-keeping integration — TFR records integrated with MiCA Article 68 record-keeping infrastructure with five-year retention.

Cross-CASP information exchange — infrastructure for information exchange between CASPs. Industry-standard protocols (TRISA, OpenVASP, Notabene, Sumsub Travel Rule) handle the technical layer.

Germany — BaFin heavy engagement

Supervision profile. BaFin’s TFR supervision is among the most demanding in the EU, consistent with BaFin’s broader AML supervisory tradition.

Specific engagement patterns:

• Detailed guidance issued early 2025 on TFR operational implementation
• Active supervisory engagement on self-hosted wallet enhanced due diligence — BaFin tests operator infrastructure adequacy
• Enforcement engagement on inadequate TFR record-keeping — multiple operators have faced supervisory action on infrastructure gaps
• Tight integration with FIU Germany (Zentralstelle für Finanztransaktionsuntersuchungen)

Operational implications for operators serving Germany:

• Infrastructure investment beyond minimum TFR baseline
• Documentation infrastructure adequate for BaFin detailed review
• Self-hosted wallet enhanced due diligence with transaction-graph analytics
• German-language documentation for formal supervisory matters

France — ACPR / AMF coordinated supervision

Supervision profile. Coordinated supervision between ACPR (banking supervisor with AML role) and AMF (markets supervisor with crypto-asset role). The dual structure produces methodical supervisory engagement.

Specific engagement patterns:

• Guidance issued mid-2025 on TFR operational expectations
• Engagement on cross-border CASP coordination
• Enforcement on inadequate self-hosted wallet enhanced due diligence
• Integration with TRACFIN (FIU France)

Operational implications for operators serving France:

• French-language documentation infrastructure
• Coordination across ACPR / AMF dual supervisory engagement
• Self-hosted wallet enhanced due diligence with French-language analytical documentation
• TRACFIN reporting infrastructure

Netherlands — AFM / DNB engagement

Supervision profile. Coordinated supervision between AFM (markets) and DNB (banking and AML). Active supervisory engagement on operational implementation.

Specific engagement patterns:

• Guidance issued through 2025 on TFR operational expectations
• Engagement on cross-border passport implications
• Enforcement on operators with substantial Dutch customer base running inadequate TFR infrastructure
• Integration with FIU Netherlands

Operational implications for operators serving Netherlands:

• Dutch-language documentation for substantial customer base
• Coordination across AFM / DNB dual supervisory engagement
• Cross-border passport infrastructure addressing Dutch customer servicing
• FIU Netherlands reporting infrastructure

Ireland — CBI banking-grade engagement

Supervision profile. CBI supervisory engagement consistent with CBI’s broader AML supervisory tradition — methodical, technical, banking-grade expectations.

Specific engagement patterns:

• Guidance issued 2025 on TFR operational implementation
• Engagement on cross-border passport implications for Irish-domiciled operators serving EU-wide customer base
• Enforcement on inadequate infrastructure
• Integration with FIU Ireland (within An Garda Síochána)

Operational implications for operators with Irish CASP authorisation:

• Infrastructure adequate for CBI detailed home-state supervisory engagement
• Cross-border passport infrastructure for multi-jurisdictional operations
• English-language documentation infrastructure (the working language)
• FIU Ireland reporting infrastructure

Luxembourg — CSSF measured engagement

Supervision profile. CSSF supervisory engagement consistent with Luxembourg financial-services supervisory tradition — thorough but procedurally efficient.

Specific engagement patterns:

• Guidance issued late 2024 / early 2025
• Engagement on operator infrastructure adequacy
• Enforcement on operators with substantial Luxembourg customer base
• Integration with FIU Luxembourg (CRF)

Operational implications for operators with Luxembourg CASP authorisation:

• Multi-language documentation (French, German, English standard for Luxembourg financial services)
• Cross-border passport infrastructure
• Integration with CRF reporting framework

Estonia / Lithuania — calibrated for export-CASP scale

Supervision profile. Active but proportionate supervisory engagement reflecting concentration of crypto-asset operators in these jurisdictions, where most operators serve cross-border customer base rather than domestic.

Specific engagement patterns:

• Guidance issued through 2025 on operational expectations
• Engagement particularly on operators serving substantial cross-border customer base
• Enforcement on infrastructure inadequacy
• Integration with Baltic FIU frameworks (Estonia FIU, FNTT Lithuania)

Operational implications for Baltic-authorised operators:

• Infrastructure for active supervisory engagement
• Cross-border passport infrastructure essential — typical Baltic operator business model is export-focused
• English-language documentation (typical operating language for Baltic-domiciled international operators)
• Integration with Baltic FIU frameworks

Spain — TFR plus marketing-restriction overlay

Supervision profile. Banco de España and CNMV supervisory engagement. Overlay with Spanish marketing-restriction framework (Royal Decree 824/2024 on crypto-asset marketing restrictions) creates additional complexity for operators serving Spanish customers.

Specific engagement patterns:

• Guidance issued mid-2025
• Engagement on cross-border CASP servicing Spanish customer base
• Enforcement engagement on marketing-related TFR matters
• Integration with SEPBLAC (FIU Spain)

Operational implications for operators serving Spain:

• Spanish-language documentation
• Coordination with Spanish marketing-restriction framework
• Spanish-language customer-facing materials
• SEPBLAC reporting infrastructure

Italy — Banca d’Italia / CONSOB coordination

Supervision profile. Coordinated supervision between Banca d’Italia (AML role) and CONSOB (markets supervision). Methodical supervisory engagement reflecting Italian supervisory tradition.

Specific engagement patterns:

• Guidance issued through 2025
• Engagement on cross-border CASP servicing Italian customer base
• Enforcement on infrastructure inadequacy
• Integration with UIF (FIU Italy)

Operational implications for operators serving Italy:

• Italian-language documentation
• Coordination across Banca d’Italia / CONSOB dual supervisory engagement
• Italian-language customer-facing materials
• UIF reporting infrastructure

What this variation means for operators

For operators with cross-border passport operations, member-state variation in TFR implementation produces specific operational implications:

Infrastructure investment varies by market — the infrastructure a German customer base demands exceeds what smaller member states require. Plan investment proportionate to customer base in each market.

Language requirements vary by market — local-language documentation essential for substantial customer base in major markets (Germany, France, Italy, Spain). Plan local-language infrastructure accordingly.

Supervisory engagement varies by market — engagement intensity differs across member states. Plan engagement infrastructure for the most active markets.

Enforcement risk varies by market — based on supervisory engagement intensity. Active-supervision markets warrant more conservative infrastructure investment.

AMLA harmonisation from 2027 — centralised AML supervision under AMLA from 2027 will materially unify the enforcement approach. Operators investing in robust infrastructure now position well for the harmonised regime.

How the self-hosted wallet rule works

Self-hosted wallets (wallets where the user holds the private keys directly, not at a CASP) get specific treatment under the TFR. For CASP-to-CASP transfers the rule is binary: collect originator and beneficiary information on every transfer, regardless of value. The self-hosted wallet path is where the one quantitative line in an otherwise zero-threshold regime sits, at EUR 1,000.

Below EUR 1,000. The CASP collects originator and beneficiary information for transfers to or from self-hosted wallets, but is not required to use technical means (chain analytics, signed-message proof, micro-transfer verification) to confirm the customer actually owns or controls the address. Information collection only.

Above EUR 1,000. The CASP must take additional steps to verify whether its customer owns or controls the self-hosted wallet involved in the transfer. The Regulation does not prescribe the method; in practice the market options are:

• Signed-message proof — the customer signs a message from the self-hosted wallet that proves control
• Micro-transfer verification — the customer sends a small (sub-threshold) test transfer that confirms control
• Chain-analytics-driven heuristics — pattern analysis suggesting customer ownership

Each option trades off user experience against technical reliability, and each meets a different level of supervisory acceptance. The EBA guidelines (EBA/GL/2024/11, published 4 July 2024) accept any verification method that delivers reliable evidence of customer control. A second AMLR-level trigger sits on top: under the AMLR (covered below) a transfer above EUR 1,000 to or from a self-hosted wallet also triggers full customer due diligence, distinct from the TFR’s information-and-verification duty. The two operate together — the TFR sets the data that accompanies the transfer, the AMLR sets the CDD trigger.

A common pitfall is reading the EUR 1,000 rule as a transfer ban. It is not. A CASP can serve self-hosted-wallet transfers above the threshold; it just applies verification and, where the AMLR bites, full CDD on the counterparty. Treating the rule as a ban manufactures a customer-experience problem the law does not require.

What the beneficiary CASP does with incomplete transfers

The beneficiary CASP must detect transfers arriving with missing or incomplete originator/beneficiary information, apply risk-based procedures, and take one of four follow-up actions:

• Execute — proceed if the risk assessment allows
• Reject — decline to make the crypto-assets available to the beneficiary
• Return — return the crypto-assets to the originator CASP
• Suspend — temporarily hold the transfer while requesting the missing information

The choice is risk-driven, not a free menu. A high-risk gap (originator name absent on a large transfer from a higher-risk jurisdiction) typically requires reject or suspend; a lower-risk gap can support execute with a documented rationale. Defaulting to execute on incomplete transfers is the kind of thing that surfaces as a deficiency in the first supervisory review.

What’s out of scope

The Travel Rule does not reach peer-to-peer transfers between two self-hosted wallets with no CASP on either side, intra-CASP transfers where one provider already holds both sides of the information (internal AML monitoring still applies), or the verification step for sub-EUR-1,000 self-hosted transfers (information collection still applies). The first carve-out is what lets genuine peer-to-peer use continue without CASP intermediation — the TFR is a CASP-focused regulation, not a general crypto-asset rule.

TFR outsourcing

Many CASPs outsource Travel Rule compliance to specialist providers. That is permitted under MiCA’s outsourcing rules, subject to the usual discipline: a written arrangement, the CASP retaining responsibility (outsourcing does not delegate liability), the arrangement recorded in the outsourcing register and, where the provider is an ICT third party, the DORA register of information, with material arrangements notifiable to the home competent authority. Outsource the technical implementation; keep the supervisory accountability and the internal capacity to oversee what is outsourced.

Industry-protocol coverage

Cross-CASP TFR information exchange runs through industry-standard protocols. The Regulation does not prescribe one (the EBA guidelines accept any protocol that meets the security and integrity requirements), so operators need coverage across several since counterparty CASPs use different solutions:

TRISA (Travel Rule Information Sharing Alliance) — open-source protocol with substantial adoption, particularly among US and European exchanges. Public key infrastructure for CASP verification.

TRP (Travel Rule Protocol) — open-source protocol with broad industry support and strong North American adoption; TRP-compatible providers include Notabene and Sumsub Travel Rule.

TRUST (Travel Rule Universal Solution Technology) — Coinbase-led consortium framework, substantial North American adoption among large CASPs, less common in the EU.

OpenVASP — Swiss-origin protocol with European adoption, particularly among institutional CASPs.

Notabene — commercial Travel Rule platform with broad CASP coverage. Strong UI for operations teams.

Sumsub Travel Rule — bundled with broader AML/KYC infrastructure. Common choice for operators already using Sumsub for KYC.

Other regional protocols — Veriscope (Shyft Network), the 21 Travel Rule Protocol, and various exchange-specific implementations.

Most serious operators implement coverage across 2-3 protocols to keep counterparty CASP coverage wide. Cross-protocol gaps create TFR-information-transmission failures that trigger supervisory engagement. Single-protocol strategies produce a real counterparty-exclusion risk.

The FATF Recommendation 16 global standard

The EU TFR is the EU’s implementation of FATF Recommendation 16 — the global standard for wire-transfer transparency. The recommendation requires originating financial institutions to obtain, hold, and transmit originator and beneficiary information accompanying transfers, and beneficiary institutions to monitor for incoming transfers that lack required information. The FATF Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (June 2019, refined through October 2021 and March 2024) applied Recommendation 16 to virtual asset service providers.

By 2026 every major crypto-active jurisdiction has implementing legislation:

• European Union — Regulation (EU) 2023/1113 (TFR), operational since December 2024
• United States — FinCEN guidance under the Bank Secrecy Act, with active enforcement
• United Kingdom — Money Laundering Regulations 2017 amendments, operational September 2023
• Singapore — MAS Notice PSN02, Travel Rule provisions for Digital Payment Token service providers
• Switzerland — FINMA framework integrated with broader Swiss AML obligations
• Various Asia-Pacific, MENA, and LATAM frameworks through 2024-2026

The thresholds diverge, and that divergence is the practical trap. The EU TFR has a zero threshold for CASP-to-CASP transfers — a EUR 50 transfer carries the same information as a EUR 50,000 one. US FinCEN applies above USD 3,000. Other jurisdictions vary. A cross-border CASP faces the strictest applicable threshold for each transfer, so an operator that builds only to the US threshold fails EU compliance. US enforcement underlines the stakes: Bittrex (USD 29m), BitMEX (USD 100m settlement), and Binance (USD 4.3bn coordinated US action) all included Travel Rule failures among the grounds.

One more angle operators underestimate is the “sunrise issue” — where a counterparty’s jurisdiction has not yet implemented Recommendation 16. That gap does not exempt the EU CASP; it has to manage the missing-information case on its side. Multi-protocol support, a verified beneficiary-identifier framework, and an explicit self-hosted-wallet workflow are what make cross-border transfers actually clear.

AMLR + AMLA — the 2027 readiness window

The EU’s new AML package, adopted together in May 2024, is the most substantive overhaul of EU AML supervision since the original 1991 Money Laundering Directive. Three instruments:

• AMLR (Regulation (EU) 2024/1624) — the single rulebook, applying directly from 10 July 2027. Covers customer due diligence, beneficial-ownership identification, reporting, internal controls.
• AMLA (Regulation (EU) 2024/1620) — establishes the Authority for Anti-Money Laundering and Countering the Financing of Terrorism, headquartered in Frankfurt. Operational from 1 July 2027; direct supervision of the largest cross-border obliged entities from 2028; indirect coordination of national supervisors for everyone else.
• AMLD6 (Directive (EU) 2024/1640) — the national-infrastructure piece: upgraded FIU capabilities, interconnected beneficial-ownership registers, aligned administrative cooperation. Transposition deadline 10 July 2027.

The core shift is from directive to regulation. Under the 4th, 5th, and 6th AMLDs each member state transposed the rules into national law, and they diverged on enforcement detail, beneficial-ownership thresholds, PEP definitions, and exempted activities. The AMLR closes that divergence by applying directly and identically — which is why a CASP operating across several member states moves from 27 jurisdiction-specific variants of the same programme to a single one.

What changes for the CDD programme

Several areas tighten meaningfully. PEP definitions harmonise across the EU and remove member-state discretion on domestic-PEP scope, producing a slightly broader PEP universe. Enhanced due diligence triggers become common — a single EU list of high-risk third countries replacing parallel national lists, anonymous transactions over EUR 10,000, correspondent relationships with non-EU institutions, and a residual high-risk-business trigger. Beneficial-ownership verification keeps the 25% threshold but requires independent supporting documentation rather than a self-declaration, verified against the national BO register through the interconnected EU platform. Crypto-specific thresholds are tighter than the fiat equivalents: full CDD on self-hosted-wallet transfers above EUR 1,000, and CDD on aggregated transactions above EUR 3,000 in a six-month window for occasional customers.

Who AMLA supervises directly

AMLA selects its first set of directly-supervised obliged entities by 1 July 2027. For CASPs the criteria capture operators active in at least six member states (via Article 60 notification, Article 63 authorisation, or Article 65 passport) with, in at least six of those states, either at least 20,000 customers or more than EUR 50 million in annual transaction value. That captures the largest pan-EU platforms — perhaps 8-15 CASPs across the EU. For these, AMLA is the AML supervisor directly: on-site inspections, direct information requests on tight timelines, supervisory measures, and joint actions with national supervisors where issues span jurisdictions.

For the other 95% of CASPs the national AML supervisor remains the counterparty — a Lithuania-authorised mid-size CASP keeps engaging with the FCIS, the supervisor it has dealt with since 5AMLD. But the substance changes even there: national supervisors apply AMLA-developed methodology, share information cross-border through AMLA-coordinated channels, and face AMLA quality review of their own supervisory work. Serious deficiencies can escalate to AMLA direct supervision outside the regular cycle. So even the unselected face heightened, standardised EU-level expectations.

The sanctions-cumulation point

AMLR sanctions reach up to 10% of total annual turnover or EUR 10 million for legal persons, and up to EUR 5 million for individuals. They can cumulate with MiCA Article 109 sanctions (up to 3%) where the same conduct breaches both — an AML failure that also breaches a MiCA conduct rule. For a EUR 200 million revenue CASP that is up to EUR 20m under AMLR plus up to EUR 6m under Article 109: a cumulative EUR 26m, around 13% of turnover. Model the cumulative figure honestly. Against that exposure, EUR 1-3m of compliance build is small.

The runway

From mid-2026 to July 2027 is roughly 12-15 months of preparation, not a deadline to back into. A workable plan: gap-analyse the current 5AMLD/6AMLD programme against the AMLR rulebook in H2 2026; rewrite policy, onboarding flows, and transaction-monitoring rules in Q1 2027; reconfigure KYC vendor settings, retrain staff, migrate beneficial-ownership verification to the interconnected register, and run a parallel-run exercise in Q2 2027; go live under the AMLR in July 2027. Two cautions worth stating plainly: do not treat the AMLR as a re-papering exercise under new article numbers (the PEP, EDD-trigger, BO-verification, and compliance-officer-independence changes are real), and mid-size CASPs should not over-build for AMLA direct supervision they will not meet the thresholds for.

DAC8 — crypto-asset tax reporting from 2026

DAC8 is the EU’s transposition of the OECD’s Crypto-Asset Reporting Framework (CARF) into the existing administrative-cooperation machinery, via Council Directive (EU) 2023/2226 amending Directive 2011/16/EU. Member states had until 31 December 2025 to transpose; the reporting obligations themselves apply from 1 January 2026. The first report is due 31 January 2027 for the 2026 period, and the first cross-border exchange between member states is scheduled for September 2027.

The thing to get right early is that this is not a tax-team project. It looks like a tax regime, but operationally it is a data-collection and reporting-systems build where data quality is the hard part, and it sits with operations, technology, and compliance. Treating it as a finance-team initiative produces the late discovery that the onboarding flow never captured the required fields.

What a RCASP is — and is not

DAC8 defines a Reporting Crypto-Asset Service Provider (RCASP) more broadly than the MiCA CASP definition. The MiCA definition captures eight enumerated services anchored in the EU regulatory perimeter; the RCASP definition is anchored in the DAC tax-cooperation perimeter and captures any entity that effectuates exchange transactions involving Reportable Crypto-Assets on behalf of customers, or operates a platform on which such transactions occur. The overlap with MiCA CASP is large (most authorised CASPs are also RCASPs) but not complete. A non-EU centralised exchange with EU tax-resident customers and no MiCA authorisation is a RCASP and must report, even though it is not a MiCA CASP. The scoping question is separate, and each regime needs its own analysis.

The data fields

For each reportable customer: name, address, jurisdiction(s) of tax residence, Tax Identification Number (TIN) in each such jurisdiction, date of birth for individuals, and place of birth where the residence jurisdiction does not issue TINs. For each reportable transaction during the calendar year, aggregated by Reportable Crypto-Asset: units received and disposed of, total fair-market value received and disposed of, transaction count, and, separately, identification of the merchant counterparty for retail-payment transactions above EUR 50,000. The fair-market-value methodology follows the OECD CARF commentary: typically the executed price, with a documented fallback for off-exchange transactions.

That EUR 50,000 retail-payment trigger is a separate flag, per transaction, not aggregated, and it sits outside the normal trading-flow reporting. A CASP running both a trading service and a merchant-payment service has to classify the flows separately and apply the trigger only to the merchant-payment side. Lump every outflow into one bucket and you miss it.

The remediation effort

Most CASPs operating before 1 January 2026 hold customers for whom they have no DAC8-compliant data, because DAC8 reports on the existing base, not just new customers. The build breaks into: a new onboarding flow capturing TIN and tax-residence self-certification from first interaction (the easy part, a sprint or two); existing-customer remediation through multi-stage outreach (email, in-app prompt, account-action gate) where first-round response rates of 60-70% are typical and the residual needs escalation; data-quality and verification work including per-jurisdiction TIN validation and documented retention of self-certifications; and the reporting-system build itself — annual aggregation, fair-market-value calculation, output in the format the home tax administration accepts, electronic submission. For a platform with a million EU customers and a few thousand reportable assets, that is a six-to-twelve-month project starting from a typical 5AMLD-baseline KYC stack.

The smart move is to build it alongside the AMLR architecture rather than as a parallel system. The 18-month gap between DAC8 (January 2026) and the AMLR (July 2027) is the window to design one coordinated data layer — both regimes hit the same onboarding flow and need the same self-certification and ongoing data-quality maintenance, and both feed national-authority reporting. And since CARF extends the standard internationally as more jurisdictions sign on, designing the EU build to handle CARF fields more broadly avoids rework when other jurisdictions activate.

Sanctions compliance

Before the framework, the conceptual point that the most common sanctions failure turns on: sanctions are not AML. They are a separate regime with a different logic, and conflating them builds a structural gap. AML is risk-based — a low-risk client gets lighter due diligence, discretion is built in. Sanctions are strict-liability — there is no “low-risk designated person”. If a client, counterparty, or wallet is subject to an asset freeze, processing a transaction is a breach, regardless of intent or risk rating. A CASP that routes sanctions screening through its risk-based AML triage has applied discretion the law does not allow, and that is precisely the gap supervisors look for. The MLRO and the AML framework can share tooling with sanctions; they cannot share logic. On a confirmed match the obligation is to freeze the funds or economic resources without delay, decline to execute, and report to the competent national authority — not to assess whether the transaction is “low risk” and proceed. EU restrictive measures bind all EU operators directly, exactly as they bind a bank; crypto-assets are treated as funds or economic resources, so there is no crypto carve-out. And the reach extends past the named account holder to counterparties, beneficial owners, and entities owned or controlled by designated persons — screening only the named client misses a common evasion structure.

The framework itself expanded sharply through 2022-2026 and is supervisor-tested. It operates in layers. The EU consolidated sanctions list, maintained by the Council, covers individuals, entities, and vessels subject to EU restrictive measures, updated continuously by Council decision — CASPs screen against it at onboarding and throughout the relationship. Sectoral packages restrict specific activity, most extensively against Russia (Council Regulation 833/2014) and Belarus (765/2006), with specific crypto-asset prohibitions, plus Iran (267/2012) and North Korea (329/2007). Country embargoes cover Cuba, Syria, Venezuela (sectoral), and others. National implementing legislation sets the penalty and enforcement detail per member state, but the EU framework is binding.

The Russia and Belarus packages contain specific crypto provisions CASPs must apply: a prohibition on providing crypto-asset wallet, account, or custody services to Russian persons or persons located in Russia (regardless of value), a prohibition on facilitating crypto-asset transactions for or with Russian persons or entities, individual designations of numerous Russian institutions and persons, sectoral overlays, and obligations to report frozen assets and refused transactions to national competent authorities. The framework has been tightened repeatedly since 2022 — operators have to monitor amendments continuously.

The OFAC overlay

Any US-touching activity triggers US OFAC sanctions compliance, and the extraterritorial reach is real. The triggers: US customers, US-dollar-denominated transactions, US payment infrastructure (US correspondent banks, US-licensed processors), substantial US ownership, or US-based vendors. Operators screen against the OFAC SDN list at onboarding and continuously, apply the OFAC 50% rule (entities 50%+ owned by sanctioned persons are themselves sanctioned even if not listed), and watch sectoral lists. OFAC has enforced against non-US crypto operators (Tornado Cash in 2022, various exchange actions since) with penalties into the hundreds of millions. EU compliance does not substitute for OFAC compliance; the two run in parallel.

Operational reality

Sanctions law is strict-liability (intent and knowledge are not required for a breach), so the build has to support real-time blocking, not just reporting. Sanctions designations change daily, which rules out onboarding-only screening: the operational standard is continuous, real-time re-screening at the transaction level, backed by blockchain-analytics integration. For self-hosted wallets specifically, designated persons sometimes route through them to evade exchange-side screening, so transfer-time screening through blockchain analytics is required. The main providers (Chainalysis, Elliptic, TRM Labs, Crystal Blockchain, with Coinfirm, Merkle Science, and Scorechain among secondary options) are typically run two-deep for redundancy, since single-provider strategies leave coverage gaps on recent designations. First-year sanctions build runs roughly EUR 100-300k for a mid-tier CASP, with ongoing cost of EUR 50-150k a year. It is one of the more sensitive parts of MiCA CASP compliance precisely because errors produce strict-liability exposure.

GDPR for crypto operators

GDPR (Regulation (EU) 2016/679) applies to all CASPs handling personal data of EU data subjects, extraterritorially — a CASP established outside the EU is in scope if it processes EU-resident personal data. Crypto operators inevitably process it: customer identification data, transaction history linked to identifiable customers, communication records, behavioural analytics, and marketing/CRM data. The framework runs alongside MiCA AML obligations — sometimes in alignment, sometimes in tension.

The crypto-specific wrinkle is the personal-data definition. A standalone wallet address is pseudonymous and, under Recital 26, is personal data only where linkable to an identifiable person. But CASPs map customer identity to customer wallets through KYC, so wallet activity in CASP systems is linkable — and therefore personal data. Public on-chain activity becomes personal data where third parties can link it to a known person, and blockchain-analytics intermediaries (Chainalysis, Elliptic, TRM Labs) face their own GDPR analysis for the EU persons in their databases. Treating pseudonymous data as out-of-scope is the classic mistake.

Lawful basis and the erasure tension

Most AML-required processing rests on legal obligation (Article 6(1)(c)) — MiCA, the AMLR, the FATF Travel Rule implementation, and national AML law all impose duties to collect, verify, and retain customer data. Customer service delivery rests on contract (6(1)(b)); fraud prevention and security on legitimate interest (6(1)(f)) with a balancing test; marketing and optional features on consent (6(1)(a)). The basis matters because it drives the data-subject rights.

The sharpest tension is erasure. Article 17 gives data subjects a right to erasure, but Article 17(3)(b) carves out compliance with a legal obligation. MiCA AML retention requires five years from the end of the customer relationship — during that window AML-required data cannot be erased. After it expires, erasure rights apply, so operators must distinguish time-bound AML retention from indefinitely-held data and run a two-track retention model. Marketing and non-AML data follow standard erasure rules throughout. And where data has been written to a public blockchain, it cannot be erased from the chain — the framework treats that as an accepted technical limitation, which is itself the argument for minimising blockchain-resident personal data by design.

Rights, breach, and the supervisor relationship

CASPs have to operate the full rights workflow, with identity verification up front to prevent impersonation — access (Article 15, one month, extendable to three), rectification (16), erasure subject to the AML carve-out (17), restriction (18), portability for consent/contract data (20), objection (21), and human review of significant automated decisions such as automated KYC rejection (22). Breach notification runs on the Article 33-34 clock: notify the DPA within 72 hours of a breach likely to risk data subjects, notify data subjects where the risk is high, and document every breach internally regardless.

On supervision, the Article 56 one-stop-shop makes the DPA of the operator’s main establishment the lead authority, with concerned DPAs in affected member states cooperating and the EDPB coordinating EU-wide. The practical advice is to build the relationship before an incident forces it — several DPAs offer prior-consultation mechanisms, and CNIL (France), the Spanish AEPD, and the German DSK have all published crypto-relevant positions. Two design principles carry the rest: privacy-by-design from the architecture phase (Article 25 — retrofitting privacy controls costs far more than building them in), and keeping the legal-obligation retention track cleanly separate from indefinite retention so erasure works in both directions.

Operational recommendations

For operators planning this whole stack, the same few principles recur:

Tier investment by market. Heavier infrastructure for the heavier markets (Germany, France, Italy, Spain, Netherlands); proportionate infrastructure for smaller ones. Local-language documentation (German, French, Italian, Spanish) for the major customer bases.

Run multi-protocol Travel Rule coverage. Implement 2-3 major protocols. Build for the EU zero threshold and the strictest applicable cross-border threshold, and handle self-hosted wallets explicitly rather than treating them as out-of-scope.

Integrate blockchain analytics once, use it everywhere. Transaction-graph analytics (Chainalysis, Elliptic, TRM Labs) feed self-hosted-wallet TFR verification and AMLR enhanced due diligence from the same infrastructure that runs real-time sanctions screening.

Design one coordinated data layer. The TFR, AMLR, DAC8, and GDPR all touch the same onboarding flow and the same customer data. Coordinated data architecture is materially cheaper than parallel systems — and the 18-month gap to July 2027 is the window to build it.

Wire in FIU reporting across passport markets where the operator has a meaningful customer base, and keep a two-track GDPR retention model that distinguishes time-bound AML retention from indefinite holding.

Prepare for AMLA now. Honestly assess selection risk, benchmark the AML programme against the harmonised EU standard, harmonise across passport markets, strengthen MLRO substance, and model the cumulative AMLR + MiCA Article 109 sanctions exposure.

Operators that build serious infrastructure now are well-positioned for both the current member-state variation and the harmonised, centralised regime arriving in 2027.

For corrections, updates, or counsel referrals on EU CASP financial-crime compliance, email [email protected].