DAC8 XML reporting — the data build, the schema, and how it lines up with CARF and CRS
DAC8 XML reporting is not a report you generate at year end — it is a data-capture obligation that started on 1 January 2026 and a schema you have to be able to populate from ledgers that were never designed to answer these questions. The directive is settled, the format instrument is published, and the first filing covers calendar year 2026. The gap most firms discover late is not legal: it is that the reportable unit is an aggregate per user, per asset type, per transaction type, valued in a single fiat currency at the moment of each transaction — and that some data must be retained for five years without ever being reported. This is the integration walkthrough.
1. What binds, and by when
The obligation comes from Council Directive (EU) 2023/2226 of 17 October 2023 — DAC8 — amending Directive 2011/16/EU on administrative cooperation in taxation. Member states had to transpose the main rules by 31 December 2025, and the provisions apply from 1 January 2026. So the first reporting period is calendar year 2026, with reports due to the national competent authority in early 2027 and automatic exchange between member states within nine months of the end of the reporting year — by 30 September 2027.
The scope catches reporting crypto-asset service providers (RCASPs) whether or not they hold a MiCAR authorisation. That is the first thing to check: a MiCAR permission is not the trigger, and a firm with no MiCAR licence but a nexus to a member state can still be an RCASP.
The format is fixed separately. Commission Implementing Regulation (EU) 2025/2263 of 12 November 2025 amended Implementing Regulation (EU) 2015/2378 to set the standard forms and computerised formats for the mandatory automatic exchange of information on reportable crypto-assets. Alongside it, the OECD’s Crypto-Asset Reporting Framework XML Schema — approved in 2023, with a user-guide technical update in 2024 and further technical adjustments in July 2025 — plus a companion CARF Status Message XML Schema for the response messages, define the international shape that DAC8 reporting aligns to. The OECD is explicit that the schema may also be used for domestic reporting by RCASPs where national law allows it, which is why some tax authorities will accept something close to the exchange format from you directly.
2. What counts as a reportable asset — the three exclusions
Do not model this as “all crypto”. Under the CARF definitions that DAC8 tracks, Relevant Crypto-Assets means all crypto-assets except three categories:
- Central bank digital currencies — treated as a digital form of fiat currency, not a crypto-asset.
- Specified electronic money products.
- Crypto-assets the RCASP has adequately determined cannot be used for payment or investment purposes.
The default matters enormously for your data model: everything else is presumed usable for payment or investment purposes unless the RCASP makes an affirmative determination otherwise. In other words, exclusion is an evidenced decision you have to record, not a status you can infer. Anything treated as a virtual asset under the FATF Recommendations is in scope, and non-fungible tokens traded on a marketplace are in scope too.
3. The four reporting lines
The reportable population splits into four categories, and they are not interchangeable in the file:
| Line | What it covers | Reported value |
|---|---|---|
| Crypto-to-fiat | Acquisitions and disposals against fiat currency | Aggregate amount paid or received, net of transaction fees |
| Crypto-to-crypto | Exchanges between forms of relevant crypto-assets | Aggregate fair market value |
| Retail payment transactions | Transfers for goods or services above USD 50,000 | Reported as a separate category |
| Transfers | Other transfers, including to external wallet addresses | Aggregate units and aggregate fair market value |
Two subtleties cause most reconciliation failures. First, net of transaction fees — the reported amount for a fiat acquisition is the amount paid net of fees, so a pipeline that reports gross order value will be consistently wrong in the same direction. Second, the retail-payment line has a de minimis: a transfer for goods or services that falls below the USD 50,000 threshold does not simply disappear, it belongs in the general Transfers aggregate instead. Dropping sub-threshold retail payments entirely is a silent under-report.
4. The aggregation and valuation rules
Reporting is on an aggregate basis per reportable user, by type of relevant crypto-asset, distinguishing the type of transaction, as of the end of the calendar year. That is a three-dimensional grouping, and it is the shape your warehouse has to produce — not a transaction list.
Valuation is where a naive implementation breaks. For crypto-to-fiat transactions the reported amount is the fiat amount paid; where amounts arise in several fiat currencies, everything must be reported in a single fiat currency, converted at the time of each relevant transaction and in a manner the RCASP applies consistently. For crypto-to-crypto exchanges, fair market value must be determined at the time of the transaction in a single currency — in practice by implicitly converting both legs to fiat at execution. Neither rule tolerates a year-end revaluation, which means the FX and price snapshot must be captured and stored at execution time. Retrofitting it from historical rate tables afterwards produces numbers you cannot defend, and the transfer lines also require reporting alignment with the digital token identifier where feasible.
5. The five-year retention duty that is not a reporting duty
This is the requirement most integration plans miss. For transfers to external wallet addresses, the RCASP reports — by type of asset — the aggregate number of units and aggregate fair market value of transfers made on behalf of a reportable user to addresses not known to be associated with a virtual asset service provider or financial institution as defined in the FATF Recommendations. The wallet addresses themselves are not reported.
But they must be kept. The RCASP is required to collect and retain in its records, for not less than five years, any external wallet addresses associated with transfers of relevant crypto-assets, so that the information is available to tax administrations in follow-up requests. So the build has two distinct outputs from the same event: an aggregate that goes into the XML, and an address-level record that goes into a five-year archive nobody queries until a tax authority asks. Firms that only build the reporting path pass validation in 2027 and fail the first follow-up request.
6. Due diligence, and the one place you can reuse work
The identification layer is deliberately modelled on the CRS: the RCASP identifies its crypto-asset users, determines which are reportable, and relies on self-certification to establish residence and tax identification. The reuse point is explicit and valuable — for the purpose of completing the self-certification, an RCASP may rely on a valid self-certification already collected under the CRS, or one collected for other tax purposes such as domestic reporting or FATCA, provided it contains all the information CARF requires.
That last clause is the whole engineering question. Your existing CRS self-certification store is reusable only field-by-field, so the sensible first task is a gap analysis between what your CRS records hold and what CARF requires, rather than a blanket re-papering exercise that annoys your entire customer base. Where a merchant relationship is involved, note that the crypto-asset user may be the merchant, the merchant’s customer, or both, depending on the structure — which changes who you must identify.
7. How this lines up with CARF and the amended CRS
DAC8 is the EU’s implementation of an international standard, not a European invention. CARF and the amended CRS were approved by the OECD in 2023 and endorsed as international standards, and first exchanges under both are expected to commence in 2027 for reporting year 2026 — the same cycle as DAC8. For a group operating inside and outside the EU that is good news and bad news: one data model can serve both, but the two build orders must be scoped together, because DAC8 also widens the existing CRS-derived reporting in the directive. Treat the EU and non-EU obligations as one programme with one canonical data set and jurisdiction-specific output adapters.
8. Worked examples
Scenario 1 — the gross-value pipeline. Facts: a platform builds its DAC8 extract from the order-management system, summing executed order notional per user per asset. What the rule says: for acquisitions and disposals against fiat, the reported figure is the aggregate amount paid or received net of transaction fees. What the practitioner does: moves the extract downstream of fee settlement, and reconciles the DAC8 aggregate to the fee-inclusive customer statement so the difference is explainable rather than mysterious. Outcome: a file that agrees with the customer’s own records instead of overstating every user’s position by the fee margin.
Scenario 2 — the €48,000 coffee-shop problem. Facts: a payment processor handles crypto transfers to merchants, most of them below USD 50,000. The team reads the threshold and filters everything under it out of the extract. What the rule says: transfers that fail the retail-payment threshold do not leave the file — they fold into the general Transfers aggregate, and only the separate retail-payment category is threshold-gated. What the practitioner does: rewrites the classification step as a routing rule with two destinations rather than a filter with one, and adds a control totalling all transfers against the sum of both buckets. Outcome: the sub-threshold volume is reported in the right place instead of being silently dropped.
Scenario 3 — the archive nobody built. Facts: eighteen months after go-live, a tax administration asks an RCASP for the external wallet addresses behind a reported transfer aggregate for one user. The firm reported the aggregates correctly but never persisted destination addresses beyond a 90-day operational log. What the rule says: external wallet addresses associated with transfers must be collected and retained for not less than five years, precisely for follow-up requests, even though they are not reported. What the practitioner does: nothing that fixes the past — the data is gone; the forward fix is a separate immutable address archive with a five-year retention class, provisioned independently of operational log rotation. Outcome: the reason to check this before the first filing, not after.
9. FAQ
What are the core requirements for DAC8 crypto reporting?
Identify your crypto-asset users and determine which are reportable using self-certification; classify relevant transactions into the four reporting lines; aggregate per user, per asset type and per transaction type for the calendar year; value in a single fiat currency at the time of each transaction; and file in the prescribed XML format.
When is the first DAC8 report due?
The rules apply from 1 January 2026, so the first reporting period is calendar year 2026, with reports to the national competent authority in early 2027 and exchange between member states by 30 September 2027.
Which XML schema do I build against?
The exchange formats for reportable crypto-assets were set by Commission Implementing Regulation (EU) 2025/2263 amending Implementing Regulation (EU) 2015/2378. That aligns with the OECD CARF XML Schema and its Status Message schema, which the OECD confirms may also be used for domestic reporting where national law permits.
How do DAC8 and CARF differ in practice?
Substantively very little — DAC8 implements the CARF standard within the EU. First exchanges under CARF, the amended CRS and DAC8 all target 2027 for reporting year 2026, so one canonical data set with jurisdiction-specific output adapters is the sensible architecture.
Do I have to report customers’ wallet addresses?
No — you report aggregate units and aggregate fair market value of transfers to external addresses. But you must collect and retain those addresses for at least five years so they can be produced in a follow-up request.
Can I reuse the self-certifications I already hold for CRS?
Yes, where they contain everything CARF requires. A valid self-certification collected under the CRS, for domestic tax reporting or under FATCA can be relied on — so start with a field-level gap analysis rather than a full re-papering.
Are stablecoins and NFTs in scope?
Broadly yes. Only central bank digital currencies, specified electronic money products, and assets the provider has affirmatively determined cannot be used for payment or investment purposes are excluded. NFTs traded on a marketplace are in scope.
10. What to do, today
- Confirm whether you are an RCASP on the nexus tests rather than on whether you hold a MiCAR licence — the two are independent.
- Capture the FX rate and fair market value at execution for every relevant transaction now; this is the one requirement you cannot backfill credibly.
- Rebuild the extract as an aggregate on three axes — user, asset type, transaction type — and place it downstream of fee settlement so amounts are net.
- Provision the five-year external-wallet-address archive as a separate retention class, independent of operational log rotation.
- Run a field-level gap analysis of your CRS self-certification store against CARF requirements, and only re-paper the delta.
- Record an evidenced, dated determination for every asset you treat as out of scope.
Related: DAC8 — EU crypto-asset tax reporting · CRS for EMIs · DAC7 platform operator reporting
