FinTax has published an article explaining a central compliance question under the Crypto-Asset Reporting Framework, or CARF: once a platform knows whether it is a Reporting Crypto-Asset Service Provider and where it has filing obligations, what exactly must it report?
The piece says CARF reporting sits on top of due diligence. An RCASP must identify reportable users and relevant controlling persons, classify their transactions involving relevant crypto-assets, and file a report that contains three broad categories of data: RCASP information, user information, and transaction information. The OECD provides the common international standard, but each jurisdiction still needs to implement it through local law and technical rules, which can change the final shape of the filing.
What must be reported under the OECD CARF standard
What counts as a relevant crypto-asset
Asset classification is the starting point for transaction reporting. Under CARF, a crypto-asset is a digital representation of value that relies on distributed ledger technology or similar technology for validation and security. In principle, a relevant crypto-asset includes all assets that fall within that definition, except for three categories: central bank digital currencies, or CBDCs; specified electronic money products, or SEMPs; and crypto-assets that an RCASP has adequately determined cannot be used for payment or investment purposes.
FinTax says the treatment of assets such as BTC and ETH is usually straightforward, while stablecoins, NFTs, tokenized securities, and some utility tokens may require further analysis.
The three categories of reportable information
The article breaks CARF reporting into three parts.
First, RCASP information. A reporting crypto-asset service provider must report its name, address, and identification number. The identification number should be a tax identification number, or TIN. If no TIN exists, the provider should use a company registration code or a Legal Entity Identifier, or LEI. If the RCASP has not been assigned an identification number, only its name and address need to be reported.
Second, user information. For an individual user, the reportable fields include name, address, residence, TIN, date of birth, and place of birth. The article notes that place of birth does not have to be reported unless the law in the RCASP’s jurisdiction requires it.
For an entity user, the required data includes name, address, residence, and TIN. If due diligence identifies reportable controlling persons, the RCASP must also report each controlling person’s name, address, residence, TIN, date of birth, place of birth, and the role in which that person acts as a controller.
FinTax stresses that the TIN must be the number assigned by the tax residence jurisdiction of the user or controlling person, not by the platform’s home jurisdiction, the place where the transaction occurred, or the source jurisdiction of income. If a user has more than one tax residence, the report must reflect each tax residence jurisdiction and each corresponding TIN. The filing cannot selectively report only part of that information.
For entity users, CARF may require the reporting analysis to look through the entity to its controlling persons. The RCASP must first identify who the controlling persons are, then determine whether those persons are reportable persons. According to the article, a person must satisfy both the tax residence test and the control test to fall within the reporting scope. The key concept is a controlling ownership interest. Holding a sufficient ownership stake, serving as senior management, or acting as settlor, trustee, or beneficiary of a trust may meet that standard.
Third, transaction information. For each type of relevant crypto-asset defined under CARF, the RCASP must report:
- the full name of the relevant crypto-asset type;
- for acquisitions and disposals against fiat currency, the total amount paid or received, the aggregate number of units, and the number of transactions;
- for acquisitions and disposals in exchange for other relevant crypto-assets, the total fair market value, the aggregate number of units, and the number of transactions;
- for reportable retail payment transactions, the total fair market value, the aggregate number of units, and the number of transactions;
- for transfers of other relevant crypto-assets to or by a reportable user that do not fall into the categories above, a breakdown by transfer type, such as airdrops, staking rewards, loan payments, or exchanges for goods or services, together with total fair market value, aggregate units, and transaction count;
- for transfers to unknown external wallets, the total fair market value and aggregate number of units.
How amounts and valuations must be handled
For acquisitions or disposals involving fiat currency, the total amount paid or received is the net amount after transaction fees, reported in the fiat currency used in the transaction. If multiple fiat currencies are involved, the amounts must be converted into a single fiat currency using a consistently applied method for each relevant transaction, such as the spot rate at the time of the transaction.
Fair market value must also be determined at the time of the transaction, net of transaction fees, and reported in a single fiat currency. On valuation methodology, the article says an RCASP should first rely on trading pairs it maintains itself. If there is no applicable internal pair price, it may turn in order to internal accounting book value, values from third-party companies or websites, the RCASP’s latest valuation for the asset, or another reasonable estimate.
The reportable retail payment category applies only when the transaction reaches the $50,000 threshold. Transfers below that amount are not excluded from reporting. Instead, they must be considered for aggregation under either transfers of other relevant crypto-assets to or by a reportable user or transfers to unknown external wallets.
If a user moves crypto-assets to a private wallet or to an account operated by another platform, and the RCASP can no longer observe the full transaction history, the RCASP must treat that movement as a transfer to an unknown external wallet. CARF also requires aggregation by transaction category. Where a relevant crypto-asset is non-fungible and different variants have different values in a fixed unit, each unit must be treated as a separate type of relevant crypto-asset.
How local implementation can change the final filing
FinTax says the OECD CARF rules and commentary set out a harmonized international standard, but each jurisdiction ultimately implements that standard through domestic law. Core rules on the definition of relevant crypto-assets, transaction categories, and report fields remain close to the OECD model, though practical differences can emerge in several areas.
Whether domestic users must also be reported
The original OECD CARF framework is mainly designed for automatic exchange of tax information across borders. A reportable jurisdiction is one that has a CARF exchange arrangement in place and appears on a public list maintained by the implementing jurisdiction. On that basis, reporting is generally focused on tax residents of other reportable jurisdictions.
Some jurisdictions have added a domestic reporting layer, requiring RCASPs to report domestic tax residents to the local tax authority as well.
The article cites the United Kingdom as one example. Under the Finance Act 2026, UK RCASPs have reporting obligations for UK tax resident users and relevant controlling persons. Current HMRC guidance says RCASPs must collect information for all users and report data on UK tax residents as well as tax residents of other participating CARF jurisdictions.
New Zealand is another case. The New Zealand tax authority has included its own jurisdiction on its CARF reportable jurisdiction list, which means New Zealand tax residents also fall within the domestic reporting scope. Official guidance states that where an RCASP has both New Zealand resident and non-resident users, identity information and relevant transaction data for both must be submitted to the tax authority. Resident data is used for domestic tax administration, while non-resident data is exchanged with the tax authority of the user’s residence jurisdiction under CARF arrangements.
By contrast, jurisdictions such as Japan and Singapore have not brought their own domestic tax residents into the CARF reporting scope, and their approach is closer to the original OECD model. Even so, the article notes that RCASPs still need to carry out due diligence on all users, including domestic users, in order to identify who falls within the reportable population. In other words, the scope of due diligence is not the same as the final reporting scope, and the scope of international exchange is not always the same as what the domestic tax authority requires.
Differences in reporting currency and valuation practice
Transaction amounts and fair market value must eventually be reported in fiat currency. Whether a jurisdiction designates a specific reporting currency can materially affect an RCASP’s data conversion process and filing systems.
FinTax points to South Africa’s CARF regulation, Notice 6887, which expressly requires transaction amounts and fair market value to be determined and reported in South African rand. The tax authority’s FAQ also addresses the compliance burden and practical challenges facing high-volume platforms and gives more detail on the requirement for consistent conversion and valuation methods. According to that FAQ, CARF does not require real-time currency conversion, does not restrict the source of exchange rates, and does not mandate transaction-by-transaction pricing. Reasonable methods such as batch processing, end-of-day exchange rates, or appropriate averages are allowed.
Whether the $50,000 retail payment threshold is localized
Under the OECD standard, a retail payment transaction is reportable under that specific category only if it reaches the $50,000 threshold. Otherwise, it falls into another transaction category.
Jurisdictions may translate that threshold into local currency under domestic law. The article says Japan sets the threshold for reportable retail payment transactions at JPY 5 million, approximately $31,273. Brazil uses the BRL equivalent of $50,000. The European Union’s DAC8 uses $50,000 or the equivalent in another currency. Other jurisdictions keep the original dollar standard.
FinTax says these local approaches generally take one of two forms: a fixed amount in local currency, or the local-currency equivalent of the dollar threshold. That difference matters in practice because it affects how RCASPs classify transactions and aggregate data. The same transaction may qualify as a retail payment in one jurisdiction and as another type of transfer in a different jurisdiction.
Differences in fields, TIN treatment, and nil filing rules
The OECD rules standardize core report fields for individual users, entity users, and controlling persons, but domestic law still has room to adjust details.
Place of birth for an individual user is generally not required unless local law says otherwise. As for TINs, if a reportable user or controlling person is resident in a jurisdiction that does not issue a TIN, or if local law does not require collection of a TIN, there is no need to report one. The article says Singapore’s Inland Revenue Authority, or IRAS, expressly allows the filer to provide the relevant reason code under its CARF XML rules in those cases.
Even where TIN reporting is required, the form of the number differs across jurisdictions. In the UK, a National Insurance number, or NINO, for an individual user or relevant controlling person, a company registration number, or CRN, for a UK company, and a Unique Taxpayer Reference, or UTR, for partnerships and trusts can all serve as the relevant tax identification number.
The article also highlights differences in filing obligations when there is no reportable information in a given year. The UK follows a no data, no filing model. Singapore generally requires a nil return, meaning the RCASP submits only its own information and leaves out user and transaction data. Japan’s National Tax Agency, in its CARF FAQ, says that if a reportable contractual relationship remains in place and has not been terminated, the RCASP must still file an annual report even if there was no transaction amount generated under that contract during the year.
How RCASPs can prepare their data and systems
Embedding CARF tax due diligence into KYC
FinTax says AML and KYC records already play an important role under CARF because they help test the reasonableness of tax self-certifications. In ordinary AML and KYC processes, an RCASP will usually have already collected an individual’s name, address, and identity documents, as well as an entity’s registration information, ownership structure, and beneficial owner data. Those data points do not need to be gathered again from scratch.
What CARF adds are tax-specific elements: tax residence jurisdictions, TINs, whether relevant controlling persons are reportable persons, and whether tax self-certifications remain valid. For ownership structure and beneficial ownership data already collected through KYC, the RCASP still needs to determine whether those persons meet the CARF definitions of controlling person and reportable person. The article’s conclusion is that KYC and CARF should share underlying data while applying different legal tests, rather than operate as two entirely separate customer frameworks.
Keeping raw transaction data and a consistent valuation mechanism
In the reporting process, the fiat currency used for filing affects transaction conversion, fair market value assessment, and transaction classification. Local implementation requirements can therefore have a substantial impact on system design, especially for global RCASPs.
FinTax says RCASPs should keep at least the original transaction currency, transaction amount, the exchange rate at the time of the transaction, the converted reporting amount and reporting currency, and the valuation time and valuation method. They should not keep only the final converted figures. That way, if a jurisdiction later updates its rule and requires reporting in a designated local currency, the RCASP can generate a compliant report from the underlying transaction data.
Building a localized rules framework
The article closes by saying that while OECD CARF can serve as a unified base data standard, the final filing logic still depends on the rules of each jurisdiction involved. RCASPs need to determine where they incur and perform CARF obligations, whether domestic tax residents are included in the reporting scope, which jurisdictions appear on the local list of reportable jurisdictions, whether optional fields such as place of birth must be filed, and whether a nil return is required when no reportable information exists.
Local variation also shows up in the form of tax identification numbers. The final report fields have to be assessed with reference to the domestic legislation and technical specifications applicable to both the RCASP and its users. FinTax says those differences cannot be handled by relying on a single uniform rule set.
The piece ends with a practical point: a CARF annual report depends on a chain of earlier judgments, so RCASPs cannot wait until the filing deadline to start preparing. CARF compliance needs to be folded into customer management, KYC procedures, and transaction systems. As CARF moves deeper into local legislation and enforcement around the world, the same user and transaction data may need to be configured differently across jurisdictions, and that preparation will affect whether reporting can be carried out accurately and consistently.