Nobody has to break UPI. They only have to get you to press 'Pay'.
🌐 इस लेख को हिन्दी में पढ़ें
In short: Most Indian payment fraud is authorised push payment fraud: the system authenticates perfectly and the victim approves the transfer. This guide explains what an OTP actually proves, why SMS is a weak channel, how collect requests, QR codes, screen-sharing and SIM swaps exploit an authentication model built to answer the wrong question, what RBI's limited liability rules mean when you shared the code yourself, why reporting within the first hour matters, and how phishing-resistant authentication such as passkeys changes the problem.
There is a persistent mental picture of digital payment fraud in which a hacker somewhere defeats a bank's encryption. It is almost entirely wrong. India processes billions of UPI transactions a month, and the fraud that drains people's accounts is, in the overwhelming majority of cases, technically flawless: the correct device, the correct PIN, the correct one-time password, a transaction the system was right to approve. The attacker did not break anything. The attacker got the account holder to authorise the payment.
Understanding why that is possible means understanding what an OTP actually proves — and what it never claimed to.
Authentication answers one narrow question
Every authentication system is trying to answer: is the person instructing this transaction the account holder? The classic factors are something you know (a PIN), something you have (a phone, a card, a security key), and something you are (a fingerprint or face). Two-factor authentication combines two of them so that stealing one is not enough.
UPI is reasonably built in these terms. The app is bound to a device and a SIM, and the UPI PIN is entered into a component the app itself cannot read. An attacker in another country cannot simply key in your PIN and move money; they need your phone too.
But notice the question the system is answering. It asks who is instructing the payment. It does not, and cannot, ask why — whether the account holder understands what the transaction does, or has been convinced of something false. A system that verifies identity perfectly will approve a perfectly identified person sending their savings to a stranger. That gap has a name in the payments industry: authorised push payment fraud, and it is the dominant category almost everywhere real-time payments exist.
What an OTP is, and what it is not
A one-time password is a short-lived shared secret sent over a channel, usually SMS, to prove you hold the registered number. It defends well against one specific thing: an attacker who has stolen a password and nothing else.
Its weaknesses are structural, not incidental.
SMS was never designed as a secure channel. Messages are not end-to-end encrypted, they can be read by malicious apps granted SMS permission, and they follow the number rather than the person — which is the whole basis of SIM swap fraud, where an attacker obtains a duplicate SIM using forged documents and every OTP begins arriving at their handset. Telecom rules now restrict certain transactions for a period after a SIM is reissued precisely because that window is where the losses happen.
The deeper weakness is that an OTP is relayable. It is a secret the user can be talked into repeating, and no amount of cryptography helps once the user reads it aloud to a caller. Real-time relay is now routine: the victim is on the phone while the attacker enters the code on the real bank site within its validity window.
An OTP proves that somebody holding your number typed the right digits. It was never designed to prove that you understood what you were approving. Almost all modern payment fraud lives in that gap.
How the gap is exploited
Nearly every widespread Indian scam is a variation on the same move — make the authorisation itself the attack.
Collect requests. UPI allows a request for money to be sent to you; approving it pushes funds out. Dressed up as a refund, a job payment, a "verification of ₹1" or a marketplace buyer paying for goods, the victim enters a PIN believing they are receiving money. The single most useful rule in Indian digital payments: you never enter a UPI PIN to receive money. Money arriving needs nothing from you. If a screen is asking for a PIN, money is leaving.
QR codes work the same way. Scanning a QR sets up a payment from you. A "scan this to receive your refund" instruction is always a payment request.
Screen sharing. The victim is persuaded to install a remote-access app so someone can "help with the KYC". The attacker then sees the screen, including OTPs, and often guides the victim through the transaction. Banks and the RBI have warned about this repeatedly; the tell is that no legitimate bank, ever, needs to see your screen.
Fear and urgency. The "digital arrest" scam — a caller impersonating police or a courier company, alleging a parcel of contraband or a money-laundering case, holding the victim on a video call for hours and demanding a transfer to "verify" funds — has caused very large individual losses in India. It works by removing the deliberation that would otherwise happen, and it is worth saying plainly: no Indian law enforcement agency arrests anyone over a video call, and none asks for money to clear an investigation.
Mule accounts. Once the transfer lands, it is split and moved through a chain of accounts, often ones rented from ordinary people who were paid a small fee to lend a bank account. This is why speed of reporting matters so much, and why lending your account to someone is not a favour but participation in a crime.
The rule nobody reads until it matters
The RBI's framework on unauthorised electronic transactions gives customers meaningful protection: where the loss arises from a breach at the bank's end or from a third party with no fault of the customer, liability is zero if the transaction is reported promptly, and limited if reported a little later. Delay increases the customer's share.
But there is a category that sits outside all of it — customer negligence, which explicitly includes sharing your PIN or OTP. In that case the customer bears the loss up to the point at which the fraud is reported. This is the legal reason attackers work so hard on the conversation rather than the cryptography: a transaction you approved is, in the first instance, your transaction.
Two practical consequences. First, the reporting clock is the most valuable thing you control after a fraud: call the national cybercrime helpline 1930 and file at cybercrime.gov.in immediately, alongside your bank, because funds can sometimes be frozen mid-chain in the first hour. Second, "reported promptly" is measured from when the bank is informed, not from when you noticed — so report first and investigate afterwards.
What actually fixes it
Security engineering has largely concluded that shared secrets are the problem, not the implementation of shared secrets. The direction of travel is phishing-resistant authentication: credentials based on public-key cryptography, stored on the device, unlocked by biometrics, where nothing transferable ever leaves the hardware. Passkeys are the consumer form of this. The property that matters is that the credential is bound to the genuine site or app, so a convincing fake cannot use it, and there is no code for a victim to read out — you cannot relay a secret that does not exist.
That closes the technical half. It does not close the other half, because a passkey will still authorise a payment the user has been persuaded to make. Progress there looks less like cryptography and more like friction in the right places: confirmation-of-payee checks that show the real registered name of the recipient before you send, cooling-off delays on first-time high-value transfers, per-scheme limits, and behavioural systems that flag a transaction that does not look like anything the account has done before. Several of these have already been introduced in Indian payments, and their design — how much friction, for whom, at what cost in usability — is an open research question rather than a settled one.
Why it matters for students and researchers
Payment security is where the interesting problems in the field now sit, and they are not principally cryptographic. Fraud detection on transaction graphs to identify mule networks, usable-security research on which warnings people actually read and which they click through, the economics of where fraud liability should fall to produce the best incentives, and the security of SIM binding and device attestation on the enormous range of Android devices in use in India — these are all live, and India is the largest real-time payments environment in the world, which makes it the most consequential place to study them.
It is also a field where local data is scarce and badly needed. Most published usable-security work is conducted with participants who differ sharply from a first-time smartphone user transacting in a second language on a low-end device, and designs validated elsewhere fail here for reasons that have nothing to do with the cryptography.
That practical, network-security-focused work is the remit of the International Journal of Information Security Engineering (ISSN 3049-1150), a peer-reviewed journal launched in 2023 that publishes original research and reviews aimed at usable information in network security. For computer science and IT students, it is a useful corrective to a syllabus that spends far more time on ciphers than on the reason almost every real loss happens.
Frequently asked questions
Is an OTP enough to keep my bank account safe?
No. An OTP proves that someone holding your registered number typed the correct code. It does not prove that the transaction is one you understood or intended, and it can be read out to a caller, intercepted by a malicious app, or redirected through a SIM swap.
Do I need to enter a UPI PIN to receive money?
Never. Incoming money requires nothing from you. Any screen asking for a PIN, or any QR code you are told to scan "to get a refund", is setting up a payment out of your account.
What is a SIM swap fraud?
An attacker obtains a duplicate SIM for your number using forged identity documents, after which your OTPs arrive on their phone. A sudden and unexplained loss of mobile network on your own handset is the warning sign, and telecom rules restrict some transactions for a period after a SIM is reissued.
Who bears the loss if I am defrauded?
Under RBI's framework, liability is zero for unauthorised transactions caused by a bank-side or third-party breach if reported promptly, and limited if reported later. Where the customer shared a PIN or OTP, that is treated as negligence and the customer bears the loss until the fraud is reported.
What should I do in the first hour after a payment fraud?
Call the cybercrime helpline 1930, file a report at cybercrime.gov.in, and inform your bank immediately. Funds move through mule accounts within minutes, so early reporting is what makes freezing them possible, and the liability clock runs from when the bank is told.
What are passkeys and why are they more secure?
Passkeys are device-stored cryptographic credentials unlocked by a fingerprint, face or device PIN. Nothing transferable is sent, and the credential works only with the genuine site or app, so there is no code to intercept or read out to an attacker.