Solutions · NBFCs & fintech

One loan. Four copies.
No defined owner.

A single loan passes through an originator, a co-lender, a lending-service provider, a collections agent and four credit bureaus, and each of them holds the borrower’s record. The DPDP Act addresses its rights to “the Data Fiduciary” — singular. No instrument in the lending stack says which copy answers an erasure request, or how a correction accepted by one party reaches the others. For app-first lenders the intake problem is largely solved by the login itself; the hard part is fulfilment across a graph of copies that nobody mapped.

FROM THE SEPTEMBER 2026 PROBLEM REGISTER · 10 PROBLEMS SWEPT · 4 SHOWN HERE · HOW THIS WAS BUILT

What the ground actually looks like

Four collisions, each read from the instrument.

Each of these is marked confirmed: two independent sources, at least one the instrument or a practitioner record. Sources are linked so your counsel can read them.

01 · RETENTION VS ERASURE, WITHOUT A SAFE HARBOUR

A lender must refuse most erasure requests on PMLA and RBI KYC grounds, prove the basis per record — and still erase everything that falls outside it, with the Rules’ 48-hour notice.

DPDP s.12 and s.8(7) require erasure once the purpose is served unless retention is required by law; PMLA s.12 and the RBI KYC Master Direction require five years. The Third Schedule’s fixed erasure clocks apply to e-commerce, gaming and social media — not to fintech — so a lender self-derives retention per data category and defends it. The refusal is lawful, but only record by record, in writing, with the specific statutory basis. Practitioners note there is “no explicit DPDP retention schedule for credit data.”

SOURCES · DPDP Rules 2025 (notified 13 Nov 2025) — retention and pre-erasure notice provisions (text) · Vinod Kothari Consultants, implications for financial-sector entities (practitioner) · RSRR on digital lending under DPDP (practitioner)

Confirmed · sweep of 2 Sep 2026
02 · WHO IS THE FIDUCIARY, PER DATA ELEMENT

In the lender–LSP–app stack, nobody can say per data element who determines purpose — so rights routing, breach duty and consent-record ownership have no owner.

The default is clear at entity level: the regulated entity is the fiduciary, the lending-service provider its processor. The real problem is narrower and worse. An LSP that runs its own analytics, its own cross-lender matching or its own decisioning is a fiduciary for that slice even while a processor for the loan slice — one data flow, two fiduciaries for different elements. The RBI Digital Lending Directions make the regulated entity accountable for the LSP’s conduct but do not allocate data rights.

SOURCES · RBI (Digital Lending) Directions, 2025 (instrument, 8 May 2025) · IndusLaw sector FAQs (practitioner) · RSRR (practitioner) · Vinod Kothari (practitioner)

Confirmed · a per-element allocation problem, not blanket ambiguity
03 · CO-LENDING: ONE BORROWER, MANY COPIES

Under the Co-Lending Directions each co-lender is plainly a fiduciary, so a borrower can lawfully demand the same correction twice and receive two different outcomes on one loan.

The RBI Co-Lending Directions, 2025 mandate a single customer-interface entity for servicing and allocate nothing for data rights. Each co-lender reports the same loan to the credit bureaus independently. A correction accepted by one lender leaves stale copies at the other and at every bureau — and nobody has published a working propagation protocol.

SOURCES · Vinod Kothari on the Co-Lending Directions, 2025 (practitioner) · Legal500, data privacy in digital lending (practitioner)

Confirmed · the absence of any allocation is itself the finding
04 · COLLECTIONS AND THE THIRD PARTY

Calling a borrower’s references, family or employer at default is processing a third party’s personal data for which no consent chain exists.

Under DPDP s.6 the consent must come from the data principal — the reference, not the borrower. The universal origination practice of collecting two or three reference contacts and calling them at default rests on boilerplate that fails specificity, disclosure and rights-notification requirements, and the lender is liable for its collection agents’ conduct. The reference never had a relationship with the lender at all: no notice, no consent, no legitimate-use hook.

SOURCES · DPDP Act s.6, s.8 (statute) · “Privacy Meets Recovery” — debt collection under DPDP (practitioner) · RBI Fair Practices / recovery-conduct rules (instrument, context)

Confirmed · structural in reference-based lending
What the law actually says — and what it doesn’t

Claims we corrected before putting them here.

The register started from AI-drafted hypotheses and kept only what the instruments supported. These are the lending-specific claims that changed on the way.

DPDP does not mandate “delete or re-consent” for legacy data.

Section 5(2) is a grandfathering-by-notice mechanism: lawfully collected pre-Act data continues under a retrospective notice, with no fresh consent required. Deletion is compelled only where no valid original consent existed — which is exactly the device-data troves (contacts, gallery, SMS) the RBI lending rules already prohibit. The distinction matters for what you build.

The lending stack’s roles are not “unclear.” They are split per element.

The mainstream position is settled at entity level: regulated entity as fiduciary, LSP as processor. The problem is that an LSP is a fiduciary for its own-purpose slices. Treating this as blanket ambiguity leads to a contract clause; treating it as a per-element allocation leads to a data map.

Intake is not the bottleneck for app-native lenders. Fulfilment is.

An authenticated session verifies identity at intake in-product — the one scale advantage fintechs hold over platforms whose users never log in. What no login solves is fulfilment across the originator, co-lender, LSP, bureau and collections copies.

The Third Schedule’s erasure clocks do not apply to fintech.

The fixed three-year inactivity clocks are for e-commerce, gaming and social media above their user thresholds. A lender has no safe-harbour clock and must derive retention per data category from PMLA, the KYC Direction and its own purpose analysis.

No DPDP adjudication against any lender exists.

The Board had no members as of 1 August 2026 and the penalty provisions commence in mid-May 2027. Every severity statement on this page is exposure-based, not enforcement-history-based — and the register says so. The penalty schedule is stated plainly here, once.

RULES NOTIFIED MID-NOV 2025 · CONSENT-MANAGER REGISTRATION OPENS MID-NOV 2026 · DUTIES, RIGHTS AND PENALTIES MID-MAY 2027 · DATES STATED AS THE NOTIFICATIONS STATE THEM

Where Consent Tree fits today

The request, its clock, its outcome
and where it went next.

Everything below is live today and maps to shipped code — the same rule as every page on this site. Capabilities we are still building are not listed here.

FOR 01 · THE REQUEST YOU MUST REFUSE

A rights request executed, timed and evidenced — with the refusal on the same record

Every access, correction and erasure request carries a response deadline computed when it is filed and an escalation ladder when it slips. An erasure cannot be marked complete unless its execution path is configured, and the destruction is recorded, not asserted. The written refusal for a PMLA-held record lands in the same audit chain, dated and attributable.

Live: DSR orchestration · SLA tracking · grievance workflows
FOR 03 · THE CORRECTION THAT MUST TRAVEL

A completed correction is dispatched to every processor the person’s data was disclosed to

When a correction completes, each processor recorded against that person’s consent is notified, and a delivery record is kept per processor — pending, delivered or failed — as evidence of who was told and when. It does not rewrite the processor’s copy for them; it makes the propagation, and its gaps, visible instead of assumed.

Live: correction propagation to processors, with per-processor delivery evidence
FOR 02 · THE ROLE MATRIX

Your processors as a register, with each signed DPA tracked and scored

The platform models you as the fiduciary and holds your processors and their data-processing agreements as a scored register — effective dates, expiry, status. Per-element fiduciary-versus-processor allocation across a co-lending chain is not something any tool the register found does, and ours does not either. The register to hold your allocation in exists; the allocation is yours to write.

Live: processor registry · DPA tracking on the scorecard
FOR ALL OF IT · EVIDENCE

Purpose-level consent, and an audit trail a regulator can verify without trusting us

Consent is captured per processing purpose, never all-or-nothing, and withdrawn as easily as it was given. Every consent, erasure, refusal and notice publication is a linked record bound to the one before it, periodically stamped by an independent timestamp authority. Anyone can check the chain.

Live: purpose-by-purpose consent · tamper-evident audit trail · verifiable receipts