DPDP and Bank Statement Data: The Questions Lenders Should Be Asking Their Vendors

For a lender, DPDP compliance on bank statement data comes down to three things. Collect only what the credit decision needs. Erase it when the purpose ends, unless a law requires you to keep it. And answer for everything a vendor does with it. The substantive obligations and the penalties commence on 13 May 2027.

The compliance clock is now specific. The Digital Personal Data Protection Rules were notified on 13 November 2025 and commence in three stages.

In January 2026 MeitY consulted on compressing the window to twelve months. The proposal was not notified, and the government's own August 2026 statement still describes an eighteen-month transition. Plan to 13 May 2027, and watch for an amendment.

Most lender compliance work so far has focused on customer-facing consent flows. The larger exposure sits elsewhere: in the borrower data already sitting with analysis vendors, in what those vendors do with it, and in the fact that the obligation does not transfer along with the file.

A bank statement is not merely financial data

This is the part that is consistently underestimated, and it determines how much care the category deserves.

A year of bank statements does not just show income and obligations. It shows pharmacy and hospital payments, which indicate health conditions. Donations, which indicate religion. Contributions, which can indicate political affiliation. Transaction locations and timings, which reconstruct movement and routine. Payments to schools, lawyers, counsellors, and dating or matrimonial services. Recurring transfers that map a person's relationships.

It is among the most revealing documents an individual possesses, and lending is one of the very few contexts in which people hand it over as a matter of routine, in bulk, to institutions they have no relationship with yet.

The Act does not create a special category for sensitive data, but it does make the "type and nature of the personal data affected" a factor in setting a penalty, under section 33(2)(b). A breach of bank statements is not priced like a breach of email addresses. That richness is also why this data deserves treatment beyond the minimum, independent of what any rule requires.

What DPDP compliance actually requires of lenders

Six obligations bite directly on statement data.

Purpose limitation. Consent is given for a specified purpose, and under section 6(1) it must be limited to the personal data necessary for that purpose. Data collected to assess a loan application is collected for that purpose: not for cross-selling, not for portfolio analytics, and not for improving a product, unless separate consent covers it. This is the obligation most likely to be breached quietly and at scale, because secondary use rarely feels like a new collection.

Data minimisation. Collect what the purpose requires. Most retail lenders ask for three to six months of statements and business lenders for six to twelve. Sahamati's fair use template for Account Aggregator underwriting caps the range at 14 months, on the reasoning that thirteen completed months show a trend. A request for twenty-four months needs a reason the file can state. Taking every account when the assessment needs the operating accounts is the same problem.

Retention limitation and erasure. Under section 8(7), data must be erased once the purpose is no longer being served, unless retention is necessary to comply with a law. Lending has genuine competing obligations here, set out in the next section, and the resolution is not to retain everything indefinitely by default but to map retention to each legal basis explicitly and erase what no basis covers. A declined application is the clearest case: the purpose ended, the lending relationship never began, and the statements are still in the system.

Notice. Itemised, in plain language, specifying the purpose, under Rule 3. A clause buried in a sanction letter does not meet this.

Security safeguards. Rule 6 lists them: encryption, obfuscation or masking; access control; logs and monitoring able to detect unauthorised access; backups; and a contract clause requiring each Data Processor to take the same safeguards. Breach intimation under Rule 7 goes to every affected person without delay and to the Board without delay, followed by a detailed report within 72 hours.

Processor accountability. Covered below, and the one that matters most commercially.

Three retention clocks, not one

"Delete it when you are done" is the right instinct and the wrong rule. A lender's statement data sits under three clocks at once.

Two consequences follow. A vendor answer of "we retain nothing at all" is no longer automatically the best answer, because from May 2027 the one-year floor applies to processing done on your behalf, and your contract has to say who holds those logs. And a declined file cannot simply be erased on the day of decline: the one-year floor still runs, and whether KYC retention applies to an applicant who never became a customer is a question for your compliance counsel. What the clocks do not support is keeping a declined applicant's full statements indefinitely because nobody decided otherwise.

The Third Schedule's fixed retention periods and its 48-hour pre-erasure notice apply only to large e-commerce, online gaming and social media platforms. They do not name lenders.

The lender remains the Data Fiduciary

When a lender sends borrower statements to an analysis vendor, the lender is the Data Fiduciary and the vendor is a Data Processor acting on the lender's instructions under contract.

The obligation does not transfer. Section 8(1) makes the Data Fiduciary responsible for compliance "irrespective of any agreement to the contrary", including for processing undertaken on its behalf by a Data Processor, and section 8(2) permits a processor only under a valid contract. If the vendor retains data longer than the purpose supports, uses it for something the borrower did not consent to, or suffers a breach, the lender is answerable for it. "Our vendor handles that" is not a position that survives a regulatory enquiry, and the penalty exposure sits with the institution holding the customer relationship.

A breach at a vendor that follows weak safeguards maps to the first row, whichever company's systems it happened on.

This makes vendor arrangements a compliance question rather than a procurement one, and it is worth reviewing existing contracts against it well before May 2027: not because enforcement starts then, but because renegotiating a processor agreement with an incumbent vendor takes longer than most teams expect.

RBI already asks for much of this

For regulated lenders, DPDP lands on top of rules that already govern vendors handling borrower data. Since 28 November 2025 they sit in RBI's consolidated directions.

• Digital lending. The rules issued in May 2025 and now folded into the credit facilities directions require data collection to be need-based, with the borrower's prior explicit consent and an audit trail. Lending service providers may store only basic minimal data. Data must sit on servers in India, and anything processed abroad must be deleted there and brought back within 24 hours.
• Outsourcing. The Managing Risks in Outsourcing Directions, 2025 replaced the earlier financial services and IT outsourcing directions. They keep ultimate responsibility for an outsourced activity with the lender, and require control over sub-contracting by the service provider.
• Incident reporting. CERT-In's 2022 directions require reportable cyber incidents to be reported within six hours of noticing them, and RBI sets a six-hour window for NBFCs reporting cyber incidents.

The DPDP vendor questions below are not new paperwork. They are the same diligence, now with a statutory penalty attached.

Seven questions to put to any analysis vendor

Each of these should have a contractual answer, not a reassuring one. They sit alongside the capability questions in our vendor evaluation protocol, and are worth asking in the same parallel run.

1. Where is the data processed, and where does it rest? Processing inside the lender's own environment is a materially different exposure from data leaving for a vendor's infrastructure. Ask specifically, and ask about intermediate copies: queues, caches, logs and debug stores are where data persists unnoticed. For regulated lenders, ask whether every copy stays in India.

2. What is retained after the analysis completes, for how long, and by whom? The useful answer is a retention schedule that separates the raw statements, the analysis output and the processing logs, ties each to a purpose or a legal requirement, and states who holds the logs that Rule 8(3) requires. "Stored securely" describes the how, not the whether.

3. Is borrower data used to train or improve your models? Ask it plainly, get it in writing, and expect a nuanced answer: most analysis tools do improve from processed data in some form, and the question is whether that use is disclosed, consented to, contractually bounded, and separable on request. A vendor who has not thought about this will say no quickly. A vendor who has will explain exactly what is used, in what form, and what a lender can switch off.

4. Can data be erased on instruction, and does that include backups, derived datasets and training corpora? Erasure that covers the primary store and nothing else is not erasure.

5. What are the sub-processors? A named list, with notification obligations before it changes. Vendors frequently use cloud OCR, enrichment or storage services that the lender has never assessed. Under section 11(1)(b) a borrower can ask the lender for the identities of every Data Processor their data was shared with, so the lender needs this list whether or not it ever reviews it.

6. What is the breach notification commitment? A defined window, in hours, with a defined channel. The lender's own clocks are short and they stack:

The lender's clocks start when it becomes aware. A vendor commitment measured in days creates a timing problem the lender cannot solve.

7. Does the Data Processing Agreement survive termination, and what happens to the data? Deletion certificates, timelines, and the fate of anything derived.

Why the Account Aggregator path is structurally cleaner

Under the Account Aggregator framework, data moves from the provider to the user encrypted end to end, against a consent artefact that records the purpose, the type of information, who receives it and when the consent expires. The technical standard adds the date range, the fetch frequency and how long the recipient may keep the data. RBI's 2025 directions for account aggregators state that no financial information may reside with the aggregator. For a lender, that is a consent record that exists as a machine-readable artefact rather than as a tick box in an application form.

The ecosystem's fair use templates also build minimisation in:

Two cautions, though.

The AA consent is granted under the RBI's framework, and the DPDP consent requirements are a separate regime with their own notice and purpose specifications. Overlapping is not the same as satisfying, and a lender should not assume one discharges the other. The DPDP Rules' own illustration of a Consent Manager describes a bank statement moving from one bank to another without the Consent Manager being able to read it, which is close to a description of an AA. Sahamati asked in March 2025 that AAs be recognised as Consent Managers, and no official position had been published as of October 2026. The relationship is a question worth putting to your own compliance counsel rather than to a vendor.

And consent scope still has to be designed for the whole lifecycle. A one-time consent taken at underwriting does not authorise a later fetch, which is both an operational constraint and, approached the other way, a discipline: it forces purpose to be specified at the point of collection, which is what the regulation is asking for anyway. We covered the mechanics of this in our post on what AA does and does not solve.

Collections: the one exemption, and its limits

Section 17(1)(f) disapplies most of the Act where personal data is processed to ascertain the financial information, assets and liabilities of a person who has defaulted on a loan or advance from a financial institution. Consent, notice, erasure and the borrower's rights do not apply to that processing. The Act's own illustration is a missed EMI.

Two limits matter. The exemption does not switch off section 8(1) accountability or the section 8(5) duty to keep reasonable security safeguards, so a collections vendor holding statement data carries the same breach exposure as an underwriting vendor. And it covers default, not monitoring: watching a performing borrower's account still needs a consent designed for it. The case for reading capacity and intent from the account during collections is set out in our post on collections prioritisation.

Minimisation is an analysis question, not only a legal one

There is a point where privacy obligations and good credit practice converge.

Collecting twenty-four months when fewer suffice is a compliance exposure. It is also usually unnecessary: twelve months captures a full seasonal cycle, which is what business assessment actually requires, and more history rarely changes a decision that twelve months does not already support. For a salaried file, three to six months usually settles income and obligations, as covered in our guide to analysing a bank statement for a loan application.

Similarly, the argument for resolving a transaction's counterparty and purpose precisely, rather than storing raw narration indefinitely and re-deriving later, is a minimisation argument as much as an accuracy one. The analysis output a credit team needs is a fraction of the raw data, and a process that produces the output and discards the input, keeping only what the retention clocks require, holds less risk than one that accumulates statements against possible future use.

The honest framing: data minimisation and analytical rigour mostly pull in the same direction. Where they conflict, the conflict should be a documented decision rather than a default.

A short readiness list

Seven things worth having settled well before May 2027.

1. Map where borrower statement data currently sits: your systems, your vendors, their sub-processors, and any intermediate stores.
2. Define retention by legal basis, separately for sanctioned, declined and withdrawn applications, against all three clocks. Declined files are the most common unexamined accumulation.
3. Review processor agreements against the seven questions above, and start with the vendors holding the most data.
4. Specify purpose in your notice at the level you actually use the data, including any secondary use you intend.
5. Establish an erasure process that reaches derived data, not just the primary store.
6. Align breach notification windows so that every vendor commitment fits inside your shortest regulatory clock, which for cyber incidents is six hours.
7. Design AA consent for the loan's life: a one-time underwriting consent and, where you intend to monitor, a separate periodic consent requested at origination.

None of this is unusual data governance. The change is that it is now enforceable, on a date, with a number attached.

Frequently asked questions

When does the DPDP Act become enforceable for lenders? The Rules were notified on 13 November 2025. Consent Manager registration under Rule 4 commences on 13 November 2026, and the substantive obligations (notice, consent, security safeguards, breach intimation, retention and erasure) commence on 13 May 2027 along with the penalty provisions. A January 2026 proposal to shorten the timeline to twelve months had not been notified as of October 2026.

Is a lender responsible for what its analysis vendor does with borrower data? Yes. The lender is the Data Fiduciary and the vendor is a Data Processor acting under contract. Section 8(1) keeps the lender responsible irrespective of any agreement to the contrary, and the penalty exposure remains with the institution holding the customer relationship.

What are the penalties under DPDP for a lender? Up to ₹250 crore for failing to take reasonable security safeguards to prevent a breach, up to ₹200 crore for failing to notify a breach, up to ₹150 crore for breaching Significant Data Fiduciary obligations, and up to ₹50 crore for any other breach. The Board considers the type and nature of the data affected when setting the amount.

Can borrower bank statement data be used to train models? Only within what the consent and purpose specification support. Secondary use beyond the stated purpose requires its own basis, which is why the question should be answered contractually, covering what is used, in what form, and whether it can be excluded or erased on instruction.

How long can a lender retain bank statements from a declined application? Only as long as a legal basis supports it. The purpose ended when the application was declined, so erasure is due under section 8(7), but Rule 8(3) requires personal data, traffic data and processing logs to be kept for at least one year, and whether KYC retention applies to an applicant who never became a customer is a question for compliance counsel. Indefinite retention by default is not supported by any of these.

Does DPDP apply to loan collections? Mostly not, once a borrower has defaulted. Section 17(1)(f) exempts processing to ascertain a defaulter's financial information, assets and liabilities from consent, notice, erasure and the borrower's rights. It does not exempt the lender's accountability for its processors or its duty to keep reasonable security safeguards.

Does Account Aggregator consent satisfy DPDP requirements? Not automatically. AA consent is granted under the RBI framework and DPDP imposes its own notice and purpose requirements. The two overlap substantially but are separate regimes, and as of October 2026 there was no official position on whether AAs will be recognised as DPDP Consent Managers. Treat the interaction as a question for compliance counsel rather than an assumption.

---

Fiscus processes Account Aggregator data natively, deploys in your environment with data residency in India, and traces every figure in its output to the source document. Book a parallel evaluation to review the data handling alongside the output.