If your credit underwriting software pulls bureau data, runs scoring models, or stores KYC records, it needs changes before DPDP takes full effect. And the work should start now rather than closer to the deadline. Finezza works with lenders running exactly this stack, and underwriting software touches nearly every category of data the Digital Personal Data Protection Act, 2023 (DPDP Act) treats as sensitive: consent, purpose limitation, automated decision-making, and retention. Full enforcement lands on 13 May 2027, when the Data Protection Board of India (DPB) gets the power to issue penalties of up to ₹250 crore. That date is a deadline for work already in progress, not a starting gun.
The work doesn’t happen in isolation, either. RBI’s Responsible Business Conduct (Second Amendment) Directions, 2026, effective from 1 January 2027, add explicit per-product consent and a ban on dark patterns to how NBFCs sell products. DPDP and RBI aren’t racing each other. They’re two separate obligations on the same stack, and treating them as one line item is where gaps start.
Key Takeaways
- DPDP’s data minimisation principle means every distinct data pull, a bureau check, a KYC verification, an alternative-data signal, needs its own purpose and its own consent record, not one blanket application-level agreement.
- DPDP doesn’t create a GDPR-style right to an explanation for automated credit decisions, but Section 8 does require that any data used to make a decision be accurate, complete, and current.
- RBI’s Fair Practices Code already requires NBFCs to communicate the main reason for a loan rejection in writing on request, a separate obligation from DPDP that most underwriting software isn’t built to satisfy.
- Alternative data such as device intelligence or SMS-parsed transaction data needs its own disclosed purpose. Collecting it because it’s available, rather than because a specific model uses it, is over-collection under the Act.
- RBI’s KYC Master Direction and the Prevention of Money Laundering Act (PMLA) can override a DPDP erasure request for records a lender is legally required to retain.
Purpose-specific Consent for Every Data Pull
Credit underwriting software pulls from CIBIL, Experian, Equifax, and CRIF as a matter of routine, often as a background step the applicant never sees. Under DPDP, each pull is a separate processing purpose, and a single “I agree to the terms” checkbox doesn’t cover it. Consent has to be specific to the pull, captured before it happens, and recorded so the lender can produce it later.
Underwriting software that fires off bureau calls as a silent background step, with no discrete consent event attached to each source, is exactly the pattern DPDP’s purpose limitation principle is meant to end. RBI’s own consent rules for NBFCs, taking a harder line on bundled consent from 1 January 2027, are aimed at product sales rather than bureau pulls specifically, but the underlying expectation, that consent should be specific, points the same way.
Automated Decisions Need Accurate Inputs, Not Necessarily an Explanation
Credit underwriting increasingly leans on scoring models, some rules-based, some closer to machine learning, to arrive at an approval, a decline, or a risk-adjusted rate. Worth being precise here, because compliance guidance often overstates this part of the law. DPDP doesn’t give applicants a GDPR-style right to an explanation for automated decisions, and there’s no requirement to produce a factor-by-factor breakdown of a score. Section 8 asks for something narrower but still real: personal data used to make a decision affecting someone has to be accurate, complete, consistent, and current.
That’s a data-quality obligation. A scoring model built on stale bureau data or a bank statement parsed six months ago is a compliance problem under DPDP before anyone asks for an explanation. RBI’s Fair Practices Code, separately, already requires NBFCs to inform rejected applicants of the main reason if they ask. Combine the two and the practical requirement looks like a “right to explanation” even though it comes from two different sources, not one.
Alternative Data Has to Earn Its Place
A growing share of underwriting software pulls in signals beyond bureau history: device intelligence, SMS-parsed transaction data, app usage patterns. DPDP’s data minimisation principle means each category needs its own purpose-bound notice, not a blanket “for credit assessment purposes” clause covering everything the software happens to collect.
If underwriting software pulls location, contact lists, or granular device metadata that doesn’t map to a specific, disclosed use, that’s over-collection under the Act, whether or not the extra data ever changes the outcome. The safer design question is what a decision specifically requires before the pull happens, not what’s convenient to have on hand.
The Retention Conflict Between Dpdp and KYC Norms
RBI’s Master Direction on Know Your Customer (KYC) requires records to be retained for five years after a business relationship ends, and the PMLA carries its own record-keeping mandate on top of that. DPDP gives customers a right to request erasure, with a 90-day window for the lender to respond.
Those obligations don’t resolve themselves. Underwriting software needs to distinguish between data it’s legally required to keep, where RBI and PMLA mandates override an erasure request, and data held out of convenience, which has to go when asked. A system that treats every field the same way, keeping everything or erasing on request without checking the legal basis, gets half of this wrong.
Building This Into the Underwriting Stack
Purpose-tagged consent capture at the point of each bureau pull, rather than one consent event at the top of the application, is the starting point. A retention engine that can tell a legally mandated record apart from an erasable one closes the loop on the KYC conflict. Decision-reason logging in the scoring layer is worth building regardless of the explanation debate, since RBI’s Fair Practices Code already asks for it.
Frequently Asked Questions
1. Does DPDP give borrowers a right to know why their loan application was declined?
Not directly. DPDP doesn’t include a GDPR-style right to an explanation for automated decisions. Section 8 requires that data used to make the decision be accurate and current. Separately, RBI’s Fair Practices Code already requires NBFCs to give the main reason for rejection in writing if the applicant asks.
2. Does a single “I agree” checkbox cover a credit bureau pull under DPDP?
No. Each bureau pull, whether from CIBIL, Experian, Equifax, or CRIF, is a distinct processing purpose under DPDP. Consent has to be captured for each specific pull before it happens.
3. How does RBI’s Responsible Business Conduct framework relate to DPDP?
They’re separate obligations on separate timelines. RBI’s directions take effect from 1 January 2027 and focus on consent and mis-selling in product sales. DPDP’s substantive obligations take effect on 13 May 2027 and cover data processing across the board.
4. Can a lender delete a customer’s data if they request erasure under DPDP?
Only partially. RBI’s KYC Master Direction and the PMLA both require certain records to be retained for a set period, overriding a DPDP erasure request for that data. Data held only for convenience has to be erased when requested.
Conclusion
If your credit underwriting software was built before either framework existed, the practical next step is mapping every data pull it makes against a specific purpose and a consent record. That mapping exercise, not a single deadline, is the real task ahead.
Finezza’s Loan Origination System and Credit Bureau Data Analytics platform are both built around discrete, source-level integrations, separate consumer connections to CIBIL, CRIF, Experian, and Equifax, rather than one generic data pipe, giving compliance teams a workable starting point for this kind of mapping.
Book a demo to see how it fits into your existing underwriting stack.
Leave a Reply