Fake Banking Apps Built With AI: Who Is Liable?

An 18-year-old from Kanpur, a Class 11 dropout, built 121 fake banking apps using free YouTube tutorials and AI coding tools. He sold them to cybercrime gangs in Jamtara, Haryana, and Rajasthan on a ₹15,000-per-app monthly subscription — updates included, like SaaS software. The apps were near-perfect replicas of SBI, PNB, Axis Bank, ICICI, UCO Bank, and even Aadhaar and PM-Kisan portals.

2,928 people lost ₹64.38 crore before Surat Police cyber cell caught him.

No hacking skill required. No criminal underworld connections required. Just a laptop, some tutorials, and an AI model that writes convincing app code. That is the part that should worry every financial institution running field collection — the barrier to building a fake version of your app just collapsed to almost zero.

Why This Is Not Just a "City Fraud" Problem

The Surat case targeted people who install apps themselves — a fake SBI app, a fake loan app. Pigmy and doorstep banking has a different, arguably softer target: the member never installs anything. The agent does.

Think through the actual failure modes for field collection:

A fake version of the agent's collection app. If an agent's phone is an open Android device, nothing stops them from side-loading an APK that looks identical to the real collection app — same icon, same login screen. It captures credentials, then quietly hands off to the real app so the agent notices nothing. Rohit Shakya's business model proves this is now a commodity service, sold monthly, to anyone willing to pay.

A fake payment confirmation shown to the member. The member hands over ₹500 in a doorstep pigmy deposit. If the app on the agent's device isn't cryptographically tied to the bank's real system, there is no way for the member — or the bank — to independently verify the money actually reached the bank's ledger and wasn't just logged to a spoofed screen.

Malware riding alongside the real app. The same personal phone that runs the legitimate collection app is also where the agent installs whatever a WhatsApp forward or ad convinces them to install. The fake banking apps described in the Surat case need exactly this kind of device — one where nothing blocks arbitrary APK installation.

The economics make this worse, not better, going forward. Building a fake app used to require a developer. Now it requires a prompt.

Who Is Actually Responsible When This Happens?

This is the question that matters most to bank management, and the honest answer has layers.

RBI puts a floor under customer liability. The RBI's 2017 circular on limiting customer liability in unauthorised electronic transactions makes banks responsible for losses where the fraud originates from a third-party breach and the customer reports it within a reasonable window. That circular was written with digital banking fraud in mind — but it does not evaporate because the transaction happened through a doorstep collection channel instead of net banking.

The bank is responsible for the channel it authorises. If a cooperative bank tells its pigmy agents "use your own phone," the bank has, in effect, authorised an uncontrolled device as its collection channel. When something goes wrong on that device, the bank cannot credibly say "not our infrastructure" — the bank chose not to control it.

The agent is rarely the villain, and rarely equipped to be the defence either. In almost every case like this, the field agent is not complicit — they are the first victim, tricked the same way a member of the public would be. Blaming the agent after the fact does not undo the loss, and it does not satisfy a regulator asking what controls the bank had in place before the fraud.

The member has no way to independently verify anything. A person handing cash to a doorstep agent is trusting the receipt in their hand. If that receipt came from a fake app, they have no way to know until money goes missing from records they never see.

Net result: liability lands on the bank almost by default, unless the bank can demonstrate it controlled the collection channel end to end.

The Real Problem: Fake Apps Leave No Trace to Track

This is the part that makes cases like Rohit Shakya's so damaging — by the time 2,928 people had lost money, there was no internal system flagging it. The fraud lived entirely outside any bank's monitoring, on devices banks never touched.

Contrast what "trackable" actually requires:

A fake app can fabricate a receipt. It cannot fabricate a server-side audit log it never had access to.

How a Controlled Device Closes This Specific Hole

The Surat case worked because the fraudsters could get a fake APK onto a phone that would accept it. Every one of ezPigmy's protections for pigmy collection maps directly onto that one weak point:

No sideloading possible. The ezPigmy Smart POS runs one signed application. There is no Play Store, no browser, no file manager to open a downloaded APK from. The exact delivery mechanism Rohit Shakya's customers relied on — get the fake app installed — does not exist on a locked device.

Every transaction is server-verified, not app-reported. The device does not decide whether a deposit succeeded. The bank's server does, and it stamps the session that created it. A cloned or fake app has no valid session to write into — there's nothing for it to fake convincingly.

Device-bound sessions, not password-only login. Even a stolen password is useless from any device other than the one it was issued to. This is the same session-binding described in our banking-data security architecture and the same lockdown model detailed in why agents must never use a personal phone for collections.

Full, independent audit trail. Every login, every collection, every device is logged centrally — visible to the bank in real time, not reconstructed weeks later from paper.

The point is not "ezPigmy has more security features." The point is narrower and more concrete: the exact mechanism used in a ₹64.38 crore fraud — a fake APK landing on a device that would accept it — has no foothold on a device that cannot accept unsigned software at all.

Three Questions for Your Bank This Week

1. If a fake version of your collection app existed today, would your agents' phones let it install?
2. If a member disputes a doorstep deposit, can you produce a server-side record independent of the device — or only what the app on that phone reported?
3. Who, in writing, is accountable if the answer to either question is "we're not sure"?

Cases like this one are not going away — AI just made building the fake app the easy part. The defensible position is not a policy telling agents to be careful. It's a device that makes the attack technically impossible.

If you'd like to see how the Smart POS closes this gap for your bank's pigmy operations, book a free demo.