Reportable Crypto-Assets: What Is In Scope — and the CBDC/E-Money Nuance
Under DAC8 (Council Directive (EU) 2023/2226), a reportable crypto-asset is any crypto-asset that can be used for payment or investment purposes — unless it falls into one of three excluded categories: it is a central bank digital currency (CBDC), it is a Specified Electronic Money Product (SEMP) — defined as a single-fiat-currency e-money instrument redeemable at par on demand — or the RCASP has adequately determined, on a documented basis, that the asset cannot be used for payment or investment purposes by any holder. If none of those exclusions apply, the asset is in scope regardless of how it is labelled or marketed.
The CBDC and SEMP exclusions are real, but they operate on only one of DAC8's two reporting tracks. CBDCs and standard e-money instruments are excluded from the CARF-track obligations that fall on RCASPs. However, DAC8 simultaneously expands the existing Common Reporting Standard into what practitioners call CRS 2.0: CBDCs, electronic money, and e-money tokens held by financial institutions on behalf of clients are now fully in scope for CRS-style reporting by those Reporting Financial Institutions. For any platform that combines crypto-asset services with e-money custody or CBDC-related products, both tracks must be assessed independently — the CARF exclusion does not extinguish the CRS obligation.
Several asset classes require careful analysis rather than automatic exclusion. Stablecoins are reportable under the CARF track unless they qualify as SEMPs — most multi-currency or algorithmically managed stablecoins will not qualify. NFTs require a case-by-case assessment: an NFT that can be used as a means of payment or traded on a liquid market for investment purposes is likely in scope; a purely non-fungible digital collectible with no payment use is more likely excluded, but the RCASP must document that determination. Decentralised crypto-assets issued without a central issuer are also covered — the absence of an issuer does not affect reportability. When in doubt, the default position under DAC8 is inclusion.
Data Collection from 1 January 2026: TIN Collection and Tax Self-Certification at Onboarding
From 1 January 2026, every RCASP must collect a defined set of data points for each reportable user at the point of onboarding — and retrospectively for pre-existing users. For individuals, the required fields are: full legal name, residential address, date of birth, jurisdiction(s) of tax residence, and the Tax Identification Number (TIN) issued by each such jurisdiction. For entities, the incorporation date and registered address replace the date of birth, and the same TIN requirements apply. The primary collection mechanism is self-certification: the user declares their tax residency status and provides their TIN(s) directly. For new users onboarding from 1 January 2026, the standard is effectively no valid certification, no service — account activation should not proceed until a complete and plausible self-certification is received.
Pre-existing users — those onboarded before 1 January 2026 — must be subject to a retroactive remediation programme. RCASPs must combine direct self-certification requests with a review of existing account data for conflicting indicia of tax residence. The reason-to-know standard is critical here: if an RCASP holds account data, KYC documentation, or transactional information that is inconsistent with a user's self-certification, the RCASP must initiate a cure procedure to resolve the conflict. Passive reliance on an uncorroborated declaration is not sufficient. Separately, DAC8 requires the European Commission to provide Member States with an electronic TIN verification tool; TIN validation requirements apply from 1 January 2028, with corresponding national transposition required by 31 December 2027.
At the transaction level, each annual report must capture aggregate gross amounts received and paid for crypto-to-fiat exchanges and crypto-to-crypto exchanges, fair market values for transfers, and — significantly — transfers to distributed ledger addresses not associated with any known service provider or financial institution, i.e., withdrawals to unhosted or self-custody wallets. Under the CARF XML reporting schema, monetary amounts (including those expressed in EUR) are reported to two decimal places (e.g. 1000.00, with the relevant ISO 4217 currency code), whereas the quantities of crypto-assets are reported to up to six decimal places. This granularity means RCASPs need robust transaction-level data pipelines in place from day one of the first reporting period, not assembled retrospectively ahead of the January 2027 filing window. See key MiCA and DAC8 deadlines for 2026 and the complete CASP licence requirements guide for the broader compliance calendar.
The 60-Day Blocking Rule: How It Works and What It Demands Technically
DAC8 Annex VI imposes a mandatory transaction-blocking mechanism that has no equivalent in the pure OECD CARF framework — this is an EU-specific addition. The sequence is strictly ordered. When a Reporting Crypto-Asset Service Provider (RCASP) cannot obtain a valid self-certification at onboarding or during remediation, it must send at least two formal reminders to the affected user. If, after the second reminder and a total elapsed period of at least 60 days from the date of the first request, the user has still not provided a valid certification, the RCASP must block that user from performing any Reportable Transaction. This is a mandatory legal obligation under DAC8 Annex VI — not an operational discretion, not a risk-based judgment. The block must remain in place until the user supplies a valid self-certification, and the RCASP must notify the user that transactions have been restricted and explain exactly how the restriction can be lifted.
The engineering and compliance implications are concrete. Platforms must implement: automated day-count tracking from the date of the first self-certification request (with a durable audit trail); a two-stage reminder workflow that records the timestamp and delivery confirmation of each reminder; and conditional transaction-restriction logic that fires at the 60-day hard trigger without manual intervention. The standard OECD CARF framework imposes no such blocking obligation — jurisdictions that implement CARF outside the EU do not carry this requirement. CASPs operating globally must therefore maintain separate workflow logic for EU-nexus users covered by DAC8.
There is also a GDPR-specific notification obligation that sits alongside the blocking rule and is frequently underestimated. Unlike a general privacy notice, DAC8 requires RCASPs to inform each affected user, before the information is reported to competent authorities, that their personal data will be collected and transmitted. This individual pre-reporting notification must be built into the data-collection workflow — it cannot be satisfied by a blanket clause buried in terms of service. Platforms that already have common MiCA compliance gaps in their user-notification procedures should treat this as a separate, additive obligation requiring its own documented process.
Reporting Deadlines: Two Levels You Must Not Confuse
The most operationally dangerous misconception in DAC8 compliance planning is treating a single date as "the reporting deadline." There are two entirely distinct deadline layers, and conflating them produces material compliance failures. Level 1 is the RCASP-to-National Competent Authority (NCA) deadline: DAC8 Annex VI sets 31 January of the year following the reporting calendar year as the EU-wide minimum. For the first reporting cycle — data collected throughout 2026 — the baseline filing deadline is 31 January 2027. Member States may legislate a later national deadline, and several have done so: Luxembourg (law adopted 19 March 2026) set 30 June 2027; Poland (law published 17 March 2026) also set 30 June 2027. These are not anomalies — they are lawful exercises of the flexibility DAC8 permits, and they represent the binding deadline for RCASPs with a nexus in those jurisdictions. Level 2 is the NCA-to-NCA automatic exchange deadline: once Member States hold RCASP filings, they must transmit non-resident investor data to the investor's country-of-residence tax authority within 9 months of the end of the reporting year — meaning by 30 September 2027 for 2026 data. This deadline falls entirely on governments. It creates no direct obligation for CASPs and must never be described as "the" reporting deadline.
The compliance picture is further complicated by implementation gaps. As of early 2026, approximately 12 Member States were subject to European Commission infringement proceedings for failing to transpose DAC8 into national law on time. In those jurisdictions, the binding domestic deadline — and potentially the precise scope of national implementation — had not yet been published. Monitoring enacted national implementing legislation in every nexus Member State is itself a standing compliance obligation, not a one-time check. For practical planning, the table below summarises confirmed filing structures across key jurisdictions.
- Denmark: RCASP → NCA deadline 31 January 2027
- Netherlands: RCASP → NCA deadline 31 January 2027
- Luxembourg: RCASP → NCA deadline 30 June 2027 (law adopted 19 March 2026)
- Poland: RCASP → NCA deadline 30 June 2027 (law published 17 March 2026)
- All Member States: NCA → NCA exchange by 30 September 2027 (government obligation only)
CASPs building their reporting calendars should also cross-reference the broader 2026 MiCA compliance timeline to avoid deadline collisions — DAC8 data-collection obligations run concurrently with MiCA authorisation milestones, and the same compliance team typically owns both tracks. If your authorisation footprint spans multiple Member States, the most conservative approach is to target 31 January 2027 as the internal filing-ready date regardless of any national extension, unless operational capacity makes that impossible.
Frequently asked questions
When exactly must my platform start collecting DAC8 data, and when must I file the first report?
Data collection obligations started on 1 January 2026 — there is no grace period for the collection phase. For the first reporting cycle (covering the full 2026 calendar year), the EU-wide minimum deadline for filing with your national competent authority is 31 January 2027. However, some Member States have enacted later national deadlines: Luxembourg and Poland, for example, both set 30 June 2027 for the first filing. The 30 September 2027 date you may have seen refers to the government-to-government exchange deadline between tax authorities — not a deadline that falls on CASPs. Always check the enacted domestic law in every Member State where you have a DAC8 nexus, as implementation is uneven.
Are CBDCs and e-money tokens excluded from DAC8 reporting?
Partially — and the nuance matters. CBDCs and Specified Electronic Money Products (SEMPs — single-fiat e-money instruments redeemable at par) are excluded from the CARF/DAC8 RCASP reporting track. However, DAC8 simultaneously expands the CRS track ('CRS 2.0'): financial institutions holding CBDCs or e-money tokens on behalf of clients become Reporting Financial Institutions and must report those holdings under the updated CRS rules. Platforms that combine crypto-asset services with e-money or CBDC custody therefore face obligations under both tracks and need to map each product line to the correct reporting mechanism.
What triggers the 60-day transaction block, and how must we implement it?
The block is triggered when: (1) you have requested a valid self-certification from a user; (2) you have sent at least two formal reminders; and (3) a total of at least 60 days has elapsed since the first request, without a valid certification being received. At that point you must — as a mandatory legal obligation under DAC8 Annex VI, not a discretionary option — prevent the user from carrying out any Reportable Transaction until they provide a valid certification. Platforms must build automated day-count tracking from the first request date, two-stage reminder workflows with audit logs, and conditional transaction-restriction logic. There is no equivalent blocking obligation under the pure OECD CARF — it is an EU-specific addition.
My platform is incorporated outside the EU but serves EU users. Does DAC8 apply to us?
Yes. DAC8's extraterritorial reach captures any RCASP that effectuates exchange transactions for users tax-resident in an EU Member State, regardless of where the platform is incorporated. Non-EU platforms without MiCA authorisation must register in a single EU Member State before their reporting obligations arise. However, there is a CARF-relief mechanism: if your platform already reports equivalent information to a non-EU tax authority under a qualifying CARF Multilateral Competent Authority Agreement that includes an effective exchange with the relevant EU Member State, you may be able to satisfy your EU reporting obligation without a separate EU filing. As of March 2026, 76 jurisdictions have committed to commencing CARF exchanges, but coverage varies — seek jurisdiction-specific advice.
How does DAC8 interact with GDPR — is a general privacy notice enough?
No. DAC8 imposes a specific, individual notification requirement that goes beyond a standard privacy policy. Each reportable user must be informed that their personal data will be collected and reported to the competent tax authority, and this notification must be provided before the information is reported — not just at the time of general onboarding. Generic cookie-banner notices or buried T&C references do not satisfy this requirement. Platforms must also reconcile DAC8 data retention obligations with GDPR's storage-limitation principle, and must analyse cross-border data transfer obligations under GDPR Chapter V when CARF multilateral exchanges route data outside the EU.
What penalties apply for non-compliance with DAC8, and can it affect our MiCA licence?
DAC8 sets an EU-minimum penalty band of €20,000 to €500,000 for serious non-compliance, with Member States free to set higher amounts under national implementing law. Beyond direct fines, the most significant risk for MiCA-licensed platforms is regulatory: national competent authorities can treat DAC8 non-compliance as grounds for restricting or revoking passporting rights, making tax-transparency compliance a de facto condition of maintaining the MiCA licence. Non-EU platforms that fail to register in a Member State do not eliminate their reporting obligations and risk enforcement measures, including being excluded from EU market access.