Rajesh runs a furniture resale account on an online marketplace. A buyer messages about a study table listed for ₹4,200. They negotiate down to ₹3,800, agree to UPI, and the buyer asks for Rajesh's number to "send the payment directly."

Ninety seconds later, Rajesh's phone buzzes with a UPI notification: ₹3,800, from an unfamiliar handle, with a message attached: "Sent, please accept to confirm." He opens the app. There's a payment request waiting, the amount matches, the name looks plausible. He taps accept, enters his PIN, and gets a debit confirmation instead of a credit.

QR code substitution at merchant counters and screen-sharing scams dressed up as bank support work through the same underlying flaw: a transaction the account holder authenticated themselves, using their own PIN, on their own device. That's what makes all three close to invisible to standard fraud detection, and it's the reason treating UPI fraud as one broad category obscures what banks, NBFCs, and fintechs actually need to fix.

Reported UPI fraud crossed 13.42 lakh incidents worth ₹1,087 crore in FY24, before easing to 12.64 lakh incidents and ₹981 crore in FY25. RBI's own annual report for FY26, released in May 2026, frames the picture in starker terms: digital payment fraud losses have risen 41-fold over five years to nearly ₹23,000 crore, against a backdrop of UPI now processing more than 20 billion transactions a month. The report also puts an official name to the exact failure mode this article is about, "authorised push payment fraud," where the customer initiates the transaction themselves despite every safeguard already in place. The sheer volume of legitimate activity is exactly what makes each fraudulent transaction close to invisible at the point it happens.

Three Ways the Same Blind Spot Gets Exploited

UPI supports two request types that look nearly identical on screen but move money in opposite directions. A Pay request is payer-initiated: you choose to send money out. A Collect request is payee-initiated: someone else asks your account to release funds, and your PIN is the only thing standing between that request and the debit. All three patterns below exploit some version of that asymmetry.

• The Collect Request, Framed as a Refund

The fraud in Rajesh's case, and in the overwhelming majority of "fake buyer" and "fake refund" scams reported across Indian marketplaces, doesn't exploit a technical flaw in UPI. It exploits the fact that a Collect notification and a payment confirmation look almost the same on a phone screen at a glance, and that most users have never been told the difference matters. The scammer's job is to control the story around the notification: "I've sent it, just accept," or, in the customer-care variant, "there's a refund pending, approve it to receive your money." Both scripts rely on the same mechanical trick: approving is authorizing a debit, framed as accepting a credit.

• The Swapped QR Code

A kirana store on a busy market street does close to two hundred small transactions a day, almost all of them through a single QR code taped to the glass counter. A stranger leans against the counter for a few seconds, presses an identical-looking sticker over the shop's code, and walks off. For the rest of the day, every customer pays exactly the way they always have: scan, check the amount, enter PIN. Nothing on their side looks any different. The owner only notices that evening, when the day's UPI credits don't add up to the day's sales.

Every customer who scanned that code and paid was authenticated correctly. Their PIN was right, their device was theirs, their intent was to pay the shop standing in front of them. The only thing that moved was which VPA sat behind the printed code, and nothing in a standard Pay-flow checks whether a QR code still belongs to the party it claims to represent.

• The Remote-Access Call

The more elaborate version adds a live human on the other end. A call from "bank support" arrives after a transaction "fails," and walks the victim into installing a screen-sharing app like AnyDesk or Quick Support, ostensibly to help. From there the fraudster doesn't need a Collect request or a tampered QR code at all. They can see the OTP, the balance, the saved beneficiaries, and initiate transfers directly while the victim watches, believing they're being helped.

In all three cases, the money doesn't sit still. It lands in a beneficiary account typically onboarded with weak or borrowed KYC, sometimes a genuine account holder paid a small fee to receive and forward funds, and gets moved out within minutes through further UPI hops or ATM withdrawal, before any institution has time to react. That's a mule account, and it's a second failure point in the chain, separate from and downstream of whichever version of the exploit got the money moving in the first place.

Every Fraud Signal at the Sending Bank Says the Transaction Is Legitimate, Because It Is

This is the part standard fraud controls aren't built to catch, and it's worth being precise about why.

Transaction monitoring systems are tuned to flag deviation: new device, new geography, unusual hour, an amount well outside a customer's normal range, a beneficiary who's never been paid before. None of the three patterns above trip these wires. Rajesh's debit came from the phone he's used for two years, in his own city, for an unremarkable amount. The kirana store's customers paid from their own accounts to what their app displayed as an ordinary transaction. The remote-access victim's session runs on their own authenticated device throughout. A new beneficiary can't be a hard block either, since every first-time buyer or new shop is, by definition, a new beneficiary; blocking on that basis breaks the product for its entire user base.

Two-factor authentication, device binding, and daily transaction caps, the standard trio RBI and NPCI point to when asked what's being done, all assume the threat is someone other than the account holder trying to move money. In every pattern above, the account holder is the one taking the action, correctly authenticated, on the right device. What failed is interpretation, not authentication: no authentication layer checks what the user believes is happening, only what they're technically authorizing. Fraudsters know this, which is why a growing share of these scams now stay in modest, unremarkable amounts, or get split into several smaller transfers, specifically to avoid tripping value-based monitoring rules at all. RBI's own FY26 annual report backs this up with a number worth sitting with: transactions above ₹10,000 make up only about 45% of fraud cases by volume, but 98.5% of fraud value, which is exactly where the real exposure concentrates even as case counts spread thin across smaller amounts.

KYC doesn't help here either, and this is the point most fraud content skips. KYC verifies the identity of the account holder at onboarding. It says nothing about who's on the other end of a specific transaction, and it can't, by design, evaluate the intent behind a request the account holder chooses to approve. The weak link across all three patterns is the receiving account's onboarding quality, not the paying customer's, and the paying customer's bank has no visibility into how well the beneficiary bank vetted that account when it was opened, months or years before the fraud occurred.

How each UPI fraud pattern defeats standard monitoring

What Happens After the Debit: NPCI, UDIR, and a Liability Fight the Framework Wasn't Built For

Once Rajesh realizes what happened, the process is procedurally straightforward and substantively uncertain, and it plays out roughly the same way regardless of which of the three patterns triggered it.

He can raise a dispute inside his UPI app, call his bank, or lodge a complaint through NPCI's own channels. Behind the scenes, the dispute moves through NPCI's Unified Dispute and Issue Resolution system, an automated, API-based layer launched in 2020 that connects the payer's bank, the payee's bank, and NPCI directly, replacing what used to be manual, file-based back-and-forth between banks. UDIR resolves genuine technical failures, stuck or duplicate debits, within days, sometimes hours. Fraud cases sit on a different track. They typically get escalated for manual investigation, and the government's own disclosures to Parliament put resolution at 22% of cases actioned within seven days and 92% within thirty, with barely 6% of disputed amounts actually recovered.

That last number is the one that matters. The gap between "resolved" and "recovered" is where RBI's 2017 liability framework runs into trouble on cases like these.

RBI's circular on customer protection in unauthorized electronic banking transactions gives zero liability to a customer who reports within three working days, provided the loss stems from bank negligence or a third-party breach with no fault of the customer's own. Report within four to seven days and liability is capped, between ₹5,000 and ₹25,000 depending on account type. Beyond seven days, it falls to the bank's own board-approved policy. The burden of proving customer liability sits with the bank, not the customer, and once reported, the bank must credit the disputed amount within ten working days, pending a 90-day investigation.

RBI's liability framework, by reporting window

The friction is definitional. That entire framework is built around unauthorized transactions, ones the customer didn't approve. Rajesh's transaction, and the remote-access victim's, were technically authorized: the right PIN, the right device. Banks have historically leaned on exactly this distinction, arguing that a correctly authenticated transaction can't be unauthorized regardless of what the customer was told or believed at the time. QR-swap victims sit in a slightly different spot, since they can credibly argue they intended to pay a specific, known merchant rather than a stranger, but the dispute still runs into the same wall: a technically authenticated PIN entry. Indian consumer courts have started pushing back on the "it was authenticated, so it was authorized" argument in social-engineering cases specifically, but it isn't settled law applied consistently across every bank and every dispute, which means outcomes remain considerably less predictable than outcomes for straightforward account takeover.

Separately, banks are required to report the incident into RBI's Central Payment Fraud Information Registry, operational since 2020, and NPCI has been tightening the technical perimeter around this fraud category specifically: mandating that UPI apps display only the bank-registered beneficiary name since June 2025 to cut down on impersonation through fake payee labels, capping high-frequency API calls like balance checks and account lookups to blunt reconnaissance, and piloting MuleHunter.AI, an RBI-backed model for identifying mule accounts by behavior rather than static KYC status. RBI's FY26 annual report goes a step further, proposing a one-hour delay before funds credit to a beneficiary on any payment above ₹10,000, plus a customer-controlled "kill switch" to block all debits from an account instantly the moment fraud or device compromise is suspected. Both are aimed squarely at authorised push payment fraud rather than account takeover, which is itself an admission that the older toolkit, device binding, PIN authentication, transaction caps, was never built for this pattern. None of this fixes any of the three cases above retroactively. It's aimed at the next one.

The Real Failure Point Sits Upstream of the Transaction

The uncomfortable conclusion for banks, NBFCs, and fintechs operating in this ecosystem is that fraud of this kind isn't a monitoring problem in the sense the industry usually means it. The models don't need to get more sensitive or pick up more parameters. Each transaction genuinely looks clean because, mechanically, it is. The fraud is a design and induced-consent problem sitting one layer above the transaction, and a second, separate onboarding problem sitting on the receiving side, whether that's a mule account with thin KYC or, in the merchant case, a QR code nobody verified still belongs to the business displaying it.

That reframes where institutional effort has the best return. Post-transaction monitoring will keep catching what it's built to catch: deviation, velocity, geography, device anomalies. It will keep missing correctly authenticated, in-pattern transactions induced through social engineering or a swapped code, because that's a different threat model entirely. The more durable lever sits upstream: onboarding-stage identity verification and account risk scoring strong enough that mule accounts don't clear KYC in the first place, merchant QR issuance actually tied to a verified business identity, and account monitoring fast enough to flag a cash-out before it clears. For institutions serious about closing this gap, that means investing as much in who gets an account, and whose name sits behind a QR code, as in what happens after money moves through it.

FAQs

• What is UPI fraud?

UPI fraud covers any scheme that gets a victim to authorize a payment they didn't intend to make, whether through a fake Collect request disguised as a refund, a QR code swapped at a shop counter, or a screen-sharing app installed under the pretext of technical support. Most cases involve a transaction the victim technically approved, not one where their account was accessed without consent.

• How do I report UPI fraud?

Raise a dispute immediately inside your UPI app, call your bank's helpline, and file a complaint on the National Cybercrime Reporting Portal (cybercrime.gov.in) or the 1930 helpline. Do all three. The app dispute triggers NPCI's UDIR process, while the cybercrime complaint creates the record law enforcement needs to trace the beneficiary account.

• What should I do in case of UPI fraud?

Report to your bank within three working days of the debit to preserve zero-liability protection under RBI's rules. Flag the account for further transaction blocks if compromise seems possible, save every screenshot and message from the fraudster, and get a written complaint acknowledgement with a reference number from your bank.

• Who is liable when UPI fraud occurs, the bank, NPCI, or the customer?

It depends on how the transaction gets classified. RBI's framework assigns zero liability to the customer for unauthorized transactions reported within three working days, limited liability if reported within four to seven days, and board-policy-determined liability beyond that. The complication is that Collect-request, QR-swap, and social-engineering scams all involve a technically authorized transaction, which pushes liability disputes into murkier territory than straightforward account takeover.

• How is UPI fraud detected?

Primarily through transaction monitoring tuned to flag deviation: new devices, unusual amounts, unfamiliar beneficiaries, abnormal timing. This catches account takeover and unauthorized access well. It's structurally weak against social-engineering and QR-substitution fraud, where the account holder authenticates the transaction themselves, because the transaction produces no anomaly for the model to flag.

The gap in each of these cases wasn't in the sending bank's fraud engine. It was upstream, in whoever cleared the beneficiary's KYC or issued a QR code nobody verified. See how OneRisk scores accounts for fraud risk at onboarding, before they become the exit point for someone else's money.