On this page · 9 sections
Summary. On 6 August 2026 the Reserve Bank of India issued nine Amendment Directions on the conduct of regulated entities in loan recovery, and they come into effect on 1 January 2027. Buried in the last clause of press release 2026-2027/827 is the part that changes product roadmaps: the directions cover "conduct of REs while deploying a technology-based mechanism for recovery of loan dues in financed mobile devices of a borrower." That is the first time an Indian regulator has written rules for device locking. The May 2026 draft proposed a 90-day-past-due trigger, a notice at 60 DPD with 21 days to cure, a further notice giving 7 more days, reversal within one hour of the default being cured, and a ₹250 per hour penalty for wrongful restriction or delayed reversal. The market this lands on is large: fintech-focused NBFCs sanctioned over 10.9 crore personal loans worth ₹1.06 lakh crore in FY 2024-25. Nine regulated-entity categories are covered, from commercial banks to HFCs. Roughly five months of engineering time remain. This guide maps the draft parameters to the systems that have to change.
What the RBI actually issued on 6 August 2026
The press release is short and the operative sentence is precise: "Accordingly, the Reserve Bank has today issued the following Amendment Directions, which shall come into effect from January 1, 2027."
The instruments cover nine categories of regulated entity. Commercial banks, small finance banks, local area banks, regional rural banks, urban co-operative banks and rural co-operative banks receive Fourth Amendment Directions, 2026. All-India financial institutions and NBFCs receive Third Amendment Directions, 2026, as do housing finance companies.
The scope statement covers the familiar recovery ground: fair treatment of borrowers during recovery, conduct of a lender's employees and recovery agents, due diligence, training and a code of conduct for agents. Then the clause that is new: "and also conduct of REs while deploying a technology-based mechanism for recovery of loan dues in financed mobile devices of a borrower."
A draft was issued on 20 May 2026 with a feedback window, and the RBI published a disposition of the comments it received alongside the final directions.
One point of discipline before any of this reaches a sprint plan. The parameters below come from the May 2026 draft as analysed by Cyril Amarchand Mangaldas, not from the final text. The final Amendment Directions supersede the draft, and the RBI has published a comment-disposition annex precisely because some of these numbers were contested. Build against the draft parameters as your working assumption, then have counsel reconcile every threshold against the notified text before you freeze the schema. Anyone quoting the draft figures as settled law in December will have a difficult January.
The draft framework, parameter by parameter
Writing in Conventus Law on 28 July 2026, Cyril Amarchand Mangaldas summarised the Draft Amendments to the Reserve Bank of India (Non-Banking Financial Companies - Responsible Business Conduct) Directions, 2025, at paragraph J.3.4 and clauses 100Q to 100S:
| Parameter | Proposed requirement | System that owns it |
|---|---|---|
| Restriction trigger | 90 days past due, after prior notices give the borrower an opportunity to cure | Collections engine, DPD calculation |
| Notice sequence | Notice at 60 DPD with 21 days to cure, then a subsequent notice giving 7 more days | Communications service, audit log |
| Restriction scope | Graduated, not a blanket lock; internet, communication and emergency services stay available | Device agent or MDM policy |
| Reversal | Within one hour of the default being cured | Payment webhook to unlock path |
| Penalty | ₹250 per hour for wrongful restriction until lifted, and for delayed reversal until functions are restored | Reconciliation and provisioning ledger |
| Data access | Absolute prohibition on accessing personal data on the device | Device agent permissions, DPDP posture |
| Product scope | Device-financed loans only | Loan origination product codes |
| Uninstallation | The device-locking software is removed on repayment | Lifecycle and closure workflow |
The firm's framing of what this does to the product is worth quoting, because it is the strategic point rather than a compliance detail: "By anchoring the trigger at 90 DPD and embedding DL within the responsible business conduct framework, the RBI is positioning it as a pure recovery mechanism. The implication is that lenders lose the ability to treat DL as a form of security interest over the financed asset."
That distinction has a direct engineering consequence. If device locking is a recovery mechanism rather than security, it belongs in the collections stack with a full audit trail and a cure path, not in the origination stack as a risk-mitigant that quietly justifies a thinner underwriting model.
The 8 changes that actually take engineering time
1. One DPD clock you can defend in an audit
Every threshold in the framework hangs off days past due, and most lending stacks compute DPD in more than one place: once in the core lending system for classification, once in the collections tool for queueing, and often once more in a data warehouse for reporting. When those three disagree by a day, a restriction applied at what one system calls 90 DPD is a wrongful restriction under another, and the draft attaches ₹250 per hour to that.
Pick one authoritative DPD source, make the others read from it, and store the exact value that was used for each restriction decision alongside the decision. Not the current value. The value at decision time.
2. Consent captured in the loan agreement, and reproducible years later
The framework permits restriction only where the borrower agreed to it. That means the consent artefact has to survive the loan: which version of the agreement, which clause, which timestamp, which channel, and whether the borrower could have completed the journey without agreeing.
This is the same evidentiary problem the Digital Personal Data Protection Act 2023 creates for processing consent, and it is worth solving once. A consent record that satisfies a DPDP notice request and an RBI inspection is the same record. Teams that already worked through the RBI digital lending directions engineering checklist will have most of this pattern in place.
3. Notice pipeline with delivery evidence
Two notices, at 60 DPD and after the 21-day cure window expires, each starting a clock. A notice your system believes it sent is not evidence. Delivery receipts, bounce handling, language selection and a retry policy all sit on the critical path, because the second notice cannot legitimately start its 7-day window if the first never arrived.
Practical design: treat each notice as a state transition on the loan, not as a message. The loan moves to notice-served only when a delivery event confirms it, and the cure clock starts from that event.
4. One-hour reversal that does not depend on a human
Reversal within one hour of the default being cured is the hardest number in the table, because it turns your payment reconciliation latency into a regulatory exposure. Most collections stacks confirm a payment on a batch reconciliation that runs several times a day. That is not compatible with a one-hour service level.
The design has to be event-driven end to end: payment success webhook, idempotent unlock command, acknowledgement from the device agent, and a timestamped record of all three. Then a watchdog that alerts when the acknowledgement does not arrive, because a device that is switched off or out of coverage is the common failure and somebody has to be able to show what was attempted.
Assume partial failure. Build the unlock command to be safely repeatable and default to unlocked when the state is ambiguous. The regulatory cost of an unnecessary unlock is zero; the cost of an unnecessary hour of restriction is a per-hour penalty.
5. Device agent that restricts function without reading data
The prohibition on accessing personal data stored on the device is described as absolute. That constrains the agent's Android permission set, the SDKs it embeds, and the telemetry it emits. Any analytics SDK that collects contacts, SMS or installed-app inventory has to go, and the exclusion has to be provable to an auditor who reads your manifest rather than your policy document.
Google Play's own policy direction runs the same way, so this is not only an RBI requirement. A lending app that requests contact or SMS permissions for recovery purposes has two regulators to satisfy, and the store one can remove your distribution overnight.
Design the agent to hold the minimum: a device identifier bound to the loan, a restriction state, and a command channel. Nothing else needs to leave the handset.
6. Graduated restriction with a protected core
The draft rules out a blanket lock and requires internet, communication and emergency services to keep working. In practice that means a policy layer that can restrict discretionary function while leaving a protected set intact, and a definition of that protected set you can defend.
Cyril Amarchand Mangaldas argues the protected layer should be defined by function rather than by connectivity: "Certain services such as banking, payments, authentication, emergency communications are integral to a borrower's ability to participate in the economy and service their obligations." That is also the pragmatic engineering position, since a borrower who cannot open a payments app cannot cure the default that triggered the restriction.
7. Uninstallation on repayment, tracked to completion
Removal of the device-locking software on repayment is a lifecycle event with a failure mode nobody plans for: the loan closes, the removal command is issued, the device never comes back online, and the agent sits on the handset indefinitely. You need a closure state that distinguishes removal-commanded from removal-confirmed, an ageing report on the gap, and a fallback the borrower can trigger themselves.
8. Reconciliation ledger for the penalty exposure
If the final directions keep a per-hour penalty, somebody has to compute it. That is a ledger: restriction applied at time T1, cure event at T2, restoration confirmed at T3, with the chargeable window derived and posted. Retro-fitting that from logs after the first dispute is expensive. Build it as a first-class record from day one, and reconcile it monthly against your customer-complaint data.
Why the market makes this urgent
Device financing is not a niche. Fintech-focused NBFCs sanctioned over 10.9 crore personal loans worth ₹1.06 lakh crore in FY 2024-25, and digital lenders disbursed ₹97,381 crore in small-ticket personal loans in one half-year, largely to borrowers entering the formal credit system for the first time.
The pattern outside India shows why regulators moved. In Kenya, M-KOPA has disbursed over $1.6 billion to 4.8 million customers through a pay-as-you-go model built around device lock, and Watu Simu has financed nearly two million devices since 2022 using internet-enabled locking software. In those markets locks engage early, sometimes from the first missed payment. No major jurisdiction had a dedicated statutory framework for the practice before India's draft, and the United States regulates handset locking by carriers during financing rather than lender-initiated restriction.
So Indian lenders are, unusually, building against the first real rulebook rather than the last. That is an advantage if your architecture treats the parameters as configuration rather than as constants compiled into the collections engine.
What this costs, honestly
| Workstream | Typical effort | Where teams underestimate |
|---|---|---|
| DPD single source of truth | 2 to 4 weeks | Backfilling historical decisions for existing loans |
| Consent capture and retrieval | 3 to 5 weeks | Versioning the agreement and proving which version applied |
| Notice pipeline with delivery evidence | 3 to 4 weeks | Multi-language delivery and bounce handling |
| Event-driven unlock inside one hour | 5 to 8 weeks | Replacing batch payment reconciliation on the cure path |
| Device agent permission reduction | 3 to 6 weeks | Removing third-party SDKs that collect device inventory |
| Penalty reconciliation ledger | 2 to 3 weeks | Agreeing the chargeable-window definition with finance |
Those ranges assume an existing lending platform with a working collections module, and they run in parallel more often than in sequence. The binding constraint is usually not code. It is that the payment, collections and app teams report to three different leaders, and the one-hour reversal path crosses all three.
India-specific considerations
Three things make this an India-only engineering problem rather than a localisation of a global product.
The DPDP overlap is the first. A device agent on a borrower's personal handset is processing personal data on behalf of a data fiduciary, and the RBI's absolute prohibition on accessing stored data narrows what your agent may hold. Build the permission set and the retention policy together, because a DPDP notice asking what data you hold about a borrower should be answerable without inspecting an APK.
The nine-entity spread is the second. A lending-technology vendor serving a small finance bank, an NBFC and an HFC is now subject to three separate Amendment Directions with the same effective date. Product configuration has to be per-entity-type from the start, not a single global policy with exceptions bolted on later.
Third, recovery agents remain in scope. The directions cover due diligence, training and a code of conduct for agents alongside the technology clause. Any agent-facing tool that can trigger or view a restriction needs role-based access, an action log tied to a named individual, and a training-completion gate. A collections app where any agent can restrict any device is the finding that writes itself. The DPDP engineering playbook and the RBI e-mandate engineering checklist cover the adjacent obligations that usually land on the same sprint.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation founded in 2021, CMMI Level 5 assessed and ISO 27001:2022 certified, with senior-led teams building lending and payments software for Indian regulated entities. For this change we work on the parts that are engineering rather than paperwork: a single defensible DPD source, an event-driven cure-and-unlock path that meets a one-hour reversal target, a device agent with a minimum permission set, and the audit and reconciliation records an inspection will ask for. We design applications aligned with RBI and DPDP requirements and work alongside your counsel on interpretation rather than in place of them. If you are scoping this against a 1 January 2027 date, talk to our fintech engineering team, or read how we approach NBFC digital lending app development.
References
Last updated: 9 August 2026.
