Managing Bank DPDP Access, Correction, and Erasure SLAs Alongside RBI KYC Retention

Banks resolve DPDP data principal requests for access, correction, and erasure by routing them through an authentication layer to meet Section 15 duties. They evaluate these requests against RBI KYC retention mandates and log the outcome for Data Protection Board of India (DPBI) audits. Section 11 of the Digital Personal Data Protection Act, 2023 grants data principals the right to access summaries of their data, processing activities, and the identities of third-party processors. For banks, meeting the prescribed SLAs requires mapping personal data across core banking systems, loan origination platforms, and marketing databases. The Chief Compliance Officer must generate evidence showing that requests were verified, processed within the statutory timeframe, and rejected only when specific regulatory exemptions apply. With exactly 228 days remaining until the DPDP hard compliance deadline of 13 May 2027, large financial institutions face immediate pressure to reconcile these data rights with existing sectoral regulations.

Reconciling DPDP Rights with RBI Directives

The intersection of the DPDP Act and banking regulation creates specific operational friction. The Prevention of Money Laundering Act (PMLA) and RBI Master Directions require banks to maintain KYC records and transaction logs for at least five years after the business relationship ends. Section 12 of the DPDP Act introduces the right to erasure. A direct conflict appears when a former customer demands the deletion of their financial profile.

Banks resolve this conflict through Section 7 legitimate uses and statutory exemptions. The DPDP Act permits retention when processing is necessary for fulfilling legal obligations. A bank receiving an erasure request must categorize the data elements involved. Core transaction records fall under legal retention mandates and are exempt from immediate deletion. Conversely, behavioral marketing data or third-party lead generation profiles do not enjoy RBI protection and must be erased within the SLA timeframe.

Handling this split requires precise data mapping and a detailed Record of Processing Activities (RoPA). The board expects the compliance function to demonstrate that the bank honors erasure rights without violating anti-money laundering laws. Manual segregation of these requests scales poorly in a large enterprise.

What to Keep vs What to Build

Legacy core banking systems hold decades of financial data. A compliance team should not attempt to rebuild these ledgers for DPDP adherence. Banks keep their existing transaction processors, data warehouses, and regulatory reporting infrastructure intact.

Instead, banks build or procure a centralized DPDP rights gateway. This runtime enforcement layer manages the intake, verification, and routing of Section 11 and Section 12 requests. The gateway acts as the orchestration engine between the customer and the fragmented backend systems.

It logs the exact time a request arrives, tracking the SLA countdown dictated by the DPDP Rules, 2025. When a customer demands a summary of processing activities, the enforcement layer queries the legacy systems, compiles the data, and formats the response. It also tracks the identities of all Data Processors, such as credit bureaus or collection agencies, fulfilling the Section 11(1)(b) disclosure requirement. Every action creates an immutable log for board reporting and DPBI audits.

Acceptance Tests a Procurement Team Can Run

Procurement teams evaluating DPDP compliance platforms must run specific acceptance tests to verify handling of bank-grade requirements. A generic ticketing system fails to meet the strict evidentiary standards expected by banking regulators.

1. Section 15 Authentication. The platform must reject anonymous or unverified requests. Section 15 mandates that data principals furnish verifiably authentic information when exercising their rights. The system must prompt the user for secure identification and match it against bank records before initiating an access or erasure workflow.

2. SLA Tracking and Grievance Routing. Section 13 requires readily available means of grievance redressal. Submit a test access request to the platform. The system must start a timer, issue automated warnings to the control owner as the deadline approaches, and generate an alert if the SLA lapses. Data principals must exhaust this internal channel before approaching the DPBI.

3. RBI Conflict Resolution. Submit an erasure request for an active loan customer. The system must block deletion of the core account data, cite the relevant RBI mandate, and generate an automated rejection notice. It should simultaneously execute the erasure in non-exempt marketing databases.

4. Evidence Pack Generation. The compliance officer must be able to export a complete audit trail of the request lifecycle. This evidence pack details who authorized the action, what data was altered, and the timestamp of the final resolution.

Board Reporting and DPBI Exposure

The board of directors holds the Chief Compliance Officer accountable for minimizing DPBI exposure. Financial regulators already scrutinize banks for cybersecurity resilience, but the DPDP Act introduces a parallel track of regulatory risk. A failure to honor a Section 11 access request within the prescribed SLA creates grounds for a data principal grievance.

Section 13 requires the bank to respond to these grievances promptly. If the bank ignores the request, the data principal can escalate the matter directly to the DPBI. A high volume of unresolved grievances signals systemic non-compliance to the board. This triggers formal audits and potential financial penalties.

To manage this exposure, compliance teams require automated dashboards that track SLA adherence across all product lines. The board needs a clear view of how many requests the bank receives, the average resolution time, and the volume of requests rejected under statutory exemptions. The DPDP Rules, 2025 also mandate that any personal data breach requires intimation to affected data principals without delay, alongside a detailed report to the DPBI within 72 hours. An incomplete inventory of personal data delays this notification process. A mature DPDP rights gateway links access requests to data mapping. This setup allows the bank to quickly identify affected data principals during a security incident and converts abstract legal duties into measurable operational metrics.

Common Mistake: Treating Withdrawal as Global Delete

Many banking teams misinterpret consent withdrawal as an automatic trigger for total data erasure. Under the DPDP Act, consent is the primary basis for processing, except where Section 7 legitimate uses apply. A customer withdrawing consent for marketing communications requires the bank to stop sending promotional offers and delete the corresponding data from campaign platforms. This withdrawal does not override legal obligations to maintain financial records. Banks process KYC documentation, loan repayment histories, and transaction logs under statutory mandates.

When a customer withdraws consent, the core banking data remains intact. Treating withdrawal as a global delete instruction causes immediate violations of RBI directives. Compliance platforms must decouple purpose-level consent from underlying legal retention rules. This architecture limits deletion to the specific purpose withdrawn, preserving the evidence trail required for financial audits. It protects the bank from DPBI penalties while satisfying the RBI. A granular approach to consent artefacts provides the board with confidence in the overall compliance posture.

Evaluate your operational readiness for Section 11 access requests, DPBI breach intimation, and erasure SLAs with our platform at https://www.complydp.com/audit-preview before the deadline.