Source, historical context and purpose
This article adapts OECD (2024), Delivering Tax Transparency to Crypto-Assets: A Step-by-Step Guide to Understanding and Implementing the Crypto-Asset Reporting Framework, approved on 4 October and adopted on 9 November 2024. The original has three substantive chapters: legal frameworks, administration/IT and due diligence/reporting. Its roughly 60 committed jurisdictions and 2027/2028 exchange timelines describe the position in 2024, not a current count or an independently verified Singapore deadline. CARF is an information-reporting framework; it does not itself determine a user’s tax liability. Domestic implementing rules and the CARF standard/commentary govern over this introductory guide.
Why a standalone crypto framework was developed
Crypto activity can bypass traditional financial intermediaries, be operated entirely online without a fixed headquarters, and move through private wallets across borders. Those features limit tax authorities’ visibility despite CRS progress. The OECD/G20 completed CARF in June 2023 and the Global Forum developed commitments and monitoring for consistent implementation. The framework identifies reporting service providers, performs user due diligence, aggregates specified transactions annually and exchanges the information with the users’ tax-residence authorities. It complements rather than replaces CRS.
CARF compared with CRS
Both use annual reporting/exchange, residence-based due diligence, IT standards and confidentiality safeguards; existing CRS systems and valid new-account procedures may help. CARF differs in assets, functional provider scope and transaction data. CRS generally covers financial institutions, accounts, balances and financial income/proceeds; CARF covers relevant crypto transactions, including providers that are individuals and businesses outside traditional finance. It aggregates fiat exchanges, crypto-to-crypto exchanges and transfers by user and asset type. It has its own XML schema; a CRS file alone does not satisfy CARF reporting.
Four public-sector building blocks and provider preparation
Jurisdictions need political commitment, domestic/international legal frameworks, administrative and IT capability, and confidentiality/data safeguards. Providers must assess RCASP status, determine reporting nexus, understand due diligence and reporting duties, and implement customer/data systems. Existing CRS experience can shorten implementation but does not remove the need to identify new actors or redesign transaction reporting. Begin early enough for providers to operate compliant systems from the first reporting period.
Domestic law and international exchange agreements
Binding domestic rules must enact definitions, due diligence, reporting, records and effective enforcement, interpreted consistently with CARF commentary. They must take effect no later than the start of the calendar year or appropriate period preceding the first exchange year. Internationally, an exchange basis such as the MAAC, an appropriate bilateral tax treaty/TIEA or regional arrangement must be supplemented by administrative agreements specifying information, method and timing. Signing the multilateral CARF MCAA does not activate every relationship: both partners need the MAAC in force/effect, required notifications and mutual inclusion on intended-partner lists.
Who is a Reporting Crypto-Asset Service Provider
An entity or individual carrying on a business that effectuates exchange transactions for customers can be a RCASP, whether counterparty, intermediary or trading-platform operator. Entities include companies, partnerships, trusts, foundations and other legal arrangements. Technology and “decentralised” branding do not decide status: control or sufficient influence enabling compliance can make platform participants RCASPs, including coordinated participants in different jurisdictions. Each such participant may qualify; designating one party for due diligence does not erase the others’ responsibilities. Domestic interpretive rules determine the business test; occasional non-commercial one-off help does not by itself constitute a business.
Six provider examples and three important exclusions
The guide covers market-making exchanges earning spreads, controlled trading platforms, crypto ATMs, subscribers purchasing assets from issuers for onward distribution, dealers buying/selling as principal to customers, and brokers executing client orders. Sole creation/issuance of an asset is not the subscription/distribution business example. Passive investment by a fund does not itself provide customer exchange services. Sole validation of ledger transactions, even for remuneration, is not customer exchange activity. The functional assessment must follow what the person actually does.
Assets, fiat money and the three crypto exclusions
Crypto-assets are transferable digital representations of value validated/secured by cryptographic distributed ledgers or similar technology; labels such as currency, security token or NFT do not decide. Relevant assets exclude CBDCs, specified electronic-money products, and assets affirmatively determined by the RCASP incapable of payment or investment use. Otherwise presume that use; marketplace-traded NFTs can qualify, and FATF virtual assets are relevant assets. Fiat includes official notes/coins and digital forms such as central-bank reserves and CBDCs. Being outside the relevant-asset definition does not by itself remove a provider’s duties for its other relevant assets.
Nexus hierarchy and same-priority reporting
Priority runs: tax residence; entity incorporation/organisation plus legal personality or tax/information-return obligation; entity management; then regular place of business for entity/individual. Management and regular business can be broader than effective management or permanent-establishment concepts; a provider may report where it pays no ordinary tax. Reporting in a higher-priority Partner Jurisdiction generally relieves lower-priority partner reporting. Equal-priority nexus in cooperating implementing jurisdictions permits choice subject to notification to the other jurisdiction. Do not assume a jurisdiction without equivalent implementing rules qualifies as a Partner Jurisdiction.
Branch rules and changing first-year nexus
A regulatory branch is a regular business place. The higher-nexus jurisdiction can also require branch activity reporting unless the branch performs its own due diligence/reporting in an implementing partner with an exchange agreement. One implementing branch fulfilling a user’s obligations can satisfy the provider for that user. In the historical 2027/2028 phase-in, a provider could move reporting to a stronger nexus when the later jurisdiction implements. The guide recommends unmodified common schema for transitional 2027 reporting where feasible, avoiding one-year bespoke fields and unnecessary migration cost.
Authorities must identify providers beyond AML registers
AML/financial-registration lists can help but are insufficient: CARF may include NFTs not FATF virtual assets and has broader nexus. Potential mechanisms include proactive central registration, nil reports, anonymous non-compliance tips and users reporting provider identities in their own returns. Authorities may extend notification of reporting elsewhere to higher-nexus cases, besides same-nexus notifications. Providers with dispersed online teams, management personnel or customer support centres need additional identification. These are implementation options, not assertions that Singapore already requires each one.
Awareness, compliance verification and enforcement
Designate a tax authority or supervisor with adequate powers/resources, a proportionate comprehensive risk-based strategy, record checks and administrative/criminal sanctions. Publish accessible rules/FAQs, sector guidance, contacts, webinars and conference outreach, particularly to unregulated newcomers. Match identified potential providers with actual reporters, investigate discrepancies, analyse reported data and audit underlying due-diligence records. In early implementation, the guide encourages considering reasonable compliance efforts and time to correct within domestic law; it does not grant a universal penalty holiday.
IT reporting, validation, secure exchange and confidentiality
Providers need systems collecting required data and producing the domestic reporting format. Authorities should validate upfront, prepare dedicated CARF XML and securely encrypt exchanges. Compatible CRS systems may be expanded; domestic use of CARF XML is optional, international conformity is required. CTS can support manual push/pull or SFTP system links, including onboarding jurisdictions. Existing Global Forum pre/post-exchange confidentiality and data-safeguard assessments generally remain relevant. Both authorities and providers retain data-protection responsibilities, including outsourced procedures.
Identify users, nominees and retail-payment customers
Users are entities/individuals for whom the provider conducts relevant exchanges or transfers. If an intermediary other than a RCASP/financial institution acts as agent, custodian, nominee, signatory or adviser for another, identify the underlying person instead. For merchant crypto payments exceeding USD50,000, customer/merchant user status depends on the relationship. Even where only the merchant is normally the user, domestic AML requirements to identify its customer mean that customer must also be treated as a user. The five-step source diagram is provider identification, due diligence, reportable-user/person identification, relevant-transaction identification and reporting.
Preexisting and new users: timing and reuse of valid certifications
Unlike CRS, substantive new-account-style diligence applies to both existing and new CARF users. Complete existing users and relevant controllers within 12 months of domestic effective date; obtain valid certifications at new account opening and one-off transactions. An institution that also follows CRS can rely on properly performed CRS new-account diligence. Existing CRS, FATCA or domestic certifications can be reused only if valid and containing every CARF-required item. Reuse is not permission to skip missing fields or the reasonableness test.
Reportable residence and all six excluded-person categories
A reportable person is tax-resident in a published exchange-partner jurisdiction and not excluded; estates follow the deceased’s relevant residence. A partnership/arrangement without tax residence uses effective management; entity certification of no tax residence permits effective-management or principal-office information. Exclusions are regularly traded listed entities; related entities of those listed entities; governmental entities; international organisations; central banks; and financial institutions except the specified professionally managed investment-entity category in IV.E(5)(b). An active entity is a different concept: it can itself be reportable even though controller look-through is not required.
Individual certification and change of circumstances
Collect signed/positively affirmed and dated name, residence address, all tax-residence jurisdictions, applicable TINs and birth date. Citizenship alone may establish residence under some laws; do not substitute nationality for complete residence analysis. Check reasonableness against onboarding and AML/KYC information. If unreliable, obtain a valid certification or reasonable explanation/support before providing relevant transactions. A later change introducing conflicting status information invalidates reliance until recertification or supported explanation. All tax residences must be declared where there is more than one.
Entity certification and the independent controller test
An authorised person signs/affirms and dates entity legal name, address, tax residences and TINs; include active/excluded criteria where applicable, and each controller’s identification and role unless separately collected or established by AML/KYC. Test reasonableness against account information. Public or held information can establish excluded status; retain the information type and review date. Independently determine controllers for an entity that is neither active nor excluded even if the entity itself is not reportable. The active test generally requires passive income below 50% and passive-income-producing assets below 50%; the complete standard contains further criteria. CARF does not use a “Passive NFE” label as its rule.
Controlling persons: ownership, other control and trusts
Identify natural persons using FATF-consistent AML/KYC; if not legally required, apply substantially similar procedures. For legal persons proceed from controlling ownership (risk-based thresholds, with 25% only an example), to other control, then senior managing official if no person identified. Trust controllers always include settlor, trustee, protector, beneficiaries/classes and any other ultimate controller; entity settlors require their controllers too. For class beneficiaries retain enough to identify them at payout/vested-right exercise, which triggers change procedures. Similar arrangements/foundations need equivalent functional positions. Controllers’ tax residence requires their own or entity self-certification; identify name/address/residences/TINs/birth date and reassess changes.
Third-party diligence and retained responsibility
A provider may use permitted outsourced diligence with mutual access to data needed to perform and demonstrate compliance, including for audit. Multiple providers handling the same transaction may designate one provider for diligence. In both cases each obligated provider remains responsible for due diligence, reporting, confidentiality and data protection. Reportable status starts when identified and continues until it ceases, for example residence/status change, exclusion, closure or complete transfer. Outsourcing does not shift statutory responsibility.
Identification data and conditional TIN/birthplace rules
Report user/controller name, recorded address, tax-residence jurisdictions and residence-issued TINs rather than source-country identifiers. TIN can be omitted where the reportable jurisdiction does not issue one or its domestic law does not require collection. Report provider name/address and identifying number, using TIN or absent that business-registration code/LEI if any. Individual/controller birth date is required; birthplace is required only where domestic law otherwise requires its collection/reporting and it is available in electronically searchable records. These conditions should not be turned into blanket missing-data exemptions.
Transaction categories: fiat, crypto exchanges and partial knowledge
Aggregate by user, asset type and transaction category, using the full asset name and digital-token identifier where feasible. Fiat purchases report amounts paid net of transaction fees and fiat disposals amounts received net of fees. Crypto-to-crypto purchases/disposals use each leg’s fair market value net of fees. Trading with the provider itself or a third party is included. If the provider handles only one leg and lacks actual knowledge of the disposal amount, treat it as a transfer rather than inventing the missing consideration. CARF is transaction-based, not an account-balance substitute.
Retail payments, transfers and external wallets
Payments for goods/services exceeding USD50,000 form a separate retail category where applicable. Merchant-agent transfers are ordinarily transfers, but identifying its customer under required AML also creates user/retail reporting for that customer. Payments below that threshold still belong in ordinary transfers; they are not generally unreportable. For known transfer types separately aggregate fair value, units and counts: airdrops, staking income, loans/disbursement/repayment/returns and goods/services exchange. Outgoing transfers to wallets not known as FATF VASPs/financial institutions require aggregate units and fiat fair value. This rule does not report individual addresses, but retain all external addresses/equivalent identifiers for at least five years for follow-up.
Valuation, currency conversion and ordered fallback methods
Use one fiat currency, identify it, value each transaction at its time and apply methods consistently before annual aggregation. Convert actual fiat amounts at transaction time. For crypto swaps value each acquired/disposed asset; a hard-to-value new token may use the other readily valued token’s fiat-equivalent value. Transfers/retail payments can use maintained crypto/fiat reference pairs. Without an applicable reference, the prescribed fallback order is internal book value; reliable third-party price aggregation; most recent provider valuation; and only as last resort a reasonable estimate. Sum each category separately for each asset/user for the calendar year or locally defined appropriate reporting period.
Attribution and adaptation notice
Source: OECD (2024), Delivering Tax Transparency to Crypto-Assets: A Step-by-Step Guide to Understanding and Implementing the Crypto-Asset Reporting Framework, Global Forum on Transparency and Exchange of Information for Tax Purposes, OECD, Paris, licensed CC BY 4.0. This is an adaptation of an original work by the OECD. The opinions expressed and arguments employed in this adaptation should not be reported as representing the official views of the OECD or of its Member countries. This article reorganises and paraphrases the source; it does not use the OECD logo or imply endorsement.
Official source
This article independently explains the substantive contents of the official PDF, including the relevant conditions, procedures and annexes. The linked document remains the authoritative source for its original wording, and later changes should be checked separately.
Read the official PDF ↗