If you run a fintech, NBFC, or digital lending app in India, you're now operating under two data laws at once — and they don't always agree with each other.
The DPDP Rules carry a phased compliance runway that most fintech teams haven't fully mapped against their onboarding flows yet. Meanwhile, RBI's KYC Master Directions and Digital Lending Directions are already in force — meaning several of your DPDP-adjacent obligations are effectively live today, not somewhere off in the future.
This post breaks down what actually changes for a KYC-heavy fintech, in operational terms — not the general "what is DPDP" explainer you've probably already read three versions of.
The core tension: two laws, one KYC flow
RBI's KYC Master Directions tell you what data to collect, from whom, and how to verify it — Aadhaar, PAN, address proof, financial statements. That collection is a legal obligation, not something you need separate consent for.
The DPDP Act governs what happens to that data afterward — how long you keep it, what else you use it for, and what rights the customer has over it. This is where most fintech consent flows currently fall short.
The practical distinction that matters:
- Data collected to satisfy RBI KYC requirements — legal basis is "legitimate use" (regulatory obligation). No separate DPDP consent needed for this specific use — but you still owe the customer a clear privacy notice explaining the basis.
- Any use of that same data beyond the regulatory purpose — marketing, cross-sell, behavioral profiling, sharing with lending partners for "better offers" — requires separate, explicit, specific, revocable consent under DPDP. This cannot be bundled into the same checkbox as loan acceptance.
A single "I agree to terms and KYC processing" checkbox that quietly also covers marketing and third-party data sharing is now a live compliance risk, not a gray area.
Where lending apps face the sharpest exposure: device data
This is the one regulators have already flagged once, under a different law. RBI's 2022 Digital Lending Guidelines already restrict lending apps from pulling contacts, call logs, gallery, or location data beyond what's strictly necessary for the loan decision. DPDP now makes the same over-collection a separate statutory violation — so a lending app that over-reaches on device permissions is exposed twice: once under RBI's digital lending rules, and again under DPDP consent requirements. That's a meaningfully higher penalty stack than either law alone.
If your onboarding flow requests contact list or SMS access "for fraud prevention" and that data later gets used for anything else — including recovery calls to references — that's a purpose-limitation breach under DPDP, on top of the RBI exposure.
What a compliant consent flow actually looks like
Based on how the DPDP Rules interact with existing RBI requirements, a defensible onboarding flow separates consent into distinct, specific items rather than one broad checkbox:
- Access to credit bureau report (CIBIL / Experian / Equifax)
- Bank statement analysis for income verification
- Sharing application data with co-lending or partner NBFCs
- Marketing communications and loan status updates
- Device data access (only where genuinely necessary, scoped narrowly)
Each needs its own affirmative action, its own timestamp, and its own audit trail — because under DPDP, you need to be able to show which consent covered which processing activity if a data principal ever files a grievance or the Data Protection Board asks.
Vendors and LSPs don't reduce your exposure — they extend it
If you work through a Lending Service Provider, KYC vendor, or co-lending partner, DPDP treats each data handoff as a separate processing activity. A vendor contract that's silent on purpose limitation and retention is itself a compliance gap — not just a commercial risk. The obligation stays with you as the Data Fiduciary even when a third party is doing the processing.
What to do — realistically, starting now
- Split your consent architecture. Separate "required for KYC" from "everything else," with distinct, logged consent for the latter.
- Audit device permissions in your app. If you're collecting contacts, SMS, or location beyond what the loan decision strictly needs, that's the highest-exposure item to fix first.
- Review vendor and LSP contracts for explicit purpose-limitation and retention language — don't assume RBI due diligence already covers this.
- Build the audit trail now. Consent timestamps, the exact text shown to the customer, and the user's action all need to be retrievable — not just logged somewhere.
- Check your Significant Data Fiduciary exposure early. High-volume NBFCs and digital lenders are strong SDF candidates, which triggers DPO appointment, DPIA requirements, and independent audits — these take months to stand up, not weeks.
None of this needs to wait for a final enforcement date. RBI's Digital Lending Directions already require most of the consent hygiene DPDP is now formalizing — so fixing your consent flow now closes two compliance gaps at once, not one.
ClearDPDP helps Indian fintech, edtech, and healthtech companies get audit-ready for DPDP — including consent architecture, ROPA generation, and DSAR management built for how Indian startups actually operate. See how it works.