Blog

OECD Crypto-Asset Reporting Framework (CARF)

Last Updated on June 20, 2025 by Arnaud Collignon

Source: “Crypto-Asset Reporting Framework XML Schema: User Guide for Tax Administrations – Version 1.0 – October 2024” (OECD, 2024)

1. Executive Summary

This post outlines the key themes and essential information from the OECD’s “Crypto-Asset Reporting Framework XML Schema: User Guide for Tax Administrations.” Published in October 2024, this guide provides a detailed technical specification for the XML schema to be used for the automatic exchange of information on crypto-assets under the Crypto-Asset Reporting Framework (CARF). It is designed to assist tax administrations in implementing and utilizing the CARF XML schema for both domestic reporting by Crypto-Asset Service Providers (CASPs) and international exchanges between Competent Authorities (CAs). The schema mandates specific data elements for reporting, covering identifying information for Reporting CASPs and Crypto-Asset Users, as well as detailed records of relevant crypto-asset transactions.

2. Main Themes and Key Information

2.1 Purpose and Scope of the CARF XML Schema

The CARF XML Schema provides a standardized format for the automatic exchange of information related to crypto-assets for tax purposes. Its primary goal is to ensure consistency and facilitate data transfer between jurisdictions and from Reporting Crypto-Asset Service Providers (RCASPs) to their domestic tax administrations. The guide states: “This document and related XML Schema… are without prejudice to the status of or sovereignty over any territory, to the delimitation of international frontiers and boundaries and to the name of any territory, city or area.” (OECD, 2024, p. 2)

2.2 Core Components of the CARF XML Schema

The schema is structured into several key sections, each focusing on a specific type of information:

  • Message Header: Contains metadata about the overall message, including sender and receiver information, message type, and reporting period.
    • SendingEntityIN: Optional for domestic reporting, identifies the RCASP sending the message via a domestically defined ID.
    • TransmittingCountry & ReceivingCountry: Mandatory 2-character ISO country codes identifying the transmitting and receiving CAs.
    • MessageRefID: A unique identifier for the message, starting with the sending country code, reportable year, and receiving country code (e.g., “CA2023LU123456789”).
  • MessageTypeIndic: Specifies the message’s purpose:
    • CARF701: New information.
    • CARF702: Corrections/deletions for previously sent information.
    • CARF703: No data to report (nil reporting).
    • ReportingPeriod: Identifies the last day of the reporting period (e.g., “2027-12-31”).
    • Timestamp: Date and time of message compilation (e.g., “2027-03-15T09:45:30.789”).
  • CARF Body: The main content of the report, containing two crucial sub-sections:
    • RCASP (Reporting Crypto-Asset Service Provider):
      • Identifies the RCASP and its “nexus to the reporting jurisdiction.”
      • Includes details such as Entity or Individual ID, TIN (Tax Identification Number) (with “NOTIN” for unknown/inexistent), name, address, and nexus type (e.g., “CARF901 – Incorporation,” “CARF902 – Residence,” “CARF904 – Place of Business”).
      • An “OtherNexus” element is available for optional domestic reporting or to notify partner jurisdictions of reporting taking place elsewhere due to an “equivalent or stronger nexus.”
    • Crypto Users:
      • Contains identification information for each Crypto-Asset User and, where applicable, “Controlling Persons of certain Entity Crypto-Asset Users.”
      • Also includes details on “Relevant Transactions carried out by a Crypto-Asset User that are reportable under the CARF.” (OECD, 2024, p. 19)
      • This element is optional if the report solely indicates the RCASP’s nexus for CARF purposes.

2.3 Data Elements for Identification (Person Party and Organisation Party Types)

Both individuals and entities are identified using structured data elements:

  • Residence Country Code (ResCountryCode): Mandatory, describes the residence country(s) for tax purposes. Multiple jurisdictions can be reported.
  • Tax Identification Number (TIN): Mandatory for both entities and individuals. If not issued or required by domestic law, “NOTIN” must be entered and the “Unknown” attribute set to “true.”
    • The “TIN issuedBy” attribute (2-character ISO country code) is mandatory unless the TIN is unknown.
  • Identification Number (IN/IIN): Optional, for other identification numbers like LEI, EIN, BRN for entities, or individual identification numbers.
    • Name:OrganisationParty_Type: Mandatory “Name” element for entities.
    • NamePerson_Type: Mandatory “LastName” for individuals, with optional “FirstName,” “MiddleName,” etc. “This data element allows to report both the name at birth and the name after marriage.” (OECD, 2024, p. 15)
  • Address: Mandatory “City” element. Other elements like “Street,” “BuildingIdentifier,” “PostCode” are optional but should be included if they exist. “OECDLegalAddressType_EnumType” provides options like residential, business, registered office, or unspecified.
  • BirthInfo (for individuals): Mandatory “BirthDate” (yyyy-MM-DD format). “BirthPlace” is optional but includes mandatory “City” and “CountryInfo” if reported.

2.4 Reporting of Relevant Transactions

The “RelevantTransactions” element is repeatable for each “Relevant Crypto-Asset type” and includes categories of reportable transactions:

  • Crypto Asset: Mandatory, includes the name of the crypto-asset. “The Crypto-Asset name should be reported in line with the Digital Token Identifier, whenever feasible.” (OECD, 2024, p. 21)
  • ExchangeType: Optional, provides additional information on certain exchange transactions (e.g., “CARF401 – Staking,” “CARF402 – Crypto Loan,” “CARF403 – Wrapping,” “CARF404 – Collateral”).
  • NumberofTransactions: Mandatory integer reflecting the count of transactions.
  • Amount: Mandatory, “reflects the aggregate fair market value… net of transaction fees.” (OECD, 2024, p. 22) Amounts are 2-digit fractional, with mandatory 3-character ISO currency code.
  • NumberofUnits: Mandatory, reflects the number of units of the crypto-asset, reportable up to six decimal places.

Specific transaction types reported include:

  • Crypto to Crypto In/Out: Acquisitions/disposals of a crypto-asset against other crypto-assets.
  • Crypto to Fiat In/Out: Acquisitions/disposals of a crypto-asset against fiat currency.
  • Crypto Transfer In/Out: Inbound/outbound transfers of crypto-assets (e.g., “CARF501 – Airdrop,” “CARF503 – Mining,” “CARF505 – Transfer from another RCASP”). “Unknown” (CARF509/CARF606) can be selected as a default where the RCASP has no knowledge of the transfer type.
  • Transfer Wallet: Information on transfers to wallet addresses “not known by the Reporting Crypto-Asset Service Provider to be associated with a virtual asset service provider or financial institution.” (OECD, 2024, p. 27)
  • RRPT (Reportable Retail Payment Transactions): Transfers of a relevant crypto-asset in consideration of goods or services exceeding USD 50,000.

2.5 Corrections and Data Management

The guide provides detailed rules for corrections and deletions of previously sent information.

  • MessageTypeIndic CARF702 is used for corrections/deletions.
  • DocTypeIndic within a message specifies the type of data for individual records:
    • OECD0: Resent Data
    • OECD1: New Data
    • OECD2: Corrected Data
    • OECD3: Deletion of Data
    • OECD10-13: Test data (for agreed testing periods only).
  • DocRefID: Mandatory unique identifier for each record, allowing for identification and correction. “a series of corrections or amendments can be handled as each correction completely replaces the previous version.” (OECD, 2024, p. 31)
  • Uniqueness: Both “MessageRefID and DocRefID must be unique in space and time.” (OECD, 2024, p. 31)
  • To cancel an entire message, a correction message must be sent deleting all records of the erroneous message.

3. Conclusion

The OECD CARF XML Schema User Guide provides a comprehensive technical blueprint for the international and domestic reporting of crypto-asset data for tax purposes. It emphasizes standardized data elements, detailed transaction categories, and clear procedures for corrections, aiming to enhance transparency and facilitate effective tax administration in the evolving digital economy. The mandatory nature of many data elements, combined with specific formatting requirements (e.g., ISO codes, date formats), highlights the OECD’s commitment to robust and interoperable reporting mechanisms.

OECD Document : https://www.oecd.org/en/publications/crypto-asset-reporting-framework-status-message-xml-schema_e528d7f5-en.html