FICOBA — France’s account register, and who must file

FICOBA is the French register of bank and similar accounts, and since 1 May 2025 the clock to feed it runs in days, not months. Article 1649 A of the Code général des impôts requires a defined set of bodies to declare to the tax administration the opening, modification and closing of accounts of any kind, along with the renting of safe-deposit boxes. The arrêté of 14 June 1982, codified at articles 164 FB to 164 FG of Annex IV to the CGI, remains the operative instrument — but the arrêté of 4 October 2024 amended it, cutting the filing window from one month to seven days. A pipeline built for the old deadline is now late by design.

1. Who must declare

Article 1649 A names four categories, and the third is the one that reaches passporting firms:

The tax administration’s own doctrine spells the population out rather than leaving it to the abstractions: banks, public accountants, credit institutions, financing companies, the Caisse des dépôts et consignations, investment service providers, and — named expressly — payment institutions and electronic money institutions. There is no volume threshold and no de minimis. A firm with one French-resident customer holding one account is a declarant.

2. Three events, and the modification list nobody reads

FICOBA is event-driven rather than periodic, and it captures opening, closure, and — the awkward one — modification. “Modification” is not a general invitation to resend the record. The declarable changes are specific:

• a change to the identity of the account holder;
• a change to the characteristics of the account;
• a change of the establishment managing the account;
• a change to the holder’s civil status, or, for a legal person, its corporate name or SIREN;
• a change to the holder’s address.

That list is the specification for the hardest part of the build. Openings and closures are discrete events any core system naturally emits. Modifications require the firm to detect that something in an already-declared record has changed — and the change-relevant field set is narrower than “the customer record was updated” and wider than “the account was amended”. A marketing-preference flag is not declarable; a corrected date of birth is. A pipeline that emits on every customer-record write produces noise; one that emits only on account events drifts from the register silently, and the drift stays invisible until a query returns a stale holder.

3. The seven-day clock

Article 164 FC of Annex IV to the CGI now requires declarations of opening, modification and closure of accounts and of safe-deposit rentals to be filed within seven days of the event, to the competent computing services centre. That text has been in force since 1 May 2025; before then the window was one month.

The same arrêté of 4 October 2024 also imposed a one-off reconciliation: a complete declaration of accounts and safe-deposit rentals open at the declaration date, together with every closure between 1 January 2024 and that date, at a date notified by the administration to each declarant and in any event no later than 30 April 2025. Firms that met that obligation now have a known baseline; firms that did not have a register position that diverged from their books at a known moment, which is a materially worse starting point for any later reconciliation.

Seven days changes the architecture, not just a parameter. A monthly window tolerates a batch job with manual review and a re-run if the file fails validation. A seven-day window, counted in calendar days from the event, leaves no room for a weekly cycle plus an error-correction pass — the correction has to fit inside the same seven days as the original.

4. What the declaration carries, and what FICOBA does not hold

Article 164 FD sets the payload: the designation and address of the establishment managing the account or safe-deposit box; the designation of the account, its number and, where different, the IBAN; its nature, type and characteristics; the date and nature of the declared operation; and the identification details of the holder, with the details of authorised representatives and beneficial owners where applicable. Declarations are made in a versioned XML format specified in the DGFiP’s cahier des charges for FICOBA 3, with a separate migration guide for institutions moving from the earlier format.

What is equally important is what the file does not contain. FICOBA records the existence and identification of accounts. It holds no balances and no transactions. For a natural person it holds name, first names, date and place of birth and address; for a legal person, name, legal form, SIRET and address; plus the account’s number, nature, type and characteristics and the dates of opening, modification and closure. Data is retained for ten years after the closure of the account is recorded.

The absence of amounts is the defining property for the build. There are no balances to reconcile and no arithmetic to check, which removes one whole class of error and concentrates everything in another: identification data quality. A FICOBA declaration is fundamentally an identity record attached to an account, so a transposed birth date or a stale address is not cosmetic — it is the substance of the return.

5. What sits outside the obligation

Several account types are excluded, and knowing them prevents both over-reporting and the wrong kind of confidence. The exclusions include notary accounts opened for a single operation, employee-savings accounts, merchants’ trade accounts, interbank treasury accounts, internal accounts with no identified holder subject to conditions, temporary or suspense accounts, advance and loan accounts, and player accounts under the online-gaming legislation.

The internal-accounts limb is the one to read carefully in a payments context. An institution running pooled or technical accounts has to establish, for each, whether there is an identified holder — because the answer decides the treatment, and the answer is a matter of how the account is actually operated rather than how it is labelled in the ledger.

6. Three situations, and what the practitioner does

Scenario 1 — the passporting institution with no French branch.

Facts: an EU credit institution operating in France under the freedom to provide services opens accounts for French residents from its head office.

What the rule says: article 1649 A reaches establishments benefiting from articles L. 511-22 and L. 511-23 CMF for their operations with French residents. The passporting route does not remove the obligation; the residence of the customer engages it.

What the practitioner does: makes French residence a maintained customer attribute rather than a onboarding-time snapshot, then builds three event feeds — open, modify, close — from the account lifecycle. Residence changing is itself a trigger: a customer who becomes French-resident brings an existing account into scope, and that is an opening from FICOBA’s point of view even though the account is old.

Scenario 2 — a corporate customer changes its name.

Facts: a French SAS rebrands. The corporate name changes; the SIREN does not. The customer-relationship team updates the record and closes the ticket.

What the rule says: a change to the corporate name of a legal-person holder is expressly a declarable modification, due within seven days.

What the practitioner does: makes the declarable-field list a property of the data model, not of a runbook — a flag on each field that says whether writing to it emits a FICOBA modification. Without that, the obligation depends on an operations analyst remembering which of forty customer fields are register-relevant, and the seven-day window is gone before anyone asks.

Scenario 3 — a rejected file on day six.

Facts: the weekly FICOBA batch is submitted on day six after the events it covers. It fails schema validation on a handful of records.

What the rule says: the seven-day window applies to the declaration of the event. A file that did not land is not a declaration.

What the practitioner does: moves submission to daily and treats the validation response as part of the same working day’s process. The design rule that follows is simple: the submission cycle must be short enough that a full reject-and-resubmit loop fits inside seven days, which in practice means submitting within two or three days of the event, not on day six.

7. Penalties, and who can see what you filed

The penalty regime is per-record and therefore scales with the size of the gap: €1,500 for each undeclared account opening or closure, and €150 for each omission or inaccuracy in a modification, capped at €10,000 per simultaneous filing. A firm that discovers a two-year backlog is not looking at a single fine.

On the access side — not a reporting duty, but the provision to cite when asked who can see what you have declared — access to FICOBA data is governed by article 5 of the amended arrêté of 14 June 1982. The recipients include tax and other financial administration agents, customs, the financial intelligence unit, social security bodies, banking institutions, judges and judicial police officers, and bailiffs and notaries acting in successions. Individuals can consult the list of accounts registered in their own name through their personal space on the tax administration’s portal, or by writing to their local tax office.

FAQ

8. What to do, today

• Check the deadline your pipeline actually assumes. If it was built before May 2025 it almost certainly assumes a month. Seven calendar days is the current rule.
• Write down the declarable-field list and attach it to the data model. The five modification triggers are specific; anything that relies on memory will miss them.
• Shorten the cycle so a reject fits inside the window. Submitting on day six leaves no room for a failed validation.
• Confirm your 30 April 2025 baseline declaration was made. If it was not, reconcile the book of accounts against the register before the gap compounds.
• Classify your technical and pooled accounts. The internal-accounts exclusion turns on whether there is an identified holder, which is an operational question, not a labelling one.

Related: The French reporting calendar · Registre des bénéficiaires effectifs — France · Issuing French IBANs · The French AML framework · CRBA — Luxembourg’s central register of bank accounts · RPC, CRT and CRC — French balance-of-payments returns · FCC and FNCI — the French cheque registers · FICP — the French credit-incident register · ERMES — the TRACFIN declaration de soupcon · SIREN, SIRET and the French RNE