DAC8 Nil Return XML: How to File When There's Nothing to Report

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

---

Even when a Reporting Crypto-Asset Service Provider (RCASP) has processed no reportable transactions during a reporting period, a formal submission may still be required. This article provides practical steps for preparing and submitting a nil return XML file under DAC8, including the exact MessageSpec structure your file should follow.

> Disclaimer: Nil return requirements differ across EU Member States. Some jurisdictions may mandate nil filings while others may not. Always consult your national tax authority's official guidance and consider seeking professional advice before relying on this article for compliance decisions.

When a Nil Return Is Required

A nil return is typically expected when an RCASP is registered with a national tax authority but has no reportable activity for the calendar year. Common scenarios include:

• No reportable transactions occurred. Your platform was operational, but no users executed crypto-to-fiat, crypto-to-crypto, or other exchange transactions that fall within scope.
• No reportable users existed. Transactions may have taken place, but none of the users involved met the criteria for reportable persons (for example, all users were resident in non-reportable jurisdictions).
• Platform was inactive. You registered as an RCASP but had not yet launched, or your platform was in wind-down with no trading activity during the period.
• De minimis thresholds applied. If your jurisdiction has implemented de minimis thresholds, all activity may have fallen below those limits.

If your jurisdiction requires nil returns, failing to file one is likely to be treated the same as a missed submission. Do not assume that "nothing to report" means "nothing to file."

XML Structure for Nil Returns

A nil return follows the same overall XML schema as a standard DAC8/CARF report. The key difference is that it contains no AccountReport elements within the CARFBody. The required structural components are:

1. XML declaration and root element with the correct namespace URIs
2. MessageSpec (message header) with all standard fields populated
3. CARFBody containing only the ReportingFI block identifying your entity
4. No AccountReport elements -- the absence of these elements signals that there is nothing to report

The file must still pass XSD validation. An empty or malformed file is not a valid nil return.

MessageSpec for Zero Reports

Below is an example of a nil return XML file with a properly constructed MessageSpec. The CARFBody contains only the reporting entity identification and no account reports.

<?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 for a nil return -->
  <MessageSpec>
    <SendingCompanyIN>DE1234567890</SendingCompanyIN>
    <TransmittingCountry>DE</TransmittingCountry>
    <ReceivingCountry>DE</ReceivingCountry>
    <MessageType>CARF</MessageType>
    <MessageRefId>DE2026.NIL.DE.00001</MessageRefId>
    <CorrMessageRefId/>
    <ReportingPeriod>2026-12-31</ReportingPeriod>
    <Timestamp>2027-03-10T08:00:00Z</Timestamp>
  </MessageSpec>

  <!-- Body contains only the reporting entity -- no AccountReport elements -->
  <CARFBody>
    <ReportingFI>
      <Name>CryptoService GmbH</Name>
      <Address>
        <stf:CountryCode>DE</stf:CountryCode>
        <stf:AddressFree>Berliner Strasse 45, 10115 Berlin, Germany</stf:AddressFree>
      </Address>
      <TIN issuedBy="DE">DE987654321</TIN>
      <FilingNumber>RCASP-DE-00099</FilingNumber>
    </ReportingFI>
    <!-- No AccountReport elements: this is a nil return -->
  </CARFBody>
</CARFMessage>

Key points about this example:

• The MessageRefId should still be globally unique. Including "NIL" in your naming convention (e.g., DE2026.NIL.DE.00001) may help you distinguish nil returns from standard reports in your records, though this is not a schema requirement.
• The ReceivingCountry should be set to the jurisdiction you are reporting to. For nil returns, this is typically your own Member State of registration, though requirements may vary.
• The ReportingPeriod must reflect the calendar year being reported on, formatted as YYYY-12-31.
• The CorrMessageRefId element should be left empty for an original nil return.

Submission Process

The submission workflow for a nil return generally mirrors that of a standard report:

1. Generate the XML file following the schema, with no AccountReport elements.
2. Validate against the XSD before submission. Even nil returns must be structurally valid.
3. Submit through your tax authority's designated channel -- this may be a web portal, SFTP endpoint, or API, depending on your jurisdiction.
4. Obtain and store the acknowledgement confirming receipt.
5. File by the standard deadline. Nil returns are typically subject to the same filing deadline as regular reports. Do not delay submission simply because there is no transaction data to compile.

Some jurisdictions may provide a simplified submission interface for nil returns (for example, a checkbox on a portal). Check whether your tax authority offers this option before building a full XML file.

Common Mistakes to Avoid

• Not filing at all. Assuming that zero activity means zero obligation is the most frequent error. If your jurisdiction mandates nil returns, a missing submission may trigger compliance follow-up or penalties.
• Submitting an invalid XML file. A nil return must still conform to the XSD schema. An empty file, a file missing the ReportingFI block, or a file with incorrect namespace URIs will typically be rejected by the receiving system.
• Using a duplicate MessageRefId. Every submission -- including nil returns -- should carry a unique MessageRefId. Reusing an ID from a previous filing may cause the submission to be rejected or overwrite prior data.
• Incorrectly filing nil when reportable data exists. Before submitting a nil return, verify against your platform's transaction logs and user records that no reportable activity genuinely occurred. Accidental nil returns may need to be corrected later through an amendment filing.
• Missing the deadline. Because nil returns require less data preparation, they are often deprioritized. Treat the filing deadline with the same urgency as a full report.

Documentation Requirements

Even though a nil return contains no user or transaction data, you should maintain supporting documentation. Records that are typically expected include:

• A copy of the submitted XML file and the acknowledgement received from the tax authority.
• Evidence supporting the nil determination -- for example, transaction logs confirming zero reportable activity, or records showing that no users met the reportable person criteria.
• Internal sign-off records confirming that the nil return was reviewed and approved before submission.
• Retention for the required period. Data retention requirements may vary by Member State, but retaining nil return records for at least the minimum period mandated by your jurisdiction is generally advisable.

This documentation may be requested if a tax authority later queries why a nil return was filed instead of a standard report.

This article is for informational purposes only and does not constitute legal or tax advice. Requirements may vary by jurisdiction and may change as Member States finalise their DAC8 implementation. Always consult your national tax authority's official guidance and consider seeking professional advice for your specific situation.