Apportioning Loss in a UPI Fraud
Meera, a savings-account customer, received three UPI debit alerts totalling ₹48,000 on 14 August at 21:40, all payable to an unfamiliar VPA. She says she telephoned the bank's 24-hour helpline at 22:30 and could not get through: the IVR offered no option to block a card or UPI, and the line was dead because of scheduled maintenance from 22:00 to 06:00, an outage the bank had not announced on its website. A fourth debit of ₹15,000 hit the account at 23:10. On 16 August at 11:00 she emailed the branch and the nodal officer; the account was hot-listed on 17 August at 15:00. Investigation shows the money left after a vishing call in which she read out an OTP; the bank's own systems were not breached. The branch manager must now decide who bears the ₹63,000 and reply to her threat to complain to the RBI Ombudsman.
1. Apportion liability across the four debits, setting out the reasoning for each part of the amount rather than citing a rule number.
Read the worked answer
Liability in unauthorised electronic transactions turns on two questions: whose act caused the loss, and when did the customer notify the bank.
The three debits of 21:40 (₹48,000). The cause is the customer's own act - she disclosed the OTP to a caller. There is no bank system breach, and the 21:40 alerts gave her immediate notice. Her liability therefore runs until she notifies the bank, and at 21:40 she had not. No bank deficiency caused these three debits: the helpline outage did not create the loss, since the money had already gone. On a strict application, ₹48,000 is borne by the customer.
The debit of 23:10 (₹15,000). By then she had tried to notify at 22:30. The attempt failed only because the bank's own reporting channel was unavailable, and the outage was undisclosed. A bank cannot rely on its own service failure to defeat a notification; the report is deemed effective at 22:30. Loss after notification is the bank's, so ₹15,000 must be credited to her account.
Note what is not being invoked: if her loss had been caused by the bank's deficiency, her liability would be nil irrespective of when she reported. Here the bank's failure came after, not before, the loss.
2. She now threatens to approach the RBI Ombudsman. What should the bank actually do, and by when?
Read the worked answer
The threat should be treated as a deadline, not a provocation.
Make an offer now. Credit the ₹15,000 attributable to the post-notification debit immediately. Holding a clearly payable amount while arguing about the rest converts a defensible case into an indefensible one.
Resolve within the customer-protection timeline. The bank is expected to resolve a disputed unauthorised-transaction complaint and credit the amount due within 10 working days of the customer's notification; failure attracts a per-day compensation of ₹100 for the delay. On a 16 August notification, the branch is already running close to that clock, and the 17 August hot-listing shows the bank had the facts early.
Reply in writing, with reasons, on the ₹48,000 - what happened, what was found, why that part is hers, and the escalation route. A written, reasoned reply is also the precondition for any later defence, because the customer must first complain to the bank and may approach the Ombudsman only if she gets no reply within 30 days or is dissatisfied.
Settle rather than litigate. Under the integrated ombudsman scheme the award can run to ₹20 lakh, plus compensation for hardship up to ₹1 lakh; an adverse finding here is likely on the post-notification ₹15,000 and cheap to avoid.
3. It later emerges that the OTP went to a mobile number that had not been used for 400 days and that the bank had never re-verified. How does that change your answer?
Read the worked answer
It changes the answer fundamentally - for the whole ₹63,000, not just the last debit.
The basis for apportionment is the cause of the loss. Had the OTP been sent to the number the customer actually uses and controls, the entire loss would be attributable to her disclosure. But sending a transaction-authorising OTP to a stale, unverified number is a deficiency on the bank's side: the authentication factor was delivered to a channel the bank had no reason to consider secure, and the customer was never asked to re-confirm it.
Where the loss arises from the bank's own negligence or deficiency, the customer's liability is nil irrespective of whether, or when, she reported the transaction. So the ₹48,000 also falls on the bank, and the total credit becomes ₹63,000. The valuation question about the 22:30 call becomes academic, though it should still be recorded in the file.
Operationally, three follow-ups are needed: freeze and re-verify registered mobile numbers that have been dormant beyond the internal threshold, treat the case as a fraud incident reportable to the bank's fraud-monitoring function, and correct the customer-facing process so that an OTP is never issued to a number not recently re-validated.