Updated At Apr 18, 2026
RBI vs DPDP: Erasure When KYC Retention Still Applies
A practical operating model for Indian BFSI leaders to honour DPDP erasure rights while meeting RBI KYC, PMLA and audit-retention obligations.
Key takeaways
- DPDP erasure rights are not absolute; personal data must be erased when the purpose is over or consent is withdrawn, except where another law (such as RBI KYC, PMLA or tax law) requires retention.
- BFSI institutions should classify KYC and related datasets by lawful basis and group them into three zones: erasure-eligible, restricted-use regulatory archive, and live operational KYC data.
- Encoding erasure logic into architecture – via regulatory data vaults, soft delete, field-level redaction, and a central consent/rights orchestration layer – is more sustainable than treating each erasure request as a manual exception.
- Standardised decision trees, response templates, and metrics on erasure handling make it easier to satisfy both RBI inspections and potential Data Protection Board scrutiny.
- Dedicated consent management platforms, such as Digital Anumati, can act as the control plane for DPDP rights, notices, and KYC-retention exceptions across complex BFSI stacks.
The regulatory collision: KYC retention versus DPDP erasure
- Compliance and risk leaders worry about discarding records needed for AML, tax, fraud and dispute resolution.
- Customer experience and product teams want to respond positively to erasure requests and avoid complaints to the Data Protection Board or RBI Ombudsman.
- Technology leaders face fragmented legacy stacks where KYC data is replicated across CBS, LOS/LMS, CRM, data warehouses and third-party systems, making consistent erasure logic hard to implement.
What RBI KYC, PMLA and related laws actually require you to retain
| Record type | Examples | Minimum retention typically required | Notes for DPDP erasure decisions |
|---|---|---|---|
| Customer-identification (KYC) records | KYC forms, officially valid documents (OVDs), PAN, photographs, address proofs, account opening forms, KYC refresh documents, risk ratings. | At least 5 years after the business relationship ends; longer if other laws (e.g., tax) require.[4] | DPDP erasure cannot override these statutory minima. You may, however, move such data into a restricted “regulatory archive” zone once the relationship ends and operational use is no longer required. |
| Transaction records | Account statements, loan disbursement and repayment entries, remittances, card transactions, channel logs that evidence customer instructions. | At least 5 years from the date of each transaction; longer where tax or other sectoral regulations apply.[4] | Typically non-erasable within the minimum retention window. After that, you can consider anonymisation or deletion unless another law or dispute risk justifies extended retention. |
| AML monitoring and reporting artefacts | Suspicious transaction reports (STRs), cash transaction reports (CTRs), enhanced due-diligence files, internal investigation memos. | Generally aligned to or longer than core KYC and transaction retention periods, depending on PMLA/FIU guidance and internal policy. | Treat these as core compliance records. They normally sit squarely in the “regulatory archive” zone, with strict access and no marketing or analytics reuse. |
| Tax and statutory accounting records | Ledgers, invoices, TDS/TCS records, GST filings, reimbursement claims linked to customer accounts. | Varies by law; often longer than banking minima. Internal policies frequently align to the longest applicable retention requirement across laws. | These may contain personal data but are usually retained under statutory obligation. Focus on minimising fields collected and tightly restricting reuse after the primary purpose is achieved. |
- Retention duties are layered: the strictest relevant law (RBI KYC, PMLA, tax, company law) usually drives the minimum period for a given record type.
- “Minimum retention” does not automatically mean “full read/write access for all users” – you can and should move old KYC data into lower-access regimes once it is no longer needed operationally.
- Your DPDP erasure design must start from a defensible retention schedule that maps these legal minima to concrete data categories and systems.
DPDP Act and Rules: erasure, retention and log obligations in practice
- Erasure by default: Once the purpose for which data was collected is achieved, or consent is withdrawn, personal data must be erased unless retention is required for compliance with another law or for other specified reasons. The Act’s own banking KYC illustration reinforces that you cannot delete records that another law still requires you to keep.
- Conditional erasure rights: When a customer requests erasure, you must examine the legal basis for each category of data. Where the basis is only consent, and no legal or contractual obligation applies, you are expected to erase. Where there is a legal obligation to retain (for example, under RBI KYC or PMLA), you may refuse erasure for those elements but should still minimise and restrict their use.
- Procedural safeguards under the DPDP Rules: these include proactive deletion at the end of defined retention periods, advance notice to Data Principals when erasure will occur on your own schedule (for example, at least 48 hours before deletion after expiry of the retention period), and minimum one-year retention of relevant logs and personal data processed for security and incident-management purposes.[2]
| DPDP duty | What it means in substance | Implication for BFSI retention/erasure design |
|---|---|---|
| Erasure when purpose is served or consent withdrawn | You should not keep personal data indefinitely; once there is no valid purpose or lawful basis, it should be erased or anonymised. | Define clear retention periods per dataset and build automated checks that trigger erasure/anonymisation jobs as soon as those periods end (subject to KYC and other legal obligations). |
| Legal-compliance exception to erasure | Where a law requires retention (for example, for KYC, AML, tax or company law), you may retain the necessary data even if a Data Principal requests erasure. | Implement decision logic that distinguishes between erasable and non-erasable data elements and records the legal basis when you decline full erasure for a request. |
| Log and security-data retention obligations under Rules | Certain logs and security/incident-handling data must be kept for at least a defined minimum period, even though they contain personal data. | Architect log stores and SIEM/SOC tooling so that these datasets are quarantined from marketing/analytics use but still accessible for security, compliance and investigation purposes for at least the mandated period. |
Classifying KYC data by lawful basis to resolve erasure conflicts
| Data element / dataset | Typical primary lawful basis | Erasure stance after account closure |
|---|---|---|
| OVD copies (passport, Aadhaar where permitted, driving licence, etc.) and KYC forms | Legal obligation (RBI KYC, PMLA) + contract with customer | Not erasable during statutory retention period. After that, move to deletion/anonymisation unless another legal need exists (e.g., pending litigation). |
| PAN, date of birth, basic identity metadata in the core customer record (CIF) | Contract (to operate the account/loan) + legal obligation (tax reporting, KYC linkage for a period) | Retain as long as needed for tax/KYC linkage and dispute resolution; later, consider pseudonymisation or partial redaction (e.g., masking PAN) before eventual deletion/anonymisation. |
| Mobile number, email address, communication preferences in CRM | Contract (for servicing) while relationship is active; consent for marketing and cross-sell communications separately captured and logged | After relationship closure, retain only where needed for legal/archive purposes. For marketing or analytics use, treat as consent-based and erase or suppress when consent is withdrawn or no longer relevant. |
| Risk scores, behavioural models, fraud flags derived from KYC and transaction data | Legitimate use (fraud prevention, risk management) + legal obligation where risk monitoring is prescribed by regulation or internal policy approved by the board | Retain in line with AML and fraud-control needs, but progressively anonymise or aggregate historic datasets so that individual-level identifiability is minimised post-retention window. |
| Marketing tags, response history to campaigns, cross-sell eligibility labels not mandated by regulation | Consent (sometimes combined with legitimate use arguments, but consent is cleaner and more defensible for marketing in BFSI contexts) | Erase or fully suppress when consent is withdrawn, when an erasure request is accepted, or when a defined marketing-retention period expires (e.g., X months after last interaction). These are prime candidates for immediate erasure even while KYC archives stay intact. |
- Avoid labelling everything as “legal obligation”. Where only part of a dataset is strictly required by law, separate and tag that portion so it can be retained while other elements become erasable.
- Document lawful basis at the field or logical-dataset level inside your data catalogue or metadata repository, not only at the product level.
- Ensure business, compliance and legal teams jointly sign off the lawful basis mapping so it is defensible in front of both RBI supervisors and the Data Protection Board.
Designing an erasure operating model that respects both RBI and DPDP
| Zone | What it covers | Primary retention driver | Erasure / restriction logic | Key controls |
|---|---|---|---|---|
| Zone 1 – Erasure-eligible data | Marketing data, optional preferences, analytics attributes not required for KYC, AML or tax; redundant duplicates of legally required data in non-critical systems. | Consent or legitimate use, with no independent legal obligation to retain after relationship closure or consent withdrawal. | Erase promptly on erasure request, consent withdrawal, or expiry of defined retention period. Aim to remove all customer-identifiable data from this zone even while Zone 2 archives are retained. | Strong data discovery, suppression lists, soft-delete plus physical deletion pipelines, and automated checks to prevent Zone 1 data being repopulated from archives. |
| Zone 2 – Restricted-use regulatory archive | Core KYC records, transaction history, AML artefacts and tax/accounting records preserved to satisfy RBI, PMLA, tax and company law obligations after the active relationship ends. | Legal obligation and risk-based retention. DPDP erasure does not apply until the retention period (plus any litigation-hold extensions) expires. | Do not erase during the legally required period, but restrict use strictly to compliance, audit, dispute and regulatory-reporting purposes. Erase or anonymise at the end of the retention period, with logs retained as required by DPDP Rules. | Dedicated archival stores or vaults; limited access roles; policy-based controls preventing use for marketing, model training or product design; strong audit logs for any access or export from the archive. |
| Zone 3 – Live operational KYC data | Customer data in core banking, loan management, cards, wallets, collections and servicing systems required to operate active accounts/relationships. | Contract + legal obligation while the account/relationship is live; supported by risk management and fraud-prevention needs. | On erasure request during an active relationship, most core operational data will not be erasable without closing the relationship. You can, however, erase or suppress Zone 1-type elements and tighten access to sensitive attributes. On closure, progressively move necessary data to Zone 2 and erase the rest. | Master-data controls, purpose-tagged APIs, access control by role and channel, and configuration to move closed relationships out of live systems into the archive on a defined schedule. |
Use this standardised workflow for handling an individual erasure request while respecting RBI and DPDP constraints.
-
Authenticate the requester and confirm scopeVerify identity using strong KYC-linked factors and clarify which products, channels and time periods the request covers. Capture this in a case record with a unique reference ID that can be audited later.
-
Locate data across systems and tag by lawful basis/zoneUse your data catalogue and master-data keys to pull a list of all relevant records in CBS, LOS/LMS, CRM, data lake, archives and third-party processors. For each logical dataset, identify its lawful basis and which of the three zones it belongs to.
-
Decide what can be erased, anonymised or restrictedApply a decision tree: Zone 1 data is erased or anonymised unless there is a specific exception; Zone 2 data is generally restricted but retained; Zone 3 data is retained while the relationship is active, though some attributes (e.g., marketing tags) may still be erased or suppressed.
-
Prepare a transparent response to the Data PrincipalDraft a standardised response explaining: what you will erase, what you will retain (and under which law/contractual obligation), and what restrictions you will apply to retained data. Include information on how the Data Principal can escalate a grievance if they disagree.
-
Execute technical erasure and restrictions with loggingTrigger deletion, anonymisation, tokenisation or access-restriction jobs in each system via a controlled workflow. Log every action taken, including timestamps, operators or services involved, and dataset identifiers, and retain these logs for at least the period required under DPDP Rules and your own policies.[2]
-
Close the case and feed metrics into governance dashboardsMark the request as closed, record whether it was fully or partially satisfied, and push metrics (turnaround time, exceptions invoked, systems touched) into your privacy and compliance dashboards for board-level oversight.
Key takeaways
- Treat erasure handling as a repeatable business process, not an ad hoc favour to individual customers.
- A three-zone model simplifies conversations between legal, compliance, IT and product teams by giving them a shared vocabulary for what can and cannot be erased today.
- Even where you cannot erase, you can usually restrict access, narrow purposes and move data into less sensitive environments to improve your DPDP posture without breaching RBI or PMLA rules.
Embedding erasure and retention into BFSI system architecture
- Master customer and KYC data: Use a golden customer profile (CIF) and central KYC repository so that erasure and restriction decisions can be initiated from one place and propagated reliably to dependent systems via events or APIs.
- Regulatory data vault: Implement a logically separate vault for Zone 2 data (statutory KYC, transaction and AML archives) with stricter access, purpose-tagged APIs, and write-once logs. Live applications should reference the vault only when required, not mirror its full contents for convenience.
- Soft delete with delayed physical deletion: For most business systems, introduce a soft-delete flag that hides data from normal views, combined with scheduled jobs that physically delete or anonymise data once all relevant retention and legal-hold checks have cleared.
- Field-level redaction and tokenisation: In analytics and reporting environments, replace direct identifiers (e.g., account numbers, PAN) with tokens or pseudonyms, and redact fields that are no longer needed. This allows continued trend analysis without retaining full personal data indefinitely.
- Unified logging and audit: Capture erasure, restriction and access events into a central log store, and retain them for at least the minimum period required for such logs and security data under DPDP Rules and your security policies.
Customer communication and grievance handling when you cannot fully erase
A pragmatic communication playbook for erasure and retention decisions in BFSI.
-
Offer a single, well-advertised entry point for DPDP rightsWhether it is a self-service privacy centre, a section in your mobile app, or a dedicated web form, make the starting point for access/correction/erasure requests easy to find and consistent across products and entities in the group.
-
Set expectations early in the journeyWhen a customer initiates an erasure request, immediately display or send an acknowledgement explaining that certain records (for example, KYC and transaction data) may need to be retained for specified legal or regulatory reasons, even if other data is erased or restricted.
-
Provide a structured outcome summary, not a generic confirmation emailRespond with a template that clearly distinguishes between: data erased; data retained with reasons (e.g., “RBI KYC Directions / PMLA”); and data restricted (e.g., moved to regulatory archive, removed from marketing lists). This transparency reduces escalation risk and builds trust with regulators.
-
Explain escalation paths and timelines for grievancesInclude details of your grievance officer, expected response timelines, and when customers may approach external bodies such as the Data Protection Board or RBI Ombudsman. Ensure these details are consistent with your privacy notice and regulatory filings.[6]
- Align language across channels: Call-centre scripts, email templates, app copy and branch FAQs should all explain erasure-versus-retention decisions using the same terms and examples.
- Log every communication: Attach copies of acknowledgements, responses and explanations to the case record so that any future inspection or dispute has full context.
- Support multiple Indian languages: For mass-market BFSI, offering erasure explanations and consent/rights flows in key Indian languages materially reduces misunderstandings and grievances, especially for vulnerable customer segments.
Governance, metrics and audit-readiness for erasure and KYC retention
| Area | Sample metrics / KRIs | Typical owner | Audit evidence to retain |
|---|---|---|---|
| Erasure and rights-handling performance | Volume of erasure requests per month; median and 95th percentile time to close; percentage fully vs partially satisfied; percentage escalated to grievances or external bodies. | DPO / CPO with support from operations and IT service owners. | Case logs, workflow screenshots, communication templates and system logs showing deletions/restrictions executed as claimed. |
| Retention hygiene and data minimisation | % of systems with documented retention schedules; % of datasets with implemented purge/anonymisation jobs; volume of records deleted or anonymised per quarter after retention expiry; exceptions where legal holds extended retention. | Chief Data Officer / CIO, with Compliance and Records Management. | Retention schedule, job configuration files, logs of purge runs, and approvals for legal holds overriding scheduled deletion. |
| Regulatory archive and access control effectiveness (Zone 2) | Number of users with access to regulatory vault; number of non-compliant access attempts blocked; volume of data exports from the archive; incidents involving misuse of archived data for non-regulatory purposes. | CISO / Head of IT Security and Head of Compliance jointly. | Access-control policies, role definitions, periodic access-review reports, SIEM logs for archive access, and incident reports with remediation evidence. |
| Board and senior-management oversight | Frequency of board/RMC updates on DPDP and KYC retention; number of material DPDP incidents; decisions on risk appetite (e.g., when to anonymise versus delete). | Board-level committee (Risk, Audit, or dedicated Data/IT Committee). | Board and committee minutes, presentations, and decision records showing how management is steering the erasure and retention programme. |
- Clarify decision rights: Who can approve exceptions to erasure? Who can extend retention due to litigation holds? Who owns the three-zone model across group entities?
- Integrate DPDP considerations into product approval and change-management processes, so new products are designed with clear lawful bases, retention rules and erasure handling from day one.
- Ensure internal audit periodically tests both sides of the equation: that erasure requests are handled correctly and that statutory retention (e.g., for KYC and PMLA records) is not inadvertently compromised by purge jobs or migrations.
Key takeaways
- What you can evidence in logs, dashboards and minutes will matter more to regulators than how elegant your policy document looks on paper.
- Combining DPDP metrics with existing risk and compliance reporting helps the board see erasure and retention as part of mainstream risk management, not a niche privacy project.
Implementation roadmap and role of consent management platforms
A pragmatic rollout sequence for BFSI teams.
-
Baseline assessment and data mappingIdentify all systems storing KYC and related personal data, current retention settings, and where DPDP-relevant rights are already implemented (if at all). Map key datasets to lawful bases and classify into the three zones at a high level.
-
Policy design and decision trees with cross-functional sign-offLegal, compliance, DPO/CPO, information security, IT and business units jointly define the erasure decision tree, retention schedules and exception-handling policies. Document these in a way that can be implemented in code and workflows.
-
Select or configure a consent and rights management platformEvaluate tools (including in-house options) against criteria such as lawful-basis mapping, consent orchestration, user rights portals, multi-language support, APIs/SDKs and analytics. Decide which platform will be your orchestration layer for notices, consents and DPDP rights across products.
-
Pilot on a contained product or segmentChoose a limited-scope portfolio (for example, a specific card or personal-loan product) to pilot end-to-end erasure workflows, retention-aligned purge jobs, and customer communications. Use this to refine decision logic, SLAs and metrics before enterprise-wide rollout.
-
Scale across products and group entities with continuous improvementExtend the operating model to other products, channels and group entities. Introduce governance checkpoints, periodic assurance reviews and technology enhancements (for example, broader data discovery or automated legal-hold management) based on lessons from earlier phases.
When evaluating consent management and DPDP tooling, decision-makers should look for capabilities that directly support the RBI–DPDP balancing act:
- Configurable lawful-basis and purpose mapping, so that each consent or processing activity is clearly linked to a purpose, legal basis and retention rule that can be enforced in workflows and APIs.
- A unified user rights portal where customers can raise access, correction and erasure requests and manage preferences, with back-end workflows to route and fulfil those requests across systems.
- Dynamic consent orchestration that can adapt notices and consent prompts by channel, language and purpose, while maintaining immutable, audit-ready records of what each customer agreed to and when.
- Analytics and dashboards that show consent trends, erasure-request volumes, SLA performance, and exception patterns, enabling leadership to manage privacy and KYC retention as an ongoing risk theme.
- Robust technical integration options – REST APIs, JavaScript and mobile SDKs – to connect web, app, branch and call-centre journeys, and to orchestrate updates into CBS, LOS/LMS, CRM and data platforms.
- Strong security and availability posture, including encryption, high-uptime SLAs and 24×7 support, appropriate for regulated BFSI workloads.
Erasure and retention in practice
Digital Anumarti - Service
1
Cold-storage after revocation
In the single revocation event at Khanna Hospital, Digital Anumati’s pipeline automatically migrated the patient’s data from active operational databases to encrypted cold-storage retention logs, removing it from active processing while preserving medico-legal compliance.
Why it matters for you
This illustrates a practical pattern for DPDP erasure where data is taken out of live use but kept in a locked-down archive, mirroring how BFSI teams can honour erasure while still meeting RBI and PMLA record-retention duties.
2
Revocation architecture in action
Khanna Hospital serves as an example of executing DPDP-compliant consent revocation architecture in Indian hospitals, demonstrating system capability to propagate downstream data erasure and deactivation after withdrawal.
Why it matters for you
For banks and NBFCs with many interconnected systems, this shows that a consent platform can coordinate revocation across downstream applications instead of treating each KYC store as a manual one-off.
3
Business case for decoupled consent
V Care Clinics’ data validates the business case for a decoupled consent architecture in elective healthcare, where separating medical service consent from marketing consent preserves clinical revenue while respecting patients’ reluctance to share cosmetic data for marketing.
Why it matters for you
This supports designing BFSI consent flows that clearly separate mandatory KYC processing from optional marketing or analytics uses, reducing DPDP risk without sacrificing core business growth.
4
Core vs marketing consent behaviour
At V Care Clinics, patients largely approved core medical data processing while disproportionately rejecting consent for marketing uses such as clinical image usage and third-party sharing with cosmetic vendors.
Why it matters for you
BFSI teams should plan for customers to accept necessary KYC processing but push back on secondary uses, so operational KYC data and optional profiling or cross-sell datasets need distinct lawful bases and erasure rules.
5
Revocations are rare but real
Across the four healthcare deployments documented, revocations were rare, with only a single revocation event reported at Khanna Hospital and none at GastroLiver Clinic, V Care Clinics, or the two diagnostic labs.
Why it matters for you
This suggests DPDP revocation-and-erasure events will be low-volume but must still be fully automated and auditable, fitting the article’s recommendation to treat them as exception flows embedded in BFSI architecture rather than ignored edge cases.
Troubleshooting erasure and KYC-retention breakdowns
- Symptom: Customers receive marketing communications after erasure or opt-out. Cause: Marketing systems are not fully integrated with the consent/rights platform or are re-hydrating data from regulatory archives. Fix: Introduce suppression lists keyed off a durable customer identifier, ensure that data pipelines from Zone 2 to marketing exclude opt‑out customers, and regularly reconcile contact lists against the consent repository.
- Symptom: Purge jobs accidentally delete records still within the KYC or PMLA retention window. Cause: Retention logic implemented only at application level, without awareness of legal minima by data category. Fix: Move retention rules into a central policy engine or configuration store; require legal/compliance sign-off on any change; test purge jobs on non‑production datasets with synthetic records representing edge cases.
- Symptom: Inconsistent responses to erasure requests across group entities. Cause: Each entity or product team interpreting DPDP independently, with no group-wide erasure playbook. Fix: Establish a group privacy office or steering committee, standardise the three-zone model and decision trees, and deploy a shared consent and rights platform where feasible, even if some entities maintain separate cores.
- Symptom: Erasure requests take months to close and are often escalated as grievances. Cause: Manual, email-based workflows; lack of integration with core systems; unclear ownership. Fix: Implement workflow tooling with SLAs, integrate with ticketing systems, and assign clear request owners by product or function, supported by automated triggers into underlying systems.
Common mistakes BFSI teams make on erasure and KYC retention
- Treating all data in KYC processes as if it were permanently non-erasable, rather than isolating what is truly required by law from what is merely convenient to retain.
- Ignoring DPDP’s erasure-by-default and minimisation duties on the assumption that sectoral regulators will “take precedence” in every case, without documenting a legal basis and rationale for each retention decision.
- Designing erasure workflows purely as a legal/compliance process and not involving architecture, data, security and CX teams early enough to make them scalable and user-friendly.
- Over-focusing on consent forms while under-investing in data discovery, lineage and cataloguing, which are prerequisites for actually executing erasure or restriction consistently across systems.
- Relying on manual spreadsheets and email approvals for erasure decisions, leaving little audit trail for regulators and exposing the institution to inconsistent treatment of similar cases.
Common questions about erasure and KYC retention for BFSI teams
FAQs
In most cases, you cannot delete core KYC and transaction records immediately on closure because RBI KYC Directions, PMLA rules and other laws require you to retain them for defined minimum periods. Those datasets should move into a restricted regulatory archive (Zone 2), with access limited to compliance, audit and dispute-handling teams.[4]
You can typically erase or strongly suppress consent-based data such as marketing tags, campaign histories and optional profiling attributes (Zone 1), and you can also remove the customer from active CRM views and servicing journeys once no live products remain. Any additional deletions beyond this baseline should be designed and approved with legal counsel, based on your institution’s risk appetite and applicable laws.
No. DPDP expressly recognises that personal data may be retained where this is necessary to comply with a law in force, and the Act’s own banking KYC illustration reinforces that you must keep such records for as long as those laws require, even if a Data Principal requests erasure.[1]
What DPDP does change is your obligation to erase or minimise personal data once those other legal obligations no longer require retention, and to justify any continued retention based on a valid lawful basis and documented rationale.[3]
Customers experience your group as one brand, not as a collection of separately regulated entities. Internally, though, each entity may be a separate Data Fiduciary with its own RBI or sectoral regulator. A practical approach is to centralise intake of DPDP rights requests through a group-level privacy centre, then route each request to the relevant entities and apply the three-zone model per entity and product.
Your response to the Data Principal should explain, in plain language, which group entities hold which data, what has been erased or suppressed, and what is being retained under specific legal or regulatory obligations.
If KYC or transaction data is processed or stored outside India (for example, by group service centres or third-party processors), your contracts and technical controls should ensure that DPDP rights, including erasure, can still be honoured while maintaining mandatory retention under Indian law. That means extending your three-zone classification, retention schedules and erasure workflows to cross-border systems and ensuring processors can execute erasure/anonymisation and provide logs back to you.
DPDP Rules introduce minimum retention periods for certain logs and security/incident-handling data, generally at least one year. Banking and AML rules, by contrast, often require five or more years for core KYC and transaction data. You should design your logging architecture so that logs relating to erasure requests, security and consent management are kept for the DPDP-mandated minimum (or longer if justified), while still ensuring that business and KYC records follow the longer RBI/PMLA-driven schedules where applicable.[2]
No technology platform, by itself, can guarantee DPDP or RBI/PMLA compliance. What a consent management and rights orchestration solution can do is make it operationally feasible to apply your policies consistently: capturing consents and purposes, routing erasure and correction requests, and producing audit-ready records and dashboards for oversight.
Platforms like Digital Anumati should therefore be seen as enablers within a broader privacy, compliance and risk-management programme that also includes governance, training, legal analysis and architectural change.[7]
Sources
- The Digital Personal Data Protection Act, 2023 (No. 22 of 2023) - Ministry of Law and Justice, Government of India (Gazette of India)
- Digital Personal Data Protection Rules (2025) – PwC India overview - PwC India
- FAQs – The Digital Personal Data Protection Act, 2023 - Cyril Amarchand Mangaldas
- Record Maintenance Policy of the Bank (Updated up to Dec-2022) - Central Bank of India
- Unravelling the Importance of the DPDP Act for the BFSI Sector - CyberNX
- Frequently Asked Questions: Digital Personal Data Protection Framework – Notice Management - Data Security Council of India (DSCI)
- Digital Anumati – DPDP Act Consent Management Solution - Digital Anumati