RBI-DPDP Retention Conflict: KYC Erasure Rules for Indian Fintechs

Two Regulators, One Dataset

Indian fintechs and NBFCs operate under a compliance architecture that most generic DPDP tools were never designed to address. The Reserve Bank of India and the Prevention of Money Laundering Act mandate that KYC records, loan files, and transaction data be retained for between five and ten years after the conclusion of a business relationship. The Digital Personal Data Protection Act 2023 mandates that personal data be erased once the purpose for which it was collected is fulfilled, or when a data principal exercises their erasure right under Section 12.

These obligations apply to the same data. They are enforced by different authorities. They point in opposite directions.

This is not a gap that will be addressed through regulatory clarification. The DPDP Act and the RBI/PMLA framework are both active law. A fintech that complies with one while ignoring the other has incomplete compliance. The Data Protection Board and the RBI are both capable of issuing notices, conducting audits, and imposing penalties.

The question is not which obligation to prioritise. The question is how to satisfy both simultaneously, with a documented framework that holds up under scrutiny from either regulator.

What Each Regulator Actually Requires

Before building a resolution framework, the precise obligations on each side must be understood.

RBI and PMLA Retention Mandates

The Prevention of Money Laundering (Maintenance of Records) Rules, 2005 require regulated entities to maintain records of all transactions, and all documents obtained under the know-your-customer procedures, for a period of five years from the date of the cessation of the business relationship. For certain categories of suspicious transactions, the retention period extends beyond five years.

The RBI’s Master Direction on KYC (updated periodically) instructs regulated entities to maintain records in a form that can be retrieved and used as evidence. For lending businesses, loan agreements, credit bureau queries, income verification documents, and repayment records are governed by a combination of these directives and the Limitation Act 1963, which can push the practical retention requirement toward ten years for contested accounts.

The practical result: KYC documents, loan records, account opening data, and related PII must be retained for a minimum of five years post-relationship, and up to ten years depending on the specific record type and whether litigation risk applies.

DPDP Act Erasure Obligations

Section 9(3) of the Digital Personal Data Protection Act 2023 states that a data fiduciary shall cease to retain personal data or means by which personal data can be associated with a data principal as soon as it is reasonable to assume that the specified purpose is no longer being served by its retention, or upon withdrawal of consent by the data principal.

Section 12 grants data principals the explicit right to erasure: they may request the deletion of their personal data when it is no longer necessary for the purpose for which it was collected.

Under the DPDP Rules (notified November 2025), Rule 8 adds a procedural requirement: data fiduciaries must provide data principals with notice before any erasure of their data, and that notice must be given at least 48 hours in advance. This creates a second obligation: informing the individual before their data is deleted, not just when they request deletion.

Where the Conflict Sits

A customer who closed their NBFC loan account six months ago has, in the ordinary course, fulfilled the stated purpose: the loan is repaid, the relationship is concluded. Under DPDP Section 9 and 12, their personal data should be erased on request.

Under PMLA, the KYC record, loan agreement, and transaction history must be retained for five years from that date. The data fiduciary is legally prohibited from erasing those records, regardless of what the data principal requests.

A compliance tool that automatically processes erasure requests without flagging this category of data is not making the fintech compliant. It is creating a PMLA violation.

Why Generic DPDP Tools Fail Here

Most DPDP compliance tools were built against a simplified model of the Act: collect with consent, store while purpose exists, erase when purpose ends or consent withdraws. This model works for consumer SaaS companies, e-commerce platforms, and direct-to-consumer businesses that do not operate under sectoral financial regulation.

It does not work for NBFCs, fintech lenders, registered brokers, or insurance companies.

Generic tools have no mechanism for categorising personal data by its legal retention basis. They treat all personal data as consent-governed data, which creates two failure modes.

The first failure mode is over-erasure: the system deletes data that must be retained under statute, creating a PMLA or RBI compliance gap the organisation discovers only during an audit.

The second failure mode is over-retention: to avoid the first failure mode, the compliance team disables erasure automation entirely and retains all data indefinitely, which creates a DPDP Section 9 violation.

Neither outcome is acceptable. A fintech that cannot process erasure requests for consent-based data is not compliant with the DPDP Act. A fintech that processes erasure requests for statutory-retain data is not compliant with PMLA. The resolution requires the tool to distinguish between the two categories, not treat them identically.

The Legal Obligation Override Framework

The resolution to the RBI/DPDP retention conflict is a documented classification framework that the industry has begun referring to as the Legal Obligation Override. The mechanism works as follows.

Step 1: Classify Personal Data by Retention Basis

Personal data held by a fintech falls into one of three categories:

Category	Examples	Governing Basis	Erasure Treatment
Consent-based data	Marketing preferences, optional profile fields, behavioural analytics	DPDP Act consent	Erasure on request, no override
Legitimate use data	Fraud signals, credit scoring inputs during active relationship	DPDP Act legitimate use	Erasure when legitimate use ends
Statutory-retain data	KYC documents, loan agreements, AML transaction records, CIBIL query logs	RBI/PMLA/KYC regulations	Erasure blocked; Legal Obligation Override applied

This classification must be performed at the data category level, not the individual record level. The classification drives system behaviour automatically.

Step 2: Implement Separate Retention Tracks

Statutory-retain data must be held in a separate retention track, isolated from consent-governed data. This separation serves two purposes.

First, it ensures that erasure workflows applied to consent-based data cannot inadvertently process statutory-retain records. The two tracks should be technically distinct, not just logically labelled.

Second, it creates the audit trail the DPBI requires. When a data principal submits an erasure request, the system can provide a complete, accurate response: consent-based data has been erased; statutory-retain data is held under a Legal Obligation Override citing the specific regulatory mandate (e.g., “PMLA Rule 3, 5-year retention from account closure date: [date]”).

Step 3: The Denial Register

When a fintech declines an erasure request because of a legal retention obligation, that denial must be documented. The documentation is the denial register.

The denial register records:

• The data principal’s identity reference (not the full PII record)
• The date the erasure request was received
• The specific statutory basis for the denial (rule citation, applicable regulation)
• The earliest date on which the statutory retention obligation expires
• The name of the compliance officer who reviewed the denial

The denial register is not optional. The DPDP Act requires data fiduciaries to be able to demonstrate the legal basis for retaining personal data beyond the point at which the data principal has requested erasure. A denial register is the primary evidence artefact for this demonstration during a DPBI audit or inspection.

Step 4: Erasure Scheduling for Statutory-Retain Data

The Legal Obligation Override is not a permanent exemption. Statutory-retain data has a defined retention end date: five years from account closure for KYC under PMLA, up to ten years for contested records under the Limitation Act, as determined by record category.

The compliance system must schedule erasure for statutory-retain data at the point the obligation expires. This scheduled erasure triggers the Rule 8 notice obligation: the data principal must receive 48-hour advance notice before their data is deleted.

This creates a compliance obligation in the opposite direction from the override. Once the legal retention period ends, the data must be erased. Retaining it beyond that point creates a DPDP Act violation without any statutory defence.

Rule 6 Log Maintenance: A Related Active Obligation

Rule 6 of the DPDP Rules (notified November 2025 and active immediately upon notification) requires all data fiduciaries to maintain processing logs for a period of one year. These logs must record consent collection events, consent withdrawal events, data principal rights requests and their outcomes, and breach notification events.

This is not a future obligation. It is active now. Fintechs that do not have a functioning processing log that captures consent events and rights requests are already in breach of Rule 6.

The processing log and the denial register are related but distinct artefacts. The processing log records what happened to personal data across the lifecycle of the relationship. The denial register records specific instances where erasure was declined and the legal basis for that decision. Both must exist. Neither substitutes for the other.

Practical Steps for NBFCs and Fintech Lenders

The following is a practical sequence for implementing the Legal Obligation Override framework.

Audit your data inventory. Map every category of personal data you hold to its retention basis. KYC documents, loan files, AML records, and credit bureau query logs should be identified as statutory-retain. Marketing data, behavioural analytics, and optional profile fields are consent-based. This distinction must be explicit, not assumed.

Implement separate retention tracks at the system level. The classification must drive system behaviour, not just inform a policy document. Statutory-retain data must be in a separate track that erasure workflows cannot process.

Build the denial register. It can be as simple as a structured log with the fields described above. The requirement is that it is retrievable and attributable. It must be available for DPBI inspection on request.

Schedule statutory-retain erasure. Every record in the statutory-retain track must have a calculated erasure date. The calculation should be: relationship end date plus applicable retention period (five years for KYC under PMLA, adjusted for record-specific rules). Set automated expiry triggers.

Wire the Rule 8 notice workflow. When a record’s statutory retention period expires, the erasure does not happen silently. The data principal must receive 48-hour advance notice. This is the same notice required for all other erasures under the DPDP Act. Automate this notification for scheduled statutory-retain deletions.

Document the legal basis in your privacy notice. The data principal’s privacy notice must disclose that certain categories of personal data are retained under statutory obligation beyond the general retention period. The specific regulations (PMLA, RBI KYC Master Direction) should be named.

What DPBI Preliminary Notices Mean for Fintechs

The Data Protection Board of India began sending preliminary notices to mid-size and large data fiduciaries in late 2025. These notices are not enforcement actions. They are preliminary inquiries requesting information about data processing practices, retention policies, and rights request handling.

A fintech that receives a preliminary notice and cannot produce a classification framework, a denial register, and evidence of a functioning rights request process is in a weak position. A fintech that can produce all three has a defensible position regardless of the volume of personal data it holds or the complexity of its regulatory environment.

The preliminary notice window is an opportunity to demonstrate compliance infrastructure, not a signal that enforcement is imminent. The organisations that use this window to build the infrastructure will be in a materially better position when enforcement does begin.

The May 2027 enforcement deadline for the DPDP Act creates a fixed horizon. The RBI and PMLA obligations are already active. The Legal Obligation Override framework is not a theoretical construct for a future compliance programme. It is the operational requirement for every regulated fintech operating in India today.