CARF Compliance Checklist, What Your Exchange Needs to Do (CFO Edition)

Who this is for

This is the version of the CARF compliance plan you can take to a board or audit committee. It assumes you are a CASP, a centralised exchange, broker, or custodial wallet provider, that will be in scope of one or more of CARF, DAC8 or the UK HMRC regime for CY2026 data.

1. Determine if you're in scope

Map every category of user against three nexus tests:

• Establishment: where is the legal entity tax resident?
• Licensing: under which licensing regime (MiCA, FSMA, MAS, etc.)?
• User residence: where do customers actually live?

Most CASPs underestimate user-residence nexus. A Singapore-licensed exchange with even a handful of EU users hits DAC8 scope and must register in one EU member state.

2. Map reporting jurisdictions

Produce a single matrix: rows are jurisdictions where you have users, columns are CARF / DAC8 / HMRC / domestic regimes. Each cell answers "do we have to file, by when, to whom, in what format?" Re-run this matrix every quarter; new jurisdictions adopt CARF on a rolling basis.

3. Collect TINs and self-certifications

For every reportable user, you need:

1. A self-certification of tax residence and jurisdiction.
2. A valid TIN for each jurisdiction of residence.
3. Evidence that you applied the "reasonableness" standard (CARF Section II.B(2)).

The 60-day rule is the operational hot spot: a user with an incomplete self-certification at account opening must be reminded, reminded again, and ultimately prevented from transacting if they don't respond within 60 days. Build the kill switch into your KYC pipeline now, retrofitting it under audit pressure is expensive.

4. Classify transactions correctly

CARF distinguishes transfer types using a code system: CARF501 to 509 cover exchange-style transactions (crypto-to-crypto, crypto-to-fiat, fiat-to-crypto), CARF601 to 606 cover retail payment transactions, and so on. Mis-classification doesn't fail XSD validation, it produces a technically valid but semantically wrong report.

Specific edge cases that consistently catch new implementers: the $50,000 retail-payment threshold (CARF Section II.A.2(c)), the SEMP stablecoin issuer reclassification mid-period, and the cold-wallet vs CASP-destination determination for outbound transfers.

5. Aggregate and generate XML

Aggregation is the heart of CARF. Per user, per crypto-asset, per transfer-type code, per reporting year, you produce a single set of figures: number of transactions, gross units, gross fair-market value. Build aggregation as a separate, testable step from transaction capture and XML serialisation, the three are otherwise easy to entangle.

6. Validate against the XSD

XSD validation is the cheapest place to catch errors. Validate every generated file before submission. Where the tax authority offers a test channel (HMRC, IRD), use it for a full dry run with CY2025 reference data before the live filing.

7. Submit to each tax authority

Each jurisdiction has a different submission channel: HMRC's portal, the EU member state's CRS infrastructure (varies by state), IRD's myIR. Some require registration weeks in advance; check now.

8. Retain evidence for ten years

DAC8 Article 8a(6) requires ten-year retention of all evidence: self-certifications, TIN validation results, generated XML files, validation logs, and submission receipts. Store these immutably and timestamped. An audit five years from now will not be kind to a CASP that overwrote its 2026 self-certifications.

What to do, by quarter

Further reading

• OECD CARF FAQs (December 2025)
• Council Directive (EU) 2023/2226 (DAC8), Article 8a(6) on retention