Most fraud teams I talk to still think about bots as a website problem. Scrapers hitting a pricing page, credential stuffing on a login form, a checkout bot grabbing inventory before real customers get a chance. All real, all annoying, all fairly well understood by now.
But the money has moved. In India especially, financial activity has shifted almost entirely into mobile apps. Lending, payments, trading, insurance, onboarding, KYC. The web page is increasingly a brochure. The app is the business. And the fraud has followed, which is the part a lot of risk teams are still catching up to.
Here is the uncomfortable part: the defences that work reasonably well on the web mostly do not transfer.
The web has a referee. The app does not.
When someone visits your website, the browser is doing a lot of work on your behalf whether you asked for it or not. It enforces the same-origin policy. It tells you something about the rendering engine. It runs your JavaScript in a sandbox you at least partially control. Services like CAPTCHA, device fingerprinting and behavioural scoring all sit on top of that shared foundation.
A mobile app has none of that. It is a binary sitting on hardware the attacker owns outright. There is no neutral referee between your code and someone who wants to take it apart. If a person is determined enough, they can decompile your APK, read your API calls, patch out your checks and rebuild it. Tools for this are free and the tutorials are on YouTube.
So the same automated attack that gets stopped at a browser layer on your website walks straight into your app, and often talks directly to your backend API without touching your interface at all.
What app bots actually do
The threat model is different, not just harder. A few patterns come up over and over in Indian fintech:
Fake account farms at onboarding. Emulators running hundreds of app instances, each completing signup to claim a referral bonus, a signup credit or a first-transaction cashback. The unit economics of customer acquisition get destroyed quietly, and the growth team usually notices before the risk team does, because it shows up as a suspiciously good month.
Automated credit applications. Scripted loan applications submitted in bulk with synthetic or stolen identity documents. Each one costs you a bureau pull and an underwriting cycle even if you reject it.
Trading and payment abuse. Scripts that exploit timing windows, latency differences or promotional mechanics faster than a human ever could.
API scraping without the app. This one gets underrated. Once someone has reverse engineered your mobile API, they do not need to run your app at all. They hit your endpoints directly, and every check you built into your user interface is irrelevant.
Why the usual tools fall short
CAPTCHA is the obvious example. On a website it is at least a speed bump. In an app, a bot that is calling your API directly never renders your screen, so it never sees the challenge. And if the attacker has patched the binary, the client-side call that triggers the challenge can simply be removed.
Server-side rate limiting helps, but it is blunt. Attackers using residential proxies and rotating device identifiers spread the load thin enough to stay under your thresholds. You end up either letting fraud through or throttling genuine users on shared networks, which in India means throttling a lot of legitimate people.
IP reputation is weak for the same reason. Mobile carrier IPs are shared at enormous scale. Blocking one is a blunt instrument that catches thousands of real customers.
This is roughly why bot detection built specifically for the mobile layer has become a separate category rather than a feature of web security tooling. Detecting automation inside an app means looking at signals the browser never gave you access to: whether the app is running on an emulator, whether the binary has been tampered with, whether a hooking framework is attached to the process, whether touch and sensor input looks like a human hand or a script, and whether the device identity has been reset between sessions to look new.
The financial argument
The reason I think this belongs in a finance discussion rather than a purely technical one is that the cost shows up on the P&L before it shows up in a security dashboard.
Fake accounts inflate your user numbers, which inflates your reported CAC efficiency, which affects how you and your investors read the business. Promotional abuse is a direct cash leak. Automated credit applications burn real money in bureau fees and underwriting time. And regulatory exposure around KYC integrity is not theoretical in Indian financial services, where onboarding standards are actively supervised.
There is also a reputational dimension that is harder to quantify. Fraud losses can be absorbed. A publicised onboarding failure at a regulated lender is a different kind of problem.
What I would actually check
If you run a mobile-first financial product, three questions are worth asking your engineering team this quarter.
Can your backend tell the difference between a request from your genuine app and a request from a script imitating it? If the honest answer is no, everything else is decoration.
Do you have visibility into whether the app is running on a real device or an emulator, and whether the binary has been modified? Not as a blocking rule necessarily, just as a signal you can see.
Is your automation detection happening server-side, or does it depend on client-side code that an attacker controls?
None of this means websites stopped mattering. It means the assumption that app security is a slightly modified version of web security is wrong, and that gap tends to get discovered expensively.
Comments
Log in or sign up to join the conversation.