52 Accounts, 87 Minutes: The Half Of The NBFC Api Heist Nobody Covered

52 Accounts, 87 Minutes: The Half Of The NBFC Api Heist Nobody Covered

What a ₹3.3 crore API heist at a Hyderabad NBFC tells lenders about the accounts that were waiting for the money.

On 19 October, between 10:31 am and 11:58 am, someone moved more than ₹3.3 crore out of a Hyderabad NBFC's bank account. 183 transfers, each between ₹50,000 and ₹2 lakh. More than two a minute, for 87 minutes.

Most of the coverage since has focused on how the attackers got in: the API, the stolen credentials, the CERT-In advisory. That is where the breach happened, so the focus makes sense.

But every one of those 183 transfers needed somewhere to land. The money went to 52 bank accounts, roughly 3.5 transfers and ₹6.3 lakh each on average. Every one of those accounts had already cleared some bank's account-opening process before 10:31 am that morning.

Nobody broke into those 52 accounts. Someone opened them. And in the five days after the attack, investigators froze about ₹40 lakh, around 12% of what was left.

Key Takeaways

• API security isn't enough: Lenders must also secure the accounts receiving fraudulent funds. KYC has limitations: Genuine identities can still be used for mule accounts.
• Connected signals matter: Shared devices, new phone numbers and unusual activity can expose fraud networks.
• Data leaks fuel identity fraud: Stolen customer documents can enable fraudulent loan applications.
• Early detection is critical: Identifying mule accounts at onboarding can prevent losses before money moves.

How The Money Left

Ten days before the Hyderabad attack, CERT-In issued a critical advisory, CIAD-2026-0046, on attackers abusing payment and disbursal APIs at BFSI entities. It lays out the chain in six steps:

1. Get in through an internet-facing application, a deprecated or unused API, or a static API token hard-coded in source code.
2. Stay and map. Install web shells, then chart the payment databases and API integrations.
3. Steal the payment gateway or partner-bank API credentials.
4. Call the disbursal or fund-transfer API from the lender's own whitelisted servers. KYC, beneficiary, balance and limit checks are skipped, because the request comes from a machine the bank trusts.
5. Push high-value IMPS and NEFT transfers into mule accounts across multiple banks, and withdraw the money immediately.
6. Delete or truncate logs and tamper with EDR.

Steps 1 to 4 are a perimeter problem, and the advisory's fixes are the right ones: MFA on payment and admin systems, no long-lived static tokens, an API inventory, maker-checker on payouts, velocity limits on new beneficiaries. We'll say it plainly. No fraud signal on a customer's phone sees a server calling its own bank's API. Device, behaviour and selfie intelligence were never in that path.

Step 5 is different. It is the one step the attacker does not fully control. The money has to land in accounts that already exist, at banks the attacker has never breached.

Where The Money Landed

The 52 accounts were the getaway car, and they had to be parked and ready before the robbery began. CERT-In's own wording is that funds are credited to mule accounts and withdrawn immediately. By the time the NBFC's CFO filed a complaint with the Telangana Cyber Security Bureau on 20 October, most of the money had already moved on.

Those accounts passed KYC because KYC was built to answer one question: is this a real person? Mules are real people, with real Aadhaar and real PAN. Fully KYC'd accounts sell on Telegram for ₹18,000 to ₹30,000 in listings we have tracked. KYC checks who is opening the account. It never asks why.

What KYC misses, the data around the account often shows. Across our deployments, mule accounts tend to share three traits that genuine customers don't:

1. Network Clustering: Mules are recruited and operated in groups. In one week of live data at an NBFC, 6.01% of users sat inside organised fraud rings, and 80% of those rings traced back to a single shared device.
2. Identity Recency: The phone number and email are months old, not years. A real salaried customer's number usually has a long history. A recruited mule's is often bought for the purpose.
3. Dormancy, then a burst: Many accounts look clean at opening and activate weeks later. A one-time check at onboarding misses them, which is why monitoring after onboarding matters too.

Screening for these at the account-opening stage works. At a public sector bank, it cut mule account creation by 40% in the first three months, with no impact on legitimate onboarding. At a top-5 private bank, device intelligence surfaced 3x more mule accounts within 60 days.

This would not have stopped the Hyderabad breach. The attacker still gets in. What changes is the supply. An attacker who needs 52 working accounts by mid-morning depends on a market that sells them, and every bank that lets a mule through its onboarding is a supplier to that market. RBIH reached the same conclusion: as of July 2026, 29 banks had onboarded MuleHunter.AI, its in-house mule detection model.

Where The Leaked Data Goes Next

Ten days after Hyderabad, a different kind of incident surfaced. On 29 October, a group calling itself ScarlettGroup claimed it held data from a Salesforce-hosted SaaS platform that AU Small Finance Bank uses for vehicle-loan customers. AU said it was investigating and that "the Bank's own systems remain unaffected" (ThePrint). The claim is unverified, and the number of customers involved has not been disclosed.

The list of claimed fields is what matters: KYC records, PAN and Aadhaar details, credit reports, bank statements, loan applications and signed agreements. Even part of that is a complete loan application kit for a real borrower with a real repayment history.

The next fraud from a leak like this rarely hits the bank that leaked. It hits every other lender, when someone applies in a real customer's name with real documents. Document checks pass, because the documents are genuine. Bureau checks pass, because the borrower has a good record.

The things a leak cannot supply sit outside the documents. The device has never been seen with that identity before. The phone number is weeks old. The applicant has no digital footprint that matches the person on the PAN card. Fraudsters carry hundreds of stolen IDs. Not hundreds of phones. One leaked identity looks clean. A hundred leaked identities applying from the same handful of phones look like what they are: a network. At a large digital lending NBFC, these signals caught 60% of identity-based fraud before onboarding, before a rupee was disbursed.

Why Smaller Lenders Take The Bigger Hit

The Hyderabad attack ran from 10:31 am to 11:58 am on a Monday. Working hours, not the middle of the night. The complaint reached the police the next day. Four things make a mid-sized NBFC an easier target than a large bank:

1. Disbursal is the core product. A bank moves money out as a side flow. An NBFC's whole business is sending money quickly, by API, to accounts it has never seen before. That is the exact path CERT-In's attack chain uses.
2. Thin security teams. Few smaller lenders run a round-the-clock security operations centre. An attack that finishes in 87 minutes can be over before anyone looks at the alerts.
3. Customer data sits with vendors. Loan origination, CRM and onboarding often run on third-party SaaS. AU's claimed leak came from a Salesforce-hosted platform, not the bank's own systems, and the bank still carries the reputational damage.
4. Rules see one account at a time. Most smaller lenders screen each applicant and each transaction alone. A mule ring is invisible that way, because every account in it looks normal. The fraud is in the connections.

What Sign3 Would Look For In The 52 Accounts

We have no visibility into the Hyderabad case or the banks that held the 52 accounts. But we know what this pattern looks like in data, and the accounts were unlikely to be 52 separate problems. Mules are recruited, run and cashed out in groups, and identities from a leak are used the same way.

With, our network intelligence, we, at Sign3, maps the links between accounts, devices, phone numbers, locations and fund flows across a lender's whole customer base. A ring shows up even when every account in it looks clean on its own. In one analysis, it surfaced 503 distinct fraud rings from 69,646 phone numbers.

CERT-In's controls harden the perimeter. Network intelligence carries through every stage after it:

The order of the rows matters. In Hyderabad, investigators recovered about 12% of what was left, because a mule can withdraw in minutes. Every row above the freeze moves the defence earlier, and the earliest one is the cheapest: stopping the mule account before it opens.

A 30-Day Checklist For Smaller Lenders

The first four items come straight from CERT-In's advisory and close the door the money left through. The last four cover where it lands.

1. Lock down access. Turn on MFA for payment, admin and remote-access systems. Retire long-lived static API tokens and move secrets into a vault.
2. List every API that can move money, including old and partner-facing ones. Switch off the ones nobody uses.
3. Put brakes on disbursal. Add maker-checker and daily ceilings to payout APIs, hold first-time beneficiaries, and reject any transfer whose reference ID has no matching loan record.
4. Reconcile in near real time. Match your payout records against bank and aggregator statements throughout the day, not at day-end. 183 transfers should not survive 87 minutes unnoticed.
5. Measure your ring exposure. Count how many of your active accounts share a device, phone number or location with another account. That number is your starting point.
6. Screen for links at onboarding, not just identity. Check whether a new applicant's device or number already connects to other applicants before the account opens.
7. Map every vendor holding KYC data. For each SaaS platform and outsourced processor, write a fast incident notice into the contract. CERT-In expects you to report within 6 hours of noticing an incident, including one a vendor reports to you.
8. Rehearse the freeze. Know who receives law-enforcement freeze orders, how fast they reach the core banking system, and what the first hour after a payout breach looks like.

The Verdict

The Hyderabad NBFC lost ₹3.3 crore through its own API, into 52 accounts that other banks had opened. API security decides whether money can leave. Onboarding decides whether it has anywhere to go. Right now, the industry only talks about the first.

Frequently Asked Questions

What happened in the Hyderabad NBFC cyberattack?

On 19 October 2026, between 10:31 am and 11:58 am, attackers with access to a Hyderabad NBFC's systems and API moved more than ₹3.3 crore out of its bank account. They made 183 transfers of ₹50,000 to ₹2 lakh each into 52 accounts. The Telangana Cyber Security Bureau has frozen about ₹40 lakh so far.

What is CERT-In advisory CIAD-2026-0046?

It is a critical advisory CERT-In issued on 9 October 2026 about attackers abusing payment and disbursal APIs at banks, NBFCs and fintechs. It describes a six-step chain that ends with funds sent to mule accounts across multiple banks and withdrawn immediately. It also lists controls, including MFA, removing static API tokens, maker-checker on payouts and velocity limits on new beneficiaries.

Why do mule accounts pass KYC?

Because the person behind them is real. A mule has a genuine Aadhaar, PAN and phone number, so every identity check passes. KYC confirms who is opening the account, not why. Fully KYC'd accounts sell on Telegram for ₹18,000 to ₹30,000.

How can banks spot mule accounts before they are used?

By looking at what links an account to others, not just at the account itself. Shared devices, very new phone numbers and connections to other applicants are visible at account opening. At a public sector bank, screening for these signals cut mule account creation by 40% in three months, with no impact on legitimate onboarding.

Can leaked KYC data be used to take a loan in someone else's name?

Yes. Leaked PAN, Aadhaar, bank statements and credit reports can make a fraudulent application look genuine, because the documents are real. Lenders need signals the documents cannot supply, such as the device and the age of the phone number. Customers should check their credit report regularly for loans or enquiries they don't recognise.