IDMerit Data Leak: 1B KYC Records Exposed Across 26 Countries

IDMerit, a California-based AI-powered identity verification provider serving financial services and fintech platforms, left a MongoDB database unprotected on the public internet, exposing approximately one billion personally identifiable records across 26 countries. Cybernews researchers discovered the exposure on November 11, 2025; IDMerit secured the database the following day. Public disclosure arrived on February 18, 2026 (99 days after discovery), a gap that carries its own regulatory significance. The exposed database contained full names, addresses, national ID numbers, dates of birth, phone numbers, email addresses, telecom metadata, and KYC/AML verification logs, and weighed more than one terabyte in total.

What Happened

The incident

Cybernews researchers discovered an unprotected MongoDB instance belonging to IDMerit on November 11, 2025. The database required no authentication to access: any party with the URL could read, copy, export, or delete its entire contents without credentials. Researchers notified IDMerit on November 12, and the company secured the database the same day. No malicious access has been confirmed, but security researchers warn that automated crawlers operated by threat actors continuously scan the internet for exposed databases and often discover them faster than human researchers do.

How it happened

The root cause was a MongoDB deployment exposed to the public internet without authentication enabled. MongoDB instances without password protection are a well-documented vulnerability class, and automated scanning tools index the entire IPv4 address space for open database ports continuously. An unprotected instance is typically discovered by malicious bots within hours, and this exposure required no perimeter breach, no vulnerability exploit, and no sophisticated intrusion: the data sat openly accessible on the internet until a security researcher found it. A basic authentication control, standard in any production database deployment, would have prevented the entire exposure.

The 99-day gap between discovery (November 11, 2025) and public disclosure (February 18, 2026) is itself significant. IDMerit was not legally required to make a public announcement, and no regulator has yet confirmed whether formal breach notifications were issued to affected individuals or downstream client companies during that window.

What Was Exposed

The database contained approximately three billion records in total, of which roughly one billion contained sensitive personally identifiable information. The exposed data types included full legal names, home addresses and postal codes, dates of birth, national ID numbers (government-issued), phone numbers, email addresses, gender information, telecom metadata, KYC/AML verification logs, and breach status and social profile annotations.

The geographic breakdown by record volume:

The data type that creates the most severe and lasting risk is national ID numbers. Unlike a password or credit card number, a government-issued ID number cannot be changed once exposed. It remains a usable fraud instrument indefinitely, enabling synthetic identity fraud, account takeover, SIM swap attacks, and targeted spear-phishing using the victim's exact personal details. KYC databases are uniquely dangerous breach targets precisely because they were assembled to verify identity: they contain the specific combination of data points that makes impersonation most convincing.

The Pattern

The IDMerit incident is not an isolated misconfiguration. It is the third major security failure at a KYC or identity verification provider within 18 months, establishing a pattern that compliance officers at fintech and crypto platforms cannot treat as coincidence.

In June 2024, AU10TIX (whose clients include Uber, TikTok, X, Bumble, Fiverr, and Upwork) had employee credentials left exposed for over a year. According to 404 Media (June 2024), those credentials granted access to a logging platform containing identity documents, facial images, and personal data of users verified through AU10TIX's platform. No regulatory fine has been confirmed to date, but the incident exposed a specific risk in the KYC supply chain: a single vendor credential becomes a master key to identity data across dozens of client platforms simultaneously.

In December 2025, Veriff's systems were compromised in an unauthorized access incident that exposed Total Wireless customer identity data. Veriff notified Total Wireless on December 10, 2025. The exposure occurred through Veriff's identity verification infrastructure, demonstrating again that a client's compliance program is only as secure as the least-hardened system in the KYC vendor chain.

In 2023, Okta's customer support management system was breached, exposing session tokens and support files for the entirety of Okta's customer base. Attackers used stolen session tokens to target downstream customers including MGM Resorts and Caesars Entertainment. While Okta is an identity platform rather than a KYC provider, the failure mode is identical: centralized identity infrastructure creates a single point of catastrophic failure for every organization that relies on it.

The structural diagnosis is consistent across all three incidents: any vendor that aggregates identity data at scale becomes a high-value target by definition. The breach is not the failure; storing the data permanently is. A KYC provider's entire business model requires collecting and retaining the most sensitive personal data that exists, and that database is a permanent target regardless of how well it is protected on any given day.

Regulatory Implications

European Union (GDPR)

GDPR applies to any organization processing personal data of EU residents, regardless of where the processor is headquartered. The IDMerit breach affects Germany (61 million records), France (53 million), and Italy (53 million), triggering mandatory notification to supervisory authorities within 72 hours of becoming aware of the breach under GDPR Article 33. Where the breach poses a high risk to individuals, direct notification to affected data subjects is also required under Article 34. Penalties for serious infringements under Article 83 reach up to EUR 20 million or 4% of annual global turnover, whichever is higher.

United States (CCPA and FTC Safeguards Rule)

California's Consumer Privacy Act exposes IDMerit to statutory damages of $100 to $750 per affected California consumer per incident for unauthorized disclosure of personal information resulting from failure to implement reasonable security. With 203 million US records in the exposed database, aggregate exposure is substantial even if only a fraction of affected individuals are California residents. The FTC's Safeguards Rule (16 CFR Part 314) also requires financial institutions to implement information security programs and report certain security events. Platforms that relied on IDMerit for KYC may face independent notification obligations depending on their regulatory classification.

India (DPDPA 2023)

India's Digital Personal Data Protection Act, enacted in 2023, applies to processing of personal data of Indian residents. Given IDMerit's India-based operations, the DPDPA's penalty framework is relevant: fines reach up to INR 250 crore (approximately USD 30 million) for significant data breaches. The DPDPA also requires Data Fiduciaries to notify the Data Protection Board of India and affected individuals of any personal data breach that is likely to affect them.

Downstream operator liability

The regulatory exposure does not stop at IDMerit. Under GDPR Article 28, controllers (the fintech platforms and financial institutions that retained IDMerit as a KYC processor) are responsible for ensuring their processors provide sufficient guarantees to implement appropriate technical and organizational measures. If no Data Processing Agreement specifying security obligations and breach notification timelines was in place between IDMerit and its clients, those clients may face independent compliance failures regardless of whether they caused the breach. Operators who used IDMerit should engage legal counsel immediately to assess whether they carry independent notification obligations to their own customers.

What Compliance Officers Must Do Now

1. Request your KYC vendor's data retention policy in writing

Any identity verification provider that retains customer PII after verification holds a permanent liability on your behalf. Contact your current KYC vendor and request written documentation of their data retention architecture: how long PII is stored, where it is stored, what access controls govern it, and what their deletion schedule looks like. Under GDPR Article 28, this information must be specified in your Data Processing Agreement. If your vendor cannot produce a DPA or cannot answer these questions specifically, that gap is itself a compliance failure independent of any breach.

2. Audit whether IDMerit was part of your verification stack

If IDMerit processed identity verification for any of your customers, assess the scope immediately: which customers' data was likely in the exposed database, which jurisdictions those customers reside in, and which notification obligations those jurisdictions trigger. Do not wait for IDMerit to initiate disclosure: GDPR Article 33's 72-hour notification clock runs from when the controller "becomes aware" of a breach, and media reports constitute awareness. Engaging legal counsel before making any public statement is essential to avoid inadvertent admissions of liability.

3. Verify your Data Processing Agreements cover security obligations

GDPR Article 28 requires that controllers only use processors who provide sufficient guarantees to implement appropriate security measures, and that those guarantees are documented in a binding contract. Review every DPA with every identity verification vendor in your stack. Confirm that each DPA specifies minimum security standards (encryption at rest and in transit, access controls, authentication requirements), breach notification timelines, and the processor's obligations in the event of an incident. A DPA that does not address these points is not GDPR-compliant.

4. Map and assess every vendor in your KYC supply chain

The IDMerit, AU10TIX, and Veriff incidents collectively demonstrate that outsourcing KYC does not eliminate regulatory exposure; it transfers data custody to a vendor while retaining your compliance obligations. Map every third-party vendor in your identity verification chain, assess each one's security posture (SOC 2 Type II certification, penetration test reports, security questionnaire responses), and confirm whether any have experienced security incidents in the last 24 months. According to IBM's Cost of a Data Breach Report 2024, mega breaches involving 50 million or more records cost an average of USD 375 million in the financial industry, and that figure reflects the breached entity's costs, not the downstream clients.

5. Update your incident response plan for third-party KYC failures

Most incident response plans are designed for direct breaches of systems you control. The IDMerit scenario (where a vendor exposes your customers' data without your knowledge or involvement) requires a separate playbook. That playbook should include a clear process for identifying which customers' data each KYC vendor holds, pre-approved communication templates for affected customer notification, a defined escalation path to legal counsel, and a timeline for regulatory notification in each jurisdiction where you operate. Review the consequences of KYC failure and ensure your plan addresses vendor-side breaches specifically, not only breaches of your own systems.

A Different Architecture

Every breach in this pattern shares the same structural precondition: a centralized repository of identity data that exists because the KYC model requires collecting and retaining PII to function. The vault is not a side effect of centralized KYC; it is the product. Any vendor that must hold identity data to deliver its service creates a permanent, high-value target. The IDMerit, AU10TIX, and Veriff incidents are not failures of individual security teams; they are the predictable outcome of an architecture built on centralized data retention at scale.

Zyphe's verify-then-shred approach eliminates this exposure class at the architecture level: identity is verified, the data is shredded, and no PII vault exists to misconfigure, compromise, or be compelled to disclose. Users own their verified credentials via self-sovereign identity and reuse them across platforms without repeated data collection. See how Zyphe's decentralized PII architecture works.

Frequently Asked Questions

What is the IDMerit data leak?

The IDMerit data leak is a security incident in which IDMerit, an AI-powered identity verification provider, left a MongoDB database unprotected on the public internet with no authentication required. Cybernews researchers discovered the exposure on November 11, 2025. The database contained approximately one billion personal records (including full names, national ID numbers, dates of birth, and telecom metadata) across 26 countries. The US accounted for 203 million records, followed by Mexico with 124 million.

Was data actually stolen in the IDMerit breach?

As of February 2026, no confirmed malicious access to the IDMerit database has been reported. However, security researchers warn that automated crawlers operated by threat actors scan continuously for exposed databases and often discover them within hours. The absence of confirmed exfiltration does not mean the data was not accessed: it means no evidence of access has been confirmed, which is not the same as confirmed non-access.

What should businesses that used IDMerit do now?

Businesses that used IDMerit for identity verification should immediately assess which customers' data was processed through IDMerit, review their GDPR Article 33 notification obligations (72-hour clock from awareness), and engage legal counsel before making any public statement. Under GDPR Article 28, controllers remain responsible for their processors' security failures. Waiting for IDMerit to initiate disclosure is not a compliant response if you are already aware of the incident through media coverage.

Why is KYC data more dangerous to expose than other personal data?

KYC databases contain government-issued ID numbers, dates of birth, and address histories assembled specifically to prove identity. Unlike passwords or credit card numbers, national ID numbers cannot be changed after exposure. A fraudster with this combination can open financial accounts, apply for credit, execute SIM swaps to bypass two-factor authentication, and construct synthetic identities that pass verification checks. The damage from an exposed KYC record is permanent and compounds over time as the data is reused across fraud schemes.

Does centralized KYC architecture create data breach risk?

Yes, structurally. Any identity verification provider that retains customer PII after verification creates a concentrated repository of high-value identity data that is a permanent target. The IDMerit, AU10TIX, and Veriff incidents within 18 months confirm this is a systemic pattern, not an isolated accident. Decentralized KYC architectures, where data is shredded after verification and users control their own verified credentials, eliminate this class of exposure by removing the centralized data vault entirely.

What Remains Unclear

As of the date of this article, several material facts about the IDMerit incident remain unconfirmed. No regulatory authority has publicly announced an investigation or enforcement action. It is not confirmed whether IDMerit issued formal breach notifications to affected individuals or to the downstream businesses that used its platform for identity verification. The total duration of the database's exposure before Cybernews researchers discovered it on November 11, 2025 has not been publicly disclosed, meaning the window during which automated crawlers could have accessed the data is unknown.

It is also not confirmed whether IDMerit holds certifications such as ISO 27001 or SOC 2 Type II that would have required independent security audits capable of detecting this class of misconfiguration. No civil litigation has been filed as of February 2026. Whether any malicious actor accessed, exported, or monetized the exposed data remains an open question. Compliance officers should plan their response based on the confirmed exposure, not on the absence of confirmed harm.