DPDPA Compliance for NBFCs: Personal Data Classification and Consent at Loan Origination

A loan approval in India today rarely rests on a single document. It draws on bureau scores, parsed bank statements, GST filings, device signals, and patterns pulled from a borrower's phone. That blend of personal, financial, and behavioural data is exactly what makes DPDPA fintech lending such a hard area to get right. Every one of those inputs is personal data, and under the Digital Personal Data Protection Act, each needs a lawful reason to sit in your systems.

Here is the part most lending teams skip past. The Act does not care how clever your underwriting model is. It cares whether the borrower agreed to what you are doing with their data, and whether you can prove it later.

Classifying personal data in DPDPA fintech lending

You cannot consent-manage data you have never mapped. The DPDPA treats all personal data the same way at a definitional level, meaning anything that can identify a person. The operational reality in lending is messier, because you collect several very different categories in the same flow.

Walk through your origination journey and you will usually find PAN and Aadhaar details (which carry their own statutory rules on top of DPDPA), income and employment records, bank account and transaction histories, credit bureau data, GST and tax filings, and the growing pile of alternative data such as device fingerprints, app usage, and location history. Each one sits on a different consent or legal footing. Treating them as one bucket is where most gaps begin.

The alternative data column is the one teams underestimate the most. They know they collect it. They rarely know exactly which third party it flows to next.

Consent at origination sets the foundation for compliant data processing

The loan application is the moment you have the borrower's full attention. It is also the only point where collecting the loan origination consent India regulators will accept is straightforward rather than a retrofit.

At origination you need separate consent for several distinct things: the credit bureau enquiry, bank statement analysis, alternative data processing, marketing after the application, and any sharing with co-lending partners or insurers. A common mistake is bundling all of this into one tick box at the bottom of a form. The DPDPA requires each purpose to be agreed to on its own, and each one must be possible to withdraw on its own. One checkbox covering five purposes falls short of what this law requires, and invites a complaint.

This separation-of-purposes logic runs through other regulated outreach too, which is why it is worth seeing how Section 6 reshapes outbound calling if your collections or cross-sell teams pick up the phone.

Where Section 7 fits, and where it stops

Certain lending activities rely on grounds other than consent. Section 7 of the DPDPA recognises certain legitimate uses that do not need separate permission. Reporting borrower data to credit information companies, for one, is something lenders are legally required to do under the credit information regime, so that processing has a lawful basis without asking again.

The line that often gets blurred: a legal duty to report data covers only that specific obligation, and reusing the same data for another purpose falls outside it. Using bureau-linked data for cross-selling, profiling, or model training is a separate purpose, and a separate purpose needs its own consent. The scope of any Section 7 ground has to be drawn tightly around the obligation that justifies it, and not a centimetre wider.

Bureau enquiries deserve their own note. Pulling someone's credit report should happen only with their explicit, purpose-specific permission. Plenty of platforms still bury this inside a blanket terms-and-conditions acceptance at sign-up. Under DPDPA that does not hold, because consent for a bureau pull has to be visible, specific, and standalone.

Alternative data is the highest-risk corner

The area that draws the first wave of scrutiny in fintech data privacy India is alternative data. Device data, app permissions, location trails, and social signals get processed for scoring purposes that are almost never explained to the borrower in plain words.

That gap, between what you collect and what the borrower understands you collect, is precisely what the Act was written to close. Alternative data DPDPA compliance calls for more than a tooltip fix. It usually means rebuilding the Notice and the consent flow so the borrower can see that their phone usage feeds a credit decision. This is uncomfortable work, because transparency here can lower conversion, though losing a few percent of approvals is preferable to explaining to the Data Protection Board why borrowers were left unaware that their location history was a scoring input.

What a compliant data architecture needs underneath

A DPDPA-compliant lending stack needs a few core controls working together.

Consent should be recorded at origination in real time, along with the exact version of the Notice presented to the borrower. Access should be controlled by purpose, so data collected for underwriting does not automatically get reused for analytics or marketing. If a borrower withdraws consent after disbursement, that withdrawal needs to reach every system that continues to process the data.

You also need a tamper-proof audit trail. If the regulator asks what a borrower agreed to months earlier, you should be able to show exactly what Notice was presented, when consent was given, and what happened afterward.

For lenders dealing with healthcare or medical-financing data, additional considerations may apply where sensitive personal information is involved.

The DPDPA allows financial penalties of up to ₹250 crore for failing to keep reasonable security safeguards, a figure significant enough for lenders handling financial data at scale to treat as a real compliance risk.

Healthcare lenders and BNPL players touching medical bills should also look at how sensitive personal data and patient consent raise the bar further, since some of your borrowers' records may carry that extra weight.

The advantage hiding in the obligation

Lending's data edge is real. It has to rest on consent the borrower gave. Borrowers are getting sharper about how their information moves, and supervisory attention on this sector is only growing. Building consent-first infrastructure now costs less than rebuilding it under a notice from the Board later, and it happens to earn borrower trust at the same time. If you want to see how a consent layer fits your origination flow without slowing it down, start with OneConsent.

If you want to make consent a seamless part of your lending journey, see how OneConsent can help you build a consent-first origination flow.