Most fintech breaches you read about involve a hacker, a vulnerability, and a headline. Most fintech losses I've actually seen up close involve none of those things. They involve someone who read the terms of a cashback offer more carefully than the product team did, found the one path through the workflow nobody had tested, and quietly walked away with money the system handed over willingly.

That's the part standard security testing misses. A penetration test asks: can someone break in? Business logic testing asks a more uncomfortable question: what happens if someone uses every feature exactly as designed, just not exactly as intended? In a country processing billions of UPI transactions a month, that second question matters just as much as the first — arguably more, because nobody needs a zero-day to abuse a referral program.

Here's where that gap shows up most often in Indian fintech apps.

Wallet Systems: Built for Speed, Tested for Function, Rarely Tested for Abuse

A digital wallet sits at the intersection of multiple money-in paths — UPI, card, net banking, cashback credits — and at least one money-out path. Every intersection like that is a place where timing and assumptions can quietly fall apart.

The classic version of this is a race condition: top up the wallet and spend from it in two near-simultaneous requests, and check whether the balance check happens before or after both transactions are committed. Done right, this should be impossible. Done wrong, a user can spend money that, technically, hadn't arrived yet — or spend the same balance twice.

There's a quieter version of the same problem around refunds. If a refund is credited back to the wallet on a different timeline than the original debit was finalized, there's often a window where the balance briefly shows more than it should, and a fast enough user can act inside that window before reconciliation catches up.

And then there's KYC tiering. Minimum-KYC wallets in India are deliberately capped at lower balance and transaction limits precisely because they require less identity verification. The abuse case writes itself: instead of one wallet pushing past its limit, several min-KYC wallets tied to the same person, device, or document quietly add up to far more than any single one was meant to allow. Testing this means asking not "does one wallet respect its limit," but "does the system know when the same person is operating five of them."

Cashback Abuse: When the Reward Engine Doesn't Talk to the Fraud Engine

Cashback and reward systems are usually built by a growth or marketing team, run on a separate set of rules from the core transaction engine, and tested almost entirely for whether the discount applies correctly. Whether the discount can be farmed is a different question, and it's often nobody's job to ask it during the build.

A few patterns show up again and again. Self-referral loops, where the same person — sometimes through nothing more sophisticated than two phone numbers — refers themselves and collects both ends of a referral bonus. "Complete one transaction, get cashback" offers that get triggered by a transaction which is then reversed or charged back, while the cashback itself was never designed to be clawed back along with it. Coupon codes that were meant to be used once per user but turn out to be enforceable only at the UI layer, so a direct API call lets the same code stack indefinitely. And new-user welcome offers claimed repeatedly through device or SIM farming, because "new user" was defined by an account creation date rather than anything tied to the actual device or identity behind it.

The uncomfortable truth here is that almost none of this requires bypassing security controls. It requires understanding the reward rule better than the team that shipped it, and most reward rules are written to maximize conversion, not to survive someone reading them adversarially.

Referral Abuse: When Growth Metrics Become the Attack Surface

Referral programs are one of the cheapest ways to acquire users in a country where customer acquisition cost is a constant pressure on every fintech roadmap, which is exactly why they're targeted as hard as they are.

The simplest version is account farming — disposable SIMs, emulator farms, or low-cost device clusters generating accounts purely to trigger referral payouts, with no intention of ever becoming a real user. A more subtle version exploits sequencing: if the reward fires the moment a referred account signs up, rather than after it completes genuine KYC or a minimum transaction, the gap between "signed up" and "verified" becomes the exploit window. And almost all of it eventually routes back to a small number of real bank accounts or UPI IDs for cash-out, which is precisely the kind of pattern that's invisible if you're only testing one account at a time, and very visible the moment you test for clusters — shared device IDs, shared IPs, shared bank accounts behind dozens of "different" users.

This is also where business logic testing and fraud analytics genuinely overlap. Testing a referral program properly means asking the same questions a fraud team would ask after the fact, just before launch instead of after the losses show up in a dashboard.

Open Banking and Account Aggregator APIs: A Newer Surface, Tested Far Less

India's Account Aggregator framework, regulated by the RBI, lets a user consent to share financial data from a bank (the Financial Information Provider) with a fintech app (the Financial Information User) through a licensed aggregator sitting in between. It's a genuinely well-designed system on paper — consent-based, purpose-bound, time-limited. Whether it's implemented that way in any given app is a separate question, and it's one that gets tested far less often than it should, mostly because the framework is newer and most testing playbooks haven't caught up yet.

A few places this tends to break down. Consent scope creep, where an app technically asks for a narrow purpose — say, balance verification for a loan application — but the data actually pulled and stored includes the full transaction history that was never part of the consent artefact. Consent that's been revoked by the user but is still technically usable because the backend never actually checks expiry or revocation status before serving cached data. And data minimization failures, where an API built to answer "is the balance above X" instead returns the full account statement, because it was easier to build one endpoint than two.

There's also a quieter authentication question worth testing: in a multi-party consent ecosystem, what actually stops one registered FIU from making a request that looks like it's coming from another? The framework assumes every participant is who they claim to be and behaves accordingly. That assumption is worth testing directly rather than trusting by default.

Why None of This Shows Up in a Standard Pentest Report

A vulnerability scanner is built to find things with names — SQL injection, broken authentication, insecure deserialization, the kind of issue that maps cleanly to a CVE or an OWASP category. Almost everything above doesn't map cleanly to anything. There's no CVE for "the referral reward fires before KYC completes." There's no scanner signature for "five minimum-KYC wallets belonging to one person add up to more than the limit was supposed to allow."

That's precisely why it gets missed so often. It doesn't fail a security test, because it was never a security bug in the traditional sense — it's a business rule that nobody adversarially tested. Catching it means building a parallel test track alongside your functional and security testing: one written by people who sit down with the product spec and ask, deliberately and a little uncharitably, "how would I personally try to get more out of this than I'm supposed to?"

At UPI's transaction volumes, even a fraction-of-a-percent abuse rate stops being a rounding error and starts being a real number on a balance sheet. Treating business logic testing as a genuine, ongoing discipline — not a one-time review before launch — is the difference between finding that number internally, on your own terms, or finding it later, in a fraud report you didn't see coming.