TL;DR
In late January 2026, an attacker used stolen credentials belonging to a single French government official to access FICOBA, France's national registry of bank accounts.
The breach exposed IBANs, account holder names, addresses, and in some cases tax IDs for roughly 1.2 million of the registry's 300 million accounts, covering 80 million people.
No malware, no exploit, no perimeter breach. The attacker simply logged in with a valid, stolen credential and queried the database like an authorized user.
The root cause: one account with broad, standing query access, no apparent multi-factor authentication, and no controls to flag unusual query volume.
For banks and financial institutions, the takeaway isn't "patch a vulnerability", it's that identity, not infrastructure, is now the primary attack surface.
What happened
In late January 2026, a malicious actor obtained login credentials belonging to a French civil servant with authorized access to FICOBA (Fichier des Comptes Bancaires et Assimilés), the centralized database that lists every bank account opened in France. Using that single, legitimate-looking login, the attacker queried a portion of the database before the intrusion was detected internally and access was restricted.
By the time France's Directorate General of Public Finances (DGFiP) and finance ministry disclosed the incident in mid-February, the numbers were stark:
over 1.2 million accounts exposed, out of roughly 300 million records covering 80 million individuals
Data types exposed: IBANs, account holder names, addresses, and in some cases tax identification numbers
Method: credential theft and impersonation of an authorized civil servant, not malware or a software exploit
French authorities, the French Banking Federation, and national cybersecurity agency ANSSI moved quickly to contain the breach, notify affected individuals, and alert banks to watch for follow-on fraud. But containment doesn't undo the exposure. Security researchers have since warned that the leaked data (names, addresses, IBANs, tax IDs) is exactly the raw material needed to run convincing, targeted phishing campaigns impersonating banks or tax authorities, and to originate fraudulent direct debit mandates against real accounts.
FICOBA has already reported a wave of scams circulating by email and SMS in the breach's aftermath.
This wasn't a hacking story. It was an identity story.
It's tempting to read this as "government database gets hacked." That framing misses the point, and the lesson for financial institutions.
There was no zero-day. No malware payload. No firewall bypass. The attacker didn't break into FICOBA, simply logged into it using a credential the system had every reason to trust. Once inside, the system did exactly what it was designed to do: let an authorized user query account records.
That's the uncomfortable pattern showing up across sectors in 2026 (government, healthcare, financial services, SaaS). Attackers are increasingly authenticating through the perimeter instead of breaking through it. When identity becomes the control plane, a single compromised credential becomes the single point of failure for an entire system, however well-architected that system otherwise is.
Three structural weaknesses made this breach possible, and none of them are unique to a government agency:
Broad, standing access on a single account. One civil servant's credentials could query a large slice of a 300-million-record national database. There's no indication query scope was limited to what that specific role actually needed.
No apparent phishing-resistant MFA. Commentary from French cybersecurity professionals following the disclosure pointed directly at missing multi-factor authentication as the likely gap that let a stolen password become full account access.
No visible anomaly detection on query behavior. A sudden spike in queries against sensitive records from one account is exactly the kind of signal that should trigger an alert, but the breach was reportedly caught through internal detection after the fact, not blocked in real time.
Why this matters for banks specifically
FICOBA isn't a bank, it's a government registry banks feed data into. But the structural problem it exposed is one every bank, credit union, and fintech shares: large stores of identity-linked financial data, accessed by employees and third parties through standing credentials.
Banks operate dozens of internal systems with exactly this shape, core banking platforms, KYC/AML databases, fraud case management tools, customer service consoles that surface full account histories. Every one of those systems has employees or vendors with broad query access, and every one of those employees is a phishing email or a reused password away from becoming the FICOBA attacker's next entry point.
The math is unforgiving: one stolen login, combined with broad standing access and no anomaly detection, is enough to produce a breach measured in millions of records, without a single line of malware ever being written.
This is compounded by a fact security teams already know but rarely act on fully: stolen credentials don't expire when the news cycle moves on. They circulate on criminal marketplaces indefinitely, get replayed against unrelated systems, and resurface months or years after the original leak. A password reused from an unrelated breach can be the credential that eventually unlocks a core banking system, the FICOBA official's compromised login almost certainly originated outside the financial system itself, through phishing or password reuse.
What financial institutions should do differently
The FICOBA breach maps cleanly to a set of controls most banks already know they should have, the incident is a reminder of what happens when they're partial or absent.
1. Move to phishing-resistant authentication.
Passwords and SMS/OTP-based MFA are replayable and phishable. FIDO2 passkeys, hardware security keys, or device-bound credentials remove the shareable secret that makes credential theft profitable in the first place.
2. Enforce least privilege and scoped access, not standing broad access.
No single account (employee or third party) should be able to query millions of sensitive records by default. Access should be scoped to what a role needs, provisioned just-in-time, and automatically revoked when no longer required (zero standing privilege).
3. Screen credentials against known exposure, not just complexity.
A 14-character password that has already appeared in a breach dump is not a strong password. Screening new and reset credentials against breach and info stealer data closes a gap that complexity rules alone leave wide open.
4. Monitor for anomalous query and access behavior, not just login events.
The login itself looked legitimate. What should have stood out was the query pattern that followed, volume, scope, and timing inconsistent with normal use. Continuous behavioral monitoring on access, not just authentication, catches what perimeter and login-based defenses miss.
5. Treat session and query monitoring as identity infrastructure, not an afterthought.
MFA protects the moment of login. It does nothing once a session token or an authenticated query session is already in an attacker's hands. Institutions need visibility into what an authenticated identity is actually doing inside a system, in real time.
6. Assume third-party and interagency access is your access.
FICOBA was breached through an interministerial access channel, a trust relationship between two government bodies. Banks maintain equivalent relationships with vendors, processors, and partner institutions. Every one of those integration points inherits the access-control weaknesses of the party on the other end unless explicitly governed.
The bigger shift: identity is the new perimeter
The FICOBA breach will likely be remembered as a government data exposure event. For security leaders at banks and financial institutions, it deserves a different label: an identity trust failure inside a financial system, with a root cause (a single unmanaged credential) that could just as easily sit inside a bank's own walls.
The infrastructure was solid. The controls were, on paper, in place. What failed was the assumption that a valid login equals a trustworthy user. In 2026, that assumption is no longer safe to make, for governments, and for the banks whose customer data flows through systems just like FICOBA.
This is the exact problem Klyro was built to solve. Instead of trusting a login and walking away, Klyro continuously verifies identity and access across an institution's systems, enforcing least privilege, flagging anomalous query and session behavior in real time, and closing the gap between "authenticated" and "authorized" before it turns into the next FICOBA. For financial institutions, that's the difference between a stolen credential causing a minor incident and one causing a headline.