On 8 and 9 October, two Mumbai-based NBFCs reportedly lost about $2 million in two days.
No fake call. No OTP. No customer clicked anything. According to a police complaint cited by Business Standard, more than 700 unauthorised instant transfers left their accounts at a large private bank. The complaint alleges that hackers compromised the API these lenders use to send loan-disbursal instructions to the bank.
Think about what that means. The system that pays your borrowers became the system that paid the attackers. Paisa gaya. Alert nahi aaya.
Three weeks later, on 1 November, a listed microfinance lender told the stock exchanges that about Rs 7.80 crore had moved out of one of its bank accounts into 82 beneficiary accounts, as The Week reported. The shape was the same, even though the company was different.
How do you stop an API-led fund theft at an NBFC? You protect three layers. First, the credentials that authorise payouts. Second, the transaction controls that check every payout before money moves. Third, the network that decides which machines can reach the payout system in the first place. Most Indian lenders have some of the first, a few have the second, but very few can honestly say they control the third.
Why This Matters for Indian Companies
So if you run technology at an NBFC, a microfinance institution, or a digital lender, read that opening again and replace “two Mumbai NBFCs” with your own company name.
Your loan-disbursal flow probably works like this. First, your loan management system approves a loan. Then an integration calls your bank’s payment API. Finally, the bank pushes the money to the borrower in seconds. That speed is the product. It is also the risk.
Here is the part that should worry you. According to CERT-In advisory CIAD-2026-0046, issued on 9 October and summarised by Ampcus Cyber, attackers call the disbursal and fund-transfer APIs directly from the victim’s own whitelisted servers. As a result, the calls skip loan creation, KYC, sanctions screening, beneficiary checks, balance checks, and per-transaction limits. Your bank sees a valid credential from a trusted address. Why would it say no?
Besides, the scale is not small. MediaNama reports an Economic Times estimate of about Rs 300 crore siphoned from smaller NBFCs in roughly two months, with more than 150 FIRs. RBI has not confirmed that figure, so treat it as reported, not proven. Still, the direction is clear. The Ministry of Home Affairs’ I4C unit warned on 3 November that attackers are using AI agents to breach systems at “machine speed”, and CERT-In says some attackers ran Re 1 test transactions before the large ones.
Also, RBI has reportedly asked banks to probe weaknesses in the APIs that connect them to non-bank lenders and fintechs. Once the regulator starts asking your bank about your integration, your integration is already a topic.
What Went Wrong: The Failure Chain
We do not know how the attackers got in at these two NBFCs. Nobody outside the investigation does. However, we do know the pattern CERT-In describes across the campaigns. It is worth walking through, because each step is a place where a decision made months ago either helped or did not.
- Entry through something exposed. First, attackers got in through internet-facing applications, middleware or exposed APIs. CERT-In lists unpatched applications, forgotten or deprecated APIs, and endpoints with no multi-factor authentication.
- Persistence. Next, web shells and backdoors went in, so fixing the first hole did not remove the attacker. In fact, CERT-In notes some institutions were hit again after remediation.
- Reconnaissance. Then the attackers mapped the payment database and the API integrations. As a result, they learned how your money moves.
- Credential theft. After that, the payment aggregator, gateway and partner-bank credentials were taken. For example, CERT-In names these weak spots: long-lived static tokens hard-coded in source code, plaintext credentials in config files, and compromised code repositories.
- Direct API calls. Next came calls to the disbursal API from your own trusted servers, with dummy reference IDs, to mule accounts at many banks. Meanwhile, the cash came out immediately.
- Cover-up. Finally, logs were deleted or truncated and endpoint protection was tampered with, so the first people to notice were the ones reading the bank statement.
Notice something. Not one of these steps needed a clever zero-day. Instead, they needed a forgotten API, a token sitting in a file, and a server nobody was watching.
The attacker did not break your bank’s security. They borrowed yours.
How It Could Have Been Stopped
Which Control Breaks Which Step
Let us be humble about this. No single product would have stopped these thefts. Instead, the defence is layers, and each layer breaks a specific step in the chain above.
| Where it failed | What the attacker did | Control that breaks it | Who owns it |
|---|---|---|---|
| Hard-coded or plaintext keys | Reused bank and gateway credentials | Secrets manager or HSM, scheduled rotation | Engineering |
| Forgotten or deprecated APIs | Entered through an unauthenticated endpoint | Full API inventory, decommission the unused | CTO |
| Payout with no matching record | Called disbursal API with dummy reference IDs | Reject any payout with no approved loan record behind it | Engineering and Operations |
| No limits at the API layer | Pushed 700+ transfers in two days | Per-transaction and daily caps, velocity holds | NBFC and its bank |
| Unknown device on the payout network | Used a foothold to reach the credential servers | Network Access Control on the production segment | IT and Security |
| Endpoint protection tampered | Turned off EDR, deleted logs | Tamper-protected EDR, central logs, posture checks | Security |
| Quiet weekend | Struck when nobody was watching | 24×7 alerts, tested response plan | CISO |
The row in bold is where we work every day, so let us be precise about it.
What Network Access Control Adds
Network Access Control, or NAC, is a security system that identifies and controls every device attempting to connect to a corporate network. Unlike a firewall, which monitors traffic crossing the network boundary, NAC governs what is allowed on the network in the first place, including devices that are already inside the building.
Here is how that maps to this incident. The attackers called the payout API from the NBFC’s own whitelisted servers. That means they first got control of a machine that was already trusted, or reached one from somewhere it should not have been reachable. Therefore, if your production and payout servers sit on a flat network, any compromised laptop, forgotten test machine, or vendor device is one hop away from your bank credentials.
EasyNAC closes that gap in three ways. First, EasyNAC identifies every device the moment it connects, so an unregistered machine on the payout segment shows up as an alert instead of a mystery. Second, you can allow only known, registered devices to reach production, so a compromised laptop cannot talk to the server that holds your bank keys. Third, device posture checks flag a machine with its endpoint agent switched off, and that machine can then be isolated. All of this works without any switch changes or network reconfiguration.
To be direct about the limits, EasyNAC will not rotate your tokens or stop a bad API from accepting a bad request. It controls who and what can sit next to your crown jewels. Because that is the layer most NBFCs have never had, we raised it in our posts on why NBFCs are missing this security layer and on a vendor laptop sitting on a bank network for months.
What Changes When the Layers Are in Place
So what changes when all the layers are in place? Your payout system stops trusting anything just because it is inside. A rogue device is flagged in minutes, instead of being discovered on a bank statement. A stolen token is useless without a matching loan record. As a result, your CEO hears about a problem from your dashboard, not from your bank’s fraud desk.
What Every CTO Should Do This Week
You do not need a six-month programme to start, but the order matters. Here is the sequence we would follow.
Start This Week
- List every API that can move money. First, find the payment gateway, aggregator, partner bank, and disbursal APIs. Then write down an owner for each one and switch off anything deprecated or unused. CERT-In asks for exactly this inventory.
- Get credentials out of code. Move keys into a secrets manager or HSM and rotate them on a schedule. Treat any token that has ever sat in a repository or config file as burned, so rotate it today.
- Enforce maker-checker inside your own systems. The bank’s check alone is not enough. A payout should be impossible without a matching, approved loan record. Reject unknown reference IDs.
- Set limits at the API layer and agree them with your bank. Add per-transaction and daily caps, plus beneficiary name matching and penny-drop checks. Also ask your bank about IP allow-listing and real-time alerts on velocity and new beneficiaries.
Build Over the Next Month
- Segment and gate the payout network. Put production and payout servers on their own segment. Then deploy NAC so only registered devices can reach it. For example, review the AWS access key leak lesson to see how exposed keys turn into live incidents.
- Watch money in real time, including weekends. Alert on velocity, new beneficiaries, and Re 1 test transactions, because CERT-In says attackers favour weekends and holidays. Likewise, reconcile against bank statements through the day instead of at month-end.
- Keep logs the attacker cannot delete. Centralise logs with at least 180 days of retention and use tamper-protected endpoint protection. Otherwise, if the logs live only on the server that got hit, you have no evidence.
- Rehearse the six-hour clock. CERT-In’s 2022 directions require incident reports within six hours. In addition, NBFCs report to RBI through the DAKSH portal within six hours, as The Week reports. Therefore, run a tabletop this month using our incident response guide.
- Give the board a one-page brief. RBI’s Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices has applied since 1 April 2024, and the RBI risk and assurance framework sets the expectation. Moreover, under the DPDP Act, failure to maintain reasonable security safeguards can attract a penalty of up to Rs 250 crore. The 72-hour breach report to the Data Protection Board takes effect on 13 May 2027, so build the habit now.
The Bigger Picture
Step back from the two Mumbai lenders, because this is not a one-off. Between 9 October and 4 November, CERT-In issued three advisories on the same theme: API credential theft on 9 October, AI agents on 15 October, and the CRAFTY FALCON campaign on 4 November. In addition, the MHA has issued its own, and RBI is asking banks to look at their links to NBFCs.
The shape of 2026 is clear. Attackers no longer go after your customers. Instead, they go after your pipes. Smaller lenders and their vendors are the softer targets, and AI tools let attackers find weaknesses faster than a monthly review cycle can. For instance, we covered the speed side of this in our post on AI agent attacks at machine speed, and our post on third-party vendor breaches at Indian banks and NBFCs shows the other half of the same story.
Final Thought
Your bank’s API trusts whoever holds your credentials. It has no other choice.
So the real question for every CTO is not “is our API secure?” It is “do we know, right now, what is sitting on the network that holds those credentials?” If the honest answer is “we think so”, that is the gap.
At Skeletos IT Services, we help Indian banks, NBFCs, and microfinance institutions deploy EasyNAC, a plug-and-protect Network Access Control solution that gives IT teams real-time visibility into every device on their network without any switch changes or network reconfiguration. If you want to understand what is actually connected to your network right now, we can show you in a 30-minute demo.
