CARF and DAC8 Crypto Reporting Compliance 2026

From 1 January 2026, crypto-asset service providers operating in the United Kingdom and European Union are required to collect standardised tax identification data from every user and report it to their respective tax authority. This obligation stems from two parallel frameworks: the OECD's Crypto-Asset Reporting Framework (CARF), adopted in the UK by HMRC, and DAC8, the EU Council directive that transposes CARF into EU law. Platforms that fail to comply face account-blocking obligations, financial penalties, and regulatory scrutiny from financial crime authorities.

This article is for informational purposes only and does not constitute legal, financial, or regulatory advice. Regulatory references are accurate as of the publication date. Consult a qualified professional for guidance specific to your situation.

What Is CARF and Why It Applies to Crypto Businesses

CARF — the Crypto-Asset Reporting Framework — is an OECD standard adopted in 2022 that requires crypto-asset service providers to collect, verify, and annually report tax identification data for their users to national tax authorities, enabling automatic cross-border exchange of that information. It applies to any business that facilitates exchanges, transfers, or custody of crypto-assets on behalf of customers.

The OECD developed CARF in response to a structural gap in the Common Reporting Standard (CRS): CRS requires banks and financial institutions to report account data, but crypto-asset holdings held outside traditional finance were invisible to tax authorities. CARF closes that gap by treating reportable crypto-asset service providers (RCASPs) as the functional equivalent of financial institutions for reporting purposes.

The framework covers all crypto-assets that can be transferred and exchanged peer-to-peer without reliance on a central intermediary — including exchange tokens such as Bitcoin and Ether, stablecoins, and most utility tokens. Non-fungible tokens (NFTs) and central bank digital currencies (CBDCs) are generally excluded, although HMRC and EU member states retain discretion to extend scope.

UK implementation: HMRC adopted CARF through the Cryptoasset Reporting Framework regulations laid before Parliament, separate from DAC8 which is an EU-only instrument. Full details are published at gov.uk.

For a broader overview of document compliance obligations in financial services, see our document compliance guide.

DAC8 vs UK CARF: Key Differences for UK-Based Platforms

DAC8 (Council Directive 2023/2226) is the EU legislative instrument that transposes CARF into EU law, amending the Directive on Administrative Cooperation (DAC) to require member states to exchange crypto-asset reporting data with each other and with third countries. The UK is not subject to DAC8 but has implemented an equivalent framework independently through HMRC. Source: EUR-Lex, Directive 2023/2226.

For UK-based crypto businesses, the practical effect is nearly identical to DAC8. The data fields required, the due diligence procedures, and the "kill switch" provisions are harmonised with the OECD standard. The primary difference is the reporting destination: UK platforms report to HMRC, not to an EU national tax authority, and exchange data through OECD multilateral channels rather than the DAC network.

UK platforms that also serve EU-resident customers, or that hold EU operating subsidiaries, will face DAC8 obligations for those activities in addition to their UK CARF obligations. Dual-jurisdiction compliance is not optional — it requires separate data collection, separate reporting streams, and separate governance documentation.

For EU-specific crypto regulatory obligations including MiCA authorisation requirements, see our guide on MiCA crypto identity verification 2026.

Which Businesses Must Report Under CARF

Any entity that, as a business, provides services enabling customers to exchange, transfer, or store crypto-assets — including exchanges, custodial wallet providers, brokers, and certain decentralised finance platforms — is a Reporting Crypto-Asset Service Provider (RCASP) under CARF and must comply with its due diligence and reporting obligations from 1 January 2026.

The following categories are within scope:

• Centralised exchanges: platforms that match buy and sell orders between users, hold custody of assets during transactions, and convert between crypto-assets or between crypto-assets and fiat currencies.
• Custodial wallet providers: businesses that hold private keys on behalf of customers, whether or not they provide exchange functionality.
• Crypto brokers: entities that execute trades on behalf of customers, including over-the-counter desks.
• Payment processors: businesses that accept crypto-assets in payment for goods or services and convert them to fiat on the merchant's behalf.
• Certain DeFi platforms: if the platform's operators retain control over the protocol, set fees, can modify smart contracts, or otherwise meet the effective control test, they may be in scope even if the platform is nominally decentralised.

The FCA cryptoasset register lists UK-registered firms: https://register.fca.org.uk. Registration with the FCA for anti-money laundering purposes does not discharge CARF reporting obligations — these are separate and administered by HMRC.

Out-of-scope activities include peer-to-peer transfers between individuals without a service provider intermediary, hardware wallet sales, and purely informational services such as price data aggregators.

KYC Data Requirements Under CARF Reporting Rules

CARF requires RCASPs to collect and verify a mandatory set of personal and tax identification data for every individual and entity customer — and to apply a "kill switch" that blocks exchange transactions if a customer refuses to provide their Tax Identification Number after two documented requests.

For individual customers, the required data fields are:

• Full legal name (as it appears on government-issued identity document)
• Residential address
• Date of birth
• Country or countries of tax residence
• Tax Identification Number (TIN) for each country of tax residence — in the UK, the National Insurance (NI) number or Unique Taxpayer Reference (UTR)
• Place of birth (required in some jurisdictions)

For corporate and entity customers, additional fields apply:

• Registered legal name
• Registered address
• Jurisdiction of incorporation or organisation
• Entity TIN (UK: Corporation Tax UTR or VAT registration number)
• Identification of controlling persons (beneficial owners) and their individual data as above

The kill switch obligation is among the most operationally significant provisions. If a customer fails to provide their TIN after two formal requests — documented with timestamps and delivery confirmation — the platform must suspend the customer's ability to execute exchange transactions. The platform is not required to close the account or seize assets, but it cannot permit further taxable transactions until the TIN is provided. This places a direct operational dependency on KYC data collection workflows: incomplete TIN capture translates to frozen accounts and potential revenue loss.

Platforms must retain all collected data for a minimum of five years from the end of the reporting period to which it relates.

CheckFile's KYC verification platform automates document-level TIN extraction and cross-references identity documents across 32 jurisdictions, reducing the manual effort required to satisfy CARF data quality standards.

Reporting Timeline and Deadlines

Data collection obligations under CARF and DAC8 commence on 1 January 2026. EU member states must receive their first CARF-format reports from RCASPs by 31 May 2027, with the first inter-authority exchange of data occurring by 30 September 2027. UK deadlines are aligned to the OECD schedule and will be confirmed by HMRC.

Platforms should not treat the 2027 reporting deadline as the trigger for compliance preparation. CARF requires data to be collected and verified at the point of onboarding and at the point of any qualifying transaction. A platform that begins collecting TIN data in late 2026 will face a retroactive compliance gap for all transactions executed earlier in the year — and HMRC and EU tax authorities have confirmed they will not accept retroactive collection as equivalent to contemporaneous verification.

The practical implication is that platforms must have compliant KYC workflows in production before 1 January 2026. For platforms still relying on manual document review processes, that window has closed.

For an overview of wider AML compliance obligations applicable to UK crypto firms, including anti-money laundering red flags and due diligence requirements, see our AMLD6 compliance guide for obliged entities.

Penalties for Non-Compliance

EU member states are required under DAC8 to impose effective, proportionate, and dissuasive penalties on RCASPs that fail to comply with reporting, due diligence, or record-keeping obligations. Specific penalty amounts are set at the national level. HMRC has separately confirmed it will use its existing information power and penalty regime to enforce UK CARF obligations.

In practice, the enforcement risk for non-compliant crypto platforms includes:

• Fixed administrative penalties: charged per reportable account or per reporting period with a missed or materially inaccurate report.
• Daily accruing penalties: applied where non-compliance continues after formal notice from the tax authority.
• Inaccuracy penalties: where reported data is incorrect due to inadequate due diligence, penalties may be charged as a percentage of the under-reported amount.
• Regulatory referral: HMRC and EU national tax authorities may refer persistent non-compliance to the FCA or equivalent national competent authority, triggering a parallel regulatory investigation that can result in registration suspension or revocation.
• Criminal liability: in cases of deliberate falsification, reporting officers may face personal criminal liability under the Fraud Act 2006 (UK) or equivalent EU member state provisions.

The FCA's supervisory approach to cryptoasset firms — documented in its annual financial crime guidance — treats tax transparency failures as an indicator of broader control weaknesses, which can trigger enhanced supervisory engagement independently of the HMRC penalty process.

Platforms should ensure their CARF compliance programmes are documented, independently reviewable, and capable of producing audit trails that demonstrate both the due diligence process and the basis for any reporting determination. CheckFile's audit-ready verification logs provide a tamper-evident chain of evidence that satisfies this requirement.

Automating KYC Document Verification for CARF Compliance

The data quality requirements under CARF — verified TIN, confirmed country of residence, authenticated identity documents — cannot be satisfied by self-certification alone. Platforms need automated document verification that extracts TIN data from source documents, cross-checks it against the declared information, and flags inconsistencies before the account reaches reportable status.

Manual KYC review at the volume typical of crypto platforms — hundreds or thousands of onboardings per day — creates unacceptable error rates. A mistyped National Insurance number, a missing date of birth, or an address that does not match the identity document can render a reportable account's data unusable for the exchange, generating a reportable defect and triggering a remediation obligation.

The most effective approach is a layered verification workflow:

1. Document capture and OCR extraction: the customer uploads a government-issued identity document; the system extracts name, address, date of birth, and document number automatically.
2. TIN collection and format validation: the customer provides their TIN (NI number, UTR, or foreign equivalent); the system validates format against the known structure for the declared jurisdiction.
3. Cross-field consistency check: extracted document data is compared against the self-declared residency and TIN; discrepancies trigger a review queue rather than silent acceptance.
4. Liveness and authenticity checks: document authenticity verification prevents fraudulent self-certification, which would expose the platform to both CARF reporting failures and separate AML liability.
5. Audit trail generation: every verification step is logged with timestamp and outcome, creating the record required for HMRC or tax authority inspection.

CheckFile automates each of these steps through a single API integration, with support for identity documents from 32 jurisdictions and real-time validation of TIN formats for over 60 countries. Platforms can review pricing and volume tiers to assess the cost relative to manual review headcount.

CheckFile's automated KYC document verification pipeline supports TIN extraction and cross-border identity validation across 32 jurisdictions, directly addressing the data quality requirements imposed by CARF reporting obligations.

Frequently Asked Questions

Does CARF apply to DeFi platforms and decentralised exchanges?

It depends on the degree of operator control. CARF applies to any entity that, as a business, provides exchange or transfer services for crypto-assets. Purely automated protocols with no identifiable operator who earns fees or controls the smart contract logic are outside scope. However, most platforms described as "DeFi" retain some operator control — governance rights, fee switches, upgrade keys — and HMRC and the EU Commission have both confirmed they will apply a substance-over-form analysis. Platforms that believe they are out of scope should obtain a documented legal opinion before 1 January 2026, not after the first reporting period.

What happens if a user refuses to provide their National Insurance number?

Under CARF, the platform must make at least two documented requests. If the user still does not provide the NI number, the platform is required to block that user from executing further exchange transactions — the "kill switch" obligation. The platform must retain a record of the requests and the user's failure to respond. The account need not be closed, but no taxable transactions can be processed until the TIN is supplied and verified.

Are NFTs in scope for CARF reporting?

Most NFTs are currently out of scope under the OECD CARF standard. The exclusion applies to NFTs that are not fungible — i.e., that are not interchangeable with other tokens on a like-for-like basis. However, if an NFT is used as a speculative investment and traded on a secondary market at scale, HMRC or an EU tax authority may treat it as within scope depending on the specific token's characteristics. Platforms that operate NFT marketplaces should seek specific guidance from HMRC or their member state tax authority rather than assuming blanket exclusion.

Do UK crypto firms need to comply with both CARF and DAC8?

UK firms that operate exclusively in the UK and serve only UK-resident customers need to comply with UK CARF (via HMRC) only. DAC8 is an EU directive that binds EU member states and the RCASPs operating within them. A UK firm with an EU subsidiary, or a UK platform that onboards customers resident in EU member states, will need to comply with DAC8 for those EU-nexus activities — either directly or through its EU-regulated entity. The safest course is to build a unified compliance framework aligned to the OECD CARF standard, which satisfies both UK and EU obligations simultaneously.