CARF Reporting Requirements: What Must Be Reported and How Local Rules Differ

Introduction

In earlier articles in our CARF series, we discussed and analyzed “who must report” and “where reporting is required” under CARF. The former addresses how to identify a Reporting Crypto-Asset Service Provider (RCASP), while the latter applies the Reporting Nexus rules to determine the jurisdictions in which an RCASP has due diligence and reporting obligations. Once the reporting entity and reporting jurisdiction have been identified, implementation of CARF gives rise to a more concrete question: what information must an RCASP report to the competent authority?

CARF reporting requires an RCASP, based on the applicable due diligence procedures, to identify Reportable Users and relevant Controlling Persons, classify and aggregate transactions in Relevant Crypto-Assets in the prescribed manner, and report three broad categories of information: information on the RCASP, information on users, and transaction information.

The OECD rules provide the common international standard, while each jurisdiction must give effect to that standard through its own domestic legislation and technical specifications. Accordingly, understanding what must be reported under CARF requires looking not only at the OECD framework itself, but also at how local implementation rules may affect the scope and content of the final report.

This article outlines the basic framework of information reportable under CARF, the principal differences in local implementation, and the data and systems preparations that RCASPs can undertake, with a view to providing practical reference.

1. Reportable Information under the OECD CARF Rules

What Are “Relevant Crypto-Assets” within the Scope of CARF?

Asset classification is the foundation of transaction reporting. Under the CARF definitions, the term “Crypto-Asset” means a digital representation of value that relies on a cryptographically secured distributed ledger or a similar technology to validate and secure transactions. “Relevant Crypto-Assets” generally include all assets that meet the definition of a Crypto-Asset, other than:

Central Bank Digital Currencies (CBDCs);

Specified Electronic Money Products (SEMPs);

Crypto-Assets that the Reporting Crypto-Asset Service Provider has adequately determined cannot be used for payment or investment purposes.

The treatment of mainstream assets such as BTC and ETH is generally relatively straightforward, while stablecoins, NFTs, tokenized securities and certain utility tokens require further analysis.

Figure 1. Illustration of the Scope of CARF and CRS

CARF Reporting Requirements: RCASP, User and Transaction Information

Reportable information falls into three broad categories: information about the Reporting Crypto-Asset Service Provider (RCASP information), information about Reportable Users or Reportable Persons (user information), and information about transactions in Relevant Crypto-Assets (transaction information). Together, these categories constitute the complete content of a CARF report.

• RCASP Information

The name, address and identifying number of the Reporting Crypto-Asset Service Provider.

• The identifying number should be the Tax Identification Number (TIN). If no TIN is available, a company registration code or Legal Entity Identifier (LEI) should be used. If no identifying number has been assigned to the RCASP, only its name and address need to be reported.

• User Information

For an individual user: name, address, jurisdiction of residence, Tax Identification Number (TIN), date of birth and place of birth;

For an Entity user: name, address, jurisdiction of residence and Tax Identification Number (TIN). For Controlling Persons of an Entity identified as reportable through the due diligence procedures, the information also includes the Controlling Person’s name, address, jurisdiction of residence, Tax Identification Number (TIN), date and place of birth, and role as a Controlling Person.

• An individual user’s place of birth does not need to be reported unless otherwise required under the domestic law of the jurisdiction in which the RCASP is located.
• A Tax Identification Number (TIN) is the identifying number assigned to the user or an Entity Controlling Person by the jurisdiction in which that person is tax resident, rather than a number issued by the jurisdiction where the platform is located, the transaction takes place, or the income arises. If the same user is identified as having multiple jurisdictions of tax residence, the report must reflect each jurisdiction in which the user is tax resident and each corresponding TIN; selective reporting is not permitted.
• Due diligence and information reporting for an Entity user may require looking through to its Controlling Persons. The RCASP must identify the Entity’s Controlling Persons and then determine whether any of those persons are Reportable Persons. An Entity Controlling Person brought within the reporting scope must satisfy both the tax-residence and control tests: the person must be tax resident in a Reportable Jurisdiction and must exercise control over the Entity. The core concept is a “controlling ownership interest”; holding an ownership interest above the applicable threshold, serving as a senior managing official, or acting as the settlor, trustee or beneficiary of a trust may, depending on the circumstances, satisfy this standard.

• Transaction Information

For each type of Relevant Crypto-Asset within the CARF definition, the following information must be reported:

The full name of the type of Relevant Crypto-Asset;

Acquisitions and disposals of Relevant Crypto-Assets against Fiat Currency: the aggregate amount paid or received, aggregate number of units, and number of Relevant Transactions;

Acquisitions and disposals of Relevant Crypto-Assets against other Relevant Crypto-Assets: aggregate fair market value, aggregate number of units, and number of Relevant Transactions;

Reportable Retail Payment Transactions: aggregate fair market value, aggregate number of units, and number of transactions;

Other Transfers of Relevant Crypto-Assets to or by a Reportable User: for Transfer transactions that do not fall within the categories above, the information is subdivided by Transfer type, such as airdrops, staking rewards, loan repayments, or exchanges for goods or services, and includes the aggregate fair market value, aggregate number of units, and number of Relevant Transactions;

Transfers to unknown external wallets: aggregate fair market value and aggregate number of units.

• The aggregate amount paid or received is the amount net of transaction fees and is reported in the Fiat Currency used in the transaction. If multiple Fiat Currencies are involved, the amounts must be reported in a single Fiat Currency and converted at the time of each Relevant Transaction using a consistently applied approach. For example, the RCASP may consistently use the spot exchange rate at the time of the transaction.
• Aggregate fair market value is determined at the time of the transaction and net of transaction fees. It must be determined and reported in a single Fiat Currency and valued at the time of each transaction using a consistently applied approach. For valuation, the RCASP should first rely on trading pairs that it maintains. If no applicable internal trading-pair price is available, alternative valuation methods may be used in sequence, including internal accounting book values, values provided by third-party companies or websites, the RCASP’s most recent valuation of the asset, or a reasonable estimate.
• A Reportable Retail Payment Transaction is subject to a USD 50,000 value threshold. A payment Transfer below that amount is not necessarily outside the reporting scope; it should instead be considered for aggregation under “other Transfers of Relevant Crypto-Assets to or by a Reportable User” or “Transfers to unknown external wallets,” as applicable.
• If a user transfers Crypto-Assets to a private wallet or to an account operated by another platform, such that the RCASP cannot know the complete circumstances of the transaction, the RCASP must also report the transaction as a Transfer to an unknown external wallet.
• The rules require all transactions to be classified and aggregated. If a Relevant Crypto-Asset is non-fungible and different variants of that Relevant Crypto-Asset have different values for a fixed unit, each unit must be treated as a separate type of Relevant Crypto-Asset.

2. Implementation Differences: From the OECD Standard to Local Reporting Requirements

The CARF rules and Commentary published by the OECD provide a unified international standard, but they ultimately take effect through implementation in the domestic law of each jurisdiction. Core rules such as the definition of Relevant Crypto-Assets, transaction categories and reporting fields are highly aligned with the OECD standard, while local policies may differ materially in certain implementation details.

• Whether Domestic Users Are Included in the Reporting Scope

The original OECD CARF framework is primarily designed for the cross-border automatic exchange of tax information. A “Reportable Jurisdiction” is a jurisdiction for which a CARF information-exchange arrangement is in effect and that is identified on a published list by the implementing jurisdiction; reporting generally focuses on tax residents of other Reportable Jurisdictions. Some jurisdictions have added domestic reporting requirements, under which an RCASP must also report information on users who are tax resident in its own jurisdiction to the local tax authority.

For example, the United Kingdom established through Finance Act 2026 a reporting obligation for UK RCASPs in respect of UK tax-resident users and relevant Controlling Persons. Current HMRC guidance also makes clear that RCASPs must collect information from all users and report data on UK tax residents as well as tax residents of other CARF-participating jurisdictions. New Zealand includes itself on its published list of CARF Reportable Jurisdictions. Inland Revenue further explains in its official guidance that where an RCASP has both New Zealand-resident and non-resident users, identifying information and relevant transaction data for both are submitted to Inland Revenue; resident data is used for domestic tax administration, while non-resident data is exchanged with the tax authority of the user’s jurisdiction of residence.

By contrast, jurisdictions such as Japan and Singapore do not include their own tax residents within the CARF reporting scope, following an approach closer to the original OECD framework. Even so, an RCASP must still perform due diligence on all users, including domestic users, in order to identify which users fall within the reporting scope. The absence of a domestic reporting requirement does not remove that due diligence obligation.

In this sense, the scope of due diligence is not the same as the scope of reporting, and the scope of international exchange is not necessarily the same as the scope of reporting required by the local tax authority.

• Conversion and Valuation Using a Single Fiat Currency

Transaction amounts and fair market values must ultimately be reported in Fiat Currency in accordance with the CARF rules. Whether a jurisdiction further prescribes a specific reporting currency will directly affect an RCASP’s data-conversion processes and reporting systems.

For example, the CARF Regulations issued by the South African Revenue Service (SARS) (Notice R.6887) expressly require transaction amounts and fair market values to be determined and reported in South African rand (ZAR). SARS’s FAQ addresses the compliance burden and practical challenges that high-volume platforms may face and provides more detailed guidance on the requirement to use a consistently applied conversion and valuation methodology. It explains that CARF does not require RCASPs to perform real-time currency conversion and does not prescribe a particular exchange-rate source or transaction-by-transaction pricing methodology. Instead, reasonable approaches such as batch processing, end-of-day exchange rates or appropriate averages may be used. High transaction volumes, asset-price volatility and differences in market data sources can therefore be balanced through operational flexibility available to the RCASP.

• Whether Monetary Thresholds Are Converted into Local-Currency Standards

Under the OECD rules, a retail payment transaction is aggregated as a Reportable Retail Payment Transaction only if it reaches the USD 50,000 threshold; otherwise, it is included in another transaction category.

In implementing CARF through domestic law, jurisdictions may convert this threshold into a local-currency standard. Japan, for example, sets the threshold for a Reportable Retail Payment Transaction at JPY 5 million (approximately USD 31,273); Brazil uses the equivalent in Brazilian reais of USD 50,000; the European Union’s DAC8 uses USD 50,000 or the equivalent amount in another currency; and some other jurisdictions retain the original U.S. dollar threshold.

Localization of the Reportable Retail Payment Transaction threshold can take several forms, including a fixed amount denominated in local currency or a local-currency equivalent of the U.S. dollar threshold. This difference affects how RCASPs classify and aggregate Relevant Crypto-Asset transactions in practice. The same transaction may constitute a retail payment transaction in Jurisdiction A but be classified as another type of Transfer in Jurisdiction B.

• Detailed Differences in Specific Reporting Fields

The OECD rules prescribe the core reporting fields for individual users, Entity users and their Controlling Persons, while leaving some room for domestic law.

An individual user’s place of birth is generally not required to be reported unless otherwise required under the law of the jurisdiction in which the RCASP is located. For a Tax Identification Number (TIN), no TIN needs to be reported if the jurisdiction in which the Reportable User or relevant Controlling Person is tax resident does not issue TINs or if its domestic law does not require TINs to be collected. In such circumstances, Singapore’s Inland Revenue Authority of Singapore (IRAS) expressly permits the relevant reason code to be provided under its CARF XML rules.

Further, even where TIN reporting is required, the form of the identifier varies across jurisdictions. In the United Kingdom, the corresponding tax identifiers include the National Insurance number (NINO) for individual users or relevant Entity Controlling Persons, the company registration number (CRN) for UK companies, and the Unique Taxpayer Reference (UTR) for partnerships and trusts.

• Whether a Return Is Required When There Is No Reportable Information

If there is no information on any Reportable User or relevant transaction during a reporting year, whether the RCASP must nevertheless file a return with the tax authority depends on the rules of the jurisdiction in which it operates.

The United Kingdom expressly follows a “no data, no return” approach. Singapore generally requires a nil return, containing only RCASP information and no user or transaction data. In addition, the Japan National Tax Agency’s CARF FAQ clarifies the relationship between transaction amounts and reportable information: where a reportable contractual relationship for transactions has not been terminated, an RCASP must still file an annual report even if no transaction amount arises under that contract during a particular year.

3. CARF Data and Systems Preparation for RCASPs

• Embed CARF Tax Due Diligence into User KYC Processes

A customer’s AML/KYC information serves under CARF as a basis for assessing the reasonableness of a tax self-certification and therefore forms an important foundation for an RCASP’s due diligence procedures. In performing AML/KYC obligations, an RCASP will generally already have collected an individual’s name, address and identity documents, as well as an Entity’s registration information, ownership structure and beneficial owners. This data does not need to be collected again. For reporting purposes, CARF additionally focuses on the jurisdiction of tax residence, TIN, whether relevant Entity Controlling Persons are Reportable Persons, and the validity of the tax self-certification. For ownership-structure and beneficial-owner information already collected through KYC, the RCASP must further determine whether those persons meet the definitions of “Controlling Person” and “Reportable Person.” Because KYC information and CARF data partially overlap, the practical relationship should be one of shared data but distinct determinations. In practice, businesses need to add a layer of CARF data requirements to their existing KYC framework rather than build an entirely separate customer system.

• Establish a Unified Fiat Currency Conversion and Valuation Mechanism

When transaction information is consolidated and reported, the Fiat Currency used affects transaction-amount conversion, fair-market-value assessment and transaction classification. Local reporting requirements can therefore have a significant impact on system design for a global RCASP. At a minimum, an RCASP should retain the original transaction currency, transaction amount, exchange rate at the time of the transaction, converted reporting amount and reporting currency, and should apply a consistent and reasonable conversion and valuation methodology rather than retaining only the converted result. Even if a jurisdiction later changes its policy to require reporting in a specified local currency, the RCASP can then generate a compliant report from the underlying transaction data.

• Build a Localized CARF Rules Framework

Although the OECD CARF can serve as a unified baseline data standard, the local implementation differences discussed in this article show that the final reporting logic remains jurisdiction-specific. An RCASP needs to identify the jurisdictions in which it incurs and must discharge CARF compliance obligations, and confirm whether the reporting scope includes domestic tax residents, which jurisdictions are included on the local list of Reportable Jurisdictions, whether optional fields such as an individual user’s place of birth must be submitted, and whether a nil return is required when there is no reportable information. Local policy differences are also reflected in the form of Tax Identification Numbers used for user reporting. The final reporting fields must therefore be determined by reference to the domestic legislation and technical specifications applicable in the jurisdictions of both the RCASP and the user; these differences cannot be addressed solely through one uniform set of rules.

Conclusion

The contents of an annual CARF report depend on a series of preliminary determinations. RCASPs therefore cannot wait until immediately before the filing deadline to begin preparing; CARF compliance needs to be embedded throughout business processes, including customer management, KYC procedures and transaction systems. CARF is increasingly moving into the stage of domestic legislation and implementation across jurisdictions, and some divergence from the unified standard developed by the OECD is therefore likely to continue. For crypto-asset service providers operating across borders, the same set of user and transaction data may need to be configured differently for reporting under the domestic rules of each relevant jurisdiction. Whether localized rules and system data can be mapped in advance will directly affect whether subsequent CARF reporting can be implemented accurately and reliably.