This article outlines the basic framework of the information that CARF should report, the main differences in local implementation, and the preparations that RCASP can undertake at the data and system level.

Author: FinTax

Introduction

In the previous CARF series of articles, we discussed and analyzed "who needs to report" and "where to report" under the CARF framework. The former pertains to the identification of Reporting Crypto-Asset Service Providers (RCASP), while the latter determines the jurisdictions in which RCASP have due diligence and reporting obligations through Reporting Nexus rules. After identifying the reporting entities and jurisdictions, a more specific question arises regarding the CARF obligations—what information should RCASP report to the competent authorities?

The CARF reporting requirements mandate RCASP to identify reportable users and related controllers based on due diligence procedures, and categorize the transactions of their related crypto-assets as prescribed, ultimately resulting in report fields encompassing RCASP information, user information, and transaction information.

The OECD provides an internationally unified standard, but each jurisdiction must implement this through local laws and technical specifications. Therefore, understanding "what to report" under CARF not only requires returning to the OECD rules themselves but also further attention to how local implementation rules may change the final reporting content.

This article outlines the basic framework of the information that CARF should report, the main differences in local implementation, and the preparations that RCASP can undertake at the data and system level, aiming to provide practical references.

1. Information to be reported under OECD CARF rules

(1) What are "Relevant Crypto-Assets" within the scope of CARF?

Asset classification is the foundation of transaction reporting. According to CARF's definition, the term "crypto-assets" refers to digital value that relies on distributed ledger or similar technologies for verification and security. "Relevant Crypto-Assets" generally encompass all assets that meet the definition of crypto-assets but exclude:

• Central Bank Digital Currencies (CBDC);
• Specific Electronic Money Products (SEMP);
• Crypto-assets that have been clearly identified by the reporting crypto-asset service provider as not being usable for payment or investment purposes.

Judgments of mainstream assets such as BTC and ETH are typically straightforward, while stablecoins, NFTs, tokenized securities, and certain functional tokens require further analysis.

Figure 1: Schematic Diagram of CARF and CRS Adjustment Scope

(2) What should CARF report specifically? Information on RCASP, users, and transactions

The information to be reported is divided into three categories, including information about the reporting crypto-asset service provider (RCASP information), reportable users or reportable persons (user information), and information on related crypto-asset transactions (transaction information), constituting the complete CARF report content.

RCASP Information

Name, address, and identification number of the reporting crypto-asset service provider *.

* The identification number uses the Taxpayer Identification Number (TIN); if there is no TIN, the company registration code or Global Legal Entity Identifier (LEI) should be used. If the RCASP is not assigned an identification number, only its name and address should be reported.

User Information

• Name, address, residence, Taxpayer Identification Number (TIN) *, date of birth, place of birth * of individual users;
• Name, address, residence, and Taxpayer Identification Number (TIN) of entity users; for reportable entity controllers identified through due diligence procedures *, also include the name, address, residence, Taxpayer Identification Number (TIN), date of birth and place of birth, as well as the role of the controller.

* The place of birth information for individual users does not need to be reported unless otherwise required by the laws of the RCASP's jurisdiction.

* The Taxpayer Identification Number (TIN) refers to the identification number assigned to users or entity controllers by the tax-resident jurisdiction, and not a number issued by the jurisdiction where the platform is located, the transaction occurs, or the source of income.

If the same user is identified as having multiple tax residences, the report should reflect every tax-resident jurisdiction the user belongs to, along with the corresponding TINs, without selective reporting.

* Due diligence and information reporting for entity users may further penetrate to their controllers. CARF requires RCASP to first identify the controllers of the entity, then determine whether the related controllers fall within the scope of reportable persons. Entity controllers included in the reporting scope must meet the dual criteria of tax residence and control, i.e., they must be tax residents in the reportable jurisdiction and exert control over the entity—the core judgment criterion is "controlling ownership interest," holding shares above a certain proportion, serving as senior management, or acting as a trust's settlor, trustee, or beneficiary, may all meet this standard.

Transaction Information

For each type of relevant crypto-asset defined under CARF *, the following should be reported:

1. The full name of the relevant crypto-asset type;
2. For acquisition and disposal of relevant crypto-assets in fiat currencies: the total amount paid/received *, the total number of units, and the related transaction count;
3. For acquiring and disposing relevant crypto-assets in exchange for other relevant crypto-assets: total fair market value *, total number of units, related transaction count;
4. For reportable retail payment transactions *: total fair market value, total number of units, transaction count;
5. For transfers of other relevant crypto-assets to or from reportable users: transfer transactions that do not belong to the above categories, broken down by transfer type (e.g., airdrops, staking rewards, loan repayments, exchange of goods or services), specifying total fair market value, total number of units, and related transaction count;
6. Transfers to unknown external wallets: total fair market value, total number of units.

* The total amount paid/received refers to the net amount after deducting transaction fees, reported in the legal currency used at the time of the transaction. If multiple fiat currencies are involved, it should be reported in a single legal currency, and conversion should be done consistently at the time of each transaction. For example, consistently using the spot exchange rate at the time of the transaction for currency conversion.

* The valuation point for total fair market value is at the time the transaction occurs and should exclude transaction fees; it must be determined and reported in a single legal currency and valued continuously in a consistent manner at the time of each transaction. Regarding valuation methods, RCASP should prioritize relying on its own maintained trading pairs; when there is no applicable internal trading pair price, alternative valuation methods such as associated accounting book values, values provided by third-party companies or websites, RCASP's latest valuation of that asset or reasonable estimates (in order) may be used.

* To constitute a reportable retail payment transaction, it must reach a threshold of $50,000, but payments below this amount are not exempt from reporting and should be considered in the sections "transfers of other relevant crypto-assets to or from reportable users" and "transfers to unknown external wallets."

* If a user transfers crypto-assets to their private wallet or to an account operated by another platform, making it impossible for the RCASP to know their complete transaction situation, the RCASP must also report it as a transfer to an unknown external wallet.

* Rules require all transactions to be classified summarily. If the relevant crypto-assets are not interchangeable, and there is a variation in value across different variants of that relevant crypto-asset within fixed units, each unit should be treated as a separate type of relevant crypto-asset.

2. Implementation Differences: From OECD Standards to Local Reporting Requirements

The CARF rules and its commentary released by the OECD provide a unified international standard, but they are ultimately transformed into local laws for implementation by various jurisdictions. Core rules such as the definition of relevant crypto-assets, categorization of transaction types, and reporting fields closely align with OECD standards, but local policies may exhibit significant differences in certain implementation details.

(1) Whether the reporting subjects include domestic users

The original OECD CARF framework primarily serves cross-border automatic exchanges of tax information. "Reportable Jurisdiction" refers to jurisdictions that have existing CARF information exchange agreements and are listed publicly by the implementing jurisdiction, focusing reporting on tax residents of other reportable jurisdictions. Some jurisdictions have added local reporting requirements, meaning that RCASP must also report information on domestic tax-resident users to their local tax authorities.

For example, the UK established the reporting obligation of UK RCASP to UK tax-resident users and related controllers through the Finance Act 2026, and the current HMRC guidelines clearly require RCASP to collect all user information and report data for UK tax residents and tax residents of other CARF participating jurisdictions. The list of reportable jurisdictions released by the New Zealand tax authority explicitly includes its own country, thus New Zealand tax residents also fall within the scope of local reporting. It further clarifies in its official guidelines that when an RCASP has both New Zealand residents and non-residents as users, the identification information and related transaction data for both should be submitted to the tax authorities, with resident data used for domestic tax management and non-resident data exchanged with the tax authorities in their country of residence according to CARF arrangements.

Meanwhile, jurisdictions such as Japan and Singapore do not include their domestic tax residents within the CARF reporting scope, processing similar to the original OECD framework. Nonetheless, RCASP still needs to conduct due diligence procedures for all users, including domestic users, to identify which users fall within the scope of reportable persons; the absence of local reporting requirements does not exempt them from this obligation.

Therefore, the due diligence scope does not equal the final reporting scope, and the international exchange scope may not necessarily equal the reporting scope required by local tax authorities.

(2) Conversion to a single legal currency and valuation methods

Transaction amounts and fair market values ultimately need to be converted to legal currency according to CARF rules for reporting. Whether jurisdictions specify reportable currencies further will directly affect RCASP's data conversion and reporting systems.

For instance, the South African Revenue Service's CARF regulation (Notice 6887) explicitly states that transaction amounts and fair market values must be determined and reported in South African Rand. The tax authority's FAQ addressed the compliance burdens and practical challenges that high transaction volume platforms may face, further elaborating on the requirements for maintaining consistency in conversion and valuation methods, stating that CARF does not require RCASP to perform real-time currency conversions, nor does it limit specific sources of exchange rates or pricing methods for each transaction. It allows for batch processing, use of the prevailing rate at the end of the day, or other reasonable averaging methods. Large transaction volumes, fluctuations in asset prices, and variances in market data sources can be balanced through the flexibility of RCASP's operations.

(3) Whether the monetary threshold is converted to local currency standards

According to OECD rules, retail payment transactions must reach a threshold of $50,000 to be aggregated as reportable retail payment transactions; otherwise, they are classified into other transaction types.

Jurisdictions may convert this into local currency standards during the implementation of local laws. For example, Japan establishes the reportable retail payment transaction threshold at 5 million yen (approximately $31,273), Brazil uses the equivalent amount in reais for $50,000, the EU DAC8 adopts $50,000 or an equivalent amount in other currencies, while some other jurisdictions retain the original dollar standard.

The localization of reportable retail payment transaction thresholds can take various forms, including setting a fixed amount in local currency or converting the dollar standard into an equivalent amount in local currency. This distinction will affect how RCASP classifies the types of related crypto-asset transactions and aggregates data in practice. The same transaction may be categorized differently across jurisdictions; in jurisdiction A it may constitute a retail payment transaction, while in jurisdiction B it could be classified as another type of transfer transaction.

(4) Specific details differences in reporting fields

OECD rules uniformly stipulate core reporting fields for individual users, entity users, and their controllers but also leave some space for local laws.

The place of birth for individual users does not generally need to be reported, unless otherwise specified by the laws of the jurisdiction of the RCASP. Regarding Taxpayer Identification Numbers (TIN), if the reportable user or related controller's tax-residence jurisdiction has not issued a TIN, or if local law does not require its collection, then reporting of TIN is not necessary. In this regard, Singapore's IRAS explicitly allows for such circumstances to provide corresponding reason codes according to their CARF XML rules.

Moreover, even where TIN submission is required, the format of the numbers can vary among jurisdictions. In the UK, the National Insurance Number (NINO) for individual users or related entity controllers, the Company Registration Number (CRN) for UK companies, and the UTR for partnerships and trusts are their corresponding Taxpayer Identification Numbers.

(5) Whether the absence of reportable information still requires reporting

If there is no reportable user or related transaction information in a reporting year, whether RCASP still needs to report to tax authorities also depends on the regulations of its jurisdiction.

The UK adopts a no data, no report model, while Singapore generally requires the submission of a nil return, meaning only RCASP information is filled out, without the need to report user and transaction data. Additionally, Japan's National Tax Agency CARF FAQ clarified the relationship between transaction amounts and reportable information, stating that if there exists an ongoing contractual relationship for reportable transactions, even if there are no transactions generated in that fiscal year related to that contract, RCASP is still required to do an annual report.

3. How RCASP can prepare data and systems for CARF

(1) Embedding CARF tax due diligence into user KYC processes

Clients' AML/KYC information plays a role in validating the reasonableness of tax self-certification within CARF, thus constituting an important basis for RCASP to fulfill due diligence obligations. When fulfilling AML/KYC obligations, RCASP typically already obtains personal names, addresses, identification documents for individuals, as well as registration information, ownership structure, and beneficial owners for entities; this data does not need to be collected anew. For reporting purposes, CARF also focuses on the individual's tax residency, TIN, whether the relevant entity controllers belong to reportable persons, and the validity of the tax self-certification, etc. For ownership structure and beneficiary information already collected in KYC, RCASP must further determine whether these individuals meet the definitions of "entity controller" and "reportable person." Since KYC data overlaps with CARF data partly, the two should have a common data-sharing relationship while maintaining distinct judgments. Practically, businesses need to add a layer of CARF data requirements on top of the existing KYC framework, rather than establishing an entirely separate customer system.

(2) Establishing a unified mechanism for currency conversion and valuation

In the integration and reporting of transaction information, the legal currency used may affect the conversion of transaction amounts, the fair market value assessment process, classification of transaction types, etc. The related localization requirements significantly impact the system design for global RCASPs. RCASP should at least retain the original trading currency, transaction amounts, exchange rates at the time of transaction, and the amounts and currencies reported after conversion, as well as valuation times and methods, and should not just store the converted results. Even if a jurisdiction updates its policy requirements for designated local currency reporting, RCASP can generate compliant reports from the underlying trading data.

(3) Improving the localized rule system for CARF

Although OECD CARF can serve as a unified foundational data standard, the local implementation differences mentioned in this article indicate that the final reporting logic rests on specific jurisdictions. RCASP needs to identify in which jurisdiction it generates and fulfills CARF compliance obligations, and verify whether the reporting scope includes domestic tax residents, which reportable jurisdictions are published locally, whether optional fields like the place of birth for individual users need to be submitted, and whether zero returns must be filed when there is no reportable information, among other issues. Local policy differences are also reflected in the format of the taxpayer identification numbers submitted for user information. The final report fields must be assessed in conjunction with the local legislative and technical specifications of both RCASP and the users’ jurisdictions, and such differences cannot solely rely on a unified set of rules for resolution.

Conclusion

The content of a CARF annual report is based on a series of preliminary judgments, meaning that RCASP cannot wait until the reporting deadline to begin preparation, but must integrate CARF compliance into customer management, KYC processes, and transaction systems within their business operations. Global CARF has gradually entered the stage of local legislation and enforcement, making the unified standards constructed by the OECD inevitably continue to diversify. For crypto service providers operating across borders, the same batch of user and transaction data requires separate configuration according to domestic rules of the jurisdictions involved; the ability to complete the localization of rules and system data in advance will directly impact whether subsequent CARF reporting can be accurately and stably implemented.