Meta title: IDScan.net Breach: What Banks Should Know About Vendor Risk

Meta description: The IDScan.net breach highlights vendor risk in identity verification. Here’s what banks should review around retention, contracts and incident response.

Keywords

• Primary: vendor risk management for banks
• Focus: identity verification vendor breach
• Secondary: third-party risk banking, CIP rule compliance, bank vendor contracts

What the IDScan.net Breach Reveals About Banking Vendor Risk

What happened in the IDScan.net incident

In late August and early September 2026, a dark-web marketplace known as Nexus advertised a large collection of driver’s licenses, government IDs, travel documents and other sensitive records. Security journalist Brian Krebs investigated the dataset after finding his own driver’s-license information among the material. His reporting linked sample records to IDScan.net, an identity-verification provider, and IDScan.net later confirmed that an unauthorized third party may have accessed or copied customer information stored in its cloud platform. Krebs reported that the records associated with his license included front and back images, as well as infrared and ultraviolet captures. Those additional image types matter because document-authentication systems can use visible, infrared and ultraviolet imagery to assess whether an identity document is genuine.

For banks, the incident is less about one vendor than about a broader third-party risk question – when an identity provider stores highly sensitive documents, who decides what gets retained, where it is stored, who can access it and when it is deleted?

IDScan.net provides identity-verification services to organizations across multiple industries, including financial services. For banks and credit unions considering or using such services, that makes data retention and access controls important vendor-risk considerations. Its platform can involve the capture and storage of identity-document information, making data retention and access controls important vendor-risk considerations. Unlike a password, a driver’s license or government-issued identity document cannot simply be reset after exposure. That makes the security, retention and eventual deletion of this data particularly consequential for banks and their customers.

IDScan.net subsequently confirmed that an unauthorized third party may have accessed or copied certain customer information stored in its cloud platform. The company said its investigation was ongoing. Multiple proposed class actions have since been filed against the company, adding legal exposure to the operational and regulatory questions surrounding the incident.

What the CIP rule actually requires?

Here’s the distinction banks need to make. Federal customer identification rules require a bank to maintain specified records about the identification document it relied upon, including information such as the document type, identification number, place of issuance and applicable issue or expiration dates. The rule does not generally require the bank to retain a photographic copy of the document itself. Whether an ID image is captured and retained can instead depend on the institution’s processes, vendor configuration, contractual arrangements and other applicable requirements. The distinction matters. The absence of a general requirement to retain an ID image does not mean CIP has no recordkeeping requirements.

Vendor due diligence can easily frame retention as a convenience. Keeping an image may mean a customer does not need to resubmit documentation later, but it also creates a larger data footprint. Banks should therefore assess whether a vendor’s retention practices are necessary, documented and consistent with the institution’s own risk appetite, security requirements and regulatory obligations.

What your vendor contract should actually say

If customer information is determined to be involved, outsourcing its storage or processing does not automatically transfer the financial institution’s regulatory responsibilities. Financial institutions should assess their incident-response and notification obligations under applicable law and regulatory guidance, while reviewing the vendor contract to determine who is responsible for investigation, communications, notification support and related costs.

The practical move isn’t simply waiting for a vendor statement. Pull the contract and check whether it clearly addresses logging, data segregation, retention limits, deletion timelines, incident-notification windows and audit rights. Also look for provisions covering subcontractors, data location, encryption, forensic cooperation, cyber insurance, indemnification and liability limits.

If the contract is silent on retention and deletion, ask the vendor to document where identity data is stored, who can access it, how long it remains available and how deletion is verified. The objective is to make the vendor’s data-handling practices contractually visible rather than relying solely on assurances made during procurement.

What banks should ask their identity vendors now

The IDScan.net incident is a reminder that vendor risk begins with understanding exactly what a provider does with identity data after verification. Before renewing or signing an agreement, banks should ask vendors to document:

• Data collected: Which identity fields and image types are captured?
• Retention: How long are images and related data retained?
• Storage: Where is the information stored, and is it segregated by customer?
• Access: Which employees, systems and subprocessors can access it?
• Deletion: When is data deleted, and how is deletion verified across production systems, backups and archives?
• Security controls: What encryption, authentication, monitoring and access-logging controls protect the data?
• Incident response: How quickly must the vendor notify the institution after discovering an incident?
• Audit rights: Can the bank review relevant controls, reports and evidence?
• Liability: How are indemnification, insurance and liability limits handled if the vendor’s security failure creates losses?
• Exit procedures: What happens to customer data when the contract ends?

The objective is not simply to add contractual language. It is to make the vendor’s data lifecycle visible, measurable and subject to ongoing oversight.

FAQs

1. Do we need to notify customers if we haven’t confirmed our data was in the Nexus database?
2. Notification should not be treated as an automatic consequence of the marketplace listing alone. The institution should investigate whether its customer information was involved and assess its notification obligations under applicable federal and state laws and regulatory requirements.
3. Are we required to keep copies of scanned IDs under CIP rules?
4. CIP generally requires banks to maintain specified identification and verification records, but it does not generally require retention of a photographic copy of the identification document itself. Banks should distinguish the regulatory recordkeeping requirement from a vendor’s separate image-retention practice.
5. What should we ask an identity vendor before signing or renewing?
6. Ask for evidence, not assurances. What data is collected, where it is stored, who can access it, how long it is retained, whether subprocessors can access it, how it is encrypted and what “deleted” means across production, backup and archived systems.
7. Can we hold a vendor liable if their breach exposes our customers?
8. Potential contractual recovery depends on the agreement’s indemnification, liability, insurance and limitation-of-liability provisions, as well as applicable law. Banks should have counsel review these provisions before assuming a vendor will absorb breach-related costs.
9. Does closing the marketplace mean the data is gone?
10. No. Removing a marketplace listing limits public access, but it does not establish that the underlying files were deleted or that copies were not distributed elsewhere. Institutions should rely on forensic findings and verified deletion information rather than assuming that removal of a listing resolves the exposure.

Sources

American Banker, “Bank ID vendor traced to a dark web license sale,” Sept. 4, 2026: https://www.americanbanker.com/news/bank-id-vendor-traced-to-a-dark-web-license-sale

KrebsOnSecurity, “FBI Probes Service Selling 153M+ Drivers Licenses,” Sept. 2026: https://krebsonsecurity.com/2026/09/fbi-probes-service-selling-153m-drivers-licenses/

Code of Federal Regulations, Customer Identification Programs for Banks, 31 CFR 1020.220: https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-B/section-1020.220

https://idscan.net/press-release/notification-of-data-security-incident/?utm_source=chatgpt.com