OECD Crypto-Asset Reporting Framework (CARF): Requirements for Crypto Businesses

On 14 September 2026, Argentina became the 77th jurisdiction to commit to the Crypto-Asset Reporting Framework — with first exchanges due by September 2029, two years after the earliest cohort. That gap is the practical shape of CARF: one international standard, many different start dates.

CARF is the OECD standard for collecting and automatically exchanging tax-relevant information on crypto-asset users and transactions. For a crypto business it reduces to four questions, in this order:

1. Are we a Reporting Crypto-Asset Service Provider (RCASP)?
2. Where do we have a reporting nexus?
3. Which users, assets, and transactions fall into scope?
4. What information must we collect and report?

CARF is an international reporting standard; actual business obligations arise through domestic implementation in jurisdictions where the RCASP has a relevant reporting nexus. Most planning errors come from answering question three before questions one and two.

Quick Facts

• CARF is an OECD international tax-transparency standard, not a tax.
• 77 jurisdictions are formally committed to implementation as of October 2026.
• First exchanges are scheduled across 2027, 2028, and 2029 cohorts.
• Non-custodial business models are not automatically outside CARF.
• The current OECD CARF XML Schema and User Guide was updated in July 2025.

What Is the OECD Crypto-Asset Reporting Framework?

CARF sets common standards for who reports, which users are reportable, how tax residence is established, which crypto-assets and transactions are in scope, what data is reported, and how tax authorities exchange that data automatically.

What CARF does not do matters just as much. It does not calculate tax, determine a taxable gain, or replace domestic tax law. CARF is an OECD international reporting standard; it does not create identical directly enforceable obligations in every committed jurisdiction without domestic implementation.

In practical terms, a CARF readiness project is a set of jurisdiction-specific projects sitting on one data foundation. For the wider architecture question — meeting crypto tax reporting requirements for businesses across several regimes at once — the pillar guide covers the infrastructure side.

How CARF Applies to Crypto Exchanges and Other Crypto Platforms

The RCASP Definition Is Functional

CARF defines an RCASP as an individual or entity that, as a business, provides a service effectuating Exchange Transactions for or on behalf of customers — including acting as counterparty, as intermediary, or as the operator making a trading platform available.

A Reporting Crypto-Asset Service Provider is defined primarily by the service it performs, not simply by whether it has custody of customer assets. Depending on actual activity, that test can capture exchanges, brokers, dealers, certain OTC businesses, crypto ATM operators, trading platforms, and other intermediaries. It does not mean every custodial wallet provider automatically qualifies, or that every exchange already has live obligations.

The sequence matters: definition first, then reporting nexus, then domestic implementation. A business can meet the definition and still have no filing obligation yet in a given jurisdiction.

Non-Custodial and Decentralized Services

Non-custodial crypto services can fall within CARF when the service and operator role meet the RCASP definition. The OECD has addressed providers of non-custodial services, including certain decentralized arrangements, rather than carving them out.

The assessment looks at activity rather than architecture:

• Does the service effectuate Exchange Transactions?
• Is there an operator or intermediary at all?
• Does anyone exercise sufficient control or influence over the arrangement?
• Is this only software, or an actual transaction-facilitating service?

Software-only tools and arrangements with no relevant service-provider role can reach a different outcome. Custody is one fact among several, not the test.

Where Does an RCASP Have to Report? Understanding CARF Nexus

CARF sets out the circumstances in which an RCASP becomes subject to due diligence and reporting obligations in an implementing jurisdiction. At a high level, the potential connections are:

• Tax residence — the RCASP is tax resident in the implementing jurisdiction.
• Incorporation or organisation — a relevant entity connection under that jurisdiction's law, together with the relevant legal or tax conditions.
• Management — the entity is managed from the implementing jurisdiction.
• Regular place of business — a relevant business presence in the jurisdiction.
• Branch — Relevant Transactions are effectuated through a local branch.

This is a high-level summary; the domestic implementation has to be checked in each case. Where more than one nexus exists, CARF applies an order of priority designed to reduce duplicate reporting of the same transactions.

A customer's tax residence helps determine reportability and information exchange, while CARF nexus rules determine where the RCASP itself may have reporting obligations. Customer residence determines reportability; RCASP nexus determines where the provider files.

Which Crypto-Assets and Transactions Are Covered by CARF?

Relevant Crypto-Assets

CARF covers crypto-assets that can be used for payment or investment purposes. Depending on their characteristics, that can include cryptocurrencies, stablecoins, certain tokenized assets, certain NFTs, and certain crypto-asset derivatives — which is not the same as saying all tokens or all NFTs are reportable.

CARF also sets out exclusions, among them Central Bank Digital Currencies, Specified Electronic Money Products, and assets adequately determined not to be usable for payment or investment purposes. Asset mapping is a per-asset exercise, not a category label.

Relevant Transactions

Relevant Transactions fall into four groups: exchanges between a Relevant Crypto-Asset and fiat currency, exchanges between Relevant Crypto-Assets, Transfers, and Reportable Retail Payment Transactions.

The last category is where the USD 50,000 figure belongs: crypto payments for goods or services above that value, where the reporting focus shifts to the retail customer. The USD 50,000 threshold for Reportable Retail Payment Transactions does not create a general exemption for smaller crypto transfers under CARF. A transfer below it can still be reportable in another category.

CARF Due Diligence: Tax Residence, Self-Certification, and Controlling Persons

CARF due diligence is tax due diligence. It overlaps with AML onboarding but answers a different question: not who the customer is, but which jurisdictions may tax them.

Individual Crypto-Asset Users

CARF establishes tax-residence information through self-certification from the user. Depending on the applicable rules and data fields, that covers the jurisdiction or jurisdictions of tax residence, taxpayer identification numbers where required, identifying information, and date of birth.

A self-certification is not simply filed. It has to pass a reasonableness check against the other information the RCASP holds, so onboarding data that contradicts the declared residence is a problem to resolve rather than a record to store. For pre-existing users, remediation runs from the domestic effective date rather than a single global deadline.

Entity Users and Controlling Persons

For an entity user, the RCASP needs the entity's identity, its tax residence, its relevant status under the rules, and — where required — its controlling persons and their own reportability and tax residence.

AML/KYC information can support CARF due diligence, but AML onboarding does not replace tax-residence self-certification. Beneficial ownership data gathered for AML purposes identifies people; it does not establish tax residence, and the two definitions of "controlling" do not always produce the same list. Existing beneficial ownership and KYB verification work is an input to the entity file, not a substitute for it.

Change of Circumstances

Where a change of circumstances makes an existing self-certification unreliable or incorrect, the RCASP cannot keep relying on the old record. Common triggers are an address change, a change of tax residence, entity restructuring, a new controlling person, or information that no longer reconciles.

This is where tax and AML processes diverge most clearly — an AML refresh cycle and a CARF change-of-circumstances review are not triggered by the same events. See how crypto KYC requirements differ from tax-reporting due diligence.

What Information Is Reported Under CARF?

User and Entity Information

The user side covers name, address, jurisdiction of tax residence, taxpayer identification number where applicable, date of birth for individuals, and the relevant entity and controlling-person data. Fields such as place of birth depend on local implementation rather than applying universally.

Transaction Information

This is where CARF is most often misread. CARF reporting is structured around reportable-user and asset/category information rather than simply transmitting a raw blockchain transaction ledger.

Reporting is built on annual figures per user, per Relevant Crypto-Asset, and per transaction category — aggregate gross amounts, number of units, and the number of Relevant Transactions where required. The categories tracked separately are acquisitions and disposals against fiat, acquisitions and disposals against other Relevant Crypto-Assets, Transfers, and Reportable Retail Payment Transactions. Submitting every TxID and timestamp is not a universal requirement.

What Operational Controls Support CARF Reporting?

CARF reporting requires an RCASP to maintain reliable links between reportable users, tax-residence information, Relevant Crypto-Assets, transaction categories, and annual reporting data. Four controls carry most of that weight.

Data Mapping

The business has to be able to join a user to their tax residence, entity status, and controlling persons, and join each transaction to a Relevant Crypto-Asset, a CARF transaction category, and the annual aggregate it rolls into. If any of those joins is manual, the reporting period becomes a reconciliation project.

Data Validation

Validation looks for missing self-certifications, inconsistent tax residence, missing or invalid TINs where required, duplicate user records, misclassified transactions, unmapped assets, and unresolved change-of-circumstances flags — before the aggregation step, not after.

Audit Trail

The file needs to show when each self-certification was obtained, which version was used for a given reporting period, what changed and when, how reportability was determined, what aggregation logic was applied, and the history of prior periods. A figure nobody can reproduce is a figure that cannot be defended.

Reporting Output

The data has to be exportable in the format the local implementation requires. Automation can support CARF data collection, validation, aggregation, and audit trails, but it does not determine RCASP status or reporting nexus. Those remain legal determinations.

For businesses running this across several regimes and high volumes, our pillar guide covers how to build scalable crypto tax-reporting infrastructure across multiple regimes.

CARF XML Schema and Reporting Data Format

The current OECD technical resource is the Crypto-Asset Reporting Framework XML Schema and User Guide, updated in July 2025 as a technical update to the version approved in 2024.

The OECD states that while the schema was primarily designed to facilitate exchanges of CARF information between tax administrations, it can also be used for domestic reporting by RCASPs where local law permits. It standardises how identities, RCASP data, Crypto-Asset Users, Controlling Persons, Relevant Transactions, and reporting periods are represented — which matters because it fixes the shape your internal data has to produce.

How CARF Information Is Exchanged Between Tax Authorities

The path in outline: the RCASP reports to its domestic tax authority, and that authority exchanges the relevant information with partner jurisdictions.

What is not automatic is the exchange itself. It depends on domestic implementation, local reporting rules, activated exchange relationships, and which jurisdictions are reportable in that relationship — so no committed jurisdiction exchanges data with every other committed jurisdiction by default. The CARF Multilateral Competent Authority Agreement and other bilateral or multilateral arrangements provide the legal mechanism.

CARF Implementation Timeline: 2027, 2028, and 2029

CARF moves through five distinct stages, and conflating them is the most common source of wrong deadlines:

• Commitment — the jurisdiction commits internationally to implement CARF.
• Domestic implementation — CARF rules become part of local law.
• Data collection — RCASPs begin collecting and remediating the required data.
• Domestic reporting — the RCASP files under the local deadline.
• International exchange — the tax authority exchanges information with partners.

As of October 2026, 77 jurisdictions are formally committed to CARF implementation, with first exchanges scheduled across 2027, 2028, and 2029. Implementation is jurisdiction-specific: some jurisdictions are already running their first data-collection year while others begin later. For the country-level picture, see CARF implementation timelines across key jurisdictions.

How CARF Relates to DAC8 and Other Crypto Tax Reporting Regimes

CARF vs DAC8

DAC8 is an EU legal crypto tax-reporting regime closely aligned with CARF but with its own scope, registration, due-diligence, reporting, enforcement, and exchange rules. Treating it as "CARF in Europe" is where EU-specific obligations get missed. The registration mechanics, Member State filing, and enforcement detail sit in our guide to EU DAC8 crypto tax reporting requirements.

Practical Consistency Across CARF and DAC8

A business operating under both can run one underlying data model for identity, tax residence, TIN, entity classification, controlling persons, assets, and transactions. CARF and DAC8 can share underlying data architecture, but their legal scope, filing, registration, and enforcement requirements must still be mapped separately. The data layer converges; the reporting logic does not.

CARF vs Other National Regimes

Some jurisdictions run their own crypto reporting rules alongside or instead of CARF-aligned regimes, with separate forms, thresholds, and timing. See how crypto tax reporting differs across jurisdictions.

What Crypto Businesses Need to Do for CARF Readiness

1. Determine whether the business meets the RCASP definition, based on the services it actually performs.
2. Map reporting nexus to the relevant implementing jurisdictions.
3. Collect valid tax-residence self-certifications and remediate existing users where required.
4. Map transactions and assets to CARF reporting categories.
5. Validate, aggregate, and preserve the data needed for domestic reporting.

Businesses running this at volume or across multiple entities will need enterprise crypto tax-reporting infrastructure rather than a per-jurisdiction workaround.

Conclusion

CARF is not a single global filing deadline. It is a common international reporting standard implemented through domestic law and cross-border exchange relationships, and commitment to CARF and an active domestic reporting obligation are not the same thing.

The working sequence for a crypto business is: RCASP status → nexus → tax-residence due diligence → Relevant Crypto-Assets → Relevant Transactions → reporting data → domestic filing → international exchange. AMLBot is not CARF filing software and does not determine tax residence or produce CARF submissions; what it can do is support the identity and verification layer the tax file is built on.

FAQ

What Is the OECD Crypto-Asset Reporting Framework (CARF)?

CARF is an OECD international standard for collecting and automatically exchanging tax-relevant information on crypto-asset users and transactions. It sets common rules for reporting entities, reportable users, assets, transactions, and data. CARF itself is an international standard; actual business obligations arise through domestic implementation in each jurisdiction.

What Is a Reporting Crypto-Asset Service Provider (RCASP)?

An RCASP is an individual or entity that, as a business, provides a service effectuating Exchange Transactions for or on behalf of customers — including acting as counterparty, as intermediary, or as the operator making a trading platform available. The test is functional and depends on the service performed rather than on custody.

How Does CARF Apply to Crypto Exchanges and Custodial Platforms?

Not every exchange or custodian automatically falls in scope. RCASP status depends on the services actually performed against the functional definition. Whether a reporting obligation exists then depends on reporting nexus and on whether the relevant jurisdiction has implemented CARF domestically, with its own effective date and filing rules.

Are Non-Custodial Crypto Platforms Subject to CARF?

Potentially. A non-custodial structure does not automatically exclude a business. The outcome depends on whether the service effectuates Exchange Transactions and whether an operator has sufficient role, control, or influence to perform CARF due diligence and reporting. Software-only tools with no service-provider role can reach a different result.

How Does CARF Determine Where a Crypto Business Must Report?

Through reporting nexus. Potential connections include tax residence, incorporation or organisation, management, a regular place of business, and a branch through which Relevant Transactions are effectuated. Where several apply, CARF prioritises them to limit duplicate reporting. A user's tax residence affects reportability, not the RCASP's own filing jurisdiction.

Which Crypto-Assets and Transactions Are Covered by CARF?

Relevant Crypto-Assets broadly cover crypto-assets capable of payment or investment use, subject to defined exclusions including Central Bank Digital Currencies and Specified Electronic Money Products. Relevant Transactions include crypto-to-fiat and fiat-to-crypto exchanges, crypto-to-crypto exchanges, Transfers, and Reportable Retail Payment Transactions.

What Due Diligence Does CARF Require?

CARF requires tax-residence self-certification from users, reasonableness checks against other information held, taxpayer identification numbers where applicable, entity classification, identification of controlling persons where required, and review when circumstances change. AML and KYC processes can support this work, but they do not replace CARF tax-residence due diligence.

What Information Does an RCASP Report Under CARF?

Reporting covers user and entity identification, jurisdiction of tax residence and TIN, relevant controlling-person data, and annual aggregated transaction information by Relevant Crypto-Asset and category — aggregate amounts, units, and transaction counts where required. Submitting every individual transaction line as a raw export is not a universal requirement.

Is CARF Already Mandatory in All 77 Committed Jurisdictions?

No. As of October 2026, 77 jurisdictions are formally committed, but domestic effective dates, first reporting years, filing deadlines, and first exchange dates differ across the 2027, 2028, and 2029 cohorts. Commitment is a political and international undertaking, not an active domestic obligation by itself.

What Is the Difference Between CARF and DAC8?

CARF is the OECD international reporting standard. DAC8 is an EU legal regime closely aligned with CARF but containing its own scope, registration requirements, due-diligence rules, reporting obligations, exchange mechanics, and enforcement. A business can share a data model across both, but the legal mapping has to be done separately for each.