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 require identity records to be kept for at least five years after a business relationship ends, and transaction records for at least five years from the date of each transaction. The Digital Personal Data Protection Act 2023 requires personal data to be erased once the specified purpose is served or consent is withdrawn (Section 8(7)), or when a data principal requests erasure (Section 12(3)). Both sections exempt retention that another law requires.

These obligations apply to the same data. They are enforced by different authorities. The RBI and PMLA mandates bind today. The DPDP erasure duty binds from 13 May 2027. The carve-out protects only the records a law names, so every other field on the same customer stays subject to erasure.

This is not a gap that will be addressed through regulatory clarification. The RBI and PMLA framework is active law, and the DPDP Act’s text is final with a fixed commencement date. A fintech that builds for 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. The same conflict applies to deposit-taking banks; for the banking-sector view, see DPDP compliance for banks.

What Each Regulator Actually Requires

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

RBI and PMLA Retention Mandates

Section 12 of the Prevention of Money-laundering Act, 2002 requires every reporting entity to keep transaction records for five years from the date of the transaction (Section 12(3)), and identity documents, account files, and business correspondence for five years after the business relationship ends or the account closes, whichever is later (Section 12(4)).

The RBI’s Know Your Customer Directions, 2025, Chapter VII (Record Management), set the same floor for each class of regulated entity: identification records for at least five years after the business relationship ends, transaction records for at least five years from the date of each transaction, held so that competent authorities can retrieve them on request. Ten-year figures in circulation are not the statutory floor for standard KYC. A longer hold applies only where a specific instrument or an active dispute requires it, and that hold needs its own documented basis. Retention is one half of the RBI overlay. The consent side is set out in the RBI consent rules for BFSI, and both halves bind the same records.

The practical result: KYC documents, account opening data, and transaction records must be retained for at least five years, with the clock set by record type. Any period beyond five years must cite the instrument or the dispute that requires it. The KYC retention matrix sets out the periods and clock-start events by regulator.

DPDP Act Erasure Obligations

Section 8(7) of the Digital Personal Data Protection Act 2023 requires a data fiduciary, unless retention is necessary for compliance with any law for the time being in force, to erase personal data when the data principal withdraws consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier. It must also cause its data processors to erase that data.

Section 12(3) grants data principals the right to request erasure. On receiving the request, the data fiduciary must erase the data unless retention is necessary for the specified purpose or for compliance with any law for the time being in force. Erasure sits within the broader set of data principal rights under the DPDP Act. It is the one that collides with sectoral retention law.

Under the DPDP Rules (notified November 2025), Rule 8 adds a procedural requirement for the classes listed in the Third Schedule: e-commerce entities with 2 crore or more registered users, online gaming intermediaries, and social media intermediaries. For those classes, the data principal must receive at least 48 hours notice before their data is erased. Most NBFCs and fintech lenders sit outside the Third Schedule, so the 48-hour notice is not a statutory obligation for them. It is the procedural standard the Rules have set, and the defensible practice to adopt.

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 Sections 8(7) and 12(3), data held for that purpose alone must be erased, at the end of purpose or on request.

Under PMLA Section 12(4) and the RBI KYC Directions, the identity records and account files must be retained for five years from that date, and each transaction record for five years from its own date. The carve-out in both DPDP sections applies to those records. The data fiduciary cannot erase them while the window runs, 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.

The Data Categories the Conflict Hits

The conflict does not touch every field a regulated lender holds. It binds a specific set of categories, and the resolution depends on naming them precisely.

Caught by statutory retention:

• KYC identity records: PAN, officially valid documents, address proof, photographs, video KYC recordings
• Transaction records and AML monitoring outputs, including suspicious transaction workpapers
• Loan agreements, sanction letters, repayment schedules, and default histories
• Credit bureau query logs and the responses received
• Account opening forms and signature records

Outside every mandate, and fully erasable:

• Marketing preferences and campaign interaction history
• Behavioural analytics and product telemetry
• Optional profile fields collected for convenience
• Support transcripts past their service purpose

The second list is where regulated lenders most often fail the DPDP side of the conflict. Because the first list cannot be erased, teams stop erasing altogether. Every field in the second list then becomes a Section 8(7) violation with no statutory defence. Mapping each category to its retention basis is the first exercise of a personal data inventory built for DPDP compliance, and it is the boundary on which the entire framework rests.

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 8(7) 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-retained data is not compliant with PMLA. The resolution requires the tool to distinguish between the two categories, not treat them identically.

The general evaluation criteria for this tooling category are covered in how to choose DPDP compliance software. For a regulated lender the shortlist question is narrower: does the platform classify records by retention basis and produce a denial register. The Compliance Vault tier exists as that capability.

The Legal Obligation Override Framework

The resolution to the RBI/DPDP retention conflict is a documented classification framework. ConsentOS calls it the Legal Obligation Override. The legal basis underneath it is the required-by-law carve-out in Sections 8(7) and 12(3). 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-retained 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-retained data must be held on a separate retention track 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 and an RBI inspector will ask for. When a data principal submits an erasure request, the system can provide a complete, accurate response: consent-based data has been erased; statutory-retained data is held under a Legal Obligation Override citing the specific regulatory mandate (e.g., “PMLA Section 12(4), five years after the relationship ends or the account closes, whichever is later: [date]”).

Step 3: The Denial Register

When a fintech declines an erasure request because of a legal retention obligation, that denial should 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

Sections 8(7) and 12(3) do not prescribe a refusal record. The carve-out applies only where retention is in fact necessary for compliance with a law, and the denial register is how a fiduciary shows that it was. It is the primary evidence artefact in a DPBI proceeding or an RBI inspection.

Step 4: Erasure Scheduling for Statutory-Retained Data

The Legal Obligation Override is not a permanent exemption. Statutory-retained data has a defined retention end date, set by record category: five years after the relationship ends or the account closes for identity records, and five years from each transaction for transaction records. A longer hold applies only where a named instrument or an active dispute requires it.

The compliance system must schedule erasure for statutory-retained data at the point the obligation expires. This scheduled erasure is where the Rule 8 notice standard applies: a Third Schedule entity must give 48-hour advance notice before deletion, and entities outside the Third Schedule should give the same notice as documented practice.

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 Obligation on the Same Clock

Rule 6 of the DPDP Rules 2025 sets the security safeguards a data fiduciary must maintain. Rule 6(1)(e) requires it to retain logs and personal data for one year, unless another law requires otherwise, so that unauthorised access can be detected, investigated, and remediated. These are security logs. Rule 6 does not prescribe a log of consent events or rights requests. That record is the fiduciary’s own evidence that it honoured withdrawals and answered requests, and it sits beside the denial register.

Rule 6 was notified on 13 November 2025 and becomes enforceable on 13 May 2027, alongside Rules 3 and 5 to 16. The preparation window is now. A fintech that reaches May 2027 without security logging in place and a record of consent events and rights requests has nothing to produce when the Board asks. The one-year retention duty itself applies from 13 May 2027. Logging that starts earlier is operational preparation.

The consent and rights record and the denial register are related but distinct artefacts. The first records consent events and rights requests 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.

The Evidence File the Regulators Expect

Both regulators judge the framework by its artefacts, not its intentions. The evidence file that satisfies an RBI inspection and a future DPBI proceeding contains five items:

1. The classification schedule: every data category mapped to its retention basis, with the specific mandate cited per category
2. The denial register, with compliance officer attribution on every refused erasure request
3. Rule 6(1)(e) security logs, retained for one year once the Rule applies, and a record of consent events and rights requests
4. A privacy notice that discloses statutory retention and names the governing regulations
5. Scheduled-erasure records proving that statutory-retained data is deleted once its mandate expires

A DPBI complaint begins with a data principal grievance, and an erasure refusal without a documented legal basis is exactly the grievance that escalates. The five artefacts above are what turns a refusal from a complaint into a closed file.

Practical Steps for NBFCs and Fintech Lenders

The following is a practical sequence for implementing the Legal Obligation Override framework. Before assigning owners, establish which of these artefacts already exist in your organisation. The free DPDP Gap Assessment scores your current position against the DPDP Act’s obligation areas and returns the gaps in a written report.

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-retained 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 pre-erasure notice workflow. When a record’s statutory retention period expires, the erasure does not happen silently. Rule 8 requires 48-hour advance notice from Third Schedule entities, and the same notice is the defensible standard for everyone else. 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, and the RBI Know Your Customer Directions, 2025 for your entity class) should be named.

What an Inspector Asks Before the Board Is Seated

As of November 2026 we have not located any Gazette notification establishing the Data Protection Board of India or appointing its Chairperson or Members. On 7 October 2026 the Central Government told the Kerala High Court that the Board is constituted but not yet functional (2026:KER:77409). The substantive obligations and the penalty provisions commence on 13 May 2027.

None of that reaches a fintech’s actual exposure today, because the first party to ask for this evidence is not the Board. It is the RBI inspector. The inspection asks which records are held under statutory mandate, which are held on consent, who authorised each erasure refusal, and on what date. The answer is a document or it is nothing.

A fintech that cannot produce a classification framework, a denial register, and evidence of a functioning rights request process is in a weak position in that inspection, and in a worse one once the Board is constituted. 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 period before the Board is seated is not a pause. It is the window in which this infrastructure can be built outside a proceeding.

The May 2027 enforcement deadline for the DPDP Act creates a fixed horizon, and the DPDP penalty framework attaches a price to every obligation the framework covers. The Legal Obligation Override framework is the operational requirement for every regulated fintech operating in India today, because the RBI and PMLA obligations it reconciles are already in force.