Cybernews linked an unprotected database of 1 billion identity records to IDMerit, which disputes the link. Why centralized KYC invites this, and the fix.
Table of contents
Key highlights
- Cybernews reported roughly one billion identity records in an unprotected database it linked to IDMerit, including over 203 million from the United States. IDMerit says it does not own, control or store the underlying data.
- No sophisticated attack was reported. According to Cybernews, the data was simply left open for anyone to download.
- Root cause is architecture, not negligence. Centralised storage means one open database or one mistake exposes the entire pooled dataset.
- Under GDPR, the data controller stays liable even when a third-party processor holds the storage, so a vendor breach becomes the institution's regulatory and reputational problem.
- Switching to another centralised provider only resets the clock. Decentralised sharded storage splits each record across nodes so no complete record exists anywhere to steal.
Centralized identity verification is a ticking time bomb because every client's PII pools into one database, so a single misconfiguration can expose every verified record at once. The IDMerit incident illustrates the point: Cybernews reported roughly one billion records, including over 203 million from the United States, in an unprotected database it linked to IDMerit. The fix is structural: decentralised storage where no complete record exists in any one place.
And What the 1B-Record IDMerit Leak Proves
Pick a fintech at random. Odds are good they have handed their KYC to a third-party verification provider, trusting that company to handle the most sensitive data their users own: full name, home address, date of birth, national ID, and phone number.
IDMerit was exactly that kind of company: Cybernews describes it as an AI-powered identity verification provider serving the fintech and financial services sectors. In February 2026, Cybernews reported that its researchers had found roughly one billion records, from 26 countries, in an unprotected database it linked to IDMerit. Just sitting there. According to Cybernews, anyone could have downloaded it. IDMerit told Cybernews it does not own, control or store customer data or the underlying data maintained by independent data sources.
The math after this leak is laid out in our breakdown of whether KYC is safe in 2026.
This post is not about IDMerit specifically. It is about the architectural decision that made what happened to IDMerit possible. And why every fintech relying on the same model should be asking hard questions right now.
What actually happened in the IDMerit incident?
On 11 November 2025, according to Cybernews, its researchers discovered an unprotected database that Cybernews linked to IDMerit. It was secured the next day, and Cybernews published its report on 18 February 2026. The contents: full names, home addresses, dates of birth, national ID numbers and phone numbers. Over 203 million records from the United States alone, by Cybernews' count.
That database is the largest entry in our KYC and identity verification breach tracker, which records the scope, entry point and vendor response for each provider incident, including IDmerit's dispute over whether the data was its own.
No sophisticated attack was needed, as Cybernews described it. The data was simply accessible. Whoever found it first could have downloaded the entire database.
Is the root cause architecture or negligence?
The natural reaction to a breach like this is to treat it as a failure of security hygiene: someone left a door unlocked. Fix the lock; problem solved. That reading is technically accurate and strategically useless.
Whatever the immediate cause, what made it catastrophic at a billion-record scale is the architecture underneath. Most identity verification providers collect PII from users across dozens of client institutions and store the verified results in one place. The more clients they serve, the larger the database grows. The larger the database, the more valuable it becomes to attackers and the more devastating any single point of failure.
This pattern is the core of the identity breach epidemic of 2026.
How the model works
Traditional identity verification is simple: collect documents and PII, verify against government databases and biometric checks, store the results for ongoing compliance. The compliance benefit is real. The byproduct is a database containing verified identity records for every customer ever onboarded through the service.
In that model, every bank, every fintech, every credit union that uses the provider adds records to the pool. One billion records is not a failure of scale. It is the logical endpoint of centralised architecture operating at scale.
One mistake = one billion records exposed
In any centralized storage model, security depends on never making a mistake. Secure the database correctly, and everything is fine. Misconfigure it once, have one administrator’s credentials compromised, get hit by one successful attack, and the entire dataset is exposed. The model has no structural redundancy against human error.
Why are identity verification providers the best targets?
Not every database is worth attacking. Identity verification providers sit at the top of the target value chart for three specific reasons.
We unpack why in why your KYC vendor is your biggest data breach risk.
- The data is pre-verified. A marketing database of email addresses requires further work to monetise. An identity verification database contains government-validated records, the exact inputs needed for identity fraud, loan fraud, account takeover, and synthetic identity creation. It is ready to use.
- It aggregates across institutions. A single verification provider serves dozens of banks and fintechs. Their database is not one company’s customer base. It is the combined, verified identities of customers across an entire sector.
- The data ages well. A stolen credit card number is useless within hours of cancellation. A stolen date of birth, national ID number, and home address stay usable for years. Loan applications, account recovery attacks, synthetic identity creation. The shelf life makes it worth targeting.
Put those three together, and the database Cybernews found was not just a high-value target. It was arguably the highest-value single database available to anyone who went looking.
Why is your KYC vendor's breach your problem?
When a verification vendor’s database is exposed, the direct victims are not the vendor. They are the banks and fintechs that trusted the vendor with their customers’ data.
A parallel case is the lessons from the Sumsub security incident.
Regulatory liability
Under GDPR, the data controller, the institution that collected data from its users, remains responsible for how it is processed and protected, even when a third-party processor handles the actual storage. A vendor breach does not stay at the vendor. Every institution whose customers appear in that database faces regulatory exposure on every data protection inquiry that follows. GDPR cumulative fines crossed €5.88 billion this year. The institutions involved do not get to point at the vendor and walk away.
The shared-liability mechanics sit at the heart of third-party breach risk in 2026.
Reputational liability
Users do not read vendor agreements. When a breach is disclosed, they read the headline, and the headline says the bank or fintech they trusted had their passport data exposed. The reputational impact travels upstream to whoever made the vendor selection, regardless of who technically held the database.
Changing vendors does not fix this
The instinctive response to a vendor breach is to switch vendors. But switching to a different provider that also stores complete, reconstructable identity records in a centralized database does not change the exposure. It resets the clock. The risk of an IDMerit-scale event at the new vendor is the same as it was at the old one, just with a different company name.
What does decentralized storage actually change?
The question is not whether centralised storage can be secured better. It can. The question is whether an architecture where a single misconfiguration exposes a billion records should exist at all.
How sharded storage works
In a decentralised sharded model, no complete user record exists anywhere. Each user’s PII is AES-GCM-256 encrypted before distribution, then split into fragments (shards) and distributed across independent nodes in multiple geographic locations. Reconstructing any record requires combining a threshold number of shards held across those nodes.
For the full mechanics, see what decentralised KYC is and how it works.
Zyphe uses a 29-of-100 threshold across thousands of nodes around the world. An attacker who compromises one node has nothing. Twenty-eight nodes, still nothing. They cannot reconstruct any record. They cannot even confirm whose data they are looking at. The blast radius of any breach event is structurally zero.
Compliance does not change; storage does
Decentralised storage does not affect the verification process itself. Document checks, biometric liveness verification, and AML screening happen exactly as before. What changes is where the verified result goes after the check.
In Zyphe’s model, the institution receives a cryptographic proof of verification. Not a copy of the underlying PII. The user holds the actual credential and, through the KYC Passport model, can present it across multiple institutions without resubmitting documents to each one. One verification, reusable everywhere. No new PII copy entering a new database every time they onboard somewhere new.
The reusable credential model is explained in what a KYC passport is.
When does decentralized storage not fix your exposure?
Decentralised storage changes where the verified result goes, not the verification itself. Document checks, biometric liveness, and AML screening still run the same way, so if your compliance gaps sit in those steps, moving storage off-centre does not close them. The architecture removes the single-database blast radius. It does not absolve you of running the checks correctly.
It also does not erase liability you already carry. Under GDPR you remain the data controller, and copies of PII already sitting in legacy vendor databases stay exposed until they are dealt with. Switching to a decentralised model is an architecture decision for new verifications, not a retroactive cleanup of every copy a user resubmitted across past providers.
What four things should you do now?
The IDMerit incident is a useful pressure test. Apply it to your own infrastructure.
- Ask your vendor the blast radius question. How many complete, reconstructable customer records exist in their database right now? If the answer is a large number, that is your current exposure.
- Review your data processing agreements. Under GDPR, you share liability. Ensure your DPAs reflect the actual risk, not boilerplate written before these breach scales became normal.
For what regulators actually require, read how the EDPB GDPR transparency sweep affects KYC.
- Count how many PII copies exist across your vendor relationships. Every time a user resubmits their identity to a new provider, another complete copy enters another database. Reusable credentials cut the count significantly.
- Treat the next vendor selection as an architecture decision. The vendor’s data model is your data model. Switching to a better-secured centralised provider is an improvement. Switching to a decentralised one is a different kind of decision entirely.
Edoardo Mustarelli (Sales Development Representative) Edoardo Mustarelli, fintech/Web3 strategist at Zyphe, driving sales growth and partnerships with global expertise across technology, finance, and strategy.