DPDP Compliance for Fintech and Lending Apps: KYC, Credit Data and Algorithmic Decisions

Identity documents, address proof, and video KYC recordings are collected primarily because regulation requires them, which places this processing under the Section 7 legitimate-use ground for compliance with law rather than pure consent. That distinction matters operationally: a borrower cannot simply withdraw consent to make their KYC record disappear while a loan is active, because the retention is compliance-driven, not consent-driven.

Where a lending app collects data beyond what KYC rules require — social media handles, contact-list access, device metadata scraped for alternate scoring — that extra collection needs its own notice and, where no legitimate use applies, its own specific consent. Bundling that extra collection into a single “KYC consent” checkbox blurs a mandatory step with an optional one and invites a grievance.

Reporting repayment data to credit bureaus, and pulling a credit report before disbursal, are core parts of the lending flow and typically fall under legitimate use or explicit consent captured in the loan agreement. Because that shared data materially affects the borrower's future access to credit, Section 8(3)'s requirement to keep data accurate and complete where it is used for a decision or disclosed to another fiduciary applies with real force here.

A stale or wrongly reported default can follow a borrower across every lender that queries the bureau, so the correction workflow under Section 12 needs a fast path — not just a generic grievance email — for a borrower disputing a bureau entry. The lending app's own contract with the bureau should specify who corrects what, and how quickly.

Alternate-data credit models — scoring built from app usage, transaction patterns, or device signals — make an automated decision that determines whether someone gets a loan and at what price. The inputs to that model need the same accuracy discipline as any other decision-affecting data, and a rejected applicant's right to access under Section 11 should extend to understanding, at a summary level, what categories of data fed the decision.

A lending platform notified as a Significant Data Fiduciary carries added weight here: periodic data protection impact assessments and independent audits under Section 10 are the natural place to interrogate whether the scoring model is using data proportionately, and whether the model's outputs are being kept accurate as circumstances change.

Many lending apps use cloud infrastructure or fraud-analytics vendors outside India. Section 16 lets the government restrict transfers to specific notified countries, and separately, payments-related data in India carries longstanding regulatory expectations around keeping certain payment system data domestically located. A fintech's vendor list should be checked against both constraints, not just the DPDP one.

Contracts with any offshore processor should require the same security safeguards and breach-notification timelines that Section 8 imposes on the fiduciary directly, since liability to the borrower and the Board does not shift just because a vendor sits in another jurisdiction.

The Obligation Finder is a useful starting point for separating what your KYC and lending workflow does under legitimate use from what it does under consent, since the two require different notices and different withdrawal mechanics. Follow that with a Vendor Assessment covering credit bureaus, scoring vendors, and cloud infrastructure providers.