DPDP meets RBI: data obligations for digital lenders and LSPs
Lending Service Providers and digital lenders answer to two rulebooks at once. Where RBI directions and the DPDP Act overlap, reinforce, and appear to conflict — and how to structure retention, consent, and data flows that satisfy both.
Two rulebooks, one borrower
A borrower's data in a digital lending flow is governed simultaneously by RBI's digital lending directions (need-based collection, explicit borrower consent for data sharing, no access to phone contacts/media, data localisation expectations, LSP accountability sitting with the Regulated Entity) and by the DPDP Act (notice, valid consent, security safeguards, erasure rights, breach notification, processor contracts).
The good news: a flow designed honestly for RBI's directions is 70% of the way to DPDP. The remaining 30% is where the two regimes use different concepts — and where enforcement risk hides.
Who is the Fiduciary here?
In the standard arrangement — LSP sources, KYCs, or services borrowers on behalf of an NBFC or bank — the Regulated Entity (RE) determines the purpose and means of processing. That makes the RE the Data Fiduciary and the LSP a Data Processor under DPDP. This matches RBI's stance that outsourcing does not outsource accountability.
Consequences that follow: the RE owns the borrower notice and consent record; the LSP processes only under a written contract (make sure it now carries DPDP clauses, not just the RBI outsourcing boilerplate); Data Principal rights requests land with the RE even if a borrower emails the LSP — build the forwarding workflow; and a breach at the LSP is the RE's 72-hour notification to the Data Protection Board. LSPs running their own products (say, a PFM app) on the same data are a separate Fiduciary for that processing — document the boundary precisely.
The retention conflict, resolved
DPDP Section 8(7): erase personal data when consent is withdrawn or the purpose is served — unless retention is necessary for compliance with any law. That carve-out is the whole answer, applied narrowly:
For the RE
KYC records and transaction records carry statutory retention under PMLA (five years) and RBI directions; loan account records follow the applicable preservation norms. These override erasure requests — but only for the named records, only for the named period. Marketing profiles, behavioural analytics, and app telemetry enjoy no statutory shelter: those go when consent goes.
For the LSP
Once data is transferred to the RE and the LSP's contracted purpose is complete, the default is deletion. An LSP retaining borrower data "in case the RE asks later" is exactly the untethered retention DPDP targets. The clean pattern: a contractual retention window for dispute support (commonly 90–180 days), then certified deletion with a deletion certificate to the RE. If a specific law binds the LSP directly (e.g., it is itself regulated), document which law, which records, which period.
The register that keeps you honest
One retention schedule listing every data category, its purpose, its legal basis for any retention beyond purpose-completion (statute + section + period), and its deletion trigger. This single artefact answers the borrower who invokes erasure, the RBI inspector, and the Data Protection Board in the same breath.
Build your retention schedule in 10 minutes
Free tool: map data categories to DPDP purposes and statutory overrides — export as your compliance register.
Build the schedule →Consent flows that satisfy both regimes
RBI demands explicit borrower consent before an LSP or DSA shares data with a lender; DPDP demands that consent be free, specific, informed, unconditional, and as easy to withdraw as to give. Combined checklist for the sourcing journey: an unticked, purpose-specific checkbox naming the recipient category ("sharing with [lender] for loan processing" — not "and our partners"); notice available in the languages your borrowers actually read; consent recorded with timestamp, notice version, and channel; withdrawal reachable in as few steps as grant; and downstream propagation so a withdrawal at the app actually stops processing at the RE's CRM and collections stack.
Where enforcement will bite first
Based on the complaint patterns already visible: contact-list and gallery access (banned by RBI, and a DPDP violation on collection-limitation grounds), data shared with unnamed "partners", recovery agents receiving full borrower files when a name and outstanding amount would do, and ex-borrowers receiving marketing years after closure. Every one of these is a complaint a single borrower can file with the Data Protection Board — enforcement here is complaint-driven, and lending produces motivated complainants.
Frequently asked questions
Can an LSP retain borrower data after transferring it to the lender?
Only within a defined contractual window (commonly 90–180 days for dispute support) or where a law directly binding the LSP requires retention. Otherwise DPDP Section 8(7) points to deletion once the contracted purpose is complete. Best practice is certified deletion with a deletion certificate issued to the Regulated Entity.
Does PMLA's five-year retention override a borrower's erasure request?
For the records PMLA actually names — KYC documents and transaction records — yes: retention required by law overrides erasure, for that period. It does not shelter marketing data, behavioural analytics, or anything outside the statutory scope. Segregate and legal-hold the covered records; delete the rest.
Who notifies the Data Protection Board if the breach happens at the LSP?
The Regulated Entity, as Data Fiduciary, owns the 72-hour notification to the Board and the notification to affected borrowers. The LSP's contract should obligate immediate incident reporting to the RE — hours, not days — so the RE can meet its clock. The RE cannot delegate this liability away.