DPDP for banks and NBFCs: KYC, lending apps, co-borrowers and collections

In September, Business Standard reported that the State Bank of India had procured the software and hardware it needs for compliance with the Digital Personal Data Protection Act, and expects to be compliant by the end of December 2026. That is almost five months before the substantive provisions apply on 13 May 2027.

The timing makes sense. Few businesses hold as much personal data as a bank or an NBFC, about as many kinds of people, under as many overlapping rules. A lender's processing touches account holders, borrowers, co-borrowers, guarantors, nominees, employees, field agents and the individuals behind its business customers. Its records are governed by the RBI's directions, the Prevention of Money Laundering Act, credit information law and CERT-In's directions, as well as by the DPDP Act.

This article works through the areas where DPDP compliance in lending is hardest, and where the Act meets the rules lenders already follow.

KYC: collected under one law, kept under another

Customer due diligence is required by the PMLA and the RBI's KYC directions. A bank or regulated NBFC cannot open an account or disburse a loan without it. Under the DPDP Act, that processing still needs a lawful basis and a notice that tells the customer what is collected and why.

The more difficult question is retention. Section 8(7) of the DPDP Act requires personal data to be erased once the purpose has been served or consent is withdrawn. The exception is where retention is necessary to comply with a law. KYC records and transaction records must be kept for the periods the PMLA and the KYC directions require after the relationship ends. When a former customer asks for erasure, the lender can and must decline to erase those records, while erasing what no law requires it to keep.

Section 12(3) makes room for this. It allows a Data Fiduciary to retain data when retention is needed for a specified purpose or to comply with law. What it doesn't allow is a blanket refusal. A well-run erasure process deletes the marketing preferences, the app analytics and the scanned documents no longer needed, keeps the records the law requires, and tells the customer what has been kept, why and until when.

Co-borrowers, guarantors and nominees

Most lenders know their borrowers well. The people around a loan are often an afterthought.

A co-borrower, a guarantor or a nominee is a Data Principal in their own right. Their personal data, often including PAN, Aadhaar details, income documents and contact numbers, usually reaches the lender through the primary applicant, not from the person directly. That raises three questions every lender has to answer.

• Notice. Has the guarantor received a notice that meets Section 5, telling them what data the lender holds about them, why, and how to exercise their rights?
• Lawful basis. On what ground is the lender processing their data? A guarantee is a contract with the guarantor. A nominee's details are usually supplied by the account holder. Each needs its own basis, and none of them follows automatically from the borrower's.
• Rights. If a guarantor asks what data the lender holds about them, can the lender find it? In many loan origination systems, a guarantor is a few fields inside the borrower's record, not a person who can be searched for.

Nominees deserve particular care. Section 14 of the DPDP Act gives every Data Principal a right to nominate someone to exercise their rights on death or incapacity. That is a separate concept from a banking nominee under the Banking Regulation Act, even though both are called nominees. Customer-facing teams need to understand the difference, and notices should not blur it.

Lending apps and digital lending

Digital lending already has its own data rules. The RBI's directions on digital lending require that data collected through lending apps is need-based, collected with the borrower's prior and explicit consent, and auditable. They restrict apps from accessing mobile phone resources such as files and media, contact lists and call logs, with limited one-time access for camera, microphone and location where needed for onboarding.

The DPDP Act sits on top of those requirements and adds to them in three ways.

First, consent has to be specific to a purpose. A single "I agree" at onboarding that covers loan processing, credit assessment, cross-selling and analytics doesn't meet Section 6. Each purpose that relies on consent needs its own choice, and optional purposes cannot be a condition of the loan.

Second, withdrawal has to be as easy as giving consent, and processing for that purpose has to stop. A borrower who withdraws consent to marketing must stop receiving it, across every channel and every partner who acts for the lender.

Third, the lender is responsible for what its lending service providers and app partners do with the data. Where an app is run by a partner, that partner usually acts as a processor for the lender, and Section 8(2) requires a valid contract. The lender cannot point to the partner if the consent journey in the partner's app fails the Act.

Collections and recovery agents

Collections is where personal data moves furthest from the lender. Recovery agencies, call centres and field agents work with borrowers' names, numbers, addresses, loan details and, often, the numbers of family members and references.

Under the DPDP Act, a collection agency processing data on the lender's behalf is a Data Processor. Section 8(2) requires a contract, and Section 8(1) keeps the lender responsible for compliance, whatever the agency does. The contract should cover the purposes for which data may be used, security safeguards, breach reporting to the lender, deletion when the engagement ends, and the lender's right to audit.

Two practices in collections deserve a hard look.

Reference and contact numbers. Numbers collected as references during onboarding are personal data of the people they belong to, who usually never agreed to be contacted about someone else's loan. Using them in collections raises questions under the DPDP Act as well as under the RBI's fair practices expectations.

Call recordings. Recordings of collection calls contain personal data of the borrower and sometimes of others in the household. They need a retention period, access controls and a place in the rights process. A borrower's access request covers recordings about them.

Joint accounts and shared data

Joint accounts create a problem most rights processes don't anticipate. When one holder of a joint account asks for access to their personal data, the records that answer the request often contain the other holder's data too: transactions they initiated, their contact details, their KYC documents.

The Act gives each Data Principal rights over their own personal data, not over someone else's. A lender answering an access request from one joint holder has to decide what belongs to the requester, what belongs to the co-holder, and what genuinely belongs to both, such as the account's transaction history. The same problem arises with family floater policies sold through a bank, with business accounts where several individuals are authorised signatories, and with loans that have several co-borrowers.

The practical answer is to set rules for these cases in advance, write them into the rights procedure, and train the team that handles requests. Deciding case by case, under a ninety-day clock, produces inconsistent answers and invites grievances.

Employees, agents and direct selling agents

A bank's own people are Data Principals too. Employee data processed for employment purposes has a legitimate use under Section 7, which covers payroll, attendance, performance and the other routine parts of employment. It doesn't automatically cover everything. Background checks run by third parties, monitoring of personal devices, and data kept long after someone leaves all need their own analysis.

Lenders also work with large numbers of people who aren't employees: direct selling agents, business correspondents, field collection staff employed by agencies, and the individuals who work for partner fintechs. Their personal data, including identity documents, bank details and performance records, is often scattered across onboarding portals, spreadsheets and email. It needs a place in the processing record, a lawful basis and a retention rule, like any other population.

Credit bureaus, co-lending and group companies

A lender exchanges data with credit information companies, co-lending partners and, often, other companies in its group. Under the DPDP Act, each of these is usually a separate Data Fiduciary, deciding its own purposes, rather than a processor acting for the lender.

That matters for notices and lawful basis. Credit information reporting is governed by its own legislation, and the lender's notice should explain it. Co-lending involves two regulated entities processing the same borrower's data for a shared loan. Each needs a lawful basis, and the borrower should understand that both are involved.

Group structures are a common blind spot. A bank, its NBFC subsidiary, its insurance arm and its broking company are separate Data Fiduciaries under the Act, even when they share systems and staff. Sharing customer data between them for cross-selling needs its own basis, which will usually be consent.

Account Aggregators and consent

Many lenders already use the RBI's Account Aggregator framework to obtain financial data with the customer's consent. Account Aggregators run a structured consent process under RBI regulation, with consent artefacts that specify the data, the purpose and the duration.

That framework is useful, but it doesn't discharge the lender's own duties under the DPDP Act. The lender still needs a notice that explains why it wants the data, a lawful basis for each purpose, and a retention rule for the data once it arrives. Data obtained through an Account Aggregator for an underwriting decision shouldn't quietly flow into marketing models. Whether particular Account Aggregators will also register as Consent Managers under the DPDP Rules is a separate question, and lenders should watch the first registrations after 13 November 2026 before planning around it.

Security safeguards and incidents

The highest penalty in the Act's Schedule, up to ₹250 crore, applies to failing to take reasonable security safeguards to prevent a personal data breach. Rule 6 sets out what reasonable safeguards include: encryption, obfuscation, masking or tokenisation, access controls, logging and monitoring, backups, and measures to detect and respond to unauthorised access. It also requires logs to be retained for one year.

Banks already operate under the RBI's IT governance and cybersecurity expectations, and much of that work counts. The DPDP lens adds one question to every control: where does personal data sit, and is it protected there? Plaintext Aadhaar numbers in a reporting database, copies of KYC documents in shared folders, and unmasked identifiers in test environments are common findings.

Incident handling now involves several clocks running from the same moment. CERT-In expects a report within six hours of noticing a cyber incident. The DPDP Rules require the Board and affected people to be informed without delay, with a detailed report to the Board within seventy-two hours. The RBI has its own reporting requirements for regulated entities. One playbook should cover all of them, with named decision-makers and pre-approved templates.

AI in credit decisions

Many lenders now use machine learning in credit assessment, fraud detection and collections. The RBI's FREE-AI committee report, released in August 2025, recommends Board-approved AI policies, transparency with customers when they deal with AI, and explainability for decisions such as credit.

The DPDP Act adds its own requirements. Section 8(3) requires a Data Fiduciary to ensure the completeness, accuracy and consistency of personal data where it is likely to be used to make a decision that affects the Data Principal. Training a model on personal data, or feeding personal data into a model, is processing, and needs a lawful basis and a notice. A large lender likely to be designated a Significant Data Fiduciary will also face the Rules' requirement to verify that its algorithmic software doesn't pose a risk to Data Principals' rights.

Branches, paper and assisted channels

A great deal of lending still happens at counters, through field staff and on paper. The DPDP Act covers personal data collected in non-digital form once it is digitised, which in practice means almost every paper form a lender processes.

That makes assisted channels a priority. Branch staff and agents need a way to give the notice and record the customer's choices, ideally in a form that produces the same record as a digital journey. Scanned documents need retention rules. Old physical files that are being digitised bring their contents into scope as they are scanned.

A checklist for lenders

What good looks like

The lenders who will be in the strongest position in May 2027 aren't the ones with the longest policies. They are the ones who can answer a specific customer's question quickly and with evidence: what data do you hold about me, who have you shared it with, and why do you still have it?

That answer depends on knowing every system and every population, on a retention schedule that reconciles the DPDP Act with the rules banks already follow, and on records that show what was done and when. SBI's decision to finish by December reflects a simple calculation. The work takes longer than the calendar suggests, and every month gained now is a month of testing before the date that counts.