RBI now wants banks to prove their API controls work in practice, not just on paper. The Mumbai NBFC heist shows why the question at the heart of security has to change: not “was this login valid?” but “should this action be happening at all?”
In October, two Mumbai-based NBFCs reportedly lost around $2 million across more than 700 transfers in under 48 hours. The attackers didn't break encryption. They didn't drop ransomware. No alarm went off in a SOC.
They used valid credentials to call a loan-disbursement API connected to a partner bank. To every system in the chain, each of those 700 transfers looked exactly like a normal payout.
That is what makes this incident worth every BFSI leader's attention. Nothing was broken into. Everything was authorized.
It has also caught the regulator's attention. This month, the Reserve Bank of India reportedly stepped up its cyber scrutiny of banks, with reports linking the move to this incident. Banks are being asked to examine the APIs that connect them with NBFCs and fintechs, and to show evidence that their controls work in practice, not just on paper.
Indian finance has been rebuilt around APIs. Banks expose disbursement and payment rails to NBFCs. NBFCs plug in lending service providers, onboarding partners and fintechs. Engineering teams automate all of it through cloud pipelines, so a loan can move from approval to a borrower's account in minutes.
It works because every link trusts the one next to it. And every link holds something an attacker wants: an API key, a service account, a token, an engineer's cloud session. Any of these can move money.
So when one of those keys is stolen, the attacker doesn't look like an intruder. They look like a trusted partner doing their job. Firewalls let them through. OTP checks never fire, because no customer is involved. Fraud rules see amounts that are individually unremarkable. By the time someone reconciles the books, the money has cleared.
This is not an Indian anomaly. It is the most profitable playbook in financial crime today.
In February 2025, crypto exchange Bybit lost about $1.5 billion in a single transaction. The FBI attributed it to TraderTraitor, a North Korean group. The attackers never touched Bybit's keys directly. They compromised a developer's machine at a third-party wallet vendor and tampered with the interface Bybit's signers relied on. The signers approved what looked like a routine transfer.
The Mumbai NBFCs and Bybit look nothing alike on the surface. One is a lending business on Indian payment rails; the other is a global crypto exchange. Underneath, the attack is the same:
Get a trusted identity. A partner's API key, a service account, or an engineer's laptop.
Reach the system that authorizes payouts. A disbursement API, a signing service, a payment batch processor.
Move money faster than any human can review it. Hundreds of small transfers, or one large one that looks routine.
Erase the trail. Clear logs, kill containers, disappear before forensics begins.
There are two doors into this room: a compromised partner from outside, or a compromised engineer from inside. Both lead to the same place, the point where money gets authorized.
Most security programs in BFSI were built to answer one question: was this access valid? Is the IP clean? Is the certificate current? Did the user pass OTP?
In every attack above, the answer was yes. The credentials were real. The access was valid. That question can't catch an attacker who already holds the keys.
The question that matters now is: should this action be happening at all?
| What security checks today | What it needs to ask instead |
|---|---|
| Did the request come from an allowed IP? | Why is a payout request arriving with no customer session behind it? |
| Did the user pass OTP? | Why is a script calling the disbursement API, not our app? |
| Is the transaction under the limit? | Why is disbursement volume four times the normal level at 2 a.m.? |
| Is the partner's API key valid? | Why is this partner suddenly sending payouts to accounts it has never paid before? |
| Did the engineer log in successfully? | Why is an engineer's session touching the payment signing service at all? |
None of these questions can be answered by looking at one log in isolation. Each requires connecting identity, API activity, transaction behavior and infrastructure into one picture, and doing it before the money settles, not during the post-mortem.
This is the problem Netenrich's Autonomous Security Operations (ASO) is built for. Instead of waiting for an alert that says "breach," ASO continuously connects the signals that, together, reveal an attack in progress: who is acting, what they are touching, how that compares with normal behavior, and what it puts at risk.
A partner key behaving unlike that partner. A service account calling an endpoint it has never called. A disbursement burst with no customer sessions behind it. On their own, each is easy to miss. Connected, they tell a story, and ASO surfaces that story while there is still time to stop the money.
That is the shift: from finding out what happened to stopping what is about to happen. Before it became a compromise.
RBI's latest push names the controls it expects to see working: stronger machine-to-machine authentication, partner due diligence, transaction limits and real-time monitoring of unusual activity. It is also asking how banks are preparing for attacks that use AI tools. And under the 2026 directions, regulated entities must report cyber incidents to RBI within six hours of detection.
Every one of those is the right ask. But each can be met on paper and still miss the Mumbai attack. Valid keys pass authentication. Hundreds of individually unremarkable transfers stay under the limit. Monitoring that reads each log on its own sees nothing unusual. Proof means showing that your controls catch an action that shouldn't be happening, even when every credential checks out.
That proof is what Netenrich is built to produce. Netenrich delivers the See it and Prove it side of Autonomous Security Operations, and it looks at three things together:
Attack Surface. Everything that could give an attacker a path to your money, inside and out: partner and fintech APIs, service accounts, tokens and other non-human identities, and third-party SaaS connections. Netenrich maps how each one connects to crown-jewel systems such as disbursement and payments, shows the blast radius if any is compromised, and tracks how that exposure drifts as new partners come on.
Are our non-human identities quietly giving third parties a path to our money?
Controls. Whether the identity, API and detection controls you already own actually deliver the coverage they promise. Netenrich tests them with simulated adversary techniques, such as credential misuse by a service account, and shows which threats they are blind to and whether the telemetry they depend on is reaching your SOC.
Are our security tools actually catching what they promised to catch?
Threats. Who is targeting institutions like yours right now, and how they would get in. ACT correlates live campaigns, such as credential abuse of payout APIs, to the exposures and control gaps you actually have, so your team knows what to fix first.
Who is targeting us right now, and how will they get in?
Findings are mapped to compliance requirements and kept current on a live dashboard, so readiness is something a bank can show RBI at any point, not a file it assembles before an inspection.
| What RBI is asking for | What proof looks like in practice |
|---|---|
| Stronger machine-to-machine authentication | Every partner key and service account mapped to the endpoints it normally calls, with an alert the moment it calls anything else |
| Partner due diligence | Every partner connection mapped to what it can reach and the blast radius if it is compromised, kept current as partners change, not frozen at the onboarding questionnaire |
| Transaction limits | Transaction behaviour correlated with identity and API activity, so 700 transfers under the limit still look as wrong as they are |
| Real-time monitoring of unusual activity | Identity, API, transaction and infrastructure signals connected into one investigation before settlement |
| Readiness for AI-enabled attacks | Detection and response that work at machine speed, because the attacks now do |
| Incident reporting within six hours of detection | Detection in minutes, so the six-hour clock starts with a confident finding, not a reconciliation surprise |
An organization that works this way every day doesn’t scramble to assemble proof when the inspection comes. Netenrich keeps the evidence of readiness current, and acts on what it finds. The proof is generated by how the organization operates.
If a partner's credentials called your disbursement API 500 times in the next 20 minutes, would you know before the money cleared?
If the honest answer is "we'd find out at reconciliation," the gap isn't in your perimeter. It's in what happens after someone is already inside. And with six hours to report to RBI, reconciliation is already too late.
Read Netenrich’s in-depth research report, The Dual-Vector Heist, to see how threat actors turn account takeovers into authorized transfers.