The Crypto-Asset Reporting Framework (CARF) is the OECD’s new global reporting standard for crypto assets. In broad terms, CARF brings crypto exchanges, brokers, payment processors, and similar services into the same cross-border tax reporting system that already applies to banks under the Common Reporting Standard (CRS). For users, CARF mainly means automatic information-sharing across borders. Crypto service providers will start treating tax reporting as a standard compliance obligation, similar to the way banks already operate under the CRS. Exchanges, brokers, payment processors, and other in-scope intermediaries may be required to identify their users, determine their tax residency, collect their tax identification number (TIN), and report certain details about the user’s crypto activity to their local tax authority. That tax authority can then transmit the information to the tax authority in the user’s country of residence through international exchange mechanisms.

Additionally, Directive on Administrative Cooperation (DAC8) represents the European Union’s implementation of CARF and updated CRS rules, embedding these global standards into EU law and ensuring consistent reporting across member states. Its primary objective is to ensure that EU tax authorities receive standardized information on crypto-asset transactions and can automatically exchange that data across EU member states, in line with CARF. DAC8 imposes reporting, due-diligence, and registration obligations on crypto-asset service providers operating in or targeting the EU, including non-EU providers with EU users.

Together, these frameworks provide a coherent, cross-border system for tax transparency, covering both traditional financial assets and crypto.

But what makes CARF especially challenging for Web3 is not the reporting mechanics – it’s attribution. DeFi, hybrid protocols, tokenized asset platforms, and stablecoin projects often split execution (smart contracts) from influence (governance, admin keys, front-ends, fee capture). CARF’s practical question becomes: who is in a position to make the platform available and comply?

CARF vs DAC8: What Changes in 2026–2027

By the beginning of 2026, around 70 jurisdictions are expected to have committed to CARF. In the EU, the UK, and the Cayman Islands, the first data collection period begins on 1 January 2026, with the first international exchanges of crypto data expected in 2027. Businesses registered or operating in these jurisdictions should urgently assess whether their activities fall within CARF’s scope and, if so, begin preparing for compliance.

Other jurisdictions – including the BVI, Seychelles, Panama, UAE, Singapore, and Hong Kong – have committed to a first data collection period starting on 1 January 2027, with data exchanges expected in 2028.

In practical terms, this means that any service provider facilitating crypto transactions may soon face new KYC and reporting obligations. This article reviews CARF’s core concepts and explores how the framework applies to more complex areas such as decentralized finance (DeFi), tokenized asset projects, prop trading, and stablecoins issuance models.

For a detailed explanation of which assets and transactions are in scope, who qualifies as a reporting entity, and what information must be reported, see our earlier article: “CARF Explained: How OECD’s Global Crypto Tax Reporting Rules Affect Your Project”.

Who Must Report: The “Reporting CASP / RCASP” Test (Plain English)

At its core, CARF revolves around one central concept: the Reporting Crypto-Asset Service Provider (reporting CASP). Determining whether a business qualifies as a reporting CASP is the most important step in assessing CARF exposure.

In simple terms, a reporting CASP is any individual or entity that, as a business, effectuates exchange transactions in crypto assets for or on behalf of customers, or makes a trading platform available. This definition is intentionally broad.

Some categories of market participants are unambiguously covered by CARF. These include:

• Centralized crypto exchanges facilitating crypto-to-crypto or crypto-to-fiat trades;
• Brokers and dealers executing transactions on behalf of customers;
• Crypto payment processors and ATMs enabling conversions or transfers;
• Individuals or entities that subscribe to one or more crypto assets, meaning persons who purchase such assets directly from an issuer for resale or distribution to customers;
• Any business operating a trading platform, regardless of whether it is custodial or non-custodial.

Importantly, custody is not decisive. A platform does not need to hold users’ private keys to fall within CARF. If it enables users to execute exchange transactions and is capable of complying with due diligence and reporting obligations, it can be treated as an RCASP.

By contrast, CARF is clear on who is not automatically captured:

• Pure token issuers, where issuance is not combined with brokerage or trading activity;
• Self-hosted wallets, where users transact independently without an intermediary;
• Bulletin boards or price-aggregation tools, provided they do not facilitate execution or exert control over trading.

In short, CARF targets intermediation, not innovation.

DeFi Under CARF: Why “Control” Beats “Decentralization” Labels

Applying CARF to decentralized or hybrid structures is far more nuanced. The OECD acknowledges that crypto services may be provided through decentralized arrangements, but decentralization alone does not remove a platform from CARF.

Instead, the decisive question is whether any person or entity exercises control or sufficient influence over the platform such that it can comply with CARF obligations. This is known as the control or sufficient influence (COSI) test.

To identify relevant indicators of influence and control, the OECD refers to the 2021 FATF Guidance on Virtual Asset Service Providers, which lists factors such as:

• Setting or modifying protocol parameters;
• Maintaining or promoting the protocol as an ongoing business;
• Having an ongoing business relationship with users, even if mediated by smart contracts;
• Holding administrative or upgrade keys;
• Retaining privileged access to the platform;
• Collecting fees or otherwise deriving profits from the platform.

If such influence exists, the relevant person or entity is likely to be treated as the reporting CASP – even if transactions are executed via smart contracts and without custodial services.

Many protocols describe themselves as decentralized while still retaining meaningful control mechanisms. CARF looks beyond labels and focuses on substance over form. Only in rare cases – where a protocol is genuinely decentralised, permissionless, immutable, with no identifiable entity exercising control may fall outside the scope of CARF. These cases are expected to remain the exception rather than the rule.

DEXs: Front-Ends, Fee Capture, DAO Governance

CARF defines “exchange transactions” broadly, covering crypto-to-crypto and crypto-to-fiat trades. The OECD clarifies that a trading platform includes any software that allows users to carry out exchange transactions. As such, DEXs generally qualify as trading platforms – the real question is who makes them available.

Where a DEX has an operating company, foundation, DAO with concentrated governance power, or a team maintaining the frontend or smart contracts, that party may be considered to be making the platform available and thus qualify as a reporting CASP.

The fact that trades settle directly on-chain or that liquidity is provided by users does not change this analysis. What matters is whether someone is in a position to identify users and report transactions.

Example – Semi-centralized DEX:

An exchange governed by a DAO, but with a core team maintaining the code and frontend, is likely within scope. Even if trades settle on-chain, the core team behind the protocol may be able to identify users and transactions and would therefore be a reporting CASP if it has nexus in a participating jurisdiction.

Example – Pure DEX:

A truly immutable DEX with no admin keys, no upgrade paths, and no identifiable operators may fall outside CARF simply because there is no one to enforce reporting obligations.

Lending Protocols: Matching, Parameters, Risk Controls

Similar logic applies to DeFi lending protocols. If a protocol is maintained by a team or DAO with administrative controls, adjustable parameters, or an active business model, those parties may qualify as RCASPs.

A lending platform may be treated as a trading platform if it automatically matches borrowers and lenders. Decentralized execution does not override centralized influence. Only where a protocol is genuinely autonomous, with no admin keys or governance control, might CARF struggle to identify a reporting entity.

In practice, most lending protocols retain governance or risk-management controls, making CARF exposure likely.

Tokenization and RWAs: When Issuers Stay Out – and Platforms Fall In

Tokenization projects transform real-world assets – such as real estate, private credit, or art – into on-chain tokens. Under CARF, such tokens are generally treated as crypto assets, particularly where they are transferable and have investment potential. CARF explicitly covers tokenized financial instruments and investment-type NFTs.

Issuing a token alone does not create RCASP status. However, operating a marketplace or facilitating secondary trading as part of a resale model may.

Example – RWA platform operator:

A company that issues tokenized real-estate interests and operates a trading platform for those tokens is effectively running a crypto exchange. That operator is likely a reporting CASP and must report trades under CARF.

Example – Broker or dealer:

A firm that subscribes to tokens from an issuer and resells them to clients may qualify as a broker or dealer. CARF explicitly includes persons who acquire crypto assets from issuers for resale or distribution.

In summary, tokenization projects must scrutinize who is doing the trading. If your business runs the exchange or service where tokenized assets change hands, it’s likely a reporting CASP. Purely creating or holding tokens without providing a trading service generally stays out of CARF.

Prop Trading: When “Own Account” Stays Out – and When It Doesn’t

Proprietary trading – where a firm trades crypto assets exclusively for its own account using its own capital – is generally outside the scope of CARF. CARF targets intermediation, not investment activity. Where a company trades solely as a principal and does not execute transactions for or on behalf of customers, it will not qualify as a reporting CASP. In such cases, the firm is a market participant rather than a service provider.

However, CARF exposure may arise where a proprietary trading model is combined with client-facing or facilitation activities. For example, if a firm executes trades using third-party capital, it may be regarded as effectuating exchange transactions on behalf of others. Similarly, a firm that labels itself as a “prop trader” but in practice operates trading accounts for external investors may fall within CARF’s broad definition of a reporting CASP.

It is also important to note that, even where proprietary trading itself falls outside the scope of CARF, transactions on the counterparty side of such trades will generally be reportable by the relevant exchanges and platforms. In other words, the absence of CARF obligations at the level of the proprietary trader does not eliminate reporting at the system level. Transaction data arising from such trading activity will still be collected and reported to tax authorities by the exchanges, brokers, or other services that facilitate the execution of those trades.

Stablecoins: Centralized vs Decentralized Coins

Stablecoins are explicitly included as reportable crypto assets under CARF, except where they qualify as regulated e-money. How CARF affects stablecoin projects depends on structure.

Centralized fiat-backed stablecoins (e.g. USDC, USDT)

The tokens themselves are crypto assets, so any trade or transfer involving them is reportable if handled by a reporting CASP (for example, a crypto exchange or payment provider). The issuer (the stablecoin company) is not automatically a RCASP just by minting coins, because issuance alone is not “effectuating transactions”. However, if the issuer also operates an exchange or on/off-ramp (e.g. allowing customers to buy the stablecoin for fiat or redeem it), that part of its business triggers CARF obligations.

Algorithmic or decentralized stablecoins (e.g. USDS)

Decentralized stablecoins typically do not have a central issuing entity in the traditional sense. Tokens are generated through smart contracts based on user-provided collateral and governed by decentralized protocols rather than sold directly by a single operator.

As a result, there is usually no clearly identifiable reporting CASP solely at the issuance level. CARF reporting obligations instead arise at the level of intermediaries through which users acquire, exchange, or transfer such stablecoins, including centralized exchanges, custodial wallets, or other service providers facilitating transactions.

In line with the broader treatment of DeFi tokens under CARF, reporting focuses on the services that enable users to transact, rather than on the protocol itself where no centralized operator administers circulation or provides user-facing services. Where a platform or entity exercises operational control or offers regulated crypto-asset services, it may fall within the scope of CARF depending on its functions.

Key CARF Obligations: What Must Be Collected and Reported

For those platforms or projects deemed reporting CASPs, CARF imposes familiar duties:

1) Customer due diligence (KYC): RCASPs must collect detailed identity and tax data for each user. This includes legal name, address, country of tax residence, Tax ID Number(s), date of birth/incorporation, and for entities, details of controlling persons. Users must provide a self-certification of their tax residency, much as in CRS. In practice, reporting CASPs will need to build or integrate KYC processes so that wallet addresses or accounts are linked to verified individuals.

2) Transaction monitoring: All reportable transactions must be recorded. By CARF’s categories, this means logging every exchange of crypto-to-fiat or crypto-to-crypto, as well as transfers of crypto out of platform wallets. For each type of asset, the reporting CASP must track total amount traded, fair market value, number of transactions and fees. Expect the need for back-end reporting tools that aggregate wallet transfers and user identities.

3) Annual reporting: Each year, reporting CASPs compile the collected data into the OECD’s prescribed XML reporting schema and submit it to their local tax authority. The 2026 tax-year data must be filed (where required) in 2027. The report must include specified data on all relevant transactions categorised by transaction type and asset. The domestic tax authority will then automatically exchange this information with jurisdictions where users are tax resident. Data is then exchanged automatically with partner jurisdictions.

Practical Compliance Checklist for Founders and Ops Teams

Any project that could be a reporting CASP should act now. Here’s a practical compliance checklist for founders, C-levels, and operation teams on how to get ready:

1. Gap Analysis:

   Conduct a thorough review of your business and services. Are you located in any of the jurisdictions listed here and facilitate exchanges, transfers, or payments involving crypto assets? If yes, you are likely reporting CASP.

2. Technology Audit:

   Can your current systems capture, store, and report the required data? Plan for necessary upgrades now.

3. Update Onboarding and KYC Processes:

   Start collecting customer due diligence data now. It’s easier to gather data progressively than to rebuild your user base later.

4. Get Legal and Tax Advice:

   Consult professionals who understand OECD tax reporting standards and crypto asset regulation in your jurisdiction. CARF compliance requires knowing where your project fits within the framework and what obligations apply. At Aurum, we help crypto projects assess whether CARF applies to their activities, map potential reporting requirements, and design the compliance process.

5. Communicate With Your Community:

   Inform your users that new reporting rules are coming. Transparency builds trust and helps manage expectations when you start collecting additional information and send reports to your tax authority.

6. Product Documentation Review:

   Update your privacy policy to clearly reflect new data collection and reporting practices under CARF. If you need support aligning your documentation, Aurum can assist in updating your policies and procedures to ensure full compliance.

7. Monitor Regulatory Updates:

   The OECD continues to refine implementation details. National governments are issuing their own versions of CARF laws, timelines, and penalties. The OECD and national tax authorities may issue clarifications, especially on DeFi structures. Staying updated is crucial – the rules will evolve as the crypto landscape evolves.

Conclusion: Design for CARF/DAC8 Reality Without Breaking the Product

CARF and DAC8 mark a structural shift: tax reporting is becoming a baseline expectation across crypto markets, not a “CeFi-only” feature. The biggest practical risk for DeFi and tokenization isn’t that smart contracts exist – it’s that someone still controls enough of the stack (parameters, upgrades, front-end access, fee streams, governance concentration) to be treated as the reporting entity.

If your product touches user-facing execution – swaps, matching, secondary trading, on/off-ramping, payment flows, or custodial layers – you should treat CARF/DAC8 readiness as a core operational workstream for 2026. Build a clear role map (who operates what), a data map (what you can capture), and a jurisdiction map (where registration/reporting triggers). The projects that handle this early will avoid last-minute redesigns, community backlash over sudden KYC, and preventable enforcement exposure.