Crypto-asset reporting under CARF and DAC8: reporting dates, data duties and security controls

Crypto-asset exchanges, brokers and wallet providers now have to collect tax identity data on every user and send it to tax authorities, which creates one of the most sensitive customer datasets they hold. The OECD Crypto-Asset Reporting Framework (CARF) sets the international standard, the EU implements it through Council Directive (EU) 2023/2226 (DAC8), the UK through HMRC's CARF regulations, and the US runs its own broker regime on IRS Form 1099-DA. This guide sets out the scope and key dates from each official source, the data that must be collected and reported, and the security and data protection controls that dataset needs. It is for compliance, security, data protection and engineering teams at crypto-asset service providers. Dates and figures were checked against official sources on 2 November 2026. This guide is not tax or legal advice; confirm obligations with the tax authority of each jurisdiction and your advisers.

Key takeaways

• The first reporting year is 2026. EU DAC8 rules apply from 1 January 2026 and the UK CARF regime commenced on 1 January 2026, with the first UK report for calendar year 2026 due by 31 May 2027.
• Every user needs a self-certification. Providers must collect tax residence and tax identification numbers (TINs), plus date and place of birth for individuals, and check them for reasonableness.
• The UK also reports domestic users. HMRC's regime covers UK tax resident users as well as residents of other CARF participating jurisdictions.
• Penalties are per user. HMRC lists penalties of up to 300 pounds per reportable user for failing to collect a valid self-certificate and up to 300 pounds per user for reporting failures.
• The provider is the data controller. DAC8 names reporting crypto-asset service providers as controllers, so GDPR security, retention and breach duties apply to the dataset.

CARF, DAC8 and the national regimes

The OECD published the Crypto-Asset Reporting Framework on 8 June 2023 in "International Standards for Automatic Exchange of Information in Tax Matters", together with amendments to the Common Reporting Standard (CRS), commentaries and exchange of information frameworks. CARF provides for the automatic exchange of tax relevant information on crypto-assets between tax authorities. Each jurisdiction implements it in national law, and the EU does so through DAC8.

The US regime is not CARF. It is a domestic information return system with its own definitions, thresholds and forms. A provider serving US and non-US customers may need to run both.

Who is in scope

• EU reporting crypto-asset service providers: DAC8 Annex VI defines them as crypto-asset service providers or crypto-asset operators that carry out services effecting exchange transactions for or on behalf of reportable users. Recital 14 confirms that providers authorised under MiCA (Regulation (EU) 2023/1114) and operators that are not authorised are both covered. The Commission must keep a register of crypto-asset operators.
• EU nexus: obligations are tied to MiCA authorisation, or to tax residence, incorporation, management or a regular place of business in a Member State.
• UK nexus: HMRC treats a business as UK based if it is UK tax resident, incorporated in the UK, managed in the UK, or has a regular place of business or branch in the UK. Businesses with more than one nexus follow nexus rules to decide where to report.
• Assets covered: DAC8 recital 14 says the concept includes stablecoins, including e-money tokens under MiCA. Annex VI excludes central bank digital currencies, electronic money, and crypto-assets the provider has adequately determined cannot be used for payment or investment purposes.
• US brokers: the IRS instructions exclude pure validators (proof of work or proof of stake) and providers of hardware or software alone, and say staking and other rewards are not reported on Form 1099-DA.

The prudential and licensing side of crypto regulation is covered in the MiCA and DORA for Crypto-Asset Service Providers Guide, and the separate transfer data rules in the Crypto Travel Rule Compliance Guide.

What must be collected and reported

Due diligence

Under DAC8 Annex VI Section III, a provider must obtain a self-certification when it establishes a relationship with a user and confirm that it is reasonable against the information it holds. The self-certification must be signed or positively affirmed and dated, and must include tax residence and the TIN for each jurisdiction of residence. For pre-existing users (those with a relationship on 31 December 2025) the deadline is 1 January 2027. HMRC adds a separate duty to tell users, by 31 January 2027, that their details will be reported.

Reported data (DAC8 Article 8ad(3))

A reportable retail payment transaction is a transfer of crypto-assets in payment for goods or services exceeding USD 50,000 or its equivalent (Annex VI Section IV C(3)). HMRC requires providers to collect data on all users but report only users resident in the UK or a CARF participating jurisdiction. UK reports are XML files of up to 250MB using the OECD schema, filed through an HMRC online service; no report is needed for a year with nothing to report.

US Form 1099-DA

The IRS instructions require brokers to report gross proceeds of digital asset sales and, for covered securities (digital assets acquired after 2025 in a custodial account and held there until sale), cost basis. De minimis rules exclude a customer's qualifying stablecoin sales where aggregate gross proceeds are 10,000 US dollars or less a year, specified NFTs at 600 dollars or less, and processor of digital asset payment sales at 600 dollars or less. Brokers request TINs on Form W-9 (or W-8 for foreign persons); TINs may be truncated on payee statements but not on forms filed with the IRS. Notice 2024-57 exempts certain transactions, including staking, lending and wrapping, until further guidance.

Penalties

HMRC's general reporting guidance summarises reporting failures as "up to £300 per user". Treat the regulation level table in the HMRC International Exchange of Information Manual (IEIM8000620) as the detailed source, and expect Member State penalties to vary.

Data protection duties

• Controller status: DAC8 Article 25(3) names reporting crypto-asset service providers as controllers. GDPR then applies in full, including Article 32 security of processing and the Article 33 and 34 breach notification duties. In the UK, UK GDPR and the Data Protection Act 2018 apply; see the UK GDPR and Data Protection Act 2018 Guide.
• Transparency: Article 25(4) requires providers to tell each individual that their data will be collected and transferred before it is reported. HMRC's notification deadline is 31 January 2027.
• Retention: Article 22(3) requires tax authorities to keep information received for no less than five years and no longer than necessary. Provider record keeping periods are set by national law; confirm the period in your jurisdiction (in the UK, the regulation 4 record keeping duty) rather than assuming.
• Purpose limitation: TINs and self-certifications are collected for tax reporting. Reusing them for marketing or unrelated analytics is a separate processing purpose that needs its own lawful basis.

Securing the CARF dataset

The CARF dataset joins verified identity, tax numbers, dates of birth, addresses and a full year of transaction totals for every user. That is ideal material for tax fraud, targeted phishing and physical threats against holders of large balances. The Coinbase insider breach showed how bribed support agents could copy names, addresses, partial Social Security numbers, government ID images and transaction history from internal tools; tax reporting data deserves at least the same protection as KYC data.

Service accounts that run the reporting pipeline, extract data from the trading ledger and upload to the tax authority are non-human identities with access to the whole dataset. Give each one an owner, a narrow scope and short lived credentials. See the Crypto Exchange Identity and Key Security Guide.

Implementation: a phased programme

1. Confirm scope and nexus for each legal entity: which jurisdictions it reports in under CARF or DAC8, and whether US Form 1099-DA rules also apply.
2. Register and plan notifications. In the UK, register with HMRC and notify users by 31 January 2027; check each Member State's registration process.
3. Build self-certification into onboarding for new users, with reasonableness checks against KYC data, and run a campaign for pre-existing users before 1 January 2027.
4. Design the data store with a data protection impact assessment, access controls, encryption and a retention schedule before collecting data at scale.
5. Build the reporting pipeline against the OECD XML schema, with aggregation by crypto-asset type, fiat conversion at transaction time and validation before submission.
6. Test with a dry run on 2026 data well before the deadline, reconcile totals with the trading ledger, and fix gaps in TINs or residence data.
7. Submit, keep receipts and handle corrections. Have a documented route for corrected reports and for users who dispute their data.

Rollback: if a pipeline release produces wrong aggregates, keep the previous validated version and its output so a corrected report can be regenerated rather than rebuilt by hand.

Decision guidance

• Single jurisdiction, small provider: a vendor reporting tool may be cheaper than building one, but you remain the controller; check where the vendor stores TINs and who at the vendor can see them.
• Multi-jurisdiction group: a central tax data platform with jurisdiction specific outputs avoids collecting the same self-certification several times, but concentrates risk, so its access controls must be the strongest in the group.
• Collect all, report some: HMRC requires collecting data on all users. Store residence and TIN once with clear tagging so only reportable users are included in each file.

Detection and measurement

• Self-certification coverage: share of active users with a valid self-certification, tracked weekly up to 1 January 2027 for pre-existing users.
• TIN completeness and validity: share of reportable users with a TIN in a valid format for their jurisdiction.
• Reconciliation variance: difference between reported aggregates and the trading ledger.
• Access to the tax dataset: number of people and service accounts with access, and alerts on bulk reads.
• Submission timeliness: days before deadline each report is accepted.

Common failure patterns

• Treating it as a tax team project only. The dataset is collected in onboarding, built from the trading ledger and protected by security; all three need owners.
• Reusing KYC tools without access limits. Support agents with KYC access can then see TINs, which is the exposure pattern in the Coinbase case.
• Missing the pre-existing user deadline. Users onboarded before 2026 without a self-certification create per user penalty exposure.
• Report files left on laptops and shared drives. XML exports contain the whole dataset in one file.
• Assuming CARF covers US obligations. Form 1099-DA has different scope, thresholds and basis rules.
• Keeping data forever. Retain for the legal period, then delete.

Framework mapping

Practitioner checklist

• Map each entity to CARF, DAC8, UK and US obligations and record the legal basis and dates.
• Register with HMRC and notify UK users by 31 January 2027, and confirm Member State processes.
• Collect and check self-certifications at onboarding and for all pre-existing users before 1 January 2027.
• Run a DPIA and treat the tax dataset as high risk personal data.
• Restrict TIN and self-certification access to the tax team; mask TINs in support tools.
• Encrypt report files, submit only through official channels and delete working copies.
• Give reporting service accounts owners, narrow scopes and managed, rotated credentials.
• Reconcile reported totals with the ledger before every submission.
• Set a retention schedule matching national record keeping rules.

Standards and references

• EUR-Lex: Council Directive (EU) 2023/2226 (DAC8)
• OECD: International Standards for Automatic Exchange of Information in Tax Matters (CARF and amended CRS)
• legislation.gov.uk: The Reporting Cryptoasset Service Providers (Due Diligence and Reporting Requirements) Regulations 2025
• HMRC: Check if you'll need to report cryptoasset data to HMRC
• HMRC: Reporting cryptoasset user and transaction data
• HMRC: International Exchange of Information Manual, CARF penalties overview
• IRS: Instructions for Form 1099-DA
• IRS: About Form 1099-DA

Related NHI Mgmt Group resources: MiCA and DORA for Crypto-Asset Service Providers Guide · Crypto Travel Rule Compliance Guide · Crypto Exchange Identity and Key Security Guide · GDPR Compliance Guide for Security Teams. This guide summarises CARF, DAC8, the UK CARF regulations and US Form 1099-DA reporting as published on 2 November 2026 and is not legal advice or tax advice.