- CERT-In says attackers steal payment API credentials and call fund-transfer APIs directly, so KYC, sanction and limit checks in the lending app never run.
- The advisory names no victim and gives no incident count or loss figure. It calls AI use in the attacks only "possible".
- Leaders should test whether payment APIs can be reached without the app's checks, and enforce limits and validation at the payment layer.
A KYC check is a step in a process. It is not a property of the money. That idea sits at the centre of a new advisory from India's national cyber agency. It applies well beyond India's lenders.
On October 9, 2026, CERT-In and its finance arm CSIRT-Fin issued advisory CIAD-2026-0046. It is aimed at India's non-bank and digital finance sector, from online lenders to wallet providers. The agency says it has seen several attack campaigns. All of them end in unauthorised fund transfers.
How the attack works
A lending app runs many checks. It creates the loan and verifies the customer. It screens sanctions, confirms the beneficiary and checks the balance. It also applies per-transaction limits. Customers meet these checks because they use the app.
The money moves through a different door. Payment gateway and partner-bank APIs are the interfaces that actually send funds. They accept calls that carry valid credentials from trusted infrastructure.
CERT-In says attackers steal those credentials. They then call the transfer APIs directly. The calls come from inside the victim's own trusted network.
Because the call skips the app, it skips every check in the app. CERT-In says the fraudulent transfers carry dummy reference numbers with no loan record behind them. They exceed per-transaction limits. They land in mule accounts at several banks, and the cash is withdrawn at once.
Where the keys come from
The advisory lists six ways in. Two involve software flaws. One is a weakness in internet-facing applications and the servers behind them. The other is an old or unused API that lets anyone upload files without logging in.
The other four are weak credential and access practices, plus one supply-chain route. Developers leave permanent API tokens inside source code. Passwords sit in plain text in configuration files or databases. Some services have no second login step. The supply-chain route is different in kind: attackers slip forged commits into code repositories.
Once inside, CERT-In says attackers plant web shells and backdoors. A web shell is a hidden page that gives remote control of a server. They study the payment databases and harvest API keys. They then delete or trim logs and tamper with endpoint detection tools. That makes investigation harder.
The lesson here is plain. Many firms build strong controls where customers can see them. They build weak ones where only machines go. A stolen key is a skeleton key to that second place.
The AI question, and what is not known
CERT-In says its analysis points to the "possible use" of AI-assisted attack tools. It also says the gap between first break-in and the fraudulent transfer has shrunk significantly in recent incidents. The word is "possible". The advisory does not prove AI use.
MediaNama reports that the advisory names no affected company. It gives no count of incidents and no amount of money lost. Leaders should treat the scale as unknown.
MediaNama also quoted Venkata Satish Guttula, an independent audit consultant. He argued that attackers act without approval boards or risk-register entries, while defenders move on slower budget and policy cycles. That is one expert's view. It still names a real planning problem.
What the advisory asks for
MediaNama notes that most recommendations are well-known practice. They include multi-factor authentication on payment platforms and bank APIs. They also include short-lived, per-session logins in place of permanent tokens. CERT-In wants a full API inventory, with unused APIs shut down.
It also asks for maker-checker approval on all fund movement. That means a second person signs off. And every payout should be checked against approved records. A reference number with no record should be rejected.
Two items go straight at the bypass. One is to bind multi-step flows cryptographically. A debit step then cannot run without the earlier validation steps. The other is to enforce limits and beneficiary checks at the API and payment stage, not only in the app.
Questions to put to your team this week
First, can anyone call our payment or bank APIs without passing the loan, KYC and sanction steps? Ask for a test, not an assurance.
Second, where do our payment API keys live? Check source code, configuration files and databases. Ask how often the keys are rotated.
Third, if a payout arrives with a reference number that matches no record, does the payment layer refuse it?
Fourth, do we match our records against bank statements in near real time? Would we notice if our logs were trimmed?
Fifth, how many old APIs are still reachable? CERT-In names unused APIs as a way in.
Checks that live only in the customer-facing app protect the app. Controls at the payment layer protect the money.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: CERT-In (Indian Computer Emergency Response Team) with CSIRT-Fin.
