When You Can't Delete: DPDP Erasure Requests vs RBI and SEBI's 5-Year Retention Mandates
Fintechs, brokers, and NBFCs face a structural conflict: the DPDP Act gives users an erasure right, while RBI and SEBI mandates require retaining KYC records, transaction data, and audit trails for five years or more. Here is how to honour both — split responses, quarantined retention, and a defensible retention matrix.
The Collision: An Erasure Right Meets a Wall of Mandatory Retention
Section 12 of the DPDP Act gives every Data Principal the right to erasure of their personal data, and the Act's storage limitation principle independently requires fiduciaries to erase data once consent is withdrawn or the specified purpose is served. But both obligations carry the same carve-out: erasure yields where retention is necessary for compliance with any law for the time being in force. For most industries that carve-out is a footnote covering tax records and a few statutory registers. For regulated financial entities, it swallows a large share of the customer data estate.
Banks, NBFCs, payment aggregators, brokers, depository participants, and fintech intermediaries operate under retention mandates from the RBI, SEBI, and the Prevention of Money Laundering Act that require identity records, transaction data, and audit trails to be kept for five years or longer — frequently running from the end of the customer relationship, not from collection. A customer who closes their account and immediately demands erasure is asking for precisely the records the sector regulator requires the entity to keep.
The irony is that financial services attract more rights requests than almost any other sector — the data is sensitive, the relationships are high-stakes, and disputes are common — while having the least freedom to fulfil the most emotionally resonant right in the statute. Handled carelessly, this produces one of two failure modes: entities that delete records a sector regulator later demands, or entities that refuse every erasure request with a vague reference to regulations and accumulate grievances that end up before the Data Protection Board.
The good news is that the DPDP Act anticipated this conflict and resolved it cleanly in favour of sectoral law — there is no genuine legal contradiction. What remains is an operational challenge: knowing precisely which records are locked, by which provision, for how long, and being able to demonstrate that everything else was actually erased. That is the discipline this article sets out.
RBI's Retention Universe: KYC, Transactions, and Audit Trails
For RBI-regulated entities, the anchor obligation comes from the Prevention of Money Laundering Act and its rules, operationalised through the RBI's KYC Master Direction. Records of the identity of clients — KYC documents, account files, and business correspondence — must be preserved for at least five years after the business relationship has ended or the account has been closed. Records of transactions must be preserved for at least five years from the date of the transaction. These are floor requirements; entities may face longer periods under specific directions or ongoing proceedings.
The five-years-after-closure structure is what makes the conflict acute. The retention clock on a customer's passport copy, address proof, and account opening form does not even start until the relationship ends. A former customer exercising DPDP erasure the day after closing their account is at the beginning of the retention period, not the end of it.
Beyond KYC and transactions, RBI's cyber security and IT governance frameworks require regulated entities to maintain audit trails and logs — system access logs, transaction audit trails, and records supporting reconstruction of events — with their own retention expectations, and payment-system participants carry obligations around payment transaction data, including the localisation requirement that payment system data be stored in India. Credit information flows to credit bureaus add another layer: a borrower's repayment history propagates into CIBIL and other bureaus' records under the Credit Information Companies Act framework, outside the originating lender's power to erase.
The practical upshot: for an RBI-regulated entity, the identity file, the transaction ledger, the audit trail around both, and reported credit data are all effectively non-erasable during their statutory windows. What that leaves genuinely erasable is discussed below — and it is more than most compliance teams initially assume.
SEBI's Retention Universe: Broker Records, Order Trails, and Call Recordings
SEBI's regime is spread across regulations rather than concentrated in one direction, but the pattern is the same. Stock brokers must maintain books of account, records, and documents for a minimum of five years under the Stock Brokers Regulations, and the Securities Contracts (Regulation) Rules impose their own five-year requirement on specified records. Where records relate to an ongoing investigation or enforcement proceeding, SEBI routinely directs preservation until the matter concludes — which can extend retention well past the baseline.
The records in scope are rich in personal data. Client registration documents and KYC (also feeding the KRA and CKYC ecosystems), order and trade logs tied to client codes, contract notes, margin and ledger statements, bank and demat mappings, and — a category unique in its sensitivity — recordings of client orders. SEBI requires brokers to maintain evidence of client orders, and telephone recordings of orders placed by clients are a standard compliance artefact, retained for years. A voice recording of an identifiable person is squarely personal data under the DPDP Act, yet it exists precisely to be an immutable evidentiary record.
Investor grievance records add another locked category: complaints routed through SCORES and their resolution trails are regulatory records the intermediary must maintain, even though they are simultaneously a chronicle of one identifiable investor's dispute. Depository participants, RTAs, mutual funds, and investment advisers each carry parallel record-keeping obligations under their respective regulations, generally on five-year-or-longer terms.
For a brokerage compliance team, the message is that the entire trade lifecycle record — from KYC through order placement to settlement and grievance — sits inside the statutory carve-out while its retention period runs. As with the RBI universe, the DPDP analysis does not change the retention answer; it changes what you must do around the retained data, which is where the next section goes.
What 'Cannot Delete' Actually Means: Retention Is Not Business as Usual
The most common mistake in reconciling these regimes is treating legally mandated retention as permission to carry on as before. It is not. The DPDP carve-out preserves the record; it does not preserve the processing. Purpose limitation continues to apply to retained data, and the lawful purpose has narrowed to exactly one thing: compliance with the retention mandate and the regulatory, audit, and legal processes it serves.
Concretely, a closed account's KYC file retained under the PMLA may be produced to the RBI, to an auditor, to the Financial Intelligence Unit, or in legal proceedings. It may not be used to run win-back marketing campaigns, enrich analytics models, seed lookalike audiences, or pre-fill a new product application. The customer withdrew from the relationship; the residual processing basis is the legal obligation, and the legal obligation defines its own boundaries. Using audit-hold data for commercial purposes converts lawful retention into unlawful processing — the worst of both worlds, since you hold the data by right but process it in breach.
This is the substance behind the quarantine concept. Retained-under-mandate data should be segregated from operational systems: moved out of the CRM, the marketing stack, and the analytics warehouse into restricted storage where access requires a documented compliance or legal purpose, is limited to designated roles, and is itself logged. The difference between a customer whose data is active and one whose data is on legal hold should be visible in your architecture, not just in a policy.
Quarantine also solves a quieter problem: scope creep at the edges of the mandate. The regulations require the KYC record and the transaction trail — they do not require the marketing preferences, behavioural analytics, app telemetry, or support chat history attached to the same customer. Without segregation, teams default to retaining the whole customer object because part of it is locked. With segregation, the locked part is isolated and everything else follows the normal erasure path.
Answering the Erasure Request: The Split Response
With the legal map in place, the correct response to an erasure request from a current or former customer is neither refusal nor full deletion — it is a split. Erase everything outside the statutory mandates, retain what the law locks, and tell the Data Principal exactly which is which.
The erasable set is usually larger than teams expect: marketing consents and campaign history, behavioural and product analytics tied to the individual, app and web telemetry, optional profile enrichment, support interactions outside grievance-record mandates, and any data collected for purposes that have lapsed. Executing this half of the split promptly and verifiably is what distinguishes a good-faith fiduciary from one hiding behind its regulators.
The retained set should be communicated with specificity. A defensible response names the categories retained (KYC records, transaction records, order recordings), the legal basis in plain language (retention required under the Prevention of Money Laundering Act and RBI KYC Master Direction, or SEBI record-keeping regulations), and the horizon (retained for five years from account closure, then erased). Compare that with the answer that generates grievances: your request cannot be processed due to regulatory requirements. The first response demonstrates a fiduciary that knows its obligations; the second reads as a brush-off, and if it reaches the Data Protection Board, the fiduciary will have to produce the specific mapping anyway — under worse circumstances.
Two refinements complete the workflow. First, record the erasure request against the retained records so that when the statutory clock expires, erasure executes automatically rather than depending on someone remembering a promise made five years earlier — the request should convert into a scheduled deletion, not a closed ticket. Second, apply the same split logic to consent withdrawal and to the storage-limitation trigger when purposes lapse; the erasure request is just the most visible of three routes into the same decision.
Architecture Patterns: Retention Matrices, Quarantine, and Immutable-but-Minimised Trails
The foundation artefact is a retention matrix: a governed table mapping each record type to the specific legal provision requiring its retention, the retention period, the trigger that starts the clock (transaction date, account closure, proceeding conclusion), and the disposition at expiry. This matrix is the machine-readable version of your legal analysis, and every automated decision downstream — what an erasure job skips, what the quarantine holds, what the expiry scheduler deletes — should trace back to a row in it. When the RBI auditor asks why data was deleted, or the DPDP data auditor asks why it was kept, the answer is the same document.
The second pattern is the quarantine store described above: segregated, access-controlled, logged, and inventoried, with retained records tagged by matrix row and clock-start date. Crucially, the quarantine needs an exit as well as an entrance — an expiry scheduler that surfaces or executes deletions as statutory periods lapse. Five-year mandates mean the first cohort of a well-run programme's scheduled deletions arrives predictably; an unmanaged archive means data retained under a mandate quietly becomes data retained unlawfully the day the mandate expires.
The third pattern addresses audit trails specifically, where immutability and minimisation pull in opposite directions. Regulators require trails that reconstruct events reliably — often implemented as append-only or WORM storage — while the DPDP Act pushes against holding identifiable data longer than necessary. The reconciliation is to design trails around stable internal identifiers rather than embedded personal data: log the account ID and event, not the customer's name, phone number, and address in every row. Identity resolves through a reference table when an authorised investigation needs it. Where trails outlive the identity mandate itself, breaking the reference link pseudonymises the trail in place without touching the immutable record.
Finally, propagate the matrix into processor contracts. Your cloud archive, KYC vendor, call-recording platform, and analytics processors need instructions that mirror your split: hold this under legal mandate, delete that on instruction, and certify both. A retention matrix your processors have never seen is only half implemented.
The Checklist: Evidence for Both Auditors
The defining feature of this problem is that you answer to two supervisory audiences with opposite instincts. The RBI inspector or SEBI auditor asks: can you produce the record? The DPDP data auditor — mandatory if you are designated a Significant Data Fiduciary, and many large financial entities will be — asks: can you prove you deleted everything you were not required to keep? A compliant programme satisfies both from the same evidence base.
The checklist: maintain the retention matrix as a governed, versioned document with legal sign-off on each row. Segregate mandate-retained data into quarantine storage with role-based access and access logging. Implement the split-response workflow for erasure requests, with template responses naming categories, legal bases, and horizons. Convert erasure requests against retained records into scheduled deletions keyed to clock expiry. Restrict retained data to compliance purposes and verify the restriction technically — confirm the marketing and analytics stacks cannot read the quarantine. Pseudonymise audit trails by architecture where feasible. Flow retention and deletion instructions into every processor agreement. And log everything: each erasure executed, each retention decision with its matrix reference, each quarantine access with its justification.
Run the two-auditor test annually as a self-assessment. Pick a departed customer from three years ago and attempt both demonstrations: produce their KYC file and transaction trail as the RBI would demand, and produce evidence that their marketing profile, analytics history, and telemetry were erased as the DPDP Act demands. If either half fails, you have found your remediation backlog before a regulator finds it for you.
The deeper point is that the DPDP Act did not create a conflict for financial entities — it created a forcing function. Entities that always retained everything indefinitely because regulations required retaining something now have to draw the line the law actually draws. Those that draw it precisely get both halves of the benefit: regulators that get their records, and customers that get a truthful, specific answer about what happens to their data. In a sector where trust is the product, that answer is worth engineering well.
Related articles
Significant Data Fiduciary Under India's DPDP Act: Are You One, and What It Means
Children's Data Under the DPDP Act: Verifiable Parental Consent Explained
DPDP Act Breach Notification: Reporting to the Data Protection Board and Data Principals
Automate your privacy compliance
See how TruePrivacy can handle DSRs, consent, and breach response — all in one platform.
Free 14-day trial · No credit card required · Setup in minutes