UPI Fraud: From Social Engineering to Transaction Manipulation

Early UPI fraud relied on technical shortcuts — fake collect requests, cloned apps, or exploiting weak authentication. As customer awareness and platform-level safeguards closed those gaps, the centre of gravity has moved to social engineering: fraudsters now invest in a convincing pretext — a fake bank support call, a courier or KYC-update scare, a too-good investment tip — and let the customer complete the transaction themselves. The payment is authorised in every technical sense. What's compromised is the customer's understanding of what they were authorising.

The typical journey has four stages. First, contact: a call, SMS or social media message impersonating a bank, courier, government department or investment platform. Second, pretext: a plausible reason to act urgently — a blocked account, a customs fee, a limited-time return. Third, the action itself: the victim is walked through approving a UPI collect request, entering a PIN they believe is for a refund, or installing a screen-sharing app so the fraudster can “help” — and instead operates the device directly. Fourth, layering: funds move quickly through one or more intermediary UPI handles or mule accounts before the customer realises what happened.

Three forces are pushing fraud toward social engineering. Real-time settlement and hard-to-reverse UPI transactions mean fraudsters no longer need to defeat a bank's controls — they only need to defeat the customer's judgement in the moment. Rising public awareness of basic phishing has forced more elaborate, researched pretexts, often informed by data leaked in unrelated breaches. And screen-sharing and remote-access apps, built for legitimate customer support, are readily repurposed as a fraud delivery mechanism.

1. A new payee is added and immediately used for a high-value transfer, with no prior transaction history to that payee.
2. A device or SIM change occurs shortly before a high-value or first-of-its-kind payment.
3. Screen-sharing or remote-access application activity is detectable on the customer's device during the session.
4. A collect request is approved unusually fast, with little to no dwell time on the confirmation screen.
5. Transaction timing or location breaks sharply from the customer's established behavioural baseline.
6. A customer support or “verification” call precedes the transaction, where case management or telecom signals are available.

1. Rules built around unauthorised access will not catch a transaction the genuine customer approved — detection needs to score the context of consent, not just the payment attributes.
2. Behavioural and session analytics (device, app, and interaction patterns) become as important as transaction-level rules.
3. Real-time hold or step-up workflows are needed for transactions that are technically authorised but behaviourally anomalous.
4. Beneficiary and mule-account risk scoring should feed directly into the authorisation decision, not just post-transaction investigation.
5. In-app warnings at the moment of transaction — not just after-the-fact customer communication — function as a control, not merely awareness content.