INDUSTRIESPAYMENTS & UPI
The rails held. The phone at either end did not.
Almost no real-time payment fraud is a break in the network. It is a correct PIN, on a bound device, entered by someone who was told to — and money that is irreversible three seconds later.
750 M
UPI transactions a day, on the way to a billion
524 k
suspected mule accounts and VPAs flagged in one month
4–6
hops between the victim's debit and the cash-out
$612 M
projected Indian APP scam losses for 2026, roughly double 2021
Sources: NPCI volume statements, 2026 · mFilterIt mule/VPA analysis, March 2026 (520,559 of the flagged identities were VPAs) · UPI fraud-detection architecture research, 2026 · ACI Worldwide APP scam projection for India.
01 — THE CASE
Twelve minutes, one collect request, six VPAs.
UPI's two factors — a bound device and the customer's own PIN — are both satisfied here. That is precisely the problem: the authorisation is real, the intent is not.
19:41
A call about a failed refundThe caller knows the last order value and the merchant name. She is told a refund is stuck and needs to be “released” from her side.SOCIAL ENGINEERING · OFF-PLATFORM
19:44
A helper app, then an accessibility grantA screen-sharing tool is installed from a link and given accessibility permission “to complete the refund form”. The payment app itself is untouched.REMOTE CONTROL · A11Y SERVICE GRANTED
19:46
A collect request, framed as receivingA pull request arrives from a VPA that has never transacted with her. On screen it reads like an incoming refund; in the protocol it is a debit authorisation.COLLECT REQUEST · PAY vs RECEIVE INVERTED
19:47
Both UPI factors are satisfiedThe device is the bound one. The PIN is hers, entered by her, coached over the phone. Nothing in the authorisation is technically false.AUTHORISED BUT UNINTENDED (AbU)
19:48
Structured under the alert thresholdsThe balance leaves as a run of small transfers, each below the value that triggers her bank's alerting and review rules, across six freshly created VPAs.MICRO-STRUCTURING · VPA VELOCITY
19:53
Cashed out four hops awayThe funds move through payments-bank and merchant VPAs — the categories that dominate flagged mule activity — and are withdrawn before the first complaint is filed.MULE CHAIN · IRREVERSIBLE
WITH SENSE
The PIN pad never opens.At 19:46 the app knows a screen-sharing session is live, an accessibility service was granted four minutes ago and the collect request is the first from this VPA. The authorisation screen is withheld, the request is held for step-up, and the customer's own phone tells her why — while the money is still hers.
victimvpa 1vpa 2merchant vpapayments bankcash-out
Authorised but unintended. The rails cannot tell the difference — the device can.
WHY A CORRECT PIN IS NOT CONSENT
02 — THE MAP
Four surfaces in a payments business. What you see, and what they use.
Pick a surface to read the exposure in the terms a PSP, TPAP or aggregator actually operates in.
WHAT THE PROCESSOR SEESA bound device, a correct UPI PIN and a payment inside the customer's usual pattern — the two factors the protocol asks for, both satisfied.
WHAT THE FRAUD NETWORK USESScreen-sharing tools and accessibility services to drive the session, malware that reads the notification tray, collect requests framed as refunds, and re-registration on a new device after a SIM swap.
screen_share_activea11y_abusesim_changed_6hrebind_new_deviceoverlay_on_pin
03 — THE COUNTER-MOVE
A third factor the rails never had: the state of the device at the moment of authorisation.
Sense does not re-underwrite the payment. It tells your PSP switch whether this authorisation came from an untampered app, on a device nobody else was driving, with a number that lives on that handset.
POSITION 01At the authorisationBefore the PIN pad opens, the app knows whether a remote session is live, an accessibility service is driving input, an overlay is on screen, the build is genuine and the device is the bound one. That verdict rides the authorisation call — single-digit milliseconds, no extra round trip.RASPIN-THREADApp AuthATTESTATIONCode ObfuscationBUILD-TIME
POSITION 02At the identityDevice binding and re-registration are only as strong as the number behind them. Sense proves the number is live on the handset over the mobile network, and reports SIM-change age — so a swap plus a new phone is no longer a clean path to a bound device.Silent Mobile VerificationIDENTITYAccount TakeoverSESSIONBot DetectionWEB & API
POSITION 03On the page and the payoutPayment pages report what actually executed in the browser — every script, every field listener, every change from the approved inventory — and payout, refund and merchant-onboarding APIs answer only your genuine clients, not replays.Bot DetectionWEB & APIAI Runtime SecurityIN-PATH
04 — THE EXPOSURE INDEX
Nine ways money leaves a payment system that is working exactly as designed.
Open a line to read the mechanism and the control that answers it. Every one of these produces a valid, authorised, irreversible transaction.
A pull request or QR is presented as money arriving. The customer approves a debit believing it is a credit — the most common real-time payment scam there is, and entirely valid at the protocol level.First-contact VPA, remote-session and overlay signals at the authorisation screen let you delay, warn or step up before the PIN is entered.
Mechanisms drawn from 2026 UPI and card-fraud research: collect-request and AbU patterns, mule/VPA network analysis, NPCI's 2026 device-binding and new-payee controls, and PCI DSS v4.0.1 client-side script requirements enforceable since 31 March 2025.
05 — THE FIRST NINETY DAYS
No switch change, no NPCI re-certification of your flow.
01DAYS 1–30Authorisation, in report-onlySDK into the payer app. Nothing declines. You see how many authorisations happen under remote control, on tampered builds or on freshly re-bound devices.
02DAYS 31–60Hold before the debitThe verdict enters the authorisation decision: delay, warn or step up on the scored slice. New-payee and high-value flows go first; ordinary payments are untouched.
03DAYS 61–90Merchants, checkout and payoutsMerchant and terminal apps attested, payment pages under continuous script monitoring, and payout and onboarding APIs restricted to genuine clients.
WHAT THE SPONSOR BANK AND THE AUDITOR RECEIVE
A signed device and session record per authorisationApp and terminal build inventory across your acceptance estateScript inventory and change log for every payment pageAbU / scam-pattern reporting separated from technical fraudIncident timelines assembled inside the reporting window
MAPPED TO
NPCI UPI security controlsRBI PA/PG Master DirectionsRBI digital payment securityPCI DSS v4.0.1 · client-sidePCI MPoC / SPoCDPDP ActOWASP MASVSCERT-In reporting
Client-side monitoring on payment pages and app-integrity evidence per transaction are now compliance artefacts, not just fraud tooling — the same records answer a chargeback, a sponsor-bank audit and a PCI assessment.
NEXT STEP
Give us a week of authorisations. We'll show you which ones nobody meant.
A device-and-checkout assessment across your payer app, merchant acceptance and payment pages — remote-control sessions at authorisation, tampered and cloned builds, structuring patterns under alert thresholds, script drift on checkout and payout-API abuse.
Run the assessmentTalk to our payments team→Report-only on live traffic first — success rates stay where they are while you look.