France's National Bank Account Database Breach: 1.2 Million Records and DORA's Incident Reporting Test

The Anatomy of a Centralized Registry Breach

The technical details of the FICOBA breach, as reported by threat intelligence firms, reveal a pattern increasingly common in attacks against government financial infrastructure. The exfiltration was not a brute-force assault on FICOBA's core database. Instead, the attackers appear to have compromised systems with authorized access to FICOBA's data — potentially through the network of government agencies and authorized entities that query the database thousands of times daily.

FICOBA's access model is broad by design. The database is queried by tax inspectors, judicial authorities, customs officials, social security administrators, notaries processing inheritances, and various other government entities. Each access point represents a potential attack surface. The 1.2 million records — while representing a fraction of the total FICOBA database (which contains data on tens of millions of accounts) — suggest that the attackers obtained access through a specific authorized channel rather than compromising the central database directly.

The data exposed in the breach had immediate operational implications for the French banking sector. Account holder names paired with IBANs and BICs provide the exact information needed for targeted vishing (voice phishing) campaigns. An attacker calling a victim can reference their specific bank, their account details, and their identity — creating a level of credibility that dramatically increases the success rate of social engineering attacks. The French banking federation (FBF) had to coordinate rapid awareness campaigns warning customers about potential fraud leveraging the stolen data.

For the financial institutions whose customers were exposed, the breach created a paradox. They were not the breached party — the government registry was. Yet their customers' data was compromised, their brand reputation was at stake, and they were the ones who would bear the operational cost of fraud prevention, customer notification, and potential account remediation. Several major French banks reportedly activated their incident response teams despite not being the primary victims, implementing enhanced fraud detection rules for accounts potentially exposed in the breach.

The regulatory response was complicated by jurisdictional ambiguity. FICOBA sits under the DGFiP, which answers to the Ministry of Finance — not to the Autorite de Controle Prudentiel et de Resolution (ACPR), which supervises financial institutions. The ACPR could demand that banks assess the impact on their customers, but it could not directly investigate the security posture of a government database. This jurisdictional gap is precisely the kind of structural vulnerability that DORA's broader framework of critical ICT third-party oversight was intended to address — but government-operated infrastructure was not the primary target of those provisions.

A Crown Jewel of Financial Data

FICOBA — the Fichier National des Comptes Bancaires et Assimiles — is one of the most sensitive financial databases in Europe. Maintained by France's Direction Generale des Finances Publiques (DGFiP), it maps every bank account opened or closed in France to its holder's identity. Tax authorities, judicial investigators, customs officials, and social services rely on it daily. It is, in effect, the master registry that connects French citizens and residents to the entire banking system.

In February 2026, reports emerged that approximately 1.2 million records had been exfiltrated from FICOBA or systems with direct access to its data. The breach was first reported by Recorded Future's threat intelligence division on February 19, 2026, and subsequently covered by The Register on February 22. The stolen data reportedly included account holder names, bank identification codes (BIC), account numbers (IBAN fragments), and the identity of the holding institution — precisely the kind of information that enables targeted financial fraud, social engineering attacks against bank customers, and identity theft at scale.

The breach raised immediate questions about the security posture of centralized government financial databases. FICOBA is not a bank — it is infrastructure that banks are legally required to report into. Every financial institution operating in France feeds data to FICOBA as a regulatory obligation. When that central registry is compromised, the breach affects not one institution but the entire French banking ecosystem. The 1.2 million records potentially span accounts across every major French bank: BNP Paribas, Societe Generale, Credit Agricole, Banque Populaire, and dozens of smaller institutions.

For DORA compliance officers, this breach presented a novel challenge. DORA's incident reporting framework (Art. 17-23) was designed primarily for incidents at financial entities themselves. But what happens when the breach occurs at a government-operated centralized infrastructure that financial entities are legally compelled to feed data into? The incident reporting obligations, the notification chains, and the remediation responsibilities become significantly more complex when the compromised system sits outside the financial entity's perimeter but contains its customers' data.

The FICOBA breach also tested DORA's ICT risk management requirements (Art. 5-16) in an uncomfortable way. Financial institutions had no choice but to provide data to FICOBA — it is a legal obligation. Yet the security of that data, once transmitted, was entirely outside their control. This creates a structural gap in the ICT risk management framework: how do you manage the risk of a mandatory data dependency that you cannot audit, cannot contractually govern, and cannot choose to exit?

DORA's Incident Reporting Under Stress

The FICOBA breach tested DORA's incident management and reporting framework (Art. 17-23) in ways the regulation's drafters may not have fully anticipated. The key tension: when a breach occurs at a centralized government infrastructure, who bears the DORA reporting obligation?

Art. 17 — ICT-related incident management process

DORA Art. 17 requires financial entities to establish an ICT-related incident management process to detect, manage, and notify ICT-related incidents. The FICOBA breach challenged this requirement because the incident did not occur within any individual financial entity's ICT perimeter. Banks' own systems were not compromised. Their firewalls were not breached. Their applications functioned normally. Yet their customers' sensitive financial data was exposed through a system they were legally compelled to feed.

The question becomes: does FICOBA qualify as an "ICT third-party service provider" under DORA's definitions? If so, the breach would trigger the full incident management and reporting chain. If FICOBA is classified as a government regulatory infrastructure rather than a third-party service, the reporting obligations become ambiguous. This classification question has material consequences for how financial institutions structure their incident management processes and their ICT third-party registers.

Art. 19 — Reporting of major ICT-related incidents

DORA Art. 19 establishes the obligation to report major ICT-related incidents to competent authorities. The classification of the FICOBA breach as "major" seems straightforward given the volume of data (1.2 million records) and the sensitivity (account identification data). However, the reporting entity question is complex. Each affected bank could argue that the breach was not its incident — it was the DGFiP's. Yet the ACPR would reasonably expect to be informed about an event that compromises the financial data of French banking customers at this scale.

The practical resolution in France appears to have involved coordinated notification through the FBF and direct ACPR engagement, but this was an ad hoc response to a novel situation rather than the execution of pre-established DORA-compliant reporting procedures. For other EU member states with similar centralized financial registries, this case study highlights the need to pre-define reporting responsibilities for government infrastructure breaches.

Art. 5-6 — ICT risk management framework

The FICOBA breach exposed a structural gap in ICT risk management. DORA Art. 5-6 requires financial entities to identify and manage all ICT risks. But how do you risk-manage a mandatory data dependency? Banks cannot refuse to report to FICOBA. They cannot audit FICOBA's security controls. They cannot negotiate SLAs or exit strategies. The data flow is a legal obligation, not a commercial arrangement subject to contractual governance.

This creates a category of ICT risk that DORA's framework addresses imperfectly: mandatory government data dependencies. Financial institutions across the EU feed data into dozens of government registries — central credit registers, transaction reporting systems, beneficial ownership registers, tax authority databases. Each represents a data dependency that the institution cannot control, cannot audit, and cannot exit. The FICOBA breach demonstrates that these dependencies carry material ICT risk that must be acknowledged in the risk register, even if the available mitigations are limited.

Art. 28-30 — Third-party risk management

DORA Art. 28-30 establishes requirements for managing ICT third-party risk, including due diligence, contractual provisions, and ongoing monitoring. Government infrastructure like FICOBA does not fit neatly into this framework. There is no contract to negotiate. There is no alternative provider to evaluate. There is no exit strategy beyond ceasing to operate in France.

However, the principles underlying Art. 28-30 remain relevant. Financial institutions should assess the risk profile of government data dependencies, implement compensating controls (enhanced fraud detection, customer monitoring, data minimization where possible), and maintain incident response playbooks specifically for scenarios where a government infrastructure breach exposes their customers' data.

Structural Lessons for EU Financial Infrastructure

The FICOBA breach reveals a category of systemic risk that DORA's current framework addresses only partially: the risk created by mandatory, government-operated centralized financial data repositories.

The Mandatory Dependency Problem

Every EU member state operates some version of centralized financial registries. Germany has the Kontenabrufverfahren (account retrieval system). Italy has the Anagrafe dei Rapporti Finanziari. The Netherlands maintains centralized tax authority databases with bank account linkages. At the EU level, the Anti-Money Laundering Authority (AMLA) is building pan-European registries that will create even larger centralized data dependencies.

The FICOBA breach demonstrates that these registries are high-value targets — they aggregate sensitive financial data from multiple institutions into a single point of compromise. An attacker who breaches one bank gets that bank's customer data. An attacker who breaches a centralized registry gets data spanning the entire national banking system.

Under DORA's current framework, financial institutions are responsible for managing their ICT third-party risks. But government registries occupy a unique position: they are simultaneously outside the institution's control and inside the institution's regulatory obligation. Banks cannot apply DORA Art. 28's contractual governance requirements to a government database they are legally compelled to report into. They cannot conduct Art. 28's due diligence on the DGFiP's cybersecurity posture. They cannot invoke Art. 28's exit strategies because the "service" is a legal obligation.

The Notification Chain Gap

The breach also exposed a gap in the incident notification chain. Under DORA Art. 19, financial entities must report major ICT-related incidents. But when the incident occurs at a government infrastructure, the notification chain fragments. The DGFiP reports to ANSSI (France's national cybersecurity agency). Banks report to the ACPR. Customers are caught between two notification regimes with different timelines, different standards, and different conceptions of what constitutes adequate disclosure.

A DORA-mature response would require pre-established coordination protocols between government cybersecurity agencies and financial supervisory authorities. The FICOBA breach suggests that these protocols either did not exist or were insufficient for the scale and novelty of the incident.

Compensating Controls as Primary Mitigation

Given that financial institutions cannot control the security of mandatory government data dependencies, the primary mitigation strategy must focus on compensating controls:

Data minimization: Where regulatory obligations permit, institutions should advocate for and implement data minimization in their feeds to centralized registries. If a registry breach exposes only hashed or truncated identifiers rather than full account details, the impact is substantially reduced.

Enhanced fraud detection: Banks whose customers were exposed in the FICOBA breach needed to rapidly deploy enhanced fraud detection rules targeting the specific fraud patterns that the stolen data enables — particularly vishing campaigns referencing specific account details.

Customer awareness: Proactive customer notification — even when the bank is not the breached party — demonstrates responsible governance and reduces the window of vulnerability for social engineering attacks.

Incident response playbooks: Every financial institution should maintain specific incident response playbooks for "upstream registry breach" scenarios, including pre-drafted customer communications, pre-configured fraud detection rules, and pre-established coordination channels with the registry operator and supervisory authorities.

Implications for DORA's Evolution

The FICOBA breach suggests that DORA's framework may need to evolve to address government-operated critical financial infrastructure. Possible adaptations include requiring government financial registries to meet minimum cybersecurity standards comparable to those imposed on critical ICT third-party providers, establishing mandatory breach notification protocols between government agencies and financial supervisory authorities, and creating a formal category of "mandatory data dependency" in the ICT risk management framework that acknowledges risks institutions must accept but cannot control.