DPDP Compliance for BFSI: The Retention Conflict Isn't Your Hardest Problem

DPDP Compliance for BFSI: The Retention Conflict Isn't Your Hardest Problem

By Yatin Chaudhary, SEO Specialist at ProtectComply · Reviewed by Jupinder Singh Bedi · Last updated 6 August 2026 · 14 min read

Quick answer

Every BFSI compliance guide leads with the same problem: RBI's KYC retention mandate conflicts with the DPDP Act's erasure right. It's real, it's well documented, and it's largely solved — the statutory obligation overrides, you isolate held data, you keep processing.

The problems that will actually catch you are the ones nobody has worked through:

1. A single breach starts three clocks, with different deadlines and different content requirements — CERT-In, RBI and the Data Protection Board.
2. Nobody knows who the Data Fiduciary is in a co-lending chain. One loan passes through a lender, an LSP, a co-lending partner and a collections agency. The Act assigns liability. Your contracts probably don't.
3. Declining an erasure request creates a written artefact you have to produce, per request, citing the specific statutory basis. Most firms have no template and no record of having issued one.

Below: the retention conflict in brief, then those three in depth.

The retention conflict, briefly

The mechanism, so we can move on.

RBI's Master Direction on KYC requires Regulated Entities to retain KYC records for a minimum of five years after the business relationship ends. PMLA imposes independent transaction record-keeping obligations enforced by FIU-IND. The DPDP Act requires erasure when consent is withdrawn or the purpose is served.

The resolution: processing necessary to comply with a legal obligation does not stop because consent was withdrawn. You can lawfully decline erasure to the extent a statutory retention mandate applies.

The operational pattern: isolate statutory-hold data from consent-governed data. Mark the record consent-withdrawn, block all processing outside the statutory purpose, and let the retention clock run. When it lapses, erase.

The trap: the override covers only what the statute requires. Data with no ongoing legal basis — app-permission-derived data like contacts, location and SMS from a lending app, marketing preferences, behavioural analytics — must be erased even while the KYC record is held. Firms that treat the whole customer file as statutorily protected are wrong, and it's the kind of wrong that shows up in an inquiry.

Now the harder problems.

Problem 1: A breach starts three clocks

One incident. Three regulators. Three deadlines, three formats, three escalation paths.

CERT-In — cyber incidents must be reported within six hours of noticing them, under the 2022 directions.

RBI — its cybersecurity framework requires incident reporting on a tighter window still, typically within two to six hours depending on the applicable direction and entity class.

Data Protection Board — intimation without delay on becoming aware, followed by detailed particulars within 72 hours: the broad facts and reasons, mitigation implemented, findings on who caused it, remedial measures, and a report on intimations given to affected Data Principals.

And separately, every affected Data Principal must be notified without delay, in plain language, with the nature and extent of the breach, likely consequences, mitigation taken, safety steps they can take, and a contact point.

Four notification obligations from one event.

Why this breaks real playbooks

Most BFSI incident response plans were built for CERT-In and RBI. They're security playbooks: contain, assess, report to the regulator. They assume the reporting audience is technical and singular.

DPDP adds a customer-facing obligation with no materiality filter. Under GDPR you notify individuals only where risk is high. That exception isn't available here — the dual notification obligation attaches, and your existing risk-assessment step doesn't gate it.

So the playbook has to change shape. Your security team is reporting to CERT-In and RBI within hours, while your privacy and communications teams are simultaneously drafting customer notifications in plain language, potentially across Eighth Schedule languages, for a customer base you have to enumerate accurately — which requires knowing which data principals were in the affected systems.

What to build

• One incident, four notification tracks, owned by named people, running in parallel rather than sequentially
• The binding constraint is the tightest clock. Build to RBI's window and everything else follows
• Pre-drafted customer notification templates, legally reviewed, in the languages you serve
• The ability to enumerate affected data principals fast. This is a data-mapping problem, not an incident-response problem, and you solve it before the incident
• A single evidence trail covering all four notifications, because the DPDP detailed report explicitly requires a report on the intimations you gave

The last point is easy to miss. The Board asks not just what happened, but what you told people and when. If your four tracks produce four disconnected records, assembling that under a 72-hour clock is not something you want to attempt for the first time during a live incident.

Problem 2: Who is the Data Fiduciary in a co-lending chain?

A single digital loan can pass through a regulated lender, a technology Lending Service Provider, a co-lending bank or NBFC, and a collections agency. Each handles borrower data. Most arrangements have no documented allocation of who is the Data Fiduciary and who is the Processor.

That allocation isn't cosmetic. The Data Fiduciary determines purpose and means, carries the compliance obligation, and is accountable for processing carried out by processors on its behalf. Getting it wrong means either accepting liability you didn't price, or assuming someone else holds it when they don't.

The questions your contracts should answer and probably don't:

• Who determines the purpose of processing at each stage? That's the Fiduciary test, not who holds the data.
• When a borrower withdraws consent at the originating lender, how does that propagate to the LSP, the co-lender and the collections agency? Within what timeframe? With what confirmation?
• When a borrower exercises an access right, who assembles the response across four organisations?
• Where a breach occurs at the LSP, who notifies the Board — and who notifies the borrower?
• When the relationship ends, who erases, on whose instruction, and who evidences it?

Are LSPs processors or fiduciaries? It depends on whether they determine purpose and means, and many arrangements are genuinely ambiguous — an LSP running its own credit model on borrower data is doing something different from one passing data through.

What to do: map every party in every lending arrangement, assign the role explicitly in the contract, and specify the propagation obligations with timeframes. Then record the allocation in your processing register, per activity. A RoPA that names the processor and links the contract reference is what turns this from a legal question into an operational control.

Credit bureau reporting sits at a similar intersection. Reporting to CIBIL, Experian, Equifax or CRIF is governed by the Credit Information Companies (Regulation) Act, 2005. DPDP adds consent and purpose-limitation obligations around that same flow which CICRA doesn't independently address — so bundled consent forms covering bureau reporting alongside other purposes are exposure, not efficiency.

Problem 3: The refusal artefact

This one is quiet and it will catch people.

When a customer requests erasure after account closure, you can lawfully decline to the extent RBI or PMLA retention applies. But declining isn't silent — you must explain the specific statutory basis in writing, and erase everything falling outside that scope.

So each refusal produces:

• A written response citing the specific statutory provision and its retention period, not "regulatory requirements"
• A record of what you did erase, because the refusal is partial
• A date when the statutory hold lapses and erasure becomes due
• Evidence of all three

At volume — a mid-sized NBFC fielding erasure requests from a lakh-plus closed accounts — this is a workflow, not a legal exercise. Handled by hand in email, it produces neither consistency nor evidence.

What to build: a templated refusal citing the applicable provision per data category, automatic partial erasure of everything outside statutory hold, a diarised erasure date per record, and an audit trail linking all of it to the original request.

Firms that have thought about the retention conflict conceptually but not built this workflow will discover the gap the first time the Board asks how many erasure requests they've declined and on what basis.

Problem 4: Legacy core banking wasn't built for this

Finacle, Flexcube, BaNCS and their peers were designed before purpose limitation existed as a requirement. They typically store data in monolithic structures without purpose-based segmentation, which makes granular consent enforcement at the data layer close to impossible.

The pattern that works: a consent management layer sitting between customer-facing applications and core banking. Consent state is captured, stored and enforced in the layer; the core system continues doing what it does. Enforcement happens at the point of access rather than at the point of storage.

This is why "just configure the core banking system" isn't an answer, and why BFSI consent projects are integration projects rather than software purchases.

Are you a Significant Data Fiduciary?

Probably, if you're at any scale.

The designation factors under Section 10 include volume and sensitivity of personal data, risk to Data Principals, and impacts on sovereignty, electoral democracy, security of the State and public order. A mid-sized NBFC with five lakh customers processing loan applications, repayment data and credit bureau information sits squarely in that profile.

No designations have been notified yet. The category exists and is currently empty. But designation happens by government notification without a preparation window, and the obligations that follow are substantial:

• A Data Protection Officer based in India
• An independent data auditor
• Periodic audits
• DPIAs — and note the trigger is entity-based rather than activity-based, so the obligation attaches across your processing rather than to selected high-risk activities. New credit-scoring models, AI-driven underwriting and new data-sharing arrangements each need assessing.

Build the capability before the notification. You will not get a runway.

By sector

Banks — highest system complexity, legacy core, widest customer base. Consent layer plus data mapping is the long pole.

NBFCs and digital lenders — app-permission data is the exposure. Contacts, location and SMS collected during onboarding have no ongoing legal basis after loan closure and must be erased even while KYC is held. Also strictest on the co-lending chain problem.

Insurers — health declarations, medical records and family history. Under GDPR these would be special category data; the DPDP Act has no such taxonomy, so obligations apply uniformly rather than with heightened conditions. That does not make the harm profile uniform, and your security safeguards should reflect the sensitivity even where the statute doesn't distinguish.

Brokers and capital markets — SEBI obligations layer on top, with their own retention and reporting requirements.

The BFSI checklist

1. Map every system holding customer personal data, including systems nobody named at kickoff
2. Build a processing register that reconciles against those systems, not against department interviews
3. Assign Fiduciary and Processor roles across every lending arrangement, in contract
4. Separate statutory-hold data from consent-governed data at the architecture level
5. Rebuild consent with purpose-level granularity — bundled consent for bureau reporting is exposure
6. Build the consent layer between apps and core banking
7. Rewrite the incident playbook for four notification tracks on the tightest clock
8. Template the erasure refusal artefact
9. Stand up DPIA capability ahead of SDF designation
10. Test it — run a mock inquiry and produce the evidence pack

Your timeline

Full compliance is due 13 May 2027, per the DPDP Rules timeline. Penalty provisions become operative 13 November 2026. Penalties reach ₹250 crore for security safeguard failures, assessed per contravention.

For BFSI the binding constraint isn't the deadline — it's the integration work. Consent layers over legacy core banking, contract renegotiation across lending chains, and incident playbook rebuilds each depend on parties you don't control.

Frequently asked questions

Does DPDP replace RBI data protection requirements?

No. They apply separately and cumulatively. RBI covers cybersecurity, operational risk and retention. DPDP covers consent, Data Principal rights and transparency. Where they conflict, the stricter obligation governs, and neither exempts you from the other.

Can a customer force us to delete KYC data?

No, to the extent RBI's Master Direction or PMLA retention applies. But you must explain the specific statutory basis in writing and erase everything outside that scope — particularly app-permission-derived data with no ongoing legal basis after the relationship ends.

How long must BFSI retain KYC records?

RBI's KYC Master Direction requires a minimum of five years after the business relationship ceases, with PMLA imposing independent transaction record-keeping obligations. Confirm the applicable period for your entity class and data category — periods differ.

Will our NBFC be designated a Significant Data Fiduciary?

Possibly. No designations have been notified yet, but volume and sensitivity of financial data make BFSI a likely candidate. Designation comes by notification without a preparation window, so build DPO, audit and DPIA capability in advance.

Who is the Data Fiduciary in a co-lending arrangement?

Whoever determines the purpose and means of processing — which may be more than one party at different stages. Most arrangements have no documented allocation, which is a liability exposure. Assign roles explicitly in contract and record them in your processing register.

What are the breach notification timelines for BFSI?

Four obligations from one incident: CERT-In within six hours, RBI on a tighter window depending on the applicable direction, the Data Protection Board without delay plus detailed particulars within 72 hours, and affected Data Principals without delay. Build to the tightest clock.

Can we use bundled consent for credit bureau reporting?

No. Consent must be purpose-specific. Bundled forms covering bureau reporting alongside other purposes fail the specificity requirement and create penalty exposure.

Where to start

Map before you buy. A gap analysis scoped to BFSI tells you which of the four problems above you're actually exposed on — and for most firms it isn't the one every article leads with.

For the platform question, see our comparison of DPDP platforms in India and the selection guide.

ProtectComply runs discovery → RoPA → DPIA end to end, with each processing activity linked to its consent basis, processor registry and retention rule — which is what makes the statutory-hold separation and the co-lending role allocation operationally tractable rather than a legal memo.

Book a BFSI walkthrough

About this guide

About the authorYatin Chaudhary is an SEO Specialist at ProtectComply, where he writes about India's data protection framework and how organisations operationalise it.

Reviewed by Jupinder Singh Bedi.

Written against the DPDP Act, 2023, the DPDP Rules, 2025, and published analysis of RBI, PMLA and CERT-In obligations as of August 2026.

Corrections: write to [corrections email] and we will review and update.

General information, not legal advice. Regulatory obligations vary by entity class and licence. Consult qualified counsel before finalising your compliance position.