AU Small Finance Bank Data Leak: Hackers Threaten to Expose Aadhaar and Customer Records

A reported cyber incident involving AU Small Finance Bank has raised fresh concerns about the security of sensitive customer information and the risks that can emerge through third-party technology platforms. A hacking group calling itself Scarlett Group has claimed that it accessed customer and internal records and has threatened to publish the data. The claims reportedly include Aadhaar and PAN details, KYC documents, credit reports, bank statements, and loan-related information. However, the alleged dataset and the full scope of exposure have not been independently verified.

The issue was covered by India Today’s report on the AU Small Finance Bank breach claims, which highlighted the hackers’ threat to expose Aadhaar and customer records. The story is not just another banking cybersecurity headline: it also illustrates why organizations must assess the security of every external platform that stores or processes customer information.

AU Small Finance Bank has said that it is investigating a potential data leak involving a software-as-a-service (SaaS) platform managed and hosted by Salesforce. The bank has clarified that the platform holds limited information relating to its vehicle loan customers, while its own banking systems remain unaffected, and banking services continue to operate normally. The confirmed fact is that an investigation into a potential leak is underway—not that every detail claimed by the attackers has been proven.

What Happened in the AU Small Finance Bank Incident?

Reports about the incident emerged on October 30, 2026, after cybersecurity monitoring account Hackmanac flagged a claim attributed to Scarlett Group. The group alleged that it had breached AU Small Finance Bank’s cyber defenses and threatened to leak customer and internal corporate information. Reports described a negotiation deadline and the possibility of public release if its demands were not met. These statements originate from the threat of an actor’s claims and should not be treated as independently established facts.

In its coverage, Reuters reported that AU Small Finance Bank was investigating a potential data leak on a platform holding limited vehicle-loan customer information. The bank’s initial response said its own systems were unaffected and that all banking services were operating normally.

Moneycontrol also reported that the investigation concerned a third-party Salesforce-hosted SaaS platform used for vehicle-loan customer information. Read the Moneycontrol report on the potential AU Small Finance Bank data leak.

The incident should be understood in two separate layers: the bank has acknowledged a potential data leakage issue involving a third-party platform, while the broader list of data allegedly held by the hackers remains unverified. That distinction matters for accurate reporting, customer communication, and compliance analysis.

What Information Do Hackers Claim to Have?

According to claims attributed to Scarlett Group and relayed by cybersecurity monitoring sources, the allegedly accessed information may include several categories of personal, financial and operational data. These categories have been reported in the media, but the bank has not confirmed that every item listed by the attackers was exposed:

• Identity and KYC information: Aadhaar details, PAN details and customer KYC documents.
• Financial information: bank statements, credit reports, and CIBIL-related information.
• Vehicle-loan documentation: loan applications, signed agreements and related customer records.
• Insurance and customer relationship records: insurance documents and CRM data.
• Internal business information: employee details, login histories, IP-related information, and audit logs.

The Mint report on the alleged Aadhaar, PAN and customer-record exposure summarized the categories attributed to the attackers and noted that the scope of the alleged leak remained unclear. The Economic Times also reported that verification was still pending.

If identity documents and financial records are exposed, the potential consequences can extend beyond immediate financial fraud. Personal information can be combined and reused for targeted phishing, impersonation, fraudulent loan or account-related approaches, social engineering, and identity misuse. These are possible risks associated with such data categories—not confirmation that these activities have occurred in this incident.

What Did AU Small Finance Bank Confirm?

A later clarification to the stock exchanges provided more details about the platform under investigation. In its November 2, 2026, filing, AU Small Finance Bank said it became aware of a potential data leakage incident on October 29. The third-party SaaS platform is used for onboarding vehicle-loan customers and contains information collected during the loan onboarding process.

The bank stated that preliminary findings indicated that the incident may have resulted in data leakage involving some vehicle-loan customers. It said around 28.5 lakh customers had been onboarded through the platform, and that a detailed internal and external forensic investigation—with support from leading cybersecurity firms—was underway to determine the nature and extent of any potential leakage. This figure describes the number of customers onboarded through the platform; it should not be described as the number of confirmed affected customers.

The bank also said its other systems remained unaffected, services were operating normally, and the incident had no impact on business operations, financial performance or business continuity. It stated that the matter had been reported to regulatory authorities, including the Reserve Bank of India (RBI) and CERT-In, in accordance with applicable requirements.

For additional context, The Economic Times reported on the bank’s November 2 clarification and the ongoing forensic investigation.

Salesforce separately said it had not identified a vulnerability in its platform related to the issue, based on the information then available. That statement does not by itself establish how the alleged data exposure occurred, whether access was obtained through credentials, configuration, integration or another route, or whether any data was actually exfiltrated.

Why This Incident Is Also a Third-Party Risk Management Issue

One of the most important lessons from the AU Small Finance Bank incident is that customer data does not always sit inside an organization's own infrastructure. Banks and other regulated businesses rely on SaaS providers, cloud platforms, customer relationship management systems, onboarding tools, payment processors, and specialist service providers. These platforms support essential workflows, but they can also create additional paths through which sensitive information may be exposed.

This is where third-party risk management (TPRM) becomes central to cybersecurity compliance. A vendor may meet an organization's requirements when a contract is signed, but its security posture, access model, subcontractors, integrations and operational practices can change over time. A one-time questionnaire is not enough to provide continuous assurance.

"The AU Bank case demonstrates why organizations need continuous visibility into the data shared with third parties, the controls protecting it, and the process for responding when a supplier-related security concern emerges."

— Telemetria Risk Intelligence Desk

Key Compliance and Security Lessons for Banks and Financial Institutions

• 1. Maintain a complete third-party inventory: Maintain an up-to-date register of vendors, SaaS platforms, cloud services, subprocessors and business owners. Identify which providers can access customer information, what data they process, where it is stored and which business processes depend on them.
• 2. Classify data before sharing it: Aadhaar, PAN, KYC files, financial statements, and loan documents require careful handling. Data classification helps teams apply proportionate safeguards, restrict unnecessary sharing, and define retention periods. Data minimization should be built into onboarding workflows.
• 3. Perform risk-based vendor due diligence: Assess a provider’s security governance, access controls, encryption practices, incident response capability, independent assurance reports, subcontractor arrangements and data-handling procedures. A vendor processing identity and financial records warrants deeper scrutiny.
• 4. Monitor vendor risk continuously: Track security incidents, changes in vendor infrastructure, subprocessors, assurance expiry dates, unresolved findings and changes in service scope. Continuous monitoring helps identify material changes between periodic assessments.
• 5. Enforce least-privilege access and strong identity controls: Limit access to authorized users and business purposes. Multi-factor authentication, role-based access control, privileged access reviews, secure API integrations, session monitoring and prompt deprovisioning can reduce unauthorized access.
• 6. Keep audit-ready evidence: Record vendor assessments, identified risks, approvals, exceptions, remediation requirements, and closure evidence. Centralized evidence, clear ownership, and time-stamped records make audits and incident reviews more reliable.
• 7. Prepare a joint incident response process: Define vendor notification timelines, evidence preservation, investigation responsibilities, regulatory/customer notification assessment and recovery coordination. Tabletop exercises should include third-party SaaS incidents, not just internal network attacks.

How Compliance Teams Can Turn This Incident into Action

Financial institutions can use incidents like this to test whether their third-party risk programme works in practice. Security, procurement, privacy, legal and compliance teams can review the following critical questions:

• Do we know every SaaS provider that stores or processes customer, identity or financial information?
• Are vendor access permissions reviewed regularly and removed when no longer required?
• Do vendor contracts define incident notification timelines, evidence preservation and cooperation requirements?
• Are high-risk vendors reassessed when their services, integrations or data access change?
• Can we quickly identify which customers, records and business processes may be affected by a vendor's incident?
• Can we produce current vendor assessments, remediation records, approvals, and audit evidence without searching disconnected systems?
• Have we tested our incident response plan for a breach involving a third-party platform?

These questions connect cybersecurity operations with compliance management. A mature programme does not simply collect vendor questionnaires; it links risks to owners, controls, remediation tasks, monitoring signals and evidence that can be reviewed by auditors and leadership.

How Telemetria Supports a More Structured Third-Party Risk Programme

The AU Small Finance Bank incident highlights why organizations need a structured way to assess and monitor external risk. Telemetria, an AI-powered third-party risk and supply-chain risk management platform, helps organizations bring vendor assessments, risk intelligence, compliance activities and monitoring workflows into a more centralised process.

With capabilities designed around vendor onboarding and assessments, risk scoring, continuous monitoring, compliance mapping and reporting, Telemetria can help teams organize vendor risk information, track findings and maintain audit-ready evidence. This supports a more consistent approach to third-party risk management across the vendor's lifecycle.

A platform such as Telemetria does not guarantee that a breach will be prevented, and it should not be presented as a tool that would have prevented this specific incident. Its value is in helping organizations improve visibility, accountability, and ongoing oversight of third-party risk.

Learn more about Telemetria’s third-party risk management platform and how it supports vendor risk management, compliance workflows, and continuous risk oversight.

The Role of ShielderSoft

Telemetria is a product by ShielderSoft, a cybersecurity-focused technology company. ShielderSoft works across cybersecurity and technology solutions, while Telemetria focuses on helping organizations manage third-party risk, vendor security and compliance processes.

As organizations expand their digital ecosystems, strong security requires more than protecting internal systems. It also requires understanding the risks introduced by every external platform, service provider, and business partner that handles sensitive information.

Conclusion: Third-Party Visibility Is Now a Core Part of Data Protection

The AU Small Finance Bank data leak reports underline the growing importance of third-party security in financial services. The bank has confirmed that it is investigating a potential data leakage incident involving a third-party SaaS platform used for vehicle-loan onboarding. It has also stated that its other systems and banking services remain unaffected, and that a forensic investigation is underway. Meanwhile, the more extensive claims made by the hackers—including the alleged Aadhaar, PAN and financial records—remain unverified.

For banks and other organizations, the broader lesson is clear: data protection and compliance must extend across the entire vendor ecosystem. A strong third-party risk management programme combines due diligence, data minimization, access governance, continuous monitoring, incident response, and audit-ready evidence. Organizations that can see and manage these risks consistently are better prepared to respond when a supplier-related security concern emerges.

Frequently Asked Questions (FAQs)