Hello everyone,
Welcome to the 213th edition of The Pattern.
Yesterday, the Economic Times reported that India's banks have picked 25 technology vendors — companies whose software already runs across most of the sector — for partnerships on AI-related security risks. Alongside that, a working group led by SBI is building a framework to help lenders find weak spots. It includes nine banks, the finance ministry, the RBI, NPCI and CERT-In. Banks have also been told to shrink their attack surface, including by deploying defensive AI agents.
All of it is worth doing.
Unfortunately, none of it touches the three things that actually leave banks exposed right now.
I'll get to those. First, let’s unpack what they're defending against.
Attackers got faster, but the defenders didn't.
Ten days ago, MeitY, CERT-In, CSIRT-Fin and the security firm SISA published the second Digital Threat Report for India's banking and payments sector. Its central finding has an awkward name — ‘AI asymmetry’ — but a simple meaning.
Work that once needed a skilled team and several weeks can now be done by a cheap tool in minutes. Both sides are getting better at using AI. However, the problem is that the attackers are getting better faster. And this gap keeps widening.
Two cases show what that looks like.
In November 2025, Anthropic disclosed that a Chinese-linked group had used its Claude model to attack 30 organisations, including financial institutions. The AI ran up to 90% of the operation on its own. It was the first large cyberespionage campaign mostly run by a machine.
Then earlier this year, Anthropic pointed Claude Mythos Preview at more than 1,000 open-source projects. It flagged 23,019 flaws, and rated 6,202 of them high or critical severity.
India is feeling the volume. Cyber incidents in the banking sector rose from 1.4 million in 2021 to 2.9 million in 2025, and Indian institutions now face attacks at 1.6 times the global average.
Why everyone is a target now
There's a money story underneath this.
Ransomware gangs used to buy their break-in tools from specialist brokers. That cost real money, so they picked targets worth the spend. Now they generate those tools themselves with AI, cheaply.
When attacking gets cheap, the math of whom to attack changes. Being small or regional used to keep you fairly safe. Not because your defences were good, but because you weren't worth the trouble. That protection is gone.
How attacks work now
The report describes three patterns already showing up in Indian banking. Each breaks something banks assume.
Everything at once.
Attackers hit the internal network, staff email, cloud systems and vendors simultaneously. Most bank response plans assume you spot one intrusion, deal with it, then handle the next. That falls apart when there is no next.
No time to patch.
Attackers find flaws at machine speed. Banks are still slowed by change management, compliance sign-offs and approval queues.
Attacking the factory, not the product.
Instead of hacking an app, criminals go after the systems that build and ship the software.
Problem one: banks approve too slowly
That second pattern is the one that should worry a bank board.
And it isn't only a banking problem. Anthropic — whose model found those 23,019 flaws — says the bottleneck has moved. Progress used to be limited by how fast you could find vulnerabilities. Now it's limited by how fast you can verify, disclose and patch them. Of 530 serious bugs it reported to open-source maintainers, 75 have been fixed. Some maintainers have asked it to slow down, because they can't design patches fast enough to keep up.
Defensive AI agents genuinely help. They spot trouble and begin containing it at machine speed. That solves half the problem.
The other half sits behind them. An agent flags a critical exposure at 2am. The fix still waits for the change board, the compliance sign-off and the next maintenance window. Detection gets faster. Permission doesn't. No vendor sells a fix for that.
Problem two: banks don't know what's inside their own software
A working paper from the National Institute of Banking Management, published this month, makes a point worth sitting with. A bank can have excellent internal controls and still be exposed through a vendor, a fintech partner or a cloud provider.
Why? Because banks often don't know what's inside the software they've licensed — which open-source libraries, which AI-generated code, which borrowed components.
This is what made Log4j so painful in 2021. The US government's Cyber Safety Review Board studied how nearly 80 organisations handled it and found that system owners often had no idea where the vulnerable software was sitting inside their own environments. One federal department spent 33,000 hours on its response.
AI makes this worse in a specific way. When a developer writes code by hand, every product ends up slightly different. When AI writes it, the same chunks get reused across many products, because the same model given similar instructions produces similar output.
So picture an AI-generated flaw in a fraud-check function. Vendor A puts it in its onboarding product. Vendor B in its lending app. Vendor C in its payments tool. Twenty banks buy from those three vendors, believing they've spread their risk. They haven't. They're all carrying the same defect, and none of them has any way to know.
That's what makes the 25-vendor list worth reading closely. Those companies were chosen because their software is already in nearly every bank. Which is another way of saying Indian banking has gradually come to depend on the same handful of suppliers.
Getting closer to them makes sense. If a flaw turns up in their code, it's sitting in everyone's systems at once, so you want early warning. But a partnership means banks hear about the problem sooner. It doesn't change the fact that they're all running the same code. Better warning, same exposure.
Problem three: the attacker already has a key
Go back to that November attack, the one where AI ran 90% of the operation against 30 organisations. The AI never broke through anyone's defences. It had working login credentials from the start and simply operated from inside the network.
The biggest AI-run attack on record didn't get past the wall. It walked in through the front door with a key.
That changes what ‘security’ has to mean. If the attacker arrives holding valid credentials, a stronger perimeter is beside the point. What matters is whether anyone notices that a legitimate account is behaving strangely — and how quickly that access can be taken away.
Why lenders should care
The RBI has already put a number on the concern. In its June Financial Stability Report, it surveyed 33 banks and 10 large NBFCs. They ranked AI-enabled cyber threats as their single biggest risk for the coming year, above ransomware, phishing and vendor risk
The spending doesn't match the worry. Two-thirds hired more security staff over the past year. But 81% still spend under 5% of revenue on IT altogether.
For anyone running a digital lending business, this sits close to home. Almost none of a modern lending stack is built in-house. It's LSP integrations, cloud services, bureau connections, vendor scoring models, KYC providers. Heavy dependence on other people's code, thin security budgets, in a year when one flaw upstream can surface across many lenders at once.
Which brings us back to the Digital Threat Report, because it closes with a practical answer — an 18-month roadmap covering six layers of a bank. What stands out is where it points: almost none of it is about strengthening the perimeter.
Identity — password-less logins for every privileged user, and continuous checking that a session is still legitimate rather than trusting it once it starts
Transactions — extend monitoring and adversarial testing to newer financial infrastructure: tokenisation, smart contracts, digital asset custody
AI systems — verify where your model weights, training data and ML libraries came from, and block prompt injection at the point content enters the system
Platform — make identity the perimeter across cloud, SaaS and on-premise, replacing network-boundary access control
Vendors — get visibility into your vendors' vendors, the exposure that stays invisible when you only look one level down, and build the ability to coordinate incident response across institutions when a shared supplier is compromised
Assurance — begin post-quantum migration for long-lived data, and replace periodic control checks with continuous monitoring
The takeaway
The 25 vendor partnerships and the SBI framework are useful. They tackle real problems around concentration and coordination.
But they don't reach the three constraints this research keeps returning to. Banks approve fixes slower than attackers move. They can't list what's inside the software they already run. And the break-in increasingly isn't a break-in — it's someone logging in with credentials they shouldn't have.
Those are questions about how a bank works day to day: how fast it can say yes to a change, whether it knows what it's running, and how carefully it hands out and takes back access. Tools help with all three. None of them does the work for you.
Cheers,
Mayank
Reading list
- India's household debt rises to 45.5% of GDP; non-housing retail loans account for 58.4%, show data
- India's Private Lenders Bet on Corporate Loan Revival for Growth
- Your next UPI payment may not need the internet at all
- Shifting shape when economy goes K-shaped
Thank you for reading. If you liked this edition, forward it to your friends, peers, and colleagues. You can also connect with me on X here and follow FinBox on LinkedIn to get the latest updates
All opinions expressed are my own and do not necessarily reflect the views of FinBox or its promoters.
