Author: FinTax
Foreword
In our previous CARF series articles, we discussed and analyzed 'who needs to report' and 'where to report' under the CARF framework. The former focuses on identifying Reporting Crypto-Asset Service Providers (RCASPs), while the latter determines the jurisdictions where RCASPs are obligated to perform due diligence and reporting duties through the Reporting Nexus rules. After identifying the reporting entities and jurisdictions, a more concrete question arises for the implementation of CARF obligations—what information must RCASPs declare to the competent authorities?
The CARF reporting requirements mandate that RCASPs, based on due diligence procedures, identify reportable users and relevant controlling persons, classify and aggregate their relevant crypto-asset transactions according to prescribed methods. The final report fields encompass three parts: RCASP information, user information, and transaction information.
The OECD provides an international unified standard, but each jurisdiction needs to implement it locally through its own laws and technical specifications. Therefore, understanding 'what to report' under CARF requires not only returning to the OECD rules themselves but also further examining how local implementation rules modify the final reporting content.
This article outlines the basic framework of CARF reportable information, key differences in local implementation, and the preparations RCASPs can make at the data and system levels, aiming to provide practical reference.
I. Reportable Information Under the OECD CARF Rules
(1) What Constitutes a "Relevant Crypto-Asset" Within the CARF Scope
Asset classification is the foundation of transaction reporting. According to CARF definitional terms, the term "crypto-asset" refers to digital representations of value that rely on distributed ledger or similar technology for validation and security. "Relevant Crypto-Assets" in principle cover all assets meeting the crypto-asset definition, but exclude:
- 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 assessment is typically straightforward for mainstream assets like BTC and ETH, whereas stablecoins, NFTs, tokenized securities, and some utility tokens require further analysis.
Figure 1: Schematic Diagram of CARF and CRS Scope Adjustments
(2) What Specifically Does CARF Report? Three Categories of Information: RCASP, User, and Transaction
Reportable information is divided into three main 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). Together, they constitute the complete CARF report content.
RCASP Information
The name, address, and identification number* of the Reporting Crypto-Asset Service Provider.
* The identification number shall be the Taxpayer Identification Number (TIN); if there is no TIN, the company registration code or Global Legal Entity Identifier (LEI) shall be used. If no identification number is assigned to the RCASP, only its name and address need to be reported.
User Information
- For individual users: name, address, jurisdiction(s) of residence, Taxpayer Identification Number (TIN)*, date of birth, place of birth*;
- For entity users: name, address, jurisdiction(s) of residence, and Taxpayer Identification Number (TIN); for reportable controlling persons* of entities identified through due diligence procedures, also include the controlling person's name, address, jurisdiction(s) of residence, Taxpayer Identification Number (TIN), date of birth and place of birth, and the capacity in which the person is a controlling person.
* Information on the place of birth for individual users need not be reported unless otherwise provided by the law of the RCASP's jurisdiction.
* The Taxpayer Identification Number (TIN) refers to the number assigned to the taxpayer by the tax residence jurisdiction(s) of the user or entity controlling person, not the number issued by the platform's jurisdiction, the place of transaction, or the source of income jurisdiction.
If the same user is determined to have multiple tax residencies, the report must reflect each tax residence jurisdiction of that user and the corresponding TIN for each, without selective reporting.
* The due diligence and information reporting for entity users may further penetrate to controlling persons. CARF requires RCASPs to first identify an entity's controlling persons and then determine whether those controlling persons are Reportable Persons. Entity controlling persons included in the report must meet dual criteria of tax residence status and control rights—they must not only be tax residents of a reportable jurisdiction but also exercise control over the entity. The core criterion is "controlling ownership interest"; holding a certain percentage or more of shares, serving as a senior managing official, or acting as a settlor, trustee, or beneficiary of a trust, etc., may meet this standard.
Transaction Information
For each type of relevant crypto-asset as defined under CARF*, report:
- The full name of the relevant crypto-asset type;
- Acquisition and disposal of relevant crypto-assets for fiat currency: total amount paid/received*, total number of units, and number of relevant transactions;
- Acquisition and disposal of relevant crypto-assets in exchange for other relevant crypto-assets: total fair market value*, total number of units, and number of relevant transactions;
- Reportable retail payment transactions*: total fair market value, total number of units, and number of transactions;
- Transfers of other relevant crypto-assets to or from a reportable user: transfers not falling under the above types, broken down by transfer type (e.g., airdrops, staking rewards, loan payments, exchanges for goods or services), specifying total fair market value, total number of units, and number of relevant transactions;
- 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 and is reported in the fiat currency used for the transaction. If multiple fiat currencies are involved, report in a single fiat currency, consistently converting at each relevant transaction occurrence. 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 of the transaction, and transaction fees should be deducted; it must be determined and reported in a single fiat currency, consistently valued at each transaction occurrence. Regarding valuation methods, RCASPs must primarily rely on trading pairs they maintain themselves; in the absence of applicable internal trading pair prices, alternative valuation methods such as internal accounting book value, values provided by third-party companies or websites, the RCASP's latest valuation or reasonable estimate of that asset (in order), etc., may be used.
* Reportable retail payment transactions require meeting a $50,000 threshold, but payment transfers below this amount are not exempt from reporting; they should be aggregated under "Transfers of other relevant crypto-assets to or from a reportable user" or "Transfers to unknown external wallets."
* If a user transfers crypto-assets to their private wallet or to an account operated by another platform, rendering the RCASP unable to know the complete transaction situation, the RCASP must also report it as a transfer to an unknown external wallet.
* The rules require classification and aggregation of all transactions. If the relevant crypto-asset is non-fungible and different variants of that relevant crypto-asset have different values in fixed units, each unit shall be treated as a separate type of relevant crypto-asset.
II. Implementation Differences: From OECD Standards to Local Reporting Requirements
The OECD-published CARF rules and their commentary provide a unified international standard, but they are ultimately transposed into local law by individual jurisdictions. Core rules such as the definition of relevant crypto-assets, transaction category classification, and reporting fields are highly aligned with OECD standards. However, regarding certain implementation details, local policies may exhibit significant variations.
(1) Whether Domestic Users Are Included in Reporting
The original OECD CARF framework primarily serves cross-border automatic exchange of tax information. "Reportable Jurisdiction" refers to jurisdictions for which a CARF exchange agreement exists and which are included in the implementing jurisdiction's published list. Reporting centers on tax residents of other reportable jurisdictions. Some jurisdictions have added domestic reporting requirements, meaning RCASPs need to simultaneously report information on their domestic tax resident users to the local tax authority.
For example, the UK, through the Finance Act 2026, established the reporting obligation for UK RCASPs regarding UK tax resident users and relevant controlling persons. Current HMRC guidance explicitly requires RCASPs to collect information on all users and report data for UK tax residents as well as tax residents of other CARF participating jurisdictions. The New Zealand Inland Revenue's published list of CARF reportable jurisdictions includes New Zealand itself, thus bringing New Zealand tax residents within the scope of domestic reporting. Its official guidance further clarifies that when an RCASP has both New Zealand resident and non-resident users, both individuals' identity information and relevant transaction data should be submitted to the Inland Revenue. Resident data is used for domestic tax administration, while non-resident data is exchanged with their country of residence according to CARF arrangements.
Meanwhile, jurisdictions such as Japan and Singapore have not included their own tax residents within the CARF reporting scope, aligning their approach more closely with the original OECD framework. Even so, RCASPs must still perform due diligence procedures on all users, including domestic ones, to identify which users fall within the reportable scope. The absence of a domestic reporting requirement does not exempt them from this obligation.
Therefore, the scope of due diligence is not equivalent to the final reporting scope, and the international exchange scope does not necessarily equal the reporting scope required by the local tax authority.
(2) Single Fiat Currency Conversion and Valuation Methods
Both transaction amounts and fair market values ultimately need to be converted into fiat currency for reporting according to CARF rules. Whether jurisdictions further specify the reporting currency directly affects RCASPs' data conversion and reporting systems.
For instance, the South African Revenue Service's (SARS) CARF regulations (Notice 6887) explicitly state that transaction amounts and fair market value must be determined and reported in South African Rand (ZAR). The revenue authority's FAQ addresses the compliance burdens and practical challenges faced by high-volume platforms, elaborating in more detail on the requirements for consistent conversion and valuation methods. It clarifies that CARF does not require real-time currency conversion by RCASPs, does not restrict specific exchange rate sources or pricing methods per transaction, but allows reasonable approaches such as batch processing, applying end-of-day exchange rates, or appropriate averages. High transaction volumes, asset price volatility, and differences in market data sources can be balanced with the operational flexibility of the RCASP.
(3) Whether Monetary Thresholds Are Converted to Local Currency Standards
Under OECD rules, retail payment transactions reaching the $50,000 threshold are aggregated as a separate reportable retail payment transaction category; otherwise, they are grouped into other transaction types.
During local law implementation, jurisdictions may convert this into a local currency standard. For example, Japan sets the reportable retail payment transaction threshold at 5 million Japanese Yen (approximately $31,273), Brazil uses the Real equivalent of $50,000, the EU DAC8 uses the Euro equivalent of $50,000, while other jurisdictions retain the original USD standard.
The localization of the reportable retail payment transaction amount threshold can take several forms, including setting a fixed local currency amount or converting the USD standard into its equivalent local currency amount. This distinction affects how RCASPs classify and aggregate relevant crypto-asset transactions in practice. The same transaction may be classified into different CARF transaction categories depending on the applicable jurisdiction—being a retail payment transaction in Jurisdiction A but classified as another type of transfer transaction in Jurisdiction B.
(4) Detail Differences in Specific Reporting Fields
The OECD rules uniformly define core reporting fields for individual users, entity users, and their controlling persons but also leave some room for local law variations.
The place of birth for individual users generally need not be reported unless otherwise provided by the law of the RCASP's jurisdiction. For Taxpayer Identification Numbers (TINs), if the tax residence jurisdiction(s) of the reportable user or relevant controlling person does not issue a TIN, or if local law does not require its collection, then the TIN need not be reported. In this regard, Singapore's IRAS explicitly allows providing a corresponding reason code per its CARF XML rules in such cases.
Furthermore, even where TIN submission is required, the format of the number varies across jurisdictions. In the UK, the National Insurance Number (NINO) for individuals or relevant entity controlling persons, the Company Registration Number (CRN) for UK companies, and the Unique Taxpayer Reference (UTR) for partnerships and trusts serve as their respective Taxpayer Identification Numbers.
(5) Whether to File a Report When There Is No Reportable Information
Whether an RCASP still needs to file a report with the tax authority if there is no information on reportable users or relevant transactions for a reporting year also depends on the regulations of its jurisdiction.
The UK clearly adopts a 'no data, no filing' model. Singapore generally requires submitting a nil return—completing only the RCASP information section without user and transaction data. Additionally, Japan's National Tax Agency CARF FAQ clarifies the relationship between transaction amounts and reportable information. If there exists an ongoing reportable contractual relationship, even if no transaction amounts related to that contract occurred in a particular year, the RCASP is still required to file an annual report.
III. How RCASPs Can Prepare Data and Systems for CARF
(1) Integrating CARF Tax Due Diligence into User KYC Processes
Customer AML/KYC documentation serves the function of validating the reasonableness of tax self-certifications under CARF, forming an important basis for RCASPs to fulfill due diligence obligations. When fulfilling AML/KYC obligations, RCASPs typically already collect data such as an individual's name, address, identification proof, and an entity's registration information, ownership structure, and beneficial owners. This data does not need to be recollected. For reporting needs, CARF additionally focuses on tax residence jurisdiction(s), TIN, whether relevant entity controlling persons are reportable persons, and the validity of tax self-certifications. For ownership structure and beneficiary information already collected during KYC, RCASPs need to further determine whether these individuals meet the definitions of "entity controlling person" and "reportable person." Due to the partial overlap between KYC data and CARF data, the relationship should be one of shared data with distinct assessments. From a practical perspective, businesses need to add a layer of CARF data requirements on top of their existing KYC framework, rather than establishing a completely separate customer system.
(2) Establishing a Unified Fiat Currency Conversion and Valuation Mechanism
In the integration and reporting of transaction information, the fiat unit used affects processes like transaction amount conversion, fair market value assessment, and transaction type classification. Related localization requirements significantly impact the system design of global RCASPs. RCASPs should at minimum retain the original transaction currency, transaction amount, exchange rate at the time of transaction, the converted reporting amount and currency, as well as the valuation time and method. It is not advisable to store only the converted results. This ensures that even if a jurisdiction updates its policy to require reporting in a specified local currency, the RCASP can still generate compliant reports from the underlying transaction data.
(3) Perfecting the CARF Localization Rule Framework
Although OECD CARF can serve as a unified foundational data standard, the local implementation differences mentioned in this article demonstrate that the final reporting logic is still grounded in specific jurisdictions. RCASPs need to identify in which jurisdictions they generate and fulfill CARF compliance obligations, and confirm issues such as whether the reporting scope includes domestic tax residents, which jurisdictions are included in the local published list of reportable jurisdictions, whether optional fields like an individual user's place of birth need to be submitted, and whether a nil return is required when there is no reportable information. Local policy differences are also reflected in the format of Taxpayer Identification Numbers for user information reporting. The final reporting fields need to be determined by combining the local legislation and technical specifications of both the RCASP's and the user's jurisdictions. Such differences cannot be handled relying solely on a single set of unified rules.
Conclusion
The content of a CARF annual report is built upon a series of prior determinations. This means RCASPs cannot start preparations only shortly before the filing deadline but need to integrate CARF compliance into business operation chains such as customer management, KYC processes, and transaction systems. Global CARF is gradually entering the phase of local legislation and enforcement, and the unified standards constructed by the OECD are inevitably subject to further divergence. For cross-border crypto service providers, the same set of user and transaction data often needs to be configured separately for actual reporting according to the domestic rules of the jurisdictions involved. The ability to complete the collation of localization rules and system data in advance will directly impact the accuracy and stability of subsequent CARF filings.
