RBI vs DPDP: Erasure When KYC Retention Still Applies

In general, no. Where RBI’s KYC Master Direction and PMLA rules require you to maintain customer identification and transaction records for defined periods, those obligations anchor the law-compliance exception in the DPDP Act. That means you should not delete KYC documents or core transaction histories before the minimum retention period expires simply because an individual has requested erasure. The main exceptions are where the statutory period has already lapsed and no other legal, regulatory, or litigation hold applies, or where the data was collected or stored in excess of what any law requires—for example, duplicate copies scattered across test environments or ad-hoc spreadsheets. A well-designed policy distinguishes clearly between mandated records, which are non-negotiable, and surplus copies, which should be minimised.

Marketing, cross-sell, and profiling data linked to KYC or transaction records usually relies on consent or business necessity rather than explicit statutory mandates. When an individual withdraws consent or requests erasure, the default move is to stop further marketing and profiling, delete or anonymise marketing-specific attributes in CRM and analytics platforms, and ensure those changes propagate to downstream tools such as email, SMS, and in-app engagement systems. Where you need to retain limited information to honour suppression—for example, a hashed identifier to avoid re-adding a customer to marketing lists—you should document this as a narrow, clearly justified exception. The key is to decouple marketing and profiling from the statutory KYC and transaction core so that legal retention requirements do not become a pretext for holding on to optional uses of the data.

Regulators are likely to focus less on the outcome in a single edge case and more on whether your decision was made under a structured, well-documented process. For each erasure request that is refused or only partially granted, you should be able to show: the original request and how the requester’s identity was verified; the datasets identified as in scope; the lawful basis and applicable retention rules for each dataset; the specific grounds on which you concluded that certain data had to be retained; any approvals or legal opinions that informed the decision; what was actually erased or anonymised; and the explanation provided to the individual. Capturing this in a central decision log, rather than in scattered email threads, makes it much easier to demonstrate accountability to the Data Protection Board, RBI, or internal audit.

Clarity early in the relationship is more effective than defensive explanations at offboarding. Privacy notices, account-opening forms, and digital consent flows should state in plain language that certain records—such as KYC documents and transaction histories—must be retained for specific periods to comply with RBI, PMLA, tax, and other laws, and will only be used for those regulatory and dispute-resolution purposes once the relationship ends. At the same time, they should make clear that marketing and optional analytics uses are subject to consent and can be withdrawn. When responding to a concrete erasure request, explain which categories of data you have deleted or minimised and which you are required to keep, referencing the underlying legal obligations rather than generic ‘policy’. Customers are more likely to accept limits when they can see that you are applying a consistent, law-based rule rather than improvising.

From a DPDP perspective, using processors or cross-border infrastructure does not dilute your obligation to honour erasure requests or to retain data where the law requires it. Contracts with processors and cloud vendors should require them to support your retention schedules and erasure workflows, including the ability to delete, archive, or restrict data on your instructions and to provide evidence of those actions. Where data is transferred outside India, you also need to account for any government notifications that restrict transfers to particular jurisdictions, but the basic logic remains the same: for data that can be erased, your processors must execute deletions end-to-end; for data that must be retained under RBI, PMLA, or other laws, they must preserve it securely for the required period and not repurpose it beyond your documented instructions.