CRS/DAC2 filing in France — the XML specification

France publishes its CRS return as an engineering specification, not a form — and two numbers buried in it decide whether your file is one submission or four. The French CRS/DAC2 filing is governed by a cahier des charges issued by the tax administration, currently FR-CRS-DAC2 XML version 3.7 for the 2025 income year. It fixes the message structure, the encryption, the deposit route and hard limits on file size and record count. This piece sets out the spec, the July deadline, the limits that force a split, and what changes for an e-money institution newly inside the perimeter under the DAC8 extension of CRS to e-money.

1. The specification, and why it is versioned

France does not publish a CRS form. It publishes a cahier des charges — a technical specification for transferring information under the CRS/DAC2 arrangements by electronic means — and reissues it each campaign with a version number. The current document for the 2025 income year is version 3.7. A separate specification exists for New Caledonia, with its own version line and its own collection schemas for the test and production phases.

Treating the version number as decoration is a recurring cause of rejection. The specification is the contract: it defines the schema the file is validated against, and a file built to last campaign’s version can fail on structure alone. The first task each year is to diff the new version against the one you built to, not to re-run last year’s job.

2. What the message contains

The file is an XML instance of the OECD’s CRS message. Two blocks carry the payload and the distinction between them matters when you are debugging a rejection:

• MessageSpec — characterises the message itself: who is sending, for which period, and what kind of transmission this is. Errors here reject the whole file regardless of its contents.
• CrsBody — identifies the reporting institution and carries the account data it is reporting.

The practical reading is that a French CRS file has two independent failure surfaces. A malformed MessageSpec is an envelope problem and usually a configuration error that repeats on every submission until it is fixed. A CrsBody problem is a data problem and is usually confined to identifiable accounts. Teams that log rejections without separating the two spend the campaign re-submitting whole files to fix individual records.

3. The two limits that force a split

The specification sets hard ceilings, and they are the numbers most worth extracting before you design the export:

Neither limit bites for a firm with a few hundred reportable accounts, which is most payments institutions in their first year. Both bite for a firm that has just brought a large retail book into scope. The design consequence is that the export has to be splittable by construction — a deterministic partition of the population with a stable rule, so that the same account lands in the same part on a re-run and a correction can be aimed at one file rather than regenerated across all of them.

Worked example. A retail payments firm brings 41,000 reportable accounts into its first French CRS campaign and builds a single export. Rule: one message carries at most 32,000 account reports, and the deposited file is capped at 100 MB before compression. What the engineer does: partitions the population on a stable key rather than on row order, so part boundaries do not move between runs; sizes the raw XML per part against the megabyte ceiling separately from the record ceiling, because the binding constraint differs depending on how much optional data each record carries; and records which part each account landed in. Outcome: a correction in March touches one part, and re-running the export in April reproduces the same partition instead of reshuffling every account into a different file.

4. Deposit: encrypted XML, through the EDI route

The declaration is coded in XML, encrypted according to the tax administration’s specifications, and transmitted through the electronic deposit channel used for third-party declarant filings. Two implications follow for a firm arriving from a portal-based reporting culture.

First, encryption is part of the submission, not an optional transport nicety, and it is specified — which means it is a component to build and test rather than a setting to switch on. Second, the deposit channel is the same family of route used for other French third-party declarant returns, so a firm already filing something else in France may have the enrolment and the certificate it needs. That is worth checking before treating CRS as a greenfield integration; the reverse is also true, and a firm with no existing French deposit route should treat enrolment, not the XML, as the long pole.

5. The deadline, and how it compares

The deadline for depositing the French CRS file is set by decree at 15 July of the year following the year in which the income was received or the balances closed. So the 2026 reporting year is deposited by 15 July 2027.

That is a materially later date than Spain’s, and the difference is a trap for a group filing in both. A single group-level CRS calendar built on the later date will miss the earlier one by six weeks.

Worked example. A group with a French branch and a Spanish branch builds one CRS programme with a single July milestone. Rule: the returns are separate obligations to separate administrations with separate deadlines, formats and channels; the Spanish window closes on 31 May. What the practitioner does: splits the programme into two tracks sharing one data layer — a common reportable-account population built once from the 31 December snapshot, and two country-specific rendering and submission steps with their own calendars and their own test cycles. Outcome: the data work is done once and the filing work twice, which is the correct shape; the alternative, two full pipelines, duplicates the expensive half and still misses the earlier date.

6. What changes for e-money and crypto firms

Two extensions arrive together and are easy to conflate, because the same EU instrument carries both.

• The CRS extension. Specified electronic money products come into the CRS definition of a financial account, which brings e-money institutions into the reporting population. The obligation runs from 1 January 2026 with the first exchange in 2027.
• The crypto-asset extension. The crypto-asset reporting framework is a separate return with its own population — crypto-asset service providers — and its own message, not an extra section inside the CRS file.

A firm that does both will file both, and should expect the two to follow different national implementation timetables even inside one member state: the CRS channel has existed for years and is versioned annually, while several administrations are still building the crypto channel. Planning on the assumption that the crypto return will simply travel down the CRS pipe is the single most common sequencing error in this area.

The classification question — whether your products are financial accounts at all, and the carve-outs that apply — is answered in the CRS scope article. This page starts after that answer is yes.

7. What to do, today

• Download the current cahier des charges and check its version against the one your export was built to. Diff before you build.
• Separate MessageSpec failures from CrsBody failures in your rejection handling, so an envelope error does not trigger a data investigation.
• Design the export as a deterministic partition from the start, against both the 32,000-record and the 100 MB pre-compression ceilings.
• Check whether the group already has a French electronic deposit enrolment for another third-party declarant return before scoping a new one.
• Build one reportable-account population from the 31 December snapshot and render it per country, rather than building a pipeline per country.
• Put the Spanish 31 May date in the French calendar if the group files in both, and set the internal freeze against the earlier one.
• Treat the crypto return as a separate project with its own channel, not as an extension of the CRS file.

8. Questions people actually ask

Related: CRS for EMIs — when you are a Financial Institution · Building the CRS return · Modelo 289 — Spain’s annual CRS return · DAC8 and EU crypto reporting · The French reporting calendar · CRS/DAC2 filing in the Netherlands