DAC8 and CARF: The Crypto-Asset Tax Reporting Obligation Every CASP Must Operate by 2026

Most crypto-asset service providers spent 2025 doing one thing: getting MiCA authorisation over the line. Capital files, governance manuals, ICT policies, white papers. It absorbed the entire compliance budget — and while it did, a second obligation arrived almost silently.

That obligation is DAC8 — the EU's eighth amendment to its Directive on Administrative Cooperation — and the OECD framework it transposes, the Crypto-Asset Reporting Framework (CARF). Together they do something MiCA never did: they turn every CASP into a tax-reporting intermediary. The first data-collection period began 1 January 2026; the first cross-border exchange of that data lands in 2027.

The uncomfortable reality: most firms have no reporting pipeline at all. This guide lays out the DAC8 Reporting Readiness Map — five workstreams that take you from 'we collect KYC data' to 'we can file a valid annual return': Reportable-User Identification, Reportable-Transaction Capture, Due-Diligence & Self-Certification, Annual Return Build, and Penalty-Exposure Controls.

The Markets in Crypto-Assets Regulation¹^[1] and DAC8 were drafted by different parts of the EU machine — MiCA by the financial-services side, DAC8 by the tax directorate. They are not the same regime, they do not share a supervisor, and crucially they do not share a deadline by coincidence — they simply landed together.

MiCA is a conduct and authorisation regime: it governs whether you may operate, with what capital, under whose supervision. DAC8 is a reporting regime: it governs what data about your customers you must hand to tax authorities, in what format, by when. A firm can be fully MiCA-authorised and entirely DAC8-non-compliant at the same time.

That is exactly the trap. The MiCA project consumed the compliance function for eighteen months, and the DAC8 reporting build was deferred on the assumption it was 'a tax thing for later'. It is not later. The first reportable period started 1 January 2026 — meaning every transaction since then is already in scope and already needs to be captured to the reporting standard.

Start with the OECD layer. The Crypto-Asset Reporting Framework²^[2] is the global model. It was published by the OECD in 2022 as the crypto analogue of the Common Reporting Standard (CRS) that already governs automatic exchange of bank-account data. CARF is not law anywhere by itself — it is a template each jurisdiction enacts.

DAC8 is the EU's enactment. Council Directive (EU) 2023/2226³^[3] amends the long-standing Directive on Administrative Cooperation (Directive 2011/16/EU) to fold CARF — and CARF-aligned amendments to CRS — into binding EU law. In plain terms: DAC8 is CARF, transposed for the EU, with the EU's own enforcement and exchange architecture bolted on.

The base DAC framework⁴^[4] has been amended seven times before — DAC2 brought in CRS bank-account exchange, DAC6 brought in cross-border arrangement reporting. DAC8 is the eighth, and the first to reach crypto-assets, e-money, and central bank digital currencies.

The operative dates: Member States had to transpose DAC8 into national law by 31 December 2025. The rules apply from 1 January 2026 — that is when data collection begins. The first reports are filed and the first automatic exchange between tax authorities happens in 2027, covering the 2026 reportable year.

DAC8 readiness is not a single project; it is five distinct workstreams that touch different parts of the business — compliance, data engineering, customer operations, and tax. Treating it as 'a compliance task' is the most common way firms under-resource it.

1. 1

   Reportable-User Identification — determine which users are reportable, in which jurisdictions, including controlling persons of entities.

2. 2

   Reportable-Transaction Capture — record every reportable transaction type with the data fields CARF requires.

3. 3

   Due-Diligence & Self-Certification — collect and reasonableness-test self-certifications of tax residence.

4. 4

   Annual Return Build — assemble the data into the XML schema and file with the competent authority.

5. 5

   Penalty-Exposure Controls — manage the Member State penalty regime and the licence risk of 'significant non-compliance'.

A reportable user is any crypto-asset user that is a resident of a reportable jurisdiction — broadly, any jurisdiction other than the one where you are reporting, that participates in the exchange network. For an EU CASP, that means almost every customer who is tax-resident somewhere other than the Member State of filing is potentially reportable.

The pivotal field is tax residence — not nationality, not country of address, not the jurisdiction of the IBAN. Tax residence is determined by self-certification cross-checked against documentary indicia. A user can be tax-resident in more than one jurisdiction, in which case they are reportable to each.

For entity users, the obligation deepens. You must look through the entity to its controlling persons — the same beneficial-ownership concept your AML function already maps for UBO purposes — and report the tax residence of each controlling person where the entity is a passive non-financial entity. This is the single largest data-mapping task in the whole map.

CARF defines three broad classes of reportable transaction, each of which must be captured with gross amounts, units, and fair-market value at the time of the transaction.

• Crypto-to-fiat exchanges — every sale of a crypto-asset for fiat currency.

• Crypto-to-crypto exchanges — every swap of one crypto-asset for another, valued in fiat at execution.

• Transfers — including transfers to external wallets, split between transfers to other reportable users and transfers out of the platform.

There is also a fourth, easily-missed category: retail payment transactions above EUR 50,000. Where a CASP processes a crypto-asset transfer in exchange for goods or services exceeding EUR 50,000, the merchant-side acceptance is itself a reportable event. Firms with a payments leg routinely overlook this.

The engineering challenge is fair-market valuation at transaction time. For a crypto-to-crypto swap there is no fiat amount in the transaction record — you must snapshot a defensible price source at the moment of execution and store it immutably. Reconstructing this after the fact is expensive and error-prone, which is why capture must be built in, not back-filled.

DAC8 imports the CRS self-certification model wholesale. Every new user must provide a self-certification of tax residence — and critically, the CASP cannot simply file the form away. It must apply a reasonableness test: does the claimed residence square with the other information already held about the user?

If you already operate CRS⁵^[5] due diligence elsewhere in the group, much of this machinery exists. But the crypto-asset user population is usually onboarded through a different stack than the bank-account population, so the self-certification flow rarely carries over without rebuild.

Where a self-certification fails the reasonableness test, the CASP must obtain a valid replacement or apply the indicia-based fallback. For pre-existing users carried over from before 2026, there is a look-back due-diligence obligation — you cannot exempt your existing book simply because it onboarded before the rules applied.

The output is an annual return filed with the competent authority of the Member State where the CASP is registered for DAC8 — typically the tax administration, per the Commission's DAC framework⁶^[6]. That authority then exchanges the relevant records with the tax authorities of each reportable jurisdiction.

The return is filed in a prescribed XML schema — the CARF XML schema, mirroring the CRS schema that CASPs with banking arms will recognise. Free-text uploads and spreadsheets are not accepted; the data must validate against the schema or it is rejected at submission. The build effort is therefore as much a data-engineering project as a compliance one.

One nuance firms miss: nil returns are still expected in most Member State implementations. If you are a registered reporting CASP but had no reportable users in a period, you still file — a return confirming nil. Silence is read as non-filing, not as 'nothing to report'.

Most Member States have aligned their reporting calendars so that the return covering the 2026 reportable year is due in the first half of 2027, with the competent-authority-to-competent-authority exchange following shortly after. That leaves a narrow window between period close and filing in which the entire year's data must be reconciled, validated against the schema, and corrected. Firms that leave reconciliation to that window discover that broken or missing fields cannot be re-collected retroactively — the transaction has happened, the price moment has passed, and the user may no longer be reachable.

DAC8 leaves penalties to the Member States, requiring only that they be effective, proportionate and dissuasive. In practice this produces a patchwork: per-record fines in some jurisdictions, fixed late-filing penalties in others, and escalating daily penalties for continued failure. A CASP serving users across the EU is exposed to the regime of its reporting Member State, but the data flows to every reportable jurisdiction.

The more serious exposure is not the fine. It is significant non-compliance — a concept that links the reporting regime back to authorisation. Repeated or systemic DAC8 failure can be treated as evidence that the firm lacks adequate governance and internal controls, which is a condition of the CASP authorisation itself. A tax-reporting failure can, in the limit, become a licence problem.

There is also a user-side enforcement lever: where a user fails to provide a valid self-certification after repeated requests, several implementations require the CASP to prevent the user from transacting until the certification is obtained. The control framework therefore has to reach into the product, not just the back office.

Two operational controls separate firms that file cleanly from firms that scramble. The first is a continuous reasonableness-monitoring rule — a change in a user's address, banking jurisdiction, or login geography should trigger a re-test of their declared tax residence, not just sit in the file. The second is a year-round reconciliation cadence rather than an annual one: reconciling reportable transactions monthly against the source ledger surfaces capture gaps while they are still fixable. Both controls cost far less than a back-fill, and both are exactly what a supervisor expects to see documented when it assesses whether the firm's governance is fit for the CASP authorisation.

Here is the good news, and it is genuine: you already collect most of the data DAC8 needs. Your KYC onboarding captures identity, address, and documentary evidence. Your UBO mapping for entity customers already identifies controlling persons. Your transaction-monitoring stack already records every exchange and transfer.

The gap is not the raw data — it is the reporting layer. AML asks 'is this customer or transaction suspicious?'. DAC8 asks 'where is this user tax-resident and what is the fiat value of every disposal?'. Those are different questions over an overlapping dataset, and the two critical fields AML does not reliably capture are tax residence and fair-market value at transaction time.

The build, done well, is therefore an extension of the AML data model, not a parallel system. Add a tax-residence self-certification to onboarding, add a fair-market-value snapshot to the transaction record, add a controlling-person tax-residence field to the entity-onboarding flow — and most of the reportable dataset assembles itself.

The governance argument is just as important as the technical one. Because significant non-compliance with DAC8 feeds back into the authorisation regime, the reporting pipeline belongs inside the same control framework your MLRO already owns for AML — with documented ownership, a tested process, and a reconciliation log the regulator can inspect. Treating DAC8 as an isolated tax obligation, parked with an external accountant once a year, is precisely the posture supervisors read as weak internal control.

There is a commercial dividend, too. A firm that can demonstrate a clean, auditable DAC8 pipeline is materially more attractive to institutional counterparties, banking partners, and acquirers — all of whom now treat tax-reporting readiness as a proxy for overall operational maturity. The same evidence pack that satisfies the competent authority doubles as diligence material in a banking or funding conversation.

• 31 December 2025 — Member State transposition deadline; DAC8 becomes national law.

• 1 January 2026 — first reportable period begins; data collection and new-user self-certification live.

• 31 December 2026 — first reportable period closes; pre-existing-user look-back due diligence due around this point.

• 2027 — first annual return filed with the competent authority; first automatic exchange between tax authorities.

The trap in this timeline is that the filing deadline in 2027 feels far away, but the data it depends on is being created right now. You cannot file in 2027 for transactions you failed to capture to standard in 2026. The work is not 'before the deadline' — it is already overdue.

DAC8 is Council Directive (EU) 2023/2226, the eighth amendment to the EU's Directive on Administrative Cooperation in taxation. It requires crypto-asset service providers to report user and transaction data to tax authorities, which is then automatically exchanged between Member States. It is the EU's transposition of the OECD's CARF.

Data collection began 1 January 2026 — the first reportable period. The first annual return is filed in 2027, and the first automatic exchange of that data between tax authorities also happens in 2027. Member States had to transpose DAC8 into national law by 31 December 2025.

In substance, yes. A non-EU CASP with reportable EU users is generally required to register and report in a Member State, unless it already reports under an equivalent CARF regime in its home jurisdiction that exchanges with the EU. The obligation follows the user base, not just the place of establishment — which is the whole point of a global framework like CARF.

CARF is the OECD's global model — a template, not law. DAC8 is the EU's binding enactment of that model, with EU-specific enforcement, the competent-authority exchange architecture, and extra scope items (e-money and CBDCs). A CASP outside the EU may instead be subject to its own jurisdiction's CARF enactment — same data, different legal instrument.

In most Member State implementations, yes — a nil return is still expected from a registered reporting CASP. Not filing is treated as non-compliance, not as an implicit 'nothing to report'. Confirm the exact nil-return rule with the competent authority of your reporting Member State.

• AML Compliance for Crypto Under 6AMLD: the KYC and UBO data model that DAC8 reporting extends rather than replaces.

• AMLR Readiness Programme: 12-Month Roadmap: how the DAC8 build slots into the wider 2026 AML and reporting workplan.

• Travel Rule Architecture Build: the adjacent transfer-data pipeline that shares much of DAC8's capture machinery.

• The CFC Map: the tax-structuring context that sits behind the residence determinations DAC8 forces you to make.

MiCA decided whether you may operate; DAC8 decides whether you can keep your data house in order under tax-authority scrutiny. The two arrived together, but only one of them has a deadline that is already running. Run your business against the DAC8 Reporting Readiness Map now, while a missed field is a data-engineering fix — not in 2027, when it is a penalty and, in the worst case, a question about your licence.