TL;DR

• RBI’s final rules, notified August 6, 2026 and effective January 1, 2027, bar lenders from remotely locking or restricting a borrower’s phone, tablet, or laptop as a collections tactic.
• One narrow exception exists: loans that financed the specific device. Even then, four conditions apply before any restriction is legal.
• Full lockout is never permitted. Essential functions (incoming calls, SMS, emergency SOS) must stay live throughout, and outgoing calls are protected for an initial window.
• Lenders and their tech vendors are barred from accessing any personal data on the device, under any circumstances.
• Wrongful or delayed restriction triggers compensation of ₹250 per hour, capped at the loan amount.
• Any device-restriction feature now needs its own standalone, auditable consent at loan origination, separate from general T&C consent.
• Most digital lenders don’t have this feature at all. For them, before January 2027 this is a matter of confirming removal, not planning a build.

The Question Most Compliance Teams Are Answering Wrong

Ask a collections or compliance lead at a mid-sized NBFC whether RBI’s new device-locking rules apply to them, and the answer usually comes fast: “We don’t do aggressive collections. This is for the app-based lenders with the bad press.”

That’s the wrong question. RBI’s rule, effective January 1, 2027, doesn’t ask what a lender’s collections philosophy is. It asks something narrower and harder to talk your way around: can you produce, timestamp by timestamp, exactly what your app did and didn’t do to a specific borrower’s device, on a specific day, in a specific default stage?

That’s an audit-proof question. A lender can have a spotless collections culture and still fail it, if the underlying system never logged the events an examiner asks to see.

What Changed and When It Takes Effect

• RBI notified final rules on August 6, 2026, issued as nine parallel circulars, one per regulated entity category.
• The commercial bank circular is cited in secondary reporting as RBI/2026-2027/223, DOR.MCS.REC.No.193/01-01-032/2026-27. This citation comes from secondary sources summarizing the notification and should be checked against RBI’s own circular repository before being reproduced in a filing.
• The rules take effect January 1, 2027, extended from an originally proposed October 1, 2026 date in a May 20, 2026 draft (Press Release 2026-2027/298).
• This confirms the January 2027 timeline flagged earlier in this series (posts 1 and 4). If your compliance calendar still shows October 2026, that’s the draft date, not the final one.

The Core Rule, and the One Exception That Applies

The baseline rule is a flat prohibition: lenders cannot remotely lock or restrict a borrower’s phone, tablet, or laptop as a recovery tactic. This applies across loan categories.

RBI carved out exactly one exception: loans that financed the specific device being restricted, commonly gadget or device-financing loans. Even inside that exception, four cumulative conditions have to be met before any restriction is legal:

1. Express, unambiguous disclosure at origination. The possibility of device restriction has to appear clearly in the loan agreement, not buried inside general terms and conditions.
2. Staged notice before restriction. The borrower has to be notified in advance, in stages, before any restriction action begins after default.
3. Graduated restriction, never a full shutdown. Essential functions, incoming calls, SMS, emergency SOS and safety alerts, stay live throughout. Outgoing calls specifically are protected for an initial window.
4. OEM or platform certification. The locking mechanism itself has to carry certification from the device manufacturer or platform provider, not be a lender-built overlay with no sign-off from Android or iOS.

Miss any one of the four, and the exception no longer applies, which puts the loan back under the flat prohibition.

The Staged Restriction Timeline, and Why the Exact Days Aren’t Settled Yet

RBI’s staging logic follows a recognizable shape: notice, cure period, graduated restriction, and only then anything approaching fuller restriction, with essential functions live at every point along the way.

What isn’t settled is the exact number of days at each stage. Secondary sources summarizing the circulars describe a notice-and-cure process spanning roughly 60 to 90 days before any restriction can begin, but the precise thresholds vary from source to source. Treat this as directional until it’s confirmed against RBI’s primary circular text, particularly before citing a specific day-count in a compliance filing or borrower-facing disclosure.

What Stays Barred Regardless of the Exception

Two things hold true even for a fully compliant gadget-financing lender operating inside the exception:

• No access to personal data on the device. Lenders and their technology vendors are barred from accessing contacts, messages, photos, location, or any other personal data on the device, under any circumstances. The exception covers restriction of function. It does not extend to access of content.
• Compensation for wrongful or delayed restriction. A borrower is owed ₹250 per hour, capped at the disbursed loan amount, if a device is restricted outside the rules, or isn’t restored within the required window once the default is cured or the restriction is otherwise lifted.

That compensation clock runs on the same logic as the notice stages: it needs a system that knows precisely when a restriction started and when it should have ended.

Where This Intersects With DPDP Consent Architecture

Posts 2 and 4 in this series covered the DPDP consent architecture requirements for AI-initiated collections outreach. The device-locking rule adds a related but distinct requirement: any device-restriction feature needs its own standalone, specific, auditable consent captured at origination, separate from general T&C or DPDP data-processing consent.

The two consents don’t have to live in separate systems. A lender that already built origination-time, purpose-specific consent capture for DPDP compliance has the architectural foundation to add a device-restriction consent record the same way, timestamped, immutable, and tied to the specific loan agreement clause it supports.

What Device-Locking Compliance Software Actually Has to Log

This is where the rule stops being a legal question and becomes a systems question. Two different audiences need two different answers.

If you’re a digital lender without a device-restriction feature (most lenders): confirm, in writing, that your app has no device-locking, app-disabling, or remote-restriction capability of any kind. If a legacy vendor integration ever shipped one, even dormant, it needs to be removed and documented as removed before January 2027. This is fundamentally an audit exercise: building toward the exception when you don’t do gadget financing creates exposure with no corresponding business need.

If you’re a legitimate gadget-financing NBFC that needs the feature, device-locking compliance software for NBFCs has to log, at minimum:

• A standalone origination-time consent record, distinct from general T&Cs, tied to the specific device-financing clause.
• An immutable audit trail of every notice sent, every stage transition, and every restoration event, each with a timestamp that can’t be edited after the fact.
• Contact-hour-style logic extended to cover the outgoing-call protection window, the same way existing rules govern permitted contact hours for collections calls.
• Restoration SLA tracking, so a lifted restriction is measurably restored within the required window, not just marked resolved in a ticketing system.
• Compensation-calculation logic that can reconstruct, on demand, whether a restriction was wrongful or delayed and what’s owed as a result.

This is what iTuring’s Model Governance module is built for. An immutable audit trail with maker-checker approval on every stage transition, built to be RBI/MRM-ready and to produce an account-level explanation on demand, is the same governance layer that already needs to exist for credit decisioning and collections scoring. A device-restriction workflow is one more process writing to that same layer, rather than a separate system built from zero.

What January 2027 Readiness Actually Looks Like

None of this is settled by updating a policy document. A compliance officer who can point to a paragraph in the loan agreement about device restriction hasn’t answered the question an examiner will actually ask, which is whether the system can produce the timestamped record: when the borrower consented, when each notice went out, when a restriction started, when it was lifted, and what essential functions stayed live throughout.

Between now and January 2027, the lenders in the clear will be the ones who’ve confirmed which side of that line they’re actually on.