KYC Record Retention vs DPDP Erasure: The Five-Year Rule

Suppose a former account holder who closed the relationship three years ago asks the institution to erase their personal data. The operational answer is not “delete everything” or “retain everything.” The institution should identify the exact PMLA, RBI and other legal retention duties, preserve only the records and periods those duties require, restrict further use, and erase or anonymise residual data that has no continuing legal or operational justification.

Current status, verified 29 August 2026: the DPDP erasure right and related Rules are notified but scheduled to commence around May 2027. Existing KYC and anti-money-laundering recordkeeping duties continue now. Teams should prepare a request workflow that separates customer-identification/account-file retention from transaction-record retention, documents the legal source and expiry date for each dataset, and avoids promising a universal deletion deadline.

In the absence of a clear, organisation-wide design for reconciling these obligations, three things happen quickly: legal and compliance disagree on how much to erase, technology teams hesitate to touch core banking or KYC repositories, and customer-facing staff give inconsistent answers. Over-erasure risks breaching statutory record-keeping duties; under-erasure risks a DPDP complaint and creates an impression that you are ignoring the new privacy regime. That combination makes DPDP erasure in a high-retention sector a board-level topic rather than a narrow legal question.

When the relevant DPDP provision commences around May 2027, a Data Principal may seek erasure in the prescribed manner. The Data Fiduciary must erase personal data unless retention is necessary for the specified purpose or for compliance with law, and must cause its processor to erase where applicable. In BFSI, the exception must be applied record by record; it is not a licence to keep marketing, profiling or unrelated analytics data indefinitely.[2]

DPDP operates alongside sectoral recordkeeping laws and prevails only to the extent of an actual inconsistency. Its own erasure rule preserves data that must be retained for compliance with law. A bank, NBFC or other regulated entity should therefore record the governing provision, record category, start date and disposal date instead of relying on a generic “regulatory retention” label.[1]

RBI’s KYC Master Direction, built on the Prevention of Money Laundering Act framework, is explicit on retention. Regulated entities must maintain records of customer identification and address, account files, and business correspondence for at least five years after the business relationship has ended, and must preserve transaction records for at least five years from the date of each transaction. Additional retention obligations may arise from suspicious transaction reporting, internal investigations, and directions from enforcement agencies, all of which assume that certain records remain intact and accessible.^[3]

Beyond RBI and PMLA, many financial groups are simultaneously subject to SEBI, IRDAI, income-tax, and Companies Act record-keeping rules. Together, these regimes mean that for KYC documentation and core transaction histories, erasure in the DPDP sense usually does not mean literal deletion on request. Instead, DPDP’s real impact is to narrow the purposes for which retained data can be used and to bring surrounding datasets—marketing, profiling, analytics, and logs—firmly within the scope of erasure and minimisation.^[6]

To turn this legal position into operational clarity, it helps to classify your major datasets into three outcomes when faced with an erasure request: data that must be retained because of explicit legal obligations, data that should be minimised or moved to controlled archives, and data that should ordinarily be erased or irreversibly anonymised. The matrix will not look identical for every institution, but the broad buckets are similar across banks, NBFCs, and fintech lenders.

KYC identity proofs, account master data, and detailed transaction histories usually sit in the ‘must retain’ column. RBI and PMLA require these records for defined periods, and they underpin your ability to respond to tax enquiries, fraud investigations, and customer disputes. Here, the DPDP-aligned response to an erasure request is not deletion but purpose limitation and hardening. That typically means taking these datasets out of day-to-day analytics and marketing use, confining access to compliance and audit teams, and, where possible, migrating them from operational systems into encrypted regulatory archives with strict role-based controls.

Credit and fraud-risk models, bureau pulls, collection scores, and derived risk indicators often fall into a ‘minimise or archive’ category. Some elements may need to be retained to evidence underwriting decisions or collection actions, but many features can be aggregated, pseudonymised, or detached from direct identifiers once the active relationship ends. For exited customers who invoke erasure, it is usually possible to keep only the minimum data required to reconstruct key decisions, while aggregating the rest into non-personal datasets used for portfolio analytics and model tuning.

CRM records, marketing lists, cross-sell and upsell segments, behavioural analytics from mobile apps and websites, and many categories of system log data tend to rely primarily on consent or business necessity rather than on explicit legal mandates. For these, the default position under DPDP should be erasure or strong anonymisation when the individual withdraws consent or requests deletion. That includes stopping outbound campaigns, deleting or obfuscating personal identifiers in analytics warehouses, and tuning log-retention policies so that full-fidelity, identifiable logs are kept only as long as needed for security and audit. In a strategic trade-off view, the regulatory risk of under-deletion is highest in these edge datasets, while the risk of over-deletion is highest in the statutory KYC and transaction core.

Once you know what belongs in the retain, minimise, and erase buckets, the challenge is to execute those decisions consistently across a heterogeneous stack: core banking platforms, card processors, LOS and LMS systems, CRM and marketing tools, data warehouses, and archival stores. The main risk is not that the rules are unclear on paper, but that every system team interprets them differently, leading to fragmented responses and weak auditability.

The starting point is a live data map that links customer journeys to systems and datasets. For each major data class—KYC documents, account and transaction records, risk and fraud data, CRM and marketing, analytics, and logs—your architecture team should know which applications hold it, what the primary processing purpose is, which lawful basis applies, which regulators drive retention, and what the configured retention period is. Tagging data with this metadata enables you to route it into distinct storage zones: hot operational stores for active relationships, warm stores for recent exits where some processing continues, and cold regulatory archives where data is kept only for statutory and dispute-resolution purposes.^[4]

On top of that map, you need a rights and retention workflow. When a DPDP erasure request arrives, the process should authenticate the individual, identify all linked systems, and apply rules per data category. For some datasets, the workflow will instruct deletion or anonymisation; for others, it will shift records into restricted archives and mark them as blocked from marketing or profiling use. Every step—what was requested, which datasets were affected, which legal bases justified continued retention, who approved any overrides, and what was communicated back to the individual—should be recorded in a decision log that can be produced to the Data Protection Board or RBI supervisors if questioned. Governance makes this architecture stick: typically, the Data Protection Officer, chief compliance officer, and heads of IT and operations should jointly own the remediation playbook, including SLAs for responding to erasure requests, criteria for imposing litigation or investigation holds that pause deletion, and escalation paths for ambiguous cases. For multi-entity groups spanning banking, NBFC, brokerage, and insurance units, a group-level policy needs to distinguish which obligations attach to which entity, even if data is held in shared warehouses.

Even with a clear framework, the first few erasure requests will surface weak spots in legacy systems and routines. Treating those cases as structured tests rather than one-off firefights makes it easier to harden your model before volumes increase.

In many large institutions, attempting to hard-code DPDP rights and KYC retention logic separately into every application quickly becomes unmanageable. An alternative pattern is to introduce a dedicated consent and rights layer that sits between customer channels and back-end systems. This layer maintains a single view of notices, consents, lawful bases, and retention rules, receives erasure and other rights requests, determines where legal or regulatory exceptions apply, and then orchestrates downstream deletion, archival, or restriction actions while capturing an audit trail.

Digital Anumati - Service is an example of such a DPDP-focused consent and rights orchestration platform. When evaluating whether to build internally or adopt a specialised platform, senior teams should look for the ability to model Indian lawful bases, encode RBI, PMLA, and other regulator-driven retention rules, handle partial fulfilment where KYC records must be retained, integrate with core banking, lending, CRM, and data-warehouse systems at scale, and produce clear evidence for regulators on how each request was handled. If you are exploring this architecture, it is worth comparing dedicated offerings such as Digital Anumati - Service with in-house builds to understand design options, integration effort, and the level of auditability each approach provides, and you can learn more on the Digital Anumati - Service site.^[7]

At an executive level, a practical way to test readiness is to ask a series of pointed questions.

If the honest answer to several of these questions is ‘not yet’, the cost of inaction is real. On one side lies the risk of DPDP complaints, investigations, and penalties for failing to honour erasure where no legal exception applied, or for being unable to show how decisions were made. On the other side lies the risk of over-deletion: destroying KYC or transaction records before minimum retention periods expire, weakening your position in fraud cases or tax audits, and inviting scrutiny from RBI, FIU-IND, and other agencies. Operationally, handling each request as a bespoke exercise consumes scarce senior time, increases the chance of inconsistent treatment across entities and geographies, and often forces emergency IT work on legacy systems.

There is also an opportunity-cost dimension. Institutions that put a coherent erasure-and-retention architecture in place gain a clearer view of their data estate, reduce noisy debates between privacy and business teams, and are better placed to design new analytics and personalisation use cases that respect DPDP constraints from day one. Those that delay are more likely to face hurried, tactical fixes driven by individual complaints or regulatory findings, which tend to be more expensive and harder to unwind.^[5]

Even with a clear framework, senior teams encounter recurring questions once they start operationalising DPDP erasure alongside KYC and PMLA retention. Most of these are not about the obvious core—nobody suggests deleting active-account KYC documents—but about the surrounding grey zones: marketing data tied to account numbers, shared services across group entities, cloud vendors, and how much detail to share with customers about what will and will not be erased.

The following questions capture issues that frequently arise in board and executive discussions. Addressing them in your own context, with input from compliance and legal, will help anchor your operating model and reduce friction when the first high-profile erasure request lands.