Skip to content

What RBI’s 2027 liability framework changes for banks

From 1 January 2027, RBI’s amended framework for limiting customer liability applies to digital transactions. Whether the bank was negligent becomes a question it must answer with evidence, case by case.

5 min read8 sources

In this guide

Read this firstThis guide summarises RBI’s press release of 24 June 2026 and public reporting of the final directions. The terms are as reported, so check RBI’s own text before acting on them. Nothing here is legal advice.

What RBI has changed

RBI issued its amendment directions on limiting customer liability in digital transactions on 24 June 2026.1 They apply to electronic banking transactions made on or after 1 January 2027.23 As reported, they do four things:

  • Zero liability on negligence. The customer carries zero liability where the bank was negligent.
  • Compensation for small losses. Individual losses of up to ₹50,000 can be compensated at 85% of the net loss or ₹25,000, whichever is lower. It is a once-in-a-lifetime benefit, and it needs a report to the bank and to the national cybercrime portal or the 1930 helpline within five calendar days.
  • A shared cost. The compensation is reported to be funded mainly by RBI, with banks contributing.
  • Faster alerts. Banks must send instant SMS alerts for transactions above ₹500.

The final text follows a draft published in March 2026, which proposed the same small-value compensation from 1 July 2026.4 The start date then moved to 1 January 2027.

Where it builds from

The principle is not new. Since July 2017, RBI’s circular on limiting customer liability in unauthorised electronic banking transactions has given customers zero liability when the bank is at fault or when the fraud is reported in time, so the loss sits with the bank.5 The circular is plain about who has to prove what:

“The burden of proving customer liability in case of unauthorised electronic banking transactions shall lie on the bank.”

As reported, the 2026 directions restate zero liability where the bank was negligent, and add a compensation scheme for small losses that banks help to fund. Two things follow: more disputes will turn on what the bank did, and small-value fraud now carries a direct cost for the bank as well as the customer.

It arrives alongside other rules

RBI’s Authentication Mechanisms for Digital Payment Transactions Directions, 2025, have been in force since 1 April 2026. Two-factor authentication stays the baseline, issuers may add risk-based checks beyond it, newer factors are encouraged and SMS OTP is not banned.67

Read together, the two sets of directions ask a bank to authenticate well, to add risk-based checks where the risk calls for them, and to expect to carry the loss where its controls fall short.

There is a third direction of travel. RBI’s April 2026 discussion paper floats a one-hour hold on digital payments of ₹10,000 or more. It is not final.8 It shows what happens when nobody can tell which session is at risk: friction for everyone.

What changes for banks

1. Negligence becomes a question of evidence

If the customer’s liability turns on whether the bank was negligent, the bank needs to show which checks ran, what they found, and what the customer was told and when. A record written at the moment of decision is stronger than one reconstructed from logs weeks later.

2. Small losses get a price

The compensation scheme covers losses of up to ₹50,000, and banks contribute to it. Small-value fraud now carries a direct cost on the bank’s side, through that contribution, as well as on the customer’s.

3. The window is short

A customer has five calendar days to report a loss for compensation. On real-time rails, a payment settles in seconds, and money in a mule account can move on long before five days are up. Recovery after the fact is the exception. The control that counts is the one that acts before the payment leaves.

4. Blanket holds become the fallback

If losses land on banks and no one can tell which session is at risk, the fallback is to slow everyone down, as the discussion paper’s one-hour hold would. A blanket hold has four costs:

  • Good customers wait on every large payment: rent, school fees, a deposit on a flat.
  • Scammers adapt. A threshold tells them where to split the money.
  • A caller who has kept someone on the line for hours can wait out an hour.
  • The hold says nothing about why, so the customer is told nothing useful.

A bank that can target holds at risky sessions has a better answer than holding every payment above a threshold. A targeted hold needs evidence from the session itself: the call, the shared screen, dictated typing, the amount against the customer’s own pattern, and the payee against the mule graph.

A checklist for the weeks before 1 January 2027

  1. Map the journeys where money leaves: a new payee, a payment, a device or SIM change, and account recovery.
  2. For each, decide what the record of a decision must show: the signals, the action, the reasons and the message the customer saw.
  3. Check that transaction alerts reach customers for transactions above ₹500.
  4. Test your controls on your own closed cases: which payees and mule accounts were linked, and what a pilot on live sessions should measure.
  5. Agree what success means before any proof on live traffic: detection lift, false-positive change, review-queue impact and latency.

Where DeepID fits

DeepID authenticates the customer and reads the session around every login, new payee and payment. That covers the network check and one-tap login, SIM and device binding, face checks, device integrity, behaviour, scam signals such as an active call or a shared screen, and payee and mule links. It returns one decision, with its reasons, to the bank’s app and to its FRM before money moves.

Every decision is logged with its reasons and the message shown to the customer, and policies are versioned, so a bank can show which rule applied and when. DeepID supports compliance and never guarantees it, and it claims no regulator approval.

Teams start with one journey, sign-up, login or payment, piloted in shadow on their own traffic. Fraud teams can begin with a free retrospective that shows the payee and mule links in their own closed cases.

Related pages

Sources

Secondary sources are news or trade reporting of a rule or figure. Check the regulator’s own text before relying on them. Nothing in this guide is legal advice.

  1. RBI (opens in a new tab), Jun 2026Press release: amendment directions on the review of the framework of limiting customer liability in digital transactions, effective 1 January 2027
  2. MediaNama (opens in a new tab), Jun 2026, press reportRBI’s final amendment directions on limiting customer liability in digital transactions, in effect from 2027
  3. Business Standard (opens in a new tab), Jun 2026, press reportRBI issues amendment directions on the framework of limiting customer liability in digital transactions
  4. Outlook Money (opens in a new tab), Mar 2026, press reportSmall-ticket digital fraud to come under compensation cover in RBI’s draft liability overhaul
  5. RBI (opens in a new tab), Jul 2017Customer protection: limiting liability of customers in unauthorised electronic banking transactions
  6. RBI (opens in a new tab), Sep 2025Press release: directions on authentication mechanisms for digital payment transactions
  7. RBI (opens in a new tab), Sep 2025Authentication Mechanisms for Digital Payment Transactions Directions, 2025
  8. The Paypers (opens in a new tab), Apr 2026, press reportRBI proposes transaction delays and senior-citizen protections to combat digital payment fraud

More guides.

Each one dated, with every rule and figure cited to its source.

Start with what your history can show.

A free retrospective on 30 to 90 days of your own transactions shows the payee and mule links in them. Session signals follow in a shadow proof, once the SDK runs.