CARF Reporting Requirements and Local Implementation Differences Explained

Written by: FinTax

In previous articles in the CARF series, we discussed and analyzed the questions of “who must report” and “where to report” under the CARF framework. The former addresses the identification of Reporting Crypto-Asset Service Providers (RCASPs), while the latter determines, through the Reporting Nexus rules, in which jurisdictions RCASPs are obligated to perform due diligence and reporting. Having established the reporting entities and jurisdictions, a more specific question arises regarding the implementation of CARF obligations: What information must RCASPs report to the competent authorities?

The CARF report requires RCASPs to identify reportable users and their relevant controlling persons based on due diligence procedures, classify and aggregate transactions related to their crypto-assets according to prescribed methods, and ultimately produce a report comprising three sections: RCASP information, user information, and transaction information.

The OECD provides an international standard, but each jurisdiction must implement it through local laws and technical regulations. Therefore, to understand what CARF requires reporting, it is necessary not only to refer to the OECD rules themselves but also to examine how local implementation rules may alter the final reporting content.

This article outlines the basic framework of information reportable under CARF, key differences in local implementation, and the preparations RCASPs can make at the data and system levels to provide practical guidance.

(1) What are "relevant crypto assets" within the scope of CARF?

Asset classification is the foundation of transaction reporting. According to the definitions under CARF, the term "crypto-asset" refers to digital value that relies on distributed ledger technology or similar technologies for verification and security. "Relevant Crypto-Asset"原则上 encompasses all assets that meet the definition of a crypto-asset, but excludes:

• Central Bank Digital Currency (CBDC);
• Specified Electronic Money Product (SEMP);
• The cryptocurrency asset service provider has adequately identified cryptocurrency assets that cannot be used for payment or investment purposes.

Judgments for major assets such as BTC and ETH are typically straightforward, while stablecoins, NFTs, tokenized securities, and certain utility tokens require further analysis.

Figure 1: Schematic illustration of the adjustment scope for CARF and CRS

(2) What specific information does CARF report? Three categories: RCASP, users, and transactions.

The reportable information is divided into three categories: information about the reporting crypto-asset service provider (RCASP information), information about reportable users or reportable persons (user information), and information about relevant crypto-asset transactions (transaction information), which together constitute the complete CARF report.

RCASP Information

Report the name, address, and identification number of the cryptocurrency service provider *.

The identification number shall be the Taxpayer Identification Number (TIN); if no TIN is available, use the company registration code or Legal Entity Identifier (LEI). If no identification number has been assigned to the RCASP, report only its name and address.

User Information

• Individual user’s name, address, residence, taxpayer identification number (TIN)*, date of birth, place of birth*;
• The name, address, residence, and taxpayer identification number (TIN) of the entity; for reportable controlling persons identified through due diligence procedures, also include the controlling person’s name, address, residence, taxpayer identification number (TIN), date and place of birth, and their role as a controller.

The birthplace information of individual users does not need to be reported unless otherwise required by the laws of the country where RCASP is located.

The Taxpayer Identification Number (TIN) is the identification number assigned to the user or entity controller by the tax jurisdiction of their residence, not by the jurisdiction where the platform is located, where the transaction occurred, or where the income was sourced.

If a user is determined to have multiple tax residences, the report must reflect each tax jurisdiction in which the user resides, along with the corresponding TINs; selective reporting is not permitted.

Due diligence and information reporting for entity users may extend further to the controllers. Under CARF, RCASPs must first identify the entity’s controllers and then determine whether such controllers qualify as reportable persons. Controllers subject to reporting must meet dual criteria: they must be tax residents of a reportable jurisdiction and exercise control over the entity—the key criterion being “controlling ownership interest.” This standard may be met by holding a certain percentage or more of shares, serving as a senior manager, or acting as a settlor, trustee, or beneficiary of a trust.

Transaction Information

For each relevant type of crypto asset as defined by CARF, the following must be reported:

1. Full names of related cryptocurrency asset types;
2. Acquire and dispose of related crypto assets using fiat currency: total amount paid/received *, total units, and number of related transactions;
3. Acquire and dispose of relevant crypto assets in exchange for other relevant crypto assets: total fair market value *, total number of units, number of related transactions;
4. Reportable retail payment transactions *: total fair market value, total units, number of transactions;
5. Transfers to or from a reporting user of other relevant crypto assets: For transfers not of the types above, categorize by transfer type (e.g., airdrops, staking rewards, loan payments, goods or services exchanged), and specify the total fair market value, total number of units, and number of related transactions;
6. Transfer to an unknown external wallet: total fair market value, total number of units.

The total amount paid or received refers to the net amount after deducting transaction fees, reported in the fiat currency used at the time of the transaction. If multiple fiat currencies are involved, the amount is reported in a single fiat currency, with conversions performed consistently each time a relevant transaction occurs—for example, using the spot exchange rate at the time of the transaction.

The valuation point for the total fair market value is at the time of the transaction and must deduct transaction fees; it must be determined and reported in a single fiat currency and consistently valued at the time of each transaction. Regarding valuation methods, RCASP must prioritize its own maintained trading pairs; in the absence of applicable internal trading pair prices, alternative valuation methods may be used in the following order: internal accounting book value, values provided by third-party companies or websites, the most recent valuation by RCASP for the asset, or a reasonable estimate.

Retail payment transactions that constitute reportable transactions must meet a threshold of $50,000; however, payments below this amount are not exempt from reporting and should be considered for aggregation under “transfers of other relevant crypto assets to or from reportable users” or “transfers to unknown external wallets.”

If a user transfers cryptocurrency assets to their private wallet or to an account operated by another platform, thereby preventing the RCASP from knowing the full transaction details, the RCASP must also report this as a transfer to an unknown external wallet.

The rules require aggregating all transactions by category. If the relevant cryptocurrency is non-fungible and different variants of that cryptocurrency have different values per fixed unit, each unit shall be considered a separate type of relevant cryptocurrency.

The OECD's CARF rules and their commentary provide a unified international standard, but each jurisdiction ultimately implements them through local legislation. Core elements such as the definition of relevant crypto-assets, classification of transactions, and reporting fields closely align with OECD standards; however, there may be notable differences in certain implementation details under local policies.

(1) Does the report cover domestic users?

The original OECD CARF framework was primarily designed for automatic exchange of tax information across borders. A "Reportable Jurisdiction" refers to a jurisdiction that has established a CARF information exchange arrangement and is listed on the public list of implementing jurisdictions. Reporting focuses on tax residents of other reportable jurisdictions. Some jurisdictions have added local reporting requirements, meaning that RCASPs must also report information on tax residents of their own country to the local tax authority.

For example, the UK has established reporting obligations for UK RCASPs targeting UK tax residents and their relevant controlling persons through the Finance Act 2026, and current HMRC guidance explicitly requires RCASPs to collect information on all users and report data on UK tax residents as well as tax residents of other CARF-participating jurisdictions. New Zealand has been listed in the Inland Revenue Department’s published list of CARF-reporting jurisdictions, thereby bringing New Zealand tax residents within the scope of local reporting. Official guidance further clarifies that when a RCASP has both New Zealand resident and non-resident users, the identity information and related transaction data of both parties must be submitted to the tax authority—resident data for domestic tax administration and non-resident data exchanged with the tax authorities of their respective countries of residence under CARF arrangements.

Meanwhile, jurisdictions such as Japan and Singapore have not included their own tax residents within the scope of CARF reporting, aligning with the original OECD framework. Nevertheless, RCASP is still required to perform due diligence procedures on all users, including domestic users, to identify which users fall within the reportable scope; the absence of local reporting requirements does not exempt this obligation.

Therefore, the scope of due diligence does not equate to the final reporting scope, and the international exchange scope does not necessarily match the reporting scope required by local tax authorities.

(2) Conversion and Valuation Method for a Single Fiat Currency

The transaction amount and fair market value must ultimately be converted into fiat currency for reporting in accordance with CARF rules. Whether each jurisdiction further specifies the reporting currency will directly impact the data conversion and reporting systems of RCASP.

For example, the South African Revenue Service’s CARF regulations (Notice 6887) explicitly require transaction amounts and fair market values to be determined and reported in South African Rand. The tax authority’s FAQ responses address the compliance burdens and practical challenges that high-volume platforms may face, providing further clarification on the requirement for consistent and uniform conversion and valuation methods. It states that CARF does not require RCASPs to perform real-time currency conversions, nor does it restrict specific exchange rate sources or pricing methods for individual transactions; instead, it permits reasonable approaches such as batch processing, using the exchange rate at the end of the day, or applying appropriate averages. The challenges posed by high trading volumes, volatile asset prices, and differences in market data sources can be mitigated through the operational flexibility afforded to RCASPs.

(3) Is the amount threshold converted to the local currency standard?

Under OECD rules, retail payment transactions are aggregated as reportable retail payment transactions only when they reach the $50,000 threshold; otherwise, they are classified as other types of transactions.

Different jurisdictions may convert the thresholds into their local currency standards during local law implementation. For example, Japan sets the reporting threshold for retail payment transactions at 5 million JPY (approximately $31,273 USD), Brazil adopts the Brazilian real equivalent of $50,000 USD, the EU’s DAC8 uses $50,000 USD or its equivalent in other currencies, and some other jurisdictions retain the original USD standard.

There are several forms of localization for reporting thresholds on retail payment transaction amounts, including setting a fixed amount in local currency or converting the USD standard into an equivalent amount in local currency; this distinction will impact how RCASP categorizes and aggregates relevant crypto asset transactions in practice. The same transaction may be classified into different CARF transaction categories depending on the applicable jurisdiction—classified as a retail payment transaction in Jurisdiction A, but as another type of transfer transaction in Jurisdiction B.

(4) Detailed differences in specific report fields

The OECD rules standardize core reporting fields for individual users, entity users, and their controllers, while still allowing for local legal flexibility.

The place of birth for individual users is generally not required to be reported, except where otherwise mandated by the laws of the jurisdiction in which the RCASP is located. For Tax Identification Numbers (TINs), a TIN need not be reported if the tax residence jurisdiction of the reportable person or controlling person does not issue TINs, or if local law does not require their collection. In such cases, Singapore’s IRAS explicitly permits the use of the corresponding reason code under its CARF XML rules.

Furthermore, even when a TIN is required, the format of the number varies across jurisdictions. In the UK, the National Insurance Number (NINO) for individual users or relevant controlling persons, the Company Registration Number (CRN) for UK companies, and the Unique Taxpayer Reference (UTR) for partnerships and trusts serve as their respective tax identification numbers.

(5) Is reporting still required if there is no information to report?

Whether an RCASP is still required to file a report with the tax authority in a reporting year during which there is no information regarding reportable users or related transactions depends on the regulations of its jurisdiction.

The UK explicitly adopts a no-data, no-filing model. Singapore原则上 requires the submission of a nil return, meaning only RCASP information needs to be provided, without user or transaction data. Additionally, Japan’s National Tax Agency’s CARF FAQ clarifies the relationship between transaction amounts and reportable information: if there exists an ongoing reportable transaction contract, an annual RCASP report is still required even if no transaction amount was generated under that contract during a given fiscal year.

(1) CARF Tax Due Diligence Integrated into User KYC Process

The customer's AML/KYC documentation serves the function of validating the reasonableness of tax self-certifications under CARF, forming a critical foundation for RCASP’s due diligence obligations. When fulfilling AML/KYC requirements, RCASP typically already possesses individuals’ names, addresses, identification documents, as well as entities’ registration details, ownership structures, and beneficial owners—data that need not be re-collected. For reporting purposes, CARF also focuses on tax residence jurisdictions, TINs, whether controlling persons of relevant entities qualify as reportable persons, and the validity of tax self-certifications. Based on the ownership structure and beneficial owner information collected during KYC, RCASP must further determine whether these individuals meet the definitions of “controlling persons” and “reportable persons.” Due to partial overlap between KYC data and CARF requirements, the two should be treated as sharing data while applying distinct assessments. From a practical standpoint, businesses should augment their existing KYC framework with additional CARF data requirements rather than establishing a completely separate customer system.

(2) Establish a unified fiat currency conversion and valuation mechanism

In the integration and reporting of transaction information, the choice of fiat currency affects processes such as transaction amount conversion, fair market value assessment, and transaction classification. These localization requirements significantly impact the system design of global RCASPs. An RCASP should retain at least the original transaction currency, transaction amount, exchange rate at the time of transaction, converted reporting amount and currency, valuation time, and valuation method, rather than storing only the converted results. Even if a jurisdiction updates its policy requiring reports in a specified local currency, the RCASP should still be able to generate compliant reports from the underlying transaction data.

(3) Improve the CARF localization rule system

Although the OECD CARF can serve as a unified foundational data standard, the local implementation differences mentioned in this article demonstrate that the final reporting logic remains grounded in specific jurisdictions. RCASPs must identify in which jurisdiction they generate and fulfill their CARF compliance obligations, and confirm whether the reporting scope includes domestic tax residents, which reportable jurisdictions are published locally, whether optional fields such as individual users’ places of birth must be submitted, and whether zero reporting is required when no reportable information exists. Local policy differences also manifest in the format of tax identification numbers. The final reported fields must be determined by combining RCASP requirements with local legislation and technical specifications of the user’s jurisdiction; such variations cannot be addressed solely through a single set of uniform rules.

The content of a CARF annual report is built upon a series of preliminary assumptions, meaning that RCASPs cannot wait until the filing deadline to begin preparation; instead, they must integrate CARF compliance into their business operations, including customer management, KYC processes, and transaction systems. Global CARF is gradually entering the phase of local legislation and enforcement, and the unified standard established by the OECD is inevitably continuing to diverge. For cross-border crypto service providers, the same set of user and transaction data must be configured separately according to the domestic rules of each relevant jurisdiction when filing. Whether they can complete the梳理 (organization and alignment) of local regulatory requirements and system data in advance will directly impact the accuracy and stability of subsequent CARF filings.