CARF compliance guide for crypto platforms: What every exchange, custodian, and RCASP must do before 2027

As of April 2026. This guide will be updated quarterly as jurisdictional rules are finalized.

As of January 1, 2026, CARF obligations took effect in the EU under DAC8 and in the UK under SI 2025/744. Brazil had published CARF-aligned regulations in November 2025 under IN RFB nº 2.291/2025, with obligations operative in 2026. With 76 jurisdictions worldwide committed to implementation and most first reporting exchanges due in 2027, if your exchange is established in the EU or UK, or serves EU-resident users as a non-EU operator, you are already in scope. Due diligence collection has started. The first reports are due in 2027. And most platforms are behind.

This guide covers everything a Reporting Crypto-Asset Service Provider (RCASP) needs to understand about CARF: who must report, what must be reported, how due diligence works, and what the implementation timeline actually looks like. It also covers what CARF means for individual investors whose transaction history will soon be flowing to tax authorities around the world.

What is CARF, and why it's different from everything that came before

The problem CARF solves

Before CARF, crypto largely existed outside automatic tax information exchange. The Common Reporting Standard (CRS), the OECD's global framework for cross-border financial account reporting, was built for traditional financial institutions: banks, custodians, brokers holding financial assets. Crypto exchanges generally were not reporting financial institutions for CRS purposes. Even where a crypto-related platform could technically fall within its scope, CRS was a cross-border financial account reporting regime focused on account balances, income, and, for custodial accounts, gross proceeds from the sale or redemption of financial assets (such as stocks and bonds).

Because of this, a taxpayer could move assets between wallets, trade across multiple exchanges in different jurisdictions, and realize significant gains with no automatic reporting to any tax authority. CRS gave tax administrators limited visibility. CARF was designed to close that gap entirely.

Per the OECD CARF Full Report (June 2023), CARF was developed to "ensure the collection and automatic exchange of information on transactions in Relevant Crypto-Assets" and to prevent "recent gains in global tax transparency" from being "gradually eroded" by the growth of crypto markets.

CARF vs. CRS: The fundamental difference

The structural difference between CARF and CRS is not a detail; it is the entire architecture of the compliance obligation.

At the OECD baseline, CARF is a cross-border framework: an RCASP reports on users who are resident in jurisdictions with which the implementing jurisdiction has an active exchange agreement. DAC8, the EU's implementation via Council Directive 2023/2226, goes further by explicitly including domestic EU residents within reportable scope, a category that would not be covered by the base CARF cross-border model, which focuses on reporting to other partner jurisdictions rather than domestic residents.

For compliance teams, this distinction matters most when assessing your user base: under the base CARF model, a domestic resident of the same country as your exchange may not be a reportable person. Under DAC8, all EU-resident users are within reportable scope regardless of where your exchange is established. The EU is not alone. Brazil and the United Kingdom, for example, have each adopted implementing legislation that similarly requires RCASPs to collect information on both resident and non-resident customers.

How CARF closes the balance-manipulation loophole

Under CRS, a taxpayer who transferred assets out of a reportable account before December 31 avoided triggering a year-end balance report. The asset would simply not appear in the snapshot.

CARF's aggregate transaction reporting throughout the year eliminates this strategy entirely. Every exchange transaction and transfer is captured during the period in which it occurred, regardless of where assets sit at year-end. Inbound and outbound transfers are both reported across three separate sub-categories, covering transfers to the user, transfers by the user, and outbound transfers to self-hosted wallets specifically. That last category gives tax authorities direct visibility into off-exchange movements. The OECD built CARF around transaction-level data because year-end balance snapshots are insufficient for an asset class that can be moved instantly across jurisdictions.

Who must report: The RCASP cefinition

What is a reporting crypto-asset service provider?

A Reporting Crypto-Asset Service Provider (RCASP) 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." (CARF Section IV(B)(1))

In practice, this covers:

• Centralized crypto exchanges (spot, derivatives, OTC)
• Custodial wallet providers
• Crypto brokers and dealers
• Operators of crypto ATMs
• Certain decentralized platforms (see below)
• Financial institutions that have added digital asset services

Software and hardware providers are excluded

The RCASP definition turns on whether an entity effectuates transactions, not merely whether it enables access to them. An entity that solely creates or sells software without using it to effectuate exchange transactions for customers is not an RCASP. Similarly, an entity providing only a bulletin board for posting prices without executing trades falls outside scope. Hardware wallet manufacturers and software-only providers that do not process transactions on behalf of customers are generally outside CARF scope.

Entities solely engaged in validating distributed ledger transactions (mining or staking) are also not RCASPs, even where such validation is remunerated.

This remains a fact-specific determination. If your business model sits near the line, evaluate carefully against the OECD Commentary's functional test.

DeFi: Non-custodial status alone does not create exemption

The OECD Commentary clarifies that a platform operator making available a trading platform must be able to exercise control or sufficient influence over the platform in order to comply with due diligence and reporting obligations. Non-custodial structure alone does not determine RCASP status; what matters is whether the entity provides a service effectuating exchange transactions for customers.

Updated OECD FAQ guidance has further confirmed that non-custodial and decentralized service providers can fall within the RCASP definition under certain circumstances. The specific indicators used to assess whether an operator exercises sufficient control continue to evolve as implementation experience develops.

Extraterritoriality: Compliance follows the user, not the company

This is the CARF principle most likely to catch US-headquartered platforms off guard. CARF compliance obligations are triggered by nexus with implementing jurisdictions, and multiple jurisdictions look to where your users are resident, not just where you are incorporated.

The OECD model establishes five nexus types: tax residence, incorporation/organisation, management, regular place of business, and branch operations. But several jurisdictions have enacted rules that reach further:

EU (DAC8): Non-EU operators serving EU-resident users must register in one EU member state if they are not already licensed under MiCA (Regulation (EU) 2023/1114). A US exchange with EU users that is not MiCA-licensed must register in a Member State to fulfill its DAC8 obligations.

UK (SI 2025/744): The UK regulations came into force January 1, 2026 and apply CARF Section I's nexus rules directly, covering platforms with a regular place of business in the UK, managed from the UK, or incorporated in the UK.

Brazil (IN RFB nº 2.291/2025): Brazil's implementation triggers obligations when a foreign provider "provides crypto-asset services in Brazil," including use of any .br domain, commercial agreements with Brazilian-resident entities, advertising directed at Brazilian residents, or indicating Brazilian payment methods such as PIX (Article 5, Paragraph 1). This is an economic nexus approach, not a domicile-based one.

Practical rule: If you serve users in any CARF-implementing jurisdiction, engage local counsel to assess whether you have a nexus obligation in that jurisdiction. US-only operations serving only US users are not currently within CARF scope; the US has committed to first exchanges by 2029 but has not enacted implementing legislation. Note that for non-EU operators, serving EU-resident users can independently trigger DAC8 registration obligations regardless of where the platform is established. That said, US platforms outside CARF are simultaneously subject to significant domestic reporting requirements under IRC §6045 and the Form 1099-DA broker reporting rules, which represent their own compliance build for the 2025 and 2026 tax years.

What must be reported: The CARF transaction taxonomy

CARF defines a relevant transaction as any exchange transaction or transfer of relevant crypto-assets. Exchange transactions cover two categories. Transfers are the residual category, with reportable retail payment transactions as a notable transfer subcategory subject to additional obligations.

1. Crypto-to-fiat exchange transactions

Any exchange between a relevant crypto-asset and a fiat currency, for example selling BTC for USD on a centralized exchange. The RCASP must report the aggregate gross amount paid and received, the aggregate number of units, and the number of transactions, reported separately for acquisitions and disposals. Amounts are reported in the fiat currency in which they were paid or received.

2. Crypto-to-crypto exchange transactions

Any exchange between two or more forms of relevant crypto-asset. The RCASP reports aggregate fair market value and unit count for both sides of the trade, valued in fiat currency at the time of each transaction. Each crypto-to-crypto transaction is split into two reportable elements: a disposal of the sold asset at its fiat-equivalent market value at time of disposal, and an acquisition of the purchased asset at its fiat-equivalent market value at time of acquisition.

3. Transfers, including self-hosted wallets

Transfers are CARF's most expansive reporting category and the one most different from US §6045. A transfer is any movement of a relevant crypto-asset from or to a user's address that the RCASP cannot determine is an exchange transaction.

This includes on-chain transfers to external wallets, airdrops, lending receipts, and staking yield credited to a user's account. On the last point: an entity solely engaged in operating staking nodes to validate the blockchain is not an RCASP and is not subject to CARF reporting. However, when an exchange credits staking yield to a user's account as part of its service, that crediting action is a reportable inbound transfer. The distinction is the exchange acting as an intermediary crediting income, not the act of validation itself.

Transfers are reported across three sub-categories: inbound transfers to the user, outbound transfers by the user, and outbound transfers specifically to self-hosted wallet addresses not known to be associated with a VASP or financial institution. That last category is reported separately with its own aggregate fair market value and unit count.

Transfers are reportable even when they are not taxable events. This is a fundamental departure from the US §6045 framework, which only triggers reporting on sales and exchanges generating gross proceeds.

RCASPs must retain all documentation and data underlying these reporting obligations for a minimum of five years after the end of the reporting period. This covers self-certifications, AML/KYC documentation, and transaction-level data.

4. Reportable retail payment transactions (a transfer subcategory)

A reportable retail payment transaction is a transfer of relevant crypto-assets in consideration for goods or services exceeding USD 50,000 in value. The OECD model states the threshold in USD; domestic implementing legislation governs the actual fiat currency and any local equivalent used in a given jurisdiction. RCASPs processing merchant payments above this threshold must also treat the merchant's customer as a crypto-asset user and report on that basis, provided the RCASP is required to verify the customer's identity under domestic AML rules.

Retail payment transactions at or below USD 50,000 are still reportable as ordinary transfers; the threshold determines the additional customer reporting obligation, not whether the transaction is reportable at all.

What crypto-assets are in scope

Included assets

The CARF definition of Crypto-Asset covers "a digital representation of value that relies on a cryptographically secured distributed ledger or a similar technology to validate and secure transactions." The OECD expressly included "similar technology" to capture future developments. In practice this encompasses:

• Cryptocurrencies (BTC, ETH, SOL, etc.)
• Stablecoins, including asset-backed stablecoins, distinct from specified electronic money products
• Utility tokens that can be used for payment or investment purposes
• Asset-backed tokens (tokenized equities, tokenized real estate)
• Derivatives issued in the form of a Crypto-Asset
• NFTs, assessed on a case-by-case basis (see below)

Excluded assets

Three categories fall outside the definition of Relevant Crypto-Asset:

1. Central Bank Digital Currencies (CBDCs): Any digital fiat currency issued by a Central Bank. These fall within CRS scope under the 2023 amendments.
2. Specified Electronic Money Products: Digital representations of a single fiat currency, issued on receipt of funds, redeemable at par at any time per regulatory requirements. Five specific criteria must be met; not all stablecoins qualify.
3. Non-payment/non-investment assets: Crypto-assets the RCASP has adequately determined cannot be used for payment or investment purposes, including closed-loop loyalty systems, airline miles tokenized on-chain, and gaming credits with no convertibility.

NFTs: A fact-specific assessment

NFTs are neither categorically included nor categorically excluded under CARF. The framework's exclusion applies to assets the RCASP has adequately determined cannot be used for payment or investment purposes. Whether a specific NFT meets that standard requires a fact-specific assessment of its characteristics and how it functions in practice. The OECD has issued interpretive FAQ guidance addressing NFT classification, including factors relevant to the exclusion determination. That guidance continues to evolve.

Apply any exclusion determination conservatively and document the analysis.

Due diligence requirements: The January 2026 deadline you may have already missed

Self-certification: Stricter than KYC

CARF's due diligence regime runs on self-certifications, formal attestations from users establishing their tax residency and TIN. A valid individual self-certification must contain the user's full name, residence address, jurisdiction(s) of tax residence, TIN for each reportable jurisdiction, and date of birth. Entity users must additionally provide controlling person information unless the entity qualifies as an active entity or excluded person.

This is categorically different from standard AML/KYC. An AML/KYC process verifies identity. A CARF self-certification verifies tax residence and tax identification. Errors have different consequences: a KYC failure triggers compliance flags, but a self-certification error means a user gets reported to the wrong tax authority. The RCASP must confirm the reasonableness of the self-certification against its AML/KYC documentation; the two processes interact but are not interchangeable.

RCASPs that are also CRS-reporting financial institutions may rely on CRS due diligence for CARF purposes, provided the existing documentation satisfies all CARF-required fields. Where CRS documentation is missing fields that CARF requires but CRS does not always mandate (such as date of birth for certain pre-existing account categories), the RCASP must collect those fields separately. For platforms that are not CRS entities, this cross-reliance is not available.

New vs. pre-existing accounts

The due diligence obligations differ depending on when the customer relationship was established.

For new accounts, CARF requires a valid self-certification at account opening, specifically "when establishing the relationship." All required fields must be collected at that time. The obligation is not deferred to the first transaction.

For pre-existing accounts, RCASPs have 12 months after the effective date of the implementing jurisdiction's rules to collect self-certifications. In the EU and UK, this maps to a December 31, 2026 deadline.

Under DAC8, where a user fails to provide required information after two reminders during a 60-day waiting period, the RCASP must prevent that user from performing reportable transactions. This is a back-end enforcement mechanism for non-responsive pre-existing users, not a safe harbor for incomplete new-account onboarding. Member States may implement this through account-level restrictions.

Managing onboarding friction without compromising compliance

Adding self-certification collection to new account onboarding creates real conversion pressure. Every additional step is a potential drop-off point. There are compliant ways to reduce friction without deferring required fields:

• Sequence within onboarding: Present self-certification fields as a natural part of the KYC/AML flow rather than as a separate, disconnected step. Since the required fields overlap with AML identity data, much of the groundwork is already being laid.
• In-app nudges for pre-existing accounts: Push notification campaigns tied to the December 31, 2026 deadline with specific deadlines drive completion without email-based outreach.
• Phishing-safe communication design: Any outreach to pre-existing users requesting tax documentation must come through secure in-app channels, not external email links. Crypto users are high-value phishing targets and will treat unsolicited tax documentation requests with appropriate suspicion.

Change of circumstances

If an RCASP learns of a change of circumstances that makes the original self-certification incorrect or unreliable, it cannot rely on the existing certification. A new valid self-certification, or a reasonable explanation with supporting documentation, must be obtained. This is an ongoing obligation, not a one-time collection event.

M&A due diligence

Updated OECD guidance has confirmed that acquirers in M&A transactions may rely on due diligence data collected by the acquired entity, subject to accuracy checks on the existing documentation. Existing user certification data collected by the target can be inherited, provided the acquirer reviews it for ongoing validity.

DAC8 and UK implementation: Going beyond the OECD baseline

The EU's implementation, DAC8 (Council Directive 2023/2226), contains several provisions that go beyond the OECD baseline. Key differences compliance teams serving EU users need to understand:

• Domestic resident reporting: DAC8 explicitly requires reporting on all EU-resident users, including domestic residents of the same country as the exchange. This goes beyond the OECD model's cross-border exchange focus.
• Blocking reportable transactions: After two reminders during a 60-day waiting period, platforms must prevent users who have not provided required self-certifications from performing reportable transactions.
• GDPR notification: Before transmitting customer data to tax authorities, platforms must notify users that their data will be reported and potentially transferred to other Member States' tax administrations.
• Penalties: DAC8 requires Member States to implement penalties that are effective, proportionate, and dissuasive. Specific amounts are left to each Member State's discretion. As a reference point, the UK implemented its own standalone CARF framework (separate from DAC8, which applies only to EU Member States) with specific figures in SI 2025/744: up to GBP 100 per user for due diligence failures (Reg. 11), up to GBP 300 per user for failure to obtain a valid self-certification (Reg. 11(2)), up to GBP 5,000 per calendar year for record-keeping failures (Reg. 12), up to GBP 5,000 for late reporting plus GBP 600 per day for continued failure (Reg. 14), and up to GBP 100 per user for inaccurate or incomplete reports (Reg. 15).
• Registration: Non-EU RCASPs serving EU users without MiCA authorization must register in a single EU member state. MiCA-authorized platforms are not required to separately register under DAC8; their MiCA authorization fulfills the registration requirement.
• First exchange: The first automatic exchange between Member State tax authorities is due by September 30, 2027, covering the 2026 reporting year.

The implementation timeline: Where most platforms stand today

The "eight months, not two years" reality

The most common mistake compliance teams make is treating CARF as a 2027 problem. It is not. Self-certification collection has been legally required since January 1, 2026 in the EU and UK. Every new account opened without a valid self-certification is a compliance gap. Every pre-existing user without a certification by December 31, 2026 represents an unresolved classification; without a valid self-certification, the platform cannot determine whether that user is a reportable person.

The first UK report, due May 31, 2027, covers the full 2026 calendar year. That means all transactions from January 1, 2026 through December 31, 2026 must be captured with the correct user classification. A platform that starts building its certification workflow in Q3 2026 will be working with incomplete user data for the first half of the year. That is not a minor gap; it is half the reportable period.

A practical implementation checklist for RCASPs

Step 1: Determine your RCASP status

• Map all business activities against the RCASP definition: are you effectuating exchange transactions for or on behalf of customers?
• If your product includes decentralized or non-custodial elements, assess whether you exercise control or sufficient influence over the platform. Document the analysis and monitor OECD FAQ guidance, which continues to evolve.
• Identify which jurisdictions' CARF implementations create obligations for your platform. For DAC8, the registration trigger for non-MiCA operators is serving EU-resident users. For the UK, obligations attach via traditional nexus criteria: tax residence, incorporation, management, or a regular place of business in the UK. These are different tests requiring separate analysis.
• For each applicable jurisdiction, determine whether you have a registration obligation. DAC8 requires non-MiCA platforms to register in an EU member state; UK requires registration by May 31, 2027 (for platforms in scope as of 2026).

Step 2: Audit your data infrastructure

• Map your current transaction data model against CARF's reporting fields, including separate coverage for inbound transfers, outbound transfers, and self-hosted wallet transfers. For each field, determine whether you can produce it.
• Confirm you can aggregate transaction values by relevant crypto-asset type, by transaction category, and by direction on an annual basis.
• Confirm your timestamp architecture. UTC vs. local time mismatches create cross-year reporting complications for transactions recorded near midnight on December 31.
• Assess your capacity to distinguish whether outbound wallet transfers are going to VASP-associated addresses vs. self-hosted wallets.

Step 3: Design self-certification collection

• CARF requires a valid self-certification at account opening, not deferred. Build collection of all required fields (full name, residence address, tax jurisdiction(s), TIN, date of birth) into your account opening flow immediately if not already done.
• For UX design, integrate self-certification fields into the existing KYC/AML onboarding sequence rather than adding them as a separate step. The data overlap makes this natural.
• Design a pre-existing account outreach campaign running through December 31, 2026. Use secure in-app messaging, not email links. Phishing risk in crypto makes any external link to a tax documentation form a security liability.
• Build a change-of-circumstances monitoring workflow: how does your system flag and recollect when user circumstances change?

Step 4: Map to jurisdictional schemas

• CARF provides a model XML schema that each jurisdiction adapts. DAC8 uses a standardized schema for EU exchanges. UK HMRC will specify its electronic report system format separately.
• Prioritize jurisdictions by user concentration. Your largest compliance exposure is where your most users live.
• Monitor jurisdiction-specific registration portals and filing deadlines.

Step 5: Evaluate technology and vendor solutions

The CARF data model requires capabilities most platforms don't have natively: transaction categorization into CARF types, aggregate valuation in fiat currency at transaction time, XML schema generation per jurisdiction, self-certification workflow management with structured escalation, and coverage for 76 committed jurisdictions with ongoing schema updates.

If the data going in isn't accurate, the reports going out won't be either. Evaluate vendors on data ingestion first, covering blockchain data, exchange API connectivity, and transfer classification. Schema generation and filing portals are the second layer.

What CARF means for individual investors

If you have accounts at a crypto exchange in the EU, UK, or any jurisdiction where CARF implementing rules are operative, here is what you need to know.

If you are tax-resident in the EU, UK, or another CARF partner jurisdiction and have accounts at exchanges with operative CARF obligations, your transaction history may be reported to your home tax authority, depending on the exchange's applicable reporting requirements and whether your home jurisdiction is a reportable jurisdiction for that exchange. Total acquisition amounts, total disposal proceeds, and total transfer volume will be disaggregated by crypto-asset type and categorized by transaction type. For EU-resident users at EU exchanges and UK-resident users at UK exchanges, reporting is already operative for the 2026 tax year.

Under DAC8, EU exchanges report on EU-resident users, including domestic residents. The base OECD CARF model focuses on cross-border reporting, but DAC8 explicitly extends this to cover EU residents regardless of where the exchange is located. If you are EU-resident and have an account at an EU exchange, you are within reportable scope.

Your exchange will ask you to certify your tax residency and TIN. If you opened a new account after January 1, 2026 at a CARF-jurisdiction exchange, you may have already been asked. If you have a pre-existing account, expect outreach through 2026. Under DAC8, failing to provide a valid self-certification after two reminders within 60 days can result in being blocked from conducting reportable transactions.

If you have accounts at exchanges in multiple countries, each exchange reports independently to its own tax authority. Where you are within reportable scope at exchanges across multiple jurisdictions, your home tax authority may receive a composite picture of your cross-platform activity.

Self-hosted wallet transfers are tracked. Transfers from your exchange account to a self-hosted wallet, even when not a taxable event, are reported as transfer-type transactions including the aggregate value transferred. Tax authorities can use this to request further information on wallet activity through existing exchange of information channels.

Conclusion

CARF is operational in the EU and UK, which are among the 47 jurisdictions committed to first exchanges in 2027. For 28 additional jurisdictions, first exchanges are due in 2028, with the US committed to 2029. The question for every exchange, custodian, and RCASP is not whether to comply, but how to build compliant systems before the reporting deadlines arrive with data that needs to be complete and accurate.

The platforms that start now, building self-certification collection, auditing data infrastructure, and mapping jurisdictional obligations, will have time to remediate gaps before the first reports are due. The platforms that wait until Q4 2026 will be filing incomplete data, or worse, filing nothing and hoping enforcement comes slowly.

The OECD built CARF specifically because the existing information exchange framework was insufficient, and the framework's design reflects that intent: aggregate transaction reporting, self-hosted wallet visibility, and government-to-government exchange built into the architecture. The jurisdictions implementing it have signaled that compliance is a priority.

Key sources

• OECD (2023), International Standards for Automatic Exchange of Information in Tax Matters: Crypto-Asset Reporting Framework and 2023 Update to the Common Reporting Standard, OECD Publishing, Paris. https://doi.org/10.1787/896d79d1-en
• OECD, Crypto-Asset Reporting Framework: Frequently Asked Questions (last updated December 2025). Available at: www.oecd.org/content/dam/oecd/en/topics/policy-issues/tax-transparency-and-international-co-operation/faqs-crypto-asset-reporting-framework.pdf
• Council Directive (EU) 2023/2226 (DAC8): EU implementation covering domestic resident reporting, registration, the blocking mechanism, and the first exchange deadline. eur-lex.europa.eu
• UK SI 2025/744 (The Reporting Cryptoasset Service Providers Regulations 2025): UK implementation covering the January 1, 2026 operative date, May 31, 2027 reporting and registration deadlines, and the penalty schedule. legislation.gov.uk
• Receita Federal do Brasil, Instrução Normativa RFB nº 2.291, de 14 de novembro de 2025 (published November 14, 2025). Official announcement: gov.br/receitafederal Full legal text: legisweb.com.br/legislacao/?id=489016
• OECD CARF Commitments (February 2026): Jurisdiction commitment waves, with 47 jurisdictions by 2027, 28 by 2028, and the US by 2029. https://www.oecd.org/content/dam/oecd/en/networks/global-forum-tax-transparency/commitments-carf.pdf
• OECD CARF XML Schema User Guide (July 2025): Technical reporting schema for implementation. https://www.oecd.org/en/publications/2025/06/crypto-asset-reporting-framework-status-message-xml-schema_0a6e5faa.html