Spain transposed DAC8 into national law by the December 31, 2025 deadline. The first reports covering calendar year 2026 are due by September 30, 2027. That means your data capture infrastructure must be operational before January 1, 2027 — it needs to record 2026 transactions from day one.
This guide covers what DAC8 is, who it covers, how it differs from Spain's existing Modelo 172/173 obligations, the CARF XML schema it requires, and the practical steps to prepare without duplicating work you've already done.
What DAC8 Actually Is
DAC8 (Council Directive 2023/2226/EU) amends the EU's Directive on Administrative Cooperation to add crypto-assets to the list of financial assets subject to automatic information exchange. The existing DAC framework already covers bank accounts (DAC1), financial institutions (DAC2), tax rulings (DAC3–5), country-by-country reporting (DAC4), and real estate (DAC7). DAC8 closes the crypto gap.
The mechanism: every CASP reports its EU clients' crypto transactions to its home member state's tax authority. That national authority then automatically shares the data with the tax authority of every other EU member state where those clients reside. A Spanish CASP with French clients reports everything to the AEAT; AEAT forwards the French clients' data to the French tax authority (DGFiP). The French CASP with Spanish clients does the reverse.
The effect is a continent-wide transaction transparency layer. There is no longer anywhere inside the EU where a crypto transaction can be invisible to the relevant tax authority — assuming the reporting works correctly.
Extraterritorial reach: DAC8 applies to non-EU CASPs with EU clients. A US exchange, a UK broker, or any third-country provider serving EU residents must register with a competent authority in one EU member state and comply with DAC8 reporting for all EU clients. Non-registration is sanctionable in every member state where the provider has users.
Timeline
Who DAC8 Covers
DAC8 defines a Reporting Crypto-Asset Service Provider (RCASP) broadly. You are an RCASP if you provide, on a professional basis, any of the following services to EU-resident clients:
- Exchange of crypto-assets for fiat currency
- Exchange of crypto-assets for other crypto-assets
- Transfer of crypto-assets (including to unhosted wallets)
- Custody and administration of crypto-assets
- Participation in or provision of financial services related to an issuer's offer or sale of crypto-assets
This covers virtually every crypto business model: exchanges, custodians, OTC desks, staking service providers, crypto payment processors, and tokenization platforms that facilitate secondary trading.
Explicitly excluded from DAC8: pure DeFi protocols without a legal entity operating the service; non-fungible tokens (NFTs) unless they are used as payment instruments; central bank digital currencies; and crypto-assets with no identifiable issuer that are not used as payment or investment instruments (a narrow category that excludes most established coins).
DAC8 vs Modelo 172: Key Differences
| Dimension | Modelo 172 | DAC8 |
|---|---|---|
| Client scope | Spanish tax residents only | All EU member state residents |
| Filing frequency | Quarterly | Annual |
| Filing deadline | 30 days after quarter end | September 30 (covering prior year) |
| XML schema | AEAT proprietary Modelo schema | OECD CARF schema |
| Transfers to unhosted wallets | Not specifically required | Required above threshold |
| Staking rewards | Partial (operation type S) | Full mandatory reporting |
| Lending/DeFi income | Not covered | Covered |
| ICO proceeds | Not covered | Covered |
| Recipient authority | AEAT (Spain only) | AEAT + automatic exchange to 26 EU tax authorities |
| Non-EU provider obligation | Yes (if serving Spanish residents) | Yes (register in one EU state, report all EU clients) |
What Transactions Must Be Reported Under DAC8
DAC8 requires annual reporting of the following per EU-resident client:
Transaction-level data
- Crypto-to-fiat exchanges: full details of every sale of crypto for EUR or other fiat currency — date, asset type, quantity, EUR equivalent at execution
- Crypto-to-crypto exchanges: every swap — both sides, with EUR equivalent of each at the time of trade
- Transfers: outbound transfers from your platform to any wallet address, including unhosted wallets — destination address, asset type, quantity, EUR equivalent
- Staking rewards received: total rewards per asset type during the year, EUR equivalent on date of receipt
- Lending income: interest or yield received from crypto lending, valued in EUR on receipt
- ICO participation: amounts paid into token sales and tokens received
Year-end balance data
- Each crypto-asset type held on behalf of the client at December 31
- Quantity and EUR equivalent at year-end
Client identification data
- Full legal name, date of birth, country of residence, tax identification number
- For corporate clients: legal name, registration number, registered address, country of incorporation
- TIN (Tax Identification Number) of the EU member state where the client is resident — not just Spanish NIF/NIE
TIN collection is the hard part. For Spanish clients, you already collect NIF/NIE. For clients from other EU member states, you need their local TIN — a French NIF, a German Steuer-ID, a Dutch BSN. This requires updating your KYC onboarding flow for all EU clients, not just Spanish residents. Start collecting now — retroactive collection from existing users is operationally painful.
The CARF XML Schema
DAC8 mandates the OECD Crypto-Asset Reporting Framework (CARF) as the data exchange format. CARF is an XML schema developed by the OECD in parallel with DAC8, designed to be the global standard for crypto transaction reporting — similar to how CRS (Common Reporting Standard) governs bank account information exchange.
Key structural differences from Spain's current Modelo XML schemas:
- Reporting period: CARF is annual; Modelo 172 is quarterly. The schemas have different root structures and period identifiers.
- Entity identifiers: CARF uses GIIN-like identifiers for reporting entities; Modelo uses Spanish NIF.
- Asset classification: CARF has its own crypto-asset type taxonomy, partially overlapping with but not identical to Modelo's classification codes.
- Transaction types: CARF has different type codes for the additional transaction categories (staking, lending, ICO) not covered in Modelo 172.
- Multi-jurisdiction fields: CARF records include sending and receiving country codes for cross-border exchange routing — absent from Modelo.
The AEAT is expected to publish its national CARF implementation guide in Q3 2026. Until then, build systems that store data in a normalized internal format from which both schemas can be generated — avoid hardcoding either schema at the data capture layer.
What If You Already File Modelo 172?
Good news: if you have a functioning Modelo 172 pipeline, you're starting from a strong position. The data capture requirements overlap significantly. The gaps are concrete and manageable:
| Gap | What to add | Effort |
|---|---|---|
| EU client scope (non-Spanish) | Extend KYC to collect TIN for all EU member states, not just Spanish NIF/NIE | Medium — KYC flow update, existing-user outreach |
| Staking rewards | Add structured staking reward records to transaction log with EUR value at receipt | Low — if staking data already captured informally |
| Lending/DeFi income | Add income type to transaction taxonomy; capture EUR value at receipt date | Low-Medium |
| Transfers to unhosted wallets | Log destination address + EUR value for all outbound transfers | Low — destination address likely already recorded |
| CARF XML generation | Build CARF XML serializer alongside existing Modelo serializer | Medium — different schema, but same underlying data |
| Year-end balance snapshot | Add December 31 snapshot generation (you already do this for Modelo 173) | Low — primarily a schema translation |
Total additional effort for a firm with clean Modelo 172 infrastructure: estimated 3–6 months of engineering time, depending on stack complexity. For firms without any structured Modelo 172 pipeline, build one now — DAC8 readiness follows naturally.
Penalties for DAC8 Non-Compliance
Spain's DAC8 transposition establishes penalties aligned with the General Tax Act. Expected penalties for RCASP non-compliance:
- Failure to register (non-EU CASPs): up to €500,000 per member state where the provider operates without registering
- Failure to report: per-record penalties equivalent to the Modelo 172 framework — €20 per omitted item, minimum €300, up to €600,000 for systematic omissions
- Incorrect client identification (wrong TIN, missing TIN): penalty per client record with incorrect data
- Late submission: 5% of unreported transaction value, minimum €1,500
The OECD CARF framework includes a peer review mechanism — member states will be assessed on their enforcement of CASP compliance. Spain, having been an early MiCA enforcer, is expected to apply DAC8 penalties actively from the first reporting cycle.
Action Plan: What to Do Now
September 2027 seems distant. It isn't. The data you need to report was generated starting January 1, 2026 — today. Every day without the right infrastructure is data you'll need to reconstruct later, at significant cost and risk.
- Update your KYC onboarding today to collect the TIN for every EU member state your clients reside in. Add a mandatory field for non-Spanish EU residents at account opening.
- Audit your existing EU client base for missing TINs. Plan a retroactive collection campaign — email, in-app prompt, account suspension for non-compliance. This is the longest lead time item.
- Extend your transaction log schema to capture staking rewards, lending income, and unhosted wallet transfer destinations as structured fields — not free-text notes.
- Get your Modelo 172 infrastructure clean first. If you're not filing Modelo 172 correctly today, DAC8 is impossible. Modelo 172 compliance is the prerequisite.
- Monitor AEAT CARF specs expected Q3 2026. Subscribe to AEAT regulatory updates and ESMA's DAC8 implementation guidance. Build your serializer against the OECD CARF schema now — national customizations are typically minor.
- Budget engineering time in 2026 Q3/Q4 for CARF XML implementation and testing. Don't leave it for 2027.
The first-mover advantage is real. Firms that have clean, structured data capture in place by end of 2026 will file DAC8 reports confidently in September 2027. Firms scrambling to reconstruct 2026 data in August 2027 will either file incorrectly — triggering penalty exposure — or pay emergency compliance fees that dwarf the cost of building the infrastructure now.
Frequently Asked Questions
What is DAC8?
DAC8 is the 8th amendment to the EU Directive on Administrative Cooperation. It requires EU crypto-asset service providers to report clients' crypto transactions to their national tax authority annually, which then automatically shares the data with tax authorities in all other EU member states where those clients reside. First reports covering 2026 are due September 30, 2027.
What is the DAC8 deadline?
September 30, 2027 for first reports covering calendar year 2026. Data capture must begin January 1, 2026 — the reporting infrastructure must be live from day one of the reporting period.
What is the difference between DAC8 and Modelo 172?
Modelo 172 covers only Spanish tax resident clients, is filed quarterly to AEAT using Spain's proprietary XML schema. DAC8 covers all EU resident clients, is filed annually using the OECD CARF XML schema, and triggers automatic data sharing across all 27 EU member states. DAC8 also covers staking, lending, ICO proceeds, and unhosted wallet transfers — transaction types Modelo 172 does not fully address. Both run in parallel from 2027.
Does DAC8 apply to non-EU crypto exchanges serving EU clients?
Yes. Non-EU CASPs with EU clients must register with a competent authority in one EU member state and comply with DAC8 for all EU clients. Failure to register is sanctionable in every EU member state where the provider operates.
What crypto transactions must be reported under DAC8?
Crypto-to-fiat exchanges, crypto-to-crypto exchanges, transfers (including to unhosted wallets above threshold), staking rewards, lending income, and ICO proceeds — all with EUR equivalents at execution time. Plus year-end balance data per crypto-asset type per EU client.
What is the CARF XML schema required by DAC8?
CARF (Crypto-Asset Reporting Framework) is the OECD XML schema adopted by DAC8 for cross-border reporting. It differs from Spain's current Modelo 172 XML format in structure, field definitions, and asset classification taxonomy. Both schemas must be generated separately from the same underlying transaction data from 2027.
If we already file Modelo 172, do we need much additional work for DAC8?
Around 65–70% of data elements overlap. Three gaps require real work: expanding client scope to all EU residents (requires TIN collection for non-Spanish clients), adding staking/lending/ICO transaction types to your data capture, and building a CARF XML serializer alongside your existing Modelo serializer. Firms with clean Modelo 172 infrastructure have a significant head start.