The Crypto-Asset Reporting Framework (CARF): The OECD’s New Global Standard for Digital Asset Transparency, and How to Comply From Day 1

Sources last verified: 13 October 2026

Official sources cited at the end of this page.

Our regulatory compliance engine clears every new exchange user for CARF on Day 1. It collects and checks each wallet holder’s self-certification, runs the TIN and reasonableness checks, resolves indicia automatically instead of by your team, classifies every transaction, and prepares the validated CARF XML report, with zero remediation, as section 10 shows.

Since 1 January 2026, crypto-asset businesses that carry out exchange transactions for customers in the European Union, whether MiCA-authorised or required to register as crypto-asset operators, and providers of cryptoasset services in the United Kingdom, have had to establish where each new user is resident for tax. That is the Crypto-Asset Reporting Framework, CARF: the OECD’s global standard under which Reporting Crypto-Asset Service Providers collect a tax self-certification from every user and, each year, report aggregated transaction data on users resident in a reportable jurisdiction, for exchange with that jurisdiction. In the EU it arrives through DAC8, alongside the amended Common Reporting Standard, CRS 2.0.

The obligation starts at the sign-up screen, not at the report. A user who opens an account in March 2026 needs a valid self-certification when the relationship is established: name, residence address, every jurisdiction of tax residence, a TIN for each reportable jurisdiction unless it issues none or its law does not require one, and date of birth, tested for reasonableness against what the provider already holds from KYC. An account that trades for nine months without one is a due diligence failure that began in March.

The cost is counted per user. In the United Kingdom, failing to obtain a valid self-certification carries a penalty of up to £300 for each reportable user, and an inaccuracy or omission in a report, where deliberate, careless or not reported to HMRC once discovered, up to £100 for each user it concerns, so the exposure grows with the platform.

There are two ways to meet CARF. The first treats it as a year-end reporting exercise: rely on what KYC collected, then chase missing tax residences and TINs before the filing date. The second treats it as an onboarding control: the self-certification is completed, tested and cured inside the sign-up flow, and every transaction is classified as it happens, so the report is built from data that was clean on Day 1. Both are set out below, with the rules each must meet. One depends on users answering emails after they have started trading. The other asks once, at the only moment they are certain to answer.

The G20 welcomed CARF at its Bali summit on 15 and 16 November 2022. The OECD first published the rules and Commentary in 2022, and published them with the multilateral agreement in a consolidated text on 8 June 2023. As at 14 September 2026, the OECD lists 77 jurisdictions committed to first exchanges by 2027, 2028 or 2029.

01 · CARF at a glance

02 · CARF Meets CRS 2.0: What Crypto Professionals Need to Know

CARF and the amended Common Reporting Standard were built as one package, consolidated in the OECD’s text of 8 June 2023, and the division of labour between them matters to anyone running a crypto business. CARF covers transactions in crypto-assets that a service provider carries out for its customers. CRS 2.0 compliance obligations expand to what sits with financial institutions: e-money and central bank digital currencies held for customers, derivatives referencing crypto-assets in custodial accounts, and investment entities that invest in crypto-assets. Those are the changes introduced in common reporting standard digital assets reporting requirements, and our CRS 2.0 compliance software covers that side.

A platform offering both crypto trading and fiat or e-money accounts can be a Reporting Crypto-Asset Service Provider for one product and a Reporting Financial Institution for another, with one customer documented under both. One flow can collect what both regimes need, which is how CRS 2.0 aligns with frameworks like CARF and DAC8 in practice, even though the reports, schemas and deadlines are separate. For financial institutions managing cross-border crypto accounts, the impact of CRS 2.0 is that crypto exposure held indirectly, through derivatives or funds, now sits inside the CRS report. Firms that want to reduce manual effort across CARF and common reporting standard digital assets reporting collect one self-certification and feed both reports from it.

In the EU both arrive through a single directive, DAC8, which applies from 1 January 2026; our DAC8 compliance software covers both tracks for EU providers. The self-certification common to all three is covered in our self-certification article.

03 · Who Must Report and What Gets Reported?

Key reporting entities

The test is a business activity, not a licence. A Reporting Crypto-Asset Service Provider is “any individual or Entity that, as a business, provides a service effectuating Exchange Transactions for or on behalf of customers, including by acting as a counterparty, or as an intermediary, to such Exchange Transactions, or by making available a trading platform”. Custody on its own is not the test: a custodial platform is caught where it effectuates exchange transactions for its customers.

A provider is subject to the rules where it has nexus: where it is tax resident; where it is incorporated and either has legal personality or files tax returns; where it is managed; or where it has a regular place of business. A branch creates nexus for the transactions it carries out. Where a provider has nexus in more than one jurisdiction, a hierarchy in the rules decides where it reports, so that it does not report the same users twice. For global crypto exchanges this is the first design question: which entity reports what, and to whom.

What gets reported

CARF applies to Relevant Crypto-Assets, which is every crypto-asset except three categories: central bank digital currencies, specified electronic money products, and crypto-assets the provider has adequately determined cannot be used for payment or investment. The last is not an automatic carve-out; it needs the provider’s own documented determination.

Three kinds of Relevant Transaction are reportable:

1. Exchanges between crypto-assets and fiat currencies, in both directions.
2. Exchanges between one form of crypto-asset and another, valued at fair market value.
3. Transfers, meaning movements to or from a user’s address or account that the provider cannot determine to be an exchange, other than between accounts it keeps for the same user, including Reportable Retail Payment Transactions: transfers in payment for goods or services above USD 50,000.

The report is not a ledger of trades. For each reportable user, the provider reports, per type of crypto-asset, the aggregate gross amounts, units and number of transactions in each category for the year. Fiat legs are reported in the currency actually paid or received; crypto-to-crypto exchanges and transfers are reported at fair market value in a single fiat currency, valued consistently at the time of each transaction. Transfers to wallet addresses not known to belong to a virtual asset service provider or a financial institution are reported in aggregate too. The addresses themselves are not reported, but the Commentary expects the provider to keep them for at least five years.

Those are the key reporting obligations for firms facilitating digital asset transactions. They also explain why classification is the hard part of CARF: every transaction has to be put in the right category, valued, and attached to the right user before the year ends.

04 · Are you in scope? A five-question check

05 · The Role of TINs in Crypto Tax Transparency

A CARF self-certification is valid only if it is signed or otherwise positively affirmed, dated no later than the day it is received, and contains the user’s first and last name, residence address, every jurisdiction of residence for tax purposes, the TIN for each reportable jurisdiction, and date of birth. The TIN is what lets the receiving tax authority match the report to a taxpayer. Without it, a report on a user can be complete in every other field and still not land.

There are only two exceptions: a TIN need not be reported if the jurisdiction does not issue one, or if its domestic law does not require it to be collected. The self-certification must be reasonable against the information the provider holds, including its AML/KYC documentation, and after a change of circumstances the original can no longer be relied on until the provider obtains a valid new one, or a reasonable explanation and documentation confirming the original.

This is where data accuracy and validation in CARF reporting workflows is won or lost: a TIN typed into a form can be well formed and still wrong. Checking it against the issuing authority at onboarding means the number in the report is the number the authority holds, and a mismatch is resolved while the user is still in the flow.

Checking a number against the issuing authority is the only way to confirm it is live. Our TIN lookup does this in real time against official sources in 130+ countries, with format validation across 210+; entity users can be checked against their business registry.

06 · CARF Compliance Workflow

1. Onboarding. Obtain the self-certification when the relationship is established, and test it against KYC data. For entity users, determine whether the entity is itself reportable and identify its controlling persons.
2. Existing users. Obtain self-certifications from pre-existing users within 12 months of the rules taking effect, under the model rules. DAC8 fixes the EU date for individual users at 1 January 2027; the UK regulations state no separate date, so confirm it with HMRC.
3. Classification. Put every transaction into the right category: crypto-to-fiat, crypto-to-crypto, transfer, retail payment, or transfer to an unhosted wallet.
4. Valuation and aggregation. Value crypto legs at fair market value in one fiat currency, consistently, and aggregate per user and per asset type.
5. Reporting. Report by the date your jurisdiction sets; the model rules leave it blank, and the UK has chosen 31 May.
6. Retention. Keep all documentation and data, including external wallet addresses, for the period your jurisdiction sets: in the UK at least five years from the end of the calendar year the records relate to; in EU Member States between five and ten years.

The infrastructure needed for enterprise crypto tax reporting aligned with CARF follows from that list: a tax profile for every user, a classification engine that runs on every transaction, a valuation source applied consistently, and a reporting layer that produces each jurisdiction’s file. Systems that hold these in separate tools usually reconcile them by hand at year-end.

The CARF XML Schema

Reports travel between tax authorities in the OECD’s CARF XML format. The first CARF XML Schema and User Guide were published on 2 October 2024; the current version is v1.5, with its User Guide published on 30 July 2025 after approval by the Committee on Fiscal Affairs on 28 July 2025. A separate status message schema, published in June 2025, carries the receiving authority’s feedback on a file.

Jurisdictions decide how providers file domestically, so the schema a provider writes may be the OECD format or a national variant. How firms should structure systems to support CARF XML reporting requirements comes down to keeping the data model independent of the file: one record per user and per transaction, from which each jurisdiction’s file is generated and validated against its schema before it is sent.

07 · Jurisdictional Rollout and the Role of Each Jurisdiction in CARF

Operational timeline

The OECD’s commitments list, last updated 14 September 2026, groups 77 jurisdictions by the year of their first exchanges. Forty-six are committed to exchange by 2027, among them every EU Member State except Cyprus, the United Kingdom, Brazil, Japan, Korea, South Africa and the Cayman Islands. Twenty-seven are committed by 2028, including Australia, Canada, Cyprus, Hong Kong (China), Singapore, Switzerland and the United Arab Emirates. Four are committed by 2029: Argentina, Azerbaijan, Mexico and the United States. India and Viet Nam are among four jurisdictions listed as not yet committed; India is described as in the process of committing.

Outside the EU, the main legal basis for exchange is the CARF multilateral competent authority agreement, which had 56 signatories as at 3 March 2026. The United States, Australia and Hong Kong (China) had not signed by that date. Between EU Member States, DAC8 itself is the basis.

Implications for multi-jurisdictional providers

Firms that manage multi-jurisdiction crypto tax reporting under CARF frameworks face difference at the edges. The core rules are common; filing dates, domestic formats, penalty regimes, enforcement measures and start dates are not. A provider has to decide where each entity reports under the nexus hierarchy and which national rules govern each file. To support multi-jurisdiction tax reporting for digital assets globally, the user’s tax profile has to be held once and read by every entity’s report.

08 · Penalties and Enforcement

CARF leaves enforcement to each jurisdiction, but its Commentary says jurisdictions “should also have in place strong measures to ensure valid self-certifications are always collected”, and “an effective way to achieve this outcome would be to introduce legislation making the effectuating of transactions conditional upon the receipt of a valid self-certification”. Significant penalties on users or providers are named as an alternative. So CARF does not require blocking, and it is not silent about it either.

The UK chose penalties. Under the Reporting Cryptoasset Service Providers (Due Diligence and Reporting Requirements) Regulations 2025, a provider that fails to obtain a valid self-certification is liable to up to £300 for each reportable user or person; a user who fails to provide one, deliberately or carelessly, to up to £300; an inaccurate or incomplete report, where deliberate, careless or not reported to HMRC once discovered, to up to £100 per user concerned; and a late report to up to £5,000, plus up to £600 for each day the failure continues after notice. HMRC’s guidance summarises the position as a penalty of up to £300 per user.

The EU chose blocking. Under DAC8, Annex VI, Section V, where a user does not provide the required information after two reminders following the initial request, “but not prior to the expiration of 60 days”, the provider “shall prevent the Crypto-Asset User from performing Reportable Transactions”. National laws set the details; our DAC8 article covers them.

09 · A Practical Compliance Roadmap for RCASPs

The order of work follows from the rules:

1. Map nexus. List every entity and branch, apply the nexus tests and the hierarchy, and decide which entity reports which users.
2. Classify the assets. Document which assets are Relevant Crypto-Assets and, for any treated as unusable for payment or investment, record the determination.
3. Fix onboarding first. Every new user since 1 January 2026 in the EU and UK needed a self-certification at sign-up. Close that gap before working the back book.
4. Work the existing users. By the date your jurisdiction sets (for EU individual users, 1 January 2027), every pre-existing user needs one too.
5. Build classification and valuation. Category, fair market value and aggregation, on every transaction, consistently.
6. Report and retain. Generate and validate each jurisdiction’s file; keep the evidence and the wallet addresses for the retention period.

What should teams evaluate when selecting CARF compliance software? Coverage of that list, tested rather than demonstrated: real-time reasonableness testing at onboarding, TIN validation against official sources, controlling persons, transaction classification and valuation, back-book remediation, schema-valid files and an evidence record per user. Evaluate any financial technology company on the same terms, and ask whether it is API-first, so it runs inside your own sign-up flow. RegTech for digital assets supports CARF implementation at scale only when it covers all six stages; a tool that covers four leaves the other two to spreadsheets.

10 · Practical Industry Solutions: The Two Ways to Meet CARF

By hand, at year-end

Many providers meet CARF today by extending KYC: a later campaign asks for tax residence and TINs, operations teams chase the gaps, and transaction data is reconciled from the ledger at year-end.

For a small user base it works. Its weakness: tax residence is asked for after the user has started trading, when the reason to answer has gone. KYC confirms who a user is; it does not establish where they are resident for tax, and the gap between the two is exactly what CARF reports.

At onboarding, from Day 1

TaxDo runs CARF due diligence inside onboarding, from the first wallet-holder self-certification to the CARF XML report, on one platform. It works in five steps, in this order, because each one needs the one before it.

Step 1 · Collect the self-certification. Guided and jurisdiction-aware, one question at a time, for individuals and entities, with a digital signature. Where the entity is passive, its controlling persons are collected in the same flow.

Step 2 · Validate the identity. Every TIN is checked in real time against official sources in 130+ countries, and the business against registries in 120+.

Step 3 · Run the due diligence. Indicia are detected across everything held on the user, and the self-certification is tested for reasonableness against it. For CARF that includes classifying every transaction across the three reportable types and classifying each crypto-asset.

Step 4 · Cure the gaps, without the compliance team:

4a · New users. Discrepancies are resolved in the same session, while the user is still onboarding, instead of landing in a queue for your team.

4b · Existing users. The user base is scanned and prioritised, and missing self-certifications, invalid TINs and unresolved discrepancies are remediated.

Step 5 · Report, and keep the evidence. Schema-validated CARF XML for each jurisdiction from one data layer, prepared and validated for you to submit. Our team can also submit it on your behalf on request, as an additional service. Every user keeps an immutable clearance record.

From Day-1 wallet-holder self-certification to transaction reporting, with zero remediation. Every user is cleared when the account opens, so nothing is left for year-end.

Our CARF compliance software · Solutions for crypto exchanges and CASPs

Where this sits, and what it does not touch

Your KYC provider keeps verifying identity, and your exchange or wallet platform keeps running the ledger. KYC answers who the user is. Tax due diligence answers where they are resident for tax, and whether their declaration holds up against what you already know. This runs at onboarding beside KYC, not in place of it.

The reporting obligation, and the responsibility for what is reported, stays with the provider, including where TaxDo submits the report on its behalf at its request. TaxDo runs the due diligence and prepares and validates the report.

The difference is when the gap is found. At sign-up, it is one more question. After the user has traded for a year, it is a campaign of reminders and a report with holes in it.

11 · Market Implications and the Outlook

The direction is set. As at 14 September 2026, seventy-seven jurisdictions are committed, from the 2027 group to the United States in 2029. First exchanges are expected to begin in 2027, and the XML schema has already been revised.

Tax residence becomes part of onboarding everywhere CARF applies, as identity verification did under AML rules. Firms weighing whether to invest in scalable tax reporting infrastructure to future-proof CARF compliance are really deciding whether to build that onboarding step once, for every jurisdiction, or once per jurisdiction as each one goes live. The key requirements for digital asset information reporting in regulated environments are the same everywhere: a tested self-certification, a classified transaction history and a file that validates.

12 · Recent Changes and What Comes Next

2 October 2024

First CARF XML Schema and User Guide released.

24 June 2025

UK regulations implementing CARF made, in force from 1 January 2026.

30 July 2025

CARF XML Schema version 1.5 User Guide published.

1 January 2026

Collection begins in the EU and the UK; EU providers must obtain self-certifications from pre-existing individual users by 1 January 2027.

14 September 2026

Latest OECD commitments list: 77 jurisdictions committed, 46 by 2027, 27 by 2028, 4 by 2029.

2027

First reports and first exchanges for the 2027 group; UK first reports due by 31 May 2027.

13 · Related Reading

Framework articles: CRS 2.0 compliance for financial institutions · DAC8 compliance · CRS 2.0 and DAC8 self-certification

Product: Regulatory compliance engine · Day 1 onboarding validation · Financial institutions · Fintechs and neo-banks