What the DPDP Act changes for AI in lending

Most lenders have read summaries of the Digital Personal Data Protection Act, 2023. Fewer have worked through what it means once software, not a credit officer, is reading the payslips, bank statements and tax returns. The Act does not mention AI specifically. It does not need to. Its principles apply to any processing of personal data, and AI makes some of them harder to meet by accident.

Here is what that means in practice.

Where the law stands today

The Act received assent in August 2023. The Digital Personal Data Protection Rules, 2025 were notified in November 2025 with an eighteen-month period for phased compliance, so the main obligations on lenders, including notice, security safeguards, breach notification, retention and the exercise of data principal rights, apply from around May 2027.

Lenders should check the latest notification before fixing their own timelines, but the direction is clear: the work needs to start now, because changing how documents flow through a lending stack takes longer than a policy update.

Consent and purpose: one purpose at a time

Under the Act, consent must be free, specific, informed and limited to the purpose stated in the notice. A borrower who uploads a bank statement to support a loan application has agreed to that purpose. They have not agreed to their statement being used to build a marketing profile, or to train a general model sold to other businesses.

AI systems blur purposes easily. A single extraction pipeline may feed underwriting, fraud checks, cross-sell scoring and model improvement at once. The practical fix is to tag every processing job with its purpose and to refuse jobs whose purpose the borrower has not agreed to, or which no other lawful ground covers. When consent is withdrawn, processing for that purpose should stop across every system, not only in the loan origination screen.

Data minimisation: read what you need, mask what you don't

A KYC packet usually contains more than the lender needs. An Aadhaar card shows the full number when most purposes need only proof of possession. The RBI has long expected lenders to make sure Aadhaar numbers are redacted where authentication is not required.

The safest point to apply this is at intake. If the number is masked as the document arrives, it never reaches the extraction model, the review queue, the search index or the logs. Masking after the fact means finding every copy, and there are always more copies than anyone expects.

The same thinking applies to extraction. If underwriting needs net salary and employer name, the system should not quietly store every field it found on the payslip.

Retention and deletion: deletion that actually deletes

The Act expects personal data to be erased once the purpose is served or consent is withdrawn, unless another law requires it to be kept. Lending is full of such laws, so retention has to be decided per category of data and per purpose, not as a single number for everything.

The harder problem is technical. AI pipelines create derived copies: extracted text, embeddings in a search index, cached page images, training datasets built from reviewed work. Deleting the original PDF while its embeddings and training examples live on is not deletion. A sound design keeps a record of every derived artefact linked to its source, so that a single deletion request can be traced and carried out everywhere, and so that the lender can show it was done.

Borrower rights: explain what the system did

Data principals have the right to obtain a summary of their personal data and the processing done with it, to have it corrected or erased, and to have their grievances addressed. When AI is involved, a meaningful answer requires the lender to know which documents were read, which values were extracted, which ones a person corrected, and what recommendation followed.

This is far easier when every extracted value links back to the page it came from, and when anything the system could not confirm is flagged rather than guessed. A correction request then becomes a specific, checkable task, not an investigation.

Accountability: a person decides, and the record holds

The Act places responsibility on the data fiduciary, including for its processors. The RBI's FREE-AI framework, published in August 2025, points in the same direction for regulated entities: disclose where AI is used and keep people able to override it.

In practice, that means AI recommends and a person decides, with maker-checker sign-off on anything that affects a borrower. Every view, change and approval should be recorded in an append-only, tamper-evident audit trail. If a breach does happen, that same trail is what lets the lender work out quickly whose data was affected.

A checklist for your next AI project

• Is every processing job tagged with a purpose the borrower agreed to, or another lawful ground?
• Are Aadhaar numbers and other identifiers you do not need masked at intake?
• Can you list every derived copy of a document, including indexes and training sets?
• Does a deletion request reach all of them?
• Can a reviewer see which page each value came from?
• Does a named person sign off on decisions, and is that recorded in a way that cannot be altered?
• Do any documents leave your environment, and if so, to which processor and for what purpose?

We designed Inferova around these principles: Aadhaar masking at intake, per-entity separation enforced in the database, values linked to their source page, and an audit trail that cannot be quietly edited. None of that replaces a lender's own legal review.

If you would like to walk through these design choices on your own documents, you can request beta access at inferova.com/demo.

Sources