State Bank of India has told its stock exchanges that 3,897 customer records containing personal data turned up among roughly 375,000 records circulating on the dark web, a figure that matches a dataset advertised on BreachForums. The bank has not named a cause or confirmed where the data came from, and the details it has disclosed are exactly what phone and message fraudsters need.
What happened
On Wednesday 21 October, India’s largest lender filed a disclosure with the exchanges saying it “has experienced an incident involving the loss of certain data”. According to the filing, SBI was warned on 16 October by its threat intelligence supplier, by the national computer emergency response team and by the military’s Defence Cyber Agency. A first review of about 375,000 records circulating on the dark web found 3,897 that contained personally identifiable information about customers.
That same day, the X account CyberPulse56 had flagged a post by a threat actor calling itself Siriusim. The actor claimed to hold around 375,000 rows of CSV data and 2,722 PDF documents linked to SBI, described as loan applications, supporting paperwork, account-opening forms and address details. Reporters at Mumbai’s Free Press Journal looked at four sample records attached to the BreachForums listing and found that the phone numbers worked. Four records cannot prove that the whole set is genuine or show where it came from, and SBI’s filing makes no link between its own analysis and the Siriusim post.
SBI says it has activated incident response and containment and brought in an independent firm from the national CERT’s panel of approved auditors. It says the incident has had no material impact on its core operations, financial performance or business continuity. Dark Reading reported on 23 October that the bank had told customers only “a very, very small number of customers” were involved.
The detail
The fields SBI lists are names, gender, dates of birth, registered mobile numbers, email and home addresses, branch codes, CIF numbers (the internal customer information file identifier), lead IDs and metadata about loans and leads. According to Dark Reading, follow-on reporting has also mentioned Central KYC numbers, video KYC material and statements of employment and income, though the bank’s own list does not include these. As The Hacker News points out, the filing does not mention account numbers, balances, passwords, one-time passcodes, card data or national identifiers such as PAN and Aadhaar.
Several important questions are still open. SBI has not said whether 3,897 records means 3,897 people. It has not said whether the data came from its own systems, a subsidiary, or a third party that processes loan applications for it. The lead and loan metadata does suggest a peripheral channel such as a lending, marketing or onboarding platform rather than the core ledger, but that is an inference, and the bank has not confirmed it.
In 2019, SBI left customer account data exposed through an unsecured server in a Mumbai data centre that supported its SBI Quick service. And in a filing on 27 July this year, Bank of Baroda used almost identical wording about an alleged compromise, that time citing possible business email compromise. Such notices reveal little.
Why it matters for UK organisations
To be clear first: nothing published so far suggests that UK customers are affected. SBI has a British arm, State Bank of India (UK) Limited, a wholly owned subsidiary set up in 2018. It has 11 retail branches and is authorised by the PRA and regulated by the PRA and FCA. The fields described in the leak, such as domestic branch codes, CIF numbers and local loan leads, appear to point to the parent’s domestic business. Where SBI UK customers do face a real risk is scammers taking advantage of the headlines. A caller citing the breach needs no stolen data to sound plausible.
The wider UK lesson is about what this sort of data makes possible. A name, mobile number, date of birth, address and a genuine internal customer ID are exactly what an authorised push payment fraudster wants. Dark Reading cites earlier research by Brian Hussey’s team at Cyderes into a data broker in India selling individual lookups for about five rupees through a Telegram bot. Breach data feeds that market. UK banks and payment firms that serve diaspora communities, and that process international remittances, should expect impersonation campaigns that combine data from overseas breaches with UK contact details.
There is also a lesson about governance. Under UK GDPR the test is the risk to individuals, not the impact on operations: a breach must be reported to the ICO within 72 hours unless it is unlikely to pose a risk to people, and where the risk is high those affected should be told without undue delay. SBI’s filing was written for investors and does not itself say whether affected customers will be told. A UK board that drafted its incident communications with only the market in mind could find that harder to justify to the ICO.
Expert view
In my experience, the data that leaks from banks rarely comes from the core banking platform, which tends to be the most heavily defended system they run. It comes from the edges: loan origination portals, CRM exports, agency lead lists, document upload buckets and the systems of third parties that handle applications. When we test these environments, we often find KYC documents kept long after they are needed and open to far more staff and suppliers than necessary.
The other thing to notice is how long the sequence took. The bank heard about the leak from outside, on the same day the claim appeared on social media, and five days later it still could not say where the data came from. That is common, and it is why you need an inventory of where personal data lives, including supplier copies, before an incident.
What to do now
- Map your data edges. List every system and supplier that holds KYC documents, loan applications or lead data, and remove anything you no longer need.
- Restrict access. Limit document stores and CRM exports to named roles and enforce MFA everywhere. This lines up with the Cyber Essentials user access control and secure configuration requirements.
- Watch for your data. Subscribe to dark web and forum monitoring for your brand and domains so that a claim like Siriusim’s reaches you first.
- Rehearse attribution. Be ready to compare leaked samples against your own datasets and your suppliers’ quickly, using field formats, internal IDs and watermark records.
- Warn customers early. Remind them that you will never ask for passcodes or payments over the phone, and give them one trusted number to call back.
- Write for two audiences. Prepare separate incident statements for investors and for affected individuals, and decide within 72 hours whether to notify the ICO, recording your reasons.
Bottom line
SBI’s leak looks small next to its customer base, but the data involved is ideal for convincing impersonation, and the bank still cannot say where it came from. For UK firms, the lesson is to know which suppliers and peripheral systems hold your customers’ identity data, and to tell those customers clearly and early when something goes wrong.
