The Crypto-Asset Reporting Framework is the OECD’s answer to the question banks answered fifteen years ago: who tells the tax authority what a customer did. DAC8 is the European Union’s implementation of the same thing. Both landed on crypto platforms with a two-stage timetable, and the first stage has already started — which is why searches for a CARF compliance readiness assessment spiked this year rather than next.
This is a vendor-neutral framework you can run against your own operation. It is not legal or tax advice, and it does not substitute for counsel in each jurisdiction where you have reporting obligations.
The two dates that define the problem
The trap in CARF is that the obligations arrive before the filings do.
- January 1, 2026 — onboarding rules apply. From this point a Reporting Crypto-Asset Service Provider must collect valid tax-residency self-certifications from new customers, and must remediate the existing book too. Every day of onboarding without a compliant self-certification adds to a backlog you will have to fix retroactively.
- January 2027 — first filings. Reporting on 2026 activity begins, with the earliest filing deadlines from around January 20, 2027 depending on jurisdiction.
The practical consequence: the 2026 data you are collecting right now is the data you will file. A platform that starts its readiness work in mid-2026 is not preparing for a future obligation — it is auditing a period that is already in scope.
Are you actually in scope?
Scope determination is the step teams most often skip, and getting it wrong in either direction is expensive. The framework targets Reporting Crypto-Asset Service Providers: broadly, businesses that effect exchange transactions in relevant crypto-assets for or on behalf of customers. That language reaches further than “centralised exchange.” Brokers, certain wallet providers with transactional functions, payment processors handling crypto legs, and some staking or trading intermediaries can fall inside it. Non-custodial software with no ability to effect transactions on a customer’s behalf generally sits outside — but “generally” is doing a lot of work in that sentence, and the analysis is jurisdiction-specific.
Two scope questions to settle in writing before anything else: which legal entities in the group are RCASPs, and in which jurisdictions each is required to report. More than 75 jurisdictions have committed to CARF, and they do not all commence on the same schedule.
The ten-point readiness assessment
Score each item honestly as done, partial, or absent. Anything at partial in the data section is functionally absent — CARF filings fail on field completeness, not on good intentions.
- Scope and entity mapping. A documented determination of which entities are RCASPs, where they report, and who signs off. Dated, and revisited when you launch a product or a market.
- Self-certification capture. A live onboarding flow that collects tax residency and taxpayer identification numbers, with the reasonableness checks the framework expects. Not a free-text box.
- Legacy remediation. A plan with a completion date for the pre-2026 customer base, including what you do with accounts that never respond. Decide the treatment of non-responders now, not in December.
- Customer classification. Individuals versus entities, and for entities, the controlling-person analysis. This is where KYC data models built for anti-money-laundering purposes usually turn out to be insufficient rather than wrong.
- Transaction data completeness. Can you produce, per customer per year, the reportable categories — crypto-to-fiat, crypto-to-crypto, transfers including retail payment transactions — with gross amounts, units, and fair-market values at the right moment? Test it on real 2026 data before you trust the answer.
- Valuation methodology. A documented, consistent source and timing convention for pricing. Different pricing sources for the same transaction produce different reportable amounts, and inconsistency is what an examiner notices.
- Jurisdictional routing. Logic that sends each customer’s record to the right authority, handles multiple residencies, and copes with a customer moving mid-year.
- Filing mechanics. Schema validation, transmission channel per jurisdiction, error handling and resubmission. Each authority has its own portal, and each portal has its own opinion about your file.
- Audit trail and retention. Evidence of what you collected, when, and what you did about failures — retained for the statutory period, retrievable per customer.
- Governance. A named owner, a reporting line to the board, and a control that would actually catch a missed filing. If the answer to “who owns CARF” is “tax and engineering,” nobody owns it.
Build, buy, or both
Most platforms end up buying the reporting layer, because the schema work multiplies with every jurisdiction while adding nothing a customer can see. Taxbit is one of the vendors that markets CARF and DAC8 automation for RCASPs, alongside a public CARF implementation tracker; several tax-reporting and regtech providers offer comparable products. We have no commercial relationship with any of them and are not recommending one.
What matters more than the vendor shortlist is the interrogation. Five questions worth asking any provider, including the incumbent you already use:
- Which specific jurisdictions are supported today, in production, with a customer filing through them — not on a roadmap?
- Where does the boundary sit? Vendors typically own schema and transmission; you almost always still own self-certification capture, classification, and valuation. Get that line in writing.
- What happens on a rejected filing — who diagnoses it, and inside what response time?
- How is customer data segregated, where does it reside, and what does the exit look like if you leave?
- What does the implementation actually require from your engineering team, in weeks?
A vendor cannot fix missing data. If your 2026 transaction records lack a field CARF requires, no reporting platform will invent it — the remediation is yours, and it gets more expensive the longer the gap stays open.
Where this connects to the rest of the picture
CARF is a reporting obligation on platforms, not a new tax on users. Its practical effect is that user-side positions get harder to leave undeclared, because the authority now receives the same data the customer does. If you are on the user side of that, our overview of how crypto taxes work and the jurisdiction-specific country guides cover the treatment in the major markets. Platforms operating under MiCA in Europe should note that MiCA authorisation and DAC8 reporting are separate obligations with separate evidence requirements — satisfying one does nothing for the other.
What we did not verify
Commencement dates, TIN requirements and penalty regimes vary by jurisdiction and continue to move as local implementing legislation lands. We have not verified any individual vendor’s jurisdiction coverage, and the checklist above is a structure for your own analysis rather than a legal opinion. Confirm every date against the relevant tax authority or your advisers before you rely on it.
Nothing here is financial advice. We hold no position in any token named on this page. See our risk disclaimer.