Fintech Weekly Deep Dive — SBI’s 3,897 Records: Exposure, Notice and the Accountability Gap | Week of October 19–25, 2026

Executive Summary

On October 21, State Bank of India (SBI) told the stock exchanges that a preliminary review of about 375,000 records found online had identified 3,897 customer records containing personal information. The bank said it had received alerts on October 16 from its threat-intelligence provider, the Defence Cyber Agency and CERT-In, and had hired an independent CERT-In-empanelled firm to investigate. On October 23, SBI said it had individually informed customers whose information it had identified, by email and/or WhatsApp. The source, authenticity and completeness of the material remain under investigation.¹²

The most widely repeated version of the story is not yet established. A threat actor calling itself “Siriusim” claimed to have 375,000 rows and 2,722 PDF files allegedly linked to SBI or its subsidiaries. SBI’s filing confirms neither the actor’s identity nor those files. Our verification pass on 19 October did not locate an independently captured forum listing, so we treated the actor’s full-payload claim as unverified. SBI’s later filing separately confirmed 3,897 customer records containing personal information within an approximately 375,000-record set it reviewed. That narrows the story; it does not authenticate the alleged 2,722 PDFs or establish that 375,000 unique SBI customers were affected. A record count is not a unique-customer count.¹²³

This is the week’s most consequential fresh consumer story because it joins an identifiable bank disclosure to a practical notification gap. The Digital Personal Data Protection Act’s direct breach-notice duty is not scheduled to take effect until May 2027. Existing cyber-reporting rules chiefly require notices to authorities; they do not by themselves tell customers what happened. SBI’s October 23 statement was therefore important, though the public still lacks a clear account of what each recipient was told, when messages were sent, or how many unique people were involved. An exposed data record does not show that an account was accessed or money stolen. It can, however, make an impersonation call much more convincing.

The Story in Depth

Context: one verified disclosure, one unverified claim

The story began in public with a forum post, not with a completed bank investigation. On October 16, an account using the alias “Siriusim” was reported as claiming to have 375,000 records and 2,722 PDFs allegedly linked to SBI and possibly its subsidiaries. A Free Press Journal reporter examined a small number of publicly posted samples and said some details appeared to correspond to real people. That limited check did not establish where the data came from, whether the entire dataset was genuine, or whether SBI systems had been accessed.²

Our own breach-verification ledger recorded the allegation on October 19 as an L0 claim: a claim had been made, but the original listing was not located in the public sources checked. We did not download the alleged customer files. This matters for two reasons. First, examining a few samples can show that some fields look plausible; it cannot authenticate hundreds of thousands of rows or identify the institution that supplied them. Second, circulating or downloading files that may contain KYC and loan documents would multiply the privacy harm without helping customers establish what happened.

On October 21, SBI filed a Regulation 30 disclosure with BSE and NSE titled “Incident involving Data Loss”. The filing is the strongest public evidence in this story because it is the bank’s own statement to the exchanges. It says alerts arrived on October 16; an initial review of approximately 375,000 records available on the dark web identified 3,897 customer records containing personally identifiable information; and the authenticity, completeness, source and extent of the material still needed investigation. SBI said it had activated incident-response and containment protocols and engaged an independent cybersecurity agency empanelled by CERT-In. It also said there was no material impact on core operations, financial performance or business continuity.¹

Those are different statements with different evidentiary weight. SBI has confirmed that its preliminary review identified customer records in a dataset it examined. It has not publicly established the route by which those records left its custody, whether a vendor or another organisation was involved, or whether the full online collection is attributable to SBI. “No material impact” is the bank’s assessment of operations and finances; it does not mean that personal data creates no risk for the people named in the records.

What happened this week

The bank’s public update moved the story beyond its investor filing. On October 23, SBI said it had individually informed all customers whose data it had identified, through email and/or WhatsApp. It also said account balances and funds were safe and urged people not to share OTPs, PINs or passwords, and to be cautious of suspicious calls, messages and emails.⁴

That update followed the Internet Freedom Foundation’s October 21 criticism that SBI’s filing described the impact on the bank but did not say whether the affected customers had been contacted. IFF asked for direct notices with an explanation of the data involved and a route for customers to seek help. The sequence matters, but it does not prove that the criticism caused SBI’s later communication. Nor does the public statement establish that every message was delivered or read: SBI has not published a dispatch count, message text, helpline, or recipient-specific account of which fields were identified for each customer.⁵

The initial notice and the later update should be read together. The October 21 exchange filing was addressed to investors and stated the bank’s preliminary position. The October 23 statement addressed customers at a general level and said individually identified customers had been contacted. That is a meaningful step. The remaining gap is specificity: customers need to know what information relating to them was identified, what threat follows from that information, how to verify a genuine SBI message, and where to report a suspicious approach.

Why the record count is not the impact count

SBI’s two numbers describe different things. The approximately 375,000 figure is the size of the dataset it says it reviewed. The 3,897 figure is the number of customer records in that review that its preliminary analysis identified as containing personal information. Dividing the second by the first gives roughly 1.04% of the reviewed records. That is a proportion of records, not a verified share of affected customers or of SBI’s customer base. Duplicate rows, incomplete records and records referring to people other than SBI customers could change the relationship between rows and people.

The filing lists registered mobile numbers, dates of birth, names, gender, email and residential addresses, branch and Customer Information File identifiers, lead IDs, and metadata linked to loan and lead records. It does not identify passwords, card credentials or transaction PINs in the list it disclosed. That omission is not proof those fields are absent from every file claimed online; it is a limit on what the public filing confirms. The wider actor claim about 2,722 PDFs, including loan or account-opening documents, remains unverified by SBI.¹²

This distinction changes the consumer response. The disclosed fields can help a caller impersonate a bank employee, refer to a branch or a loan enquiry, and pressure a person into sharing an OTP or following a link. That is a plausible social-engineering risk, not evidence that such fraud has happened in this incident. A name and contact details do not themselves authenticate a caller. A person who receives a data-exposure notice should not infer that their account was accessed; equally, an assurance about account balances does not answer whether identity information could be misused.

The rules: reporting an incident is not the same as telling a customer

India has several reporting layers, and they serve different audiences. CERT-In’s 2022 directions require covered organisations to report specified cyber incidents, including data breaches and data leaks, within six hours of noticing them or being brought to notice. Its FAQ says organisations may submit the information available at the time and provide additional details later. RBI’s 2016 Cyber Security Framework tells banks to report unusual cyber-security incidents promptly to the central bank; its reporting template asks for incident detection time, systems affected, customer impact, root cause and mitigation. RBI’s 2023 IT governance directions also require board-level oversight, cyber-incident response and recovery arrangements, and risk controls that account for third-party arrangements.⁶⁷⁸⁹

These duties do not permit a conclusion about SBI’s compliance from the public dates alone. The bank says it received communications from CERT-In and other alert sources on October 16. The public filing followed on October 21. The filing date is not the same as the time SBI notified CERT-In or RBI, and the public record we reviewed does not state when those regulator reports were made. The six-hour rule is about reporting to CERT-In, not a six-hour deadline for a bank to publish an exchange filing or contact every customer. Without the incident timeline and regulator reports, the five calendar days between the stated alert date and the exchange filing do not prove a reporting violation.¹⁶⁷⁸

The direct-to-customer rule under the DPDP Act is on a later clock. Section 8(5) sets a security-safeguard duty and Section 8(6) provides for notices to the Data Protection Board and each affected person. The Act’s commencement notification and the Digital Personal Data Protection Rules, 2025 phase the substantive obligations in; Rule 7’s breach-notification procedure is scheduled to commence 18 months after publication of the Rules, in May 2027. The fact that the framework has been notified does not make every duty enforceable today.¹⁰¹¹¹²

IFF also cited an RBI document titled Advisory No. 3/2026, dated March 25, as recommending customer communication after data incidents. That source needs a caveat: MediaNama published a copy and described its customer-notification and incident-response guidance, but its article said it was still verifying the document because it was not available on the RBI website. We did not locate a corresponding official RBI publication during this review. It would be wrong to treat the copy as a binding RBI direction or as independently authenticated policy. The gap between regulator reporting and customer notice is therefore real in the statutory framework; the status of this purported advisory is a separate open question.⁵¹³

The practical test is not whether SBI’s current conduct can be judged under a future rule. It is whether regulators and banks use this transition period to establish clear, verifiable customer-notification practice before the DPDP timetable reaches May 2027. The 2016 RBI framework already expects banks to assess customer impact and report incidents promptly. A notification standard that arrives only after a major event is less useful to the people who need to respond to it.

Data & Metrics

• Timeline: SBI says it received alerts on 16 October; it informed stock exchanges on 21 October and said on the 23rd that identified customers had been contacted. The public record does not state the times of regulator reports or individual messages.¹⁴
• Reviewed set: About 375,000 records were available on the dark web. SBI’s preliminary review identified 3,897 records with PII, not a confirmed count of unique people.¹
• Ratio: 3,897 divided by 375,000 is about 1.04% of the reviewed record count, not an SBI-customer breach rate; the counts may not represent unique people.¹
• The 2,722-PDF figure remains a separate threat-actor claim. SBI has not verified those documents.¹²
• Notice channel: Email and/or WhatsApp. No dispatch count, sample notice or delivery confirmation is public.⁴

The source labels are as important as the figures. The 3,897 count is a preliminary bank finding; the 375,000-record and 2,722-document figures originated in an actor claim and were not confirmed as a complete SBI dataset. The first is not a final count of people. The second and third should remain attributed claims until SBI or an independent investigation substantiates them.¹²

Expert Views

Kaspersky researcher Saurabh Sharma, quoted by The Hindu, said, “Data does not need to be fresh to be valuable.” He was describing how criminals bundle and reuse stolen information, not asserting that SBI customers have already been targeted. Names, addresses and dates of birth can make a later impersonation more believable, and KYC documents can be repurposed for identity fraud. Those are risks tied to the reported data types, not findings that fraud occurred in this case.¹⁴

A Mint analysis quoted bank cybersecurity leaders on the work an investigation should measure. Kotak Mahindra Bank’s Abhijit Chakravarty said the first day after a suspected breach should focus on containment, impact assessment, preserving evidence, regulatory readiness and communication. For boards, he pointed to detection, containment and recovery time, customer impact, notification compliance and speed of remediation. The same article quoted Yes Bank’s Mahesh Ramamoorthy on reviewing vendor access and applying least-privilege controls. Those are useful tests for SBI’s final report, not evidence that any specific control failed here.¹⁵

IFF’s contribution is a rights-and-remedy perspective: a disclosure written for the market can leave the affected person without the information needed to defend against targeted fraud. Its initial statement asked SBI to notify customers directly. SBI later said that it had done so. The next question is whether those notices were sufficiently specific and whether customers could obtain further help.⁵

Consumer Impact

If you bank with SBI, follow the bank’s own warning: do not share an OTP, UPI PIN, card PIN or password with anyone who calls or messages you. A caller may know your name, branch or that you once enquired about a loan; those details do not prove the caller works for SBI. Stop the conversation and contact the bank through the number in the official app, on your card, or on SBI’s website. Do not use a phone number or link supplied by the unexpected caller.

If you receive a message saying you are one of the customers identified, verify it independently before replying or opening a link. SBI has said notices were sent by email and/or WhatsApp, but the public statement does not give a customer-verification page or the exact message format. Ask SBI through an official channel what information relating to you was identified. Check account and transaction alerts. A data exposure alone is not a reason to assume that a password or payment credential was stolen; change credentials promptly if SBI confirms they were involved, or if you see suspicious access.

If you spot an unauthorised transaction, contact SBI immediately and report the suspected cyber fraud through India’s National Cyber Crime Reporting Portal or helpline 1930. RBI’s customer-liability rules apply to unauthorised electronic transactions and turn on the facts and reporting time; they do not automatically convert every data exposure into a compensated loss. Save the bank notice, messages, call logs and complaint number. Do not share those records publicly if they contain account or identity details.¹⁶¹⁷

Looking Ahead

SBI’s investigation should answer five questions in a public, privacy-preserving update: how many unique people were identified; which data fields were associated with each person; whether any records or documents beyond the 3,897 were verified; where the material came from, including any vendor or lending partner; and what containment and remediation followed. The bank should also state the notice date and channels at an aggregate level, publish a safe contact route for affected customers, and explain whether any suspicious activity has been linked to this incident. It can do that without publishing names, account numbers or raw customer files.

The regulators should clarify which incident reports they received and what customer-facing practice they expect while the DPDP breach-notice provisions remain in their transition period. Any review of compliance must use the actual timestamps and evidence, not the interval between a bank alert and a public filing. The DPDP Act and Rule 7 should arrive with plain-language templates, translated notices and a way for customers to confirm that a message is genuine. Banks need to test those processes before a notification clock becomes enforceable.

For customers, the useful lesson is narrow: a bank saying “funds are safe” addresses access to balances, not every risk from exposed identity and loan data. For SBI, the measure of the response will be whether the final account lets affected people understand their own exposure and seek help without navigating the dark web or a press release.

Sources