DAC8 XML Report: Complete Annotated Example

Category: XML Templates Last Updated: 2026-02-12 Applies To: EU DAC8 / OECD CARF XML Schema

---

Overview

This article provides a complete, annotated DAC8/CARF XML report example. Every major element is included and explained so that implementers can use this as a reference when building their own XML generation logic. The structure follows the OECD Common Reporting Standard for Crypto-Assets Framework (CARF) XML schema, which underpins the EU DAC8 directive for crypto-asset reporting.

> Note: The exact schema version and namespace URIs may change as the OECD and EU finalise implementation details. Always verify against the latest published XSD before submitting.

Complete XML Example

<?xml version="1.0" encoding="UTF-8"?>
<CARFMessage xmlns="urn:oecd:ties:carfmessage:v1"
             xmlns:carf="urn:oecd:ties:carf:v1"
             xmlns:stf="urn:oecd:ties:stf:v4"
             version="1.0">

  <!-- === MESSAGE HEADER === -->
  <MessageSpec>
    <!-- Unique identifier for the sending entity (e.g., GIIN or local tax ID) -->
    <SendingCompanyIN>DE1234567890</SendingCompanyIN>

    <!-- ISO 3166-1 alpha-2 code of the transmitting country -->
    <TransmittingCountry>DE</TransmittingCountry>

    <!-- ISO 3166-1 alpha-2 code of the receiving jurisdiction -->
    <ReceivingCountry>FR</ReceivingCountry>

    <!-- Message type: CARF indicates a CARF/DAC8 report -->
    <MessageType>CARF</MessageType>

    <!-- Optional: correction indicator. Leave empty for original submissions -->
    <CorrMessageRefId/>

    <!-- Reporting period: calendar year covered by this report -->
    <ReportingPeriod>2026-12-31</ReportingPeriod>

    <!-- Timestamp of message generation in UTC -->
    <Timestamp>2027-03-15T10:30:00Z</Timestamp>
  </MessageSpec>

  <!-- === CARF BODY === -->
  <CARFBody>
    <!-- Reporting entity identification -->
    <ReportingFI>
      <!-- Legal name of the Reporting Crypto-Asset Service Provider (RCASP) -->
      <Name>CryptoExchange GmbH</Name>

      <!-- Address of the reporting entity -->
      <Address>
        <stf:CountryCode>DE</stf:CountryCode>
        <stf:AddressFree>Friedrichstrasse 100, 10117 Berlin, Germany</stf:AddressFree>
      </Address>

      <!-- Tax Identification Number of the reporting entity -->
      <TIN issuedBy="DE">DE123456789</TIN>

      <!-- Identifier assigned by the local tax authority, if applicable -->
      <FilingNumber>RCASP-DE-00042</FilingNumber>
    </ReportingFI>

    <!-- === ACCOUNT REPORT (one per reportable user per jurisdiction) === -->
    <AccountReport>
      <!-- Unique reference for this account report within the message -->
      <DocRefId>DE2026.CARF.000001</DocRefId>

      <!-- Account holder details -->
      <AccountHolder>
        <!-- Individual account holder -->
        <Individual>
          <Name>
            <stf:FirstName>Jean</stf:FirstName>
            <stf:LastName>Dupont</stf:LastName>
          </Name>
          <Address>
            <stf:CountryCode>FR</stf:CountryCode>
            <stf:AddressFree>15 Rue de Rivoli, 75001 Paris, France</stf:AddressFree>
          </Address>
          <!-- Tax residency jurisdiction -->
          <TIN issuedBy="FR">FR1234567890123</TIN>
          <BirthInfo>
            <BirthDate>1985-07-14</BirthDate>
            <City>Lyon</City>
            <CountryCode>FR</CountryCode>
          </BirthInfo>
        </Individual>
      </AccountHolder>

      <!-- Transaction summary for this user in the reporting period -->
      <TransactionSummary>
        <!-- Crypto-to-fiat transactions -->
        <TransactionType>EXCHANGE</TransactionType>
        <NumberOfTransactions>47</NumberOfTransactions>
        <AggregateGrossProceeds currCode="EUR">28500.00</AggregateGrossProceeds>

        <!-- Asset details -->
        <CryptoAssetDetails>
          <AssetCode>BTC</AssetCode>
          <TotalUnits>0.85000000</TotalUnits>
        </CryptoAssetDetails>
      </TransactionSummary>

      <!-- Additional transaction types for the same user -->
      <TransactionSummary>
        <TransactionType>TRANSFER</TransactionType>
        <NumberOfTransactions>3</NumberOfTransactions>
        <AggregateTransferValue currCode="EUR">5200.00</AggregateTransferValue>
        <CryptoAssetDetails>
          <AssetCode>ETH</AssetCode>
          <TotalUnits>2.50000000</TotalUnits>
        </CryptoAssetDetails>
      </TransactionSummary>
    </AccountReport>

  </CARFBody>
</CARFMessage>

Field-by-Field Annotations

MessageSpec Section

Field	Purpose	Format
SendingCompanyIN	Identifies the reporting entity to the tax authority	Tax ID or GIIN
TransmittingCountry	Country from which the report originates	ISO 3166-1 alpha-2
ReceivingCountry	Destination tax jurisdiction	ISO 3166-1 alpha-2
MessageType	Always CARF for DAC8 crypto reports	Fixed string
ReportingPeriod	Last day of the calendar year covered	YYYY-12-31
Timestamp	When the XML was generated	ISO 8601 UTC

ReportingFI Section

The ReportingFI block identifies the Reporting Crypto-Asset Service Provider (RCASP). This must match the entity registered with the tax authority. The TIN element must carry the issuedBy attribute indicating which country issued the tax identification number.

AccountReport Section

Each AccountReport element represents one reportable user in one receiving jurisdiction. If a user is tax-resident in multiple jurisdictions, separate AccountReport entries are generated for each jurisdiction (in separate XML files, one per receiving country).

The DocRefId must be unique across all submissions and is critical for corrections and amendments later.

TransactionSummary Section

Transaction summaries are aggregated by type. The OECD CARF schema currently defines several transaction types including EXCHANGE (crypto-to-fiat and crypto-to-crypto), TRANSFER (to wallets not held by the RCASP), and RETAIL_PAYMENT (direct payment for goods/services).

Each summary includes the aggregate gross proceeds or transfer value in the reporting currency, the number of transactions, and details about the crypto-assets involved.

Important Implementation Notes

• One file per receiving jurisdiction. Do not combine multiple receiving countries in a single XML file.
• Character encoding must be UTF-8. Ensure your XML serialiser does not produce other encodings.
• Namespace URIs shown above are illustrative. Always reference the exact URIs from the official OECD-published XSD.
• Validate before submitting. Run every generated file against the XSD schema to catch structural errors before transmission.
• Currency codes must follow ISO 4217 (e.g., EUR, USD, GBP).
• TIN formatting varies by jurisdiction. Do not assume a universal format; validate TINs against country-specific rules where possible.

This example covers the most common scenario: an individual account holder with exchange and transfer transactions. Entity account holders, corrections, and void messages follow the same overall structure but use additional elements covered in other articles in this series.