Guide to DPDP Act Compliance for Banks

India's data protection framework is moving closer to implementation. With the DPDP Act, 2023 and DPDP Rules, 2025 establishing the compliance framework, organisations now need to focus on translating regulatory requirements into operational practices.

Banks will be among those facing this challenge most directly. They process vast amounts of personal data across account opening, KYC, transactions, lending, digital banking, customer support and marketing—often across branches, core banking systems, apps and third-party providers.

So, what do banks need to do to become DPDP compliant?

This guide breaks down the practical steps banks can take to build DPDP compliance into everyday banking operations.

How Can Banks Get DPDP Compliant?

Banks can become DPDP compliant by following a structured implementation flow: inventory personal data , map its movement, define processing purposes, redesign consent, operationalise Data Principal rights, align retention practices, strengthen security, govern third parties and establish clear accountability. Each step should be applied to actual banking workflows rather than treated as an isolated compliance task.

The practical implementation sequence is:

1. Inventory personal data
2. Map data flows
3. Define processing purposes
4. Redesign consent
5. Separate essential and optional processing
6. Operationalise Data Principal rights
7. Align retention and erasure
8. Strengthen security and breach response
9. Assess third parties
10. Establish governance

Let's break down what each step means inside an actual bank.

Step 1: Build a Complete Inventory of Personal Data Across Banking Operations

Banks should begin DPDP compliance by identifying every category of personal data they collect and every system in which it exists. The inventory should extend beyond core banking records to include onboarding, KYC, lending, digital channels, customer service, marketing and third-party environments.

This step answers the most basic compliance question:

What personal data does the bank actually hold?

Surprisingly, many organisations discover that the answer depends on whom they ask.

IT may know the databases. Operations may know the forms. Marketing may know the CRM. Branch teams may know about physical records that never appear on an enterprise data map.

That is precisely why a bank needs a centralised data inventory.

What Personal Data Should Banks Include in Their Data Inventory?

Banks should build their inventory around major banking operations rather than trying to document every system at once. Start with these key data categories:

1. Customer Onboarding and Account Opening Data

   Includes names, contact details, addresses, identity information, nominee details, occupation, income-related information and supporting documents. Review whether every field collected is necessary and document its purpose, owner and destination system.

2. KYC and Verification Data

   Includes PAN and other identity information, address documents, photographs, video-based verification records and verification metadata. Track not only the original documents but also copies and outputs stored across different systems.

3. Account, Transaction and Core Banking Data

   Includes account details, customer profiles, transaction records, beneficiary information, service requests and communication preferences. Identify downstream systems that receive copies of this data from the core banking environment.

4. Lending and Credit Data

   Includes income and employment information, financial records, credit-related data, guarantor and co-applicant details, property documents and repayment information. Map the data of every individual involved in the lending workflow—not just the primary applicant.

5. Digital Banking and Behavioural Data

   Includes login information, device identifiers, authentication data, session information, app interactions and fraud signals. Separate data required to operate and secure banking services from optional analytics or personalisation data.

6. Marketing and Customer Engagement Data

   Includes communication preferences, campaign interactions, product interests, lead information and call campaign records. Keep marketing datasets distinct from core customer servicing data and document how they are used.

The goal is simple: identify what personal data the bank holds, where it exists, why it is processed and who is responsible for it.

Step 2: Map How Personal Data Moves Across the Banking Ecosystem

After building an inventory, banks should map how personal data moves from collection through processing, sharing, storage and eventual deletion. The goal is to identify every system, team and third party involved in a banking workflow—not merely document where data was first collected.

Map workflows, not departments

A common mistake is asking each department to list "its data."

Instead, start with a banking process and follow the data.

For every workflow, identify:

1. Where is the data collected?
2. Which system receives it first?
3. Who accesses it internally?
4. Which other systems receive a copy?
5. Is data shared with an external entity?
6. Where is it stored?
7. What event changes or ends the processing?

Prioritise high-volume workflows

Start with the workflows that process the largest volumes or most sensitive categories of personal data:

• Customer onboarding
• KYC
• Account servicing
• Digital banking
• Lending
• Customer support
• Marketing
• Third-party processing

Step 3: Define and Document the Purpose for Each Banking Data Processing Activity

Banks should document why personal data is processed at the activity level rather than assigning one broad purpose to the entire customer relationship. Clear purpose definition helps distinguish account servicing, regulatory compliance, fraud prevention, lending and marketing activities and creates the foundation for lawful processing and retention decisions.

The DPDP Act permits processing for a lawful purpose based on consent or certain legitimate uses recognised under the Act. It also requires notices and consent requests to identify the relevant personal data and processing purpose where applicable.

For banks, "to provide banking services" is usually too broad to be operationally useful.

Break the processing into actual activities.

Step 4: Redesign Consent Management Across Banking Channels

Banks should redesign consent management around the channels through which customers interact with them, including branches, mobile apps, internet banking, relationship managers and call centres. Where consent is the basis for processing, banks need clear, specific and informed consent flows with withdrawal mechanisms that can operate consistently across connected systems.

For banks, the challenge is not merely obtaining consent. The real challenge is making consent operational across every customer interaction channel.

1. Consent at Branches

   Review account-opening forms, declarations and optional service selections to ensure consent is not buried in lengthy documentation. Where possible, digitise consent records so preferences can be updated across connected systems.

2. Consent in Mobile and Internet Banking

   Build clear consent and preference controls into digital journeys for optional processing activities, communications and analytics. Make withdrawal and preference updates easy to access rather than hiding them inside a lengthy privacy notice.

3. Consent for Marketing and Cross-Selling

   Separate essential banking communications from promotional activities such as credit card, loan, insurance or investment offers. Track why customer data is being used and ensure preference changes reach every relevant marketing system.

4. Consent Through Relationship Managers and Call Centres

   Customers may update preferences during human interactions. A withdrawal or opt-out recorded by a relationship manager or call centre should automatically reach downstream CRM and campaign systems.

The goal is simple: consent collected through one channel should be visible and actionable across the entire banking ecosystem.

Step 5: Separate Essential Banking Processing From Optional Data Uses

Banks should distinguish processing that is necessary for delivering banking services or meeting applicable legal obligations from processing undertaken for additional purposes such as marketing, cross-selling, personalisation or optional analytics. This separation prevents banks from treating all customer data as available for every business use simply because a banking relationship exists.

A bank may process information for essential operational activities like:

• Account servicing
• Transaction execution
• Security controls
• Customer authentication
• Regulatory requirements
• Fraud prevention

It may also process information for additional activities such as:

• Product recommendations
• Promotional campaigns
• Behavioural analysis
• Personalisation
• Cross-selling

Build a purpose-to-processing matrix.

For each activity, record:

Data → Purpose → Processing basis → System → Recipient → Retention trigger

This creates a practical control layer between the business objective and the data.

Step 6: Build Data Principal Rights Workflows Across Banking Systems

Banks should operationalise Data Principal rights through workflows that can locate, retrieve, correct and manage personal data across multiple banking systems. The main challenge is not understanding the rights in isolation but ensuring that customer requests can be executed consistently across core banking, CRM, lending, digital and third-party environments.

The DPDP Act provides rights relating to access to information about personal data, correction and erasure, grievance redressal and nomination. Data Fiduciaries are also required to establish an effective grievance redressal mechanism.

For a bank, a rights request is a systems challenge.

Banks need to build workflows that can handle Data Principal rights across multiple systems—not respond to each request from scratch.

For example:

• Access requests: A bank should be able to locate relevant customer data across core banking, CRM, lending, mobile banking and customer support systems.
• Correction requests: If a customer updates their address, the bank should identify the source system and ensure relevant downstream systems are updated.
• Consent withdrawal: Where processing is based on consent, an opt-out should flow across CRM, campaign platforms, call centres and relationship manager tools. The DPDP Act requires a Data Fiduciary to cease consent-based processing within a reasonable time upon withdrawal, unless processing is otherwise required or authorised under applicable law.
• Grievances: Banks should define a clear entry channel, responsible team, escalation process and response-tracking mechanism.

The key is to build these workflows before a customer request arrives.

Step 7: Align Data Retention and Erasure with Banking Operations

Banks should establish data retention schedules that connect each category of personal data to its business purpose, applicable legal or regulatory retention requirements and deletion trigger. Erasure should therefore be treated as a controlled lifecycle process rather than a blanket instruction to delete customer data when an account closes or consent is withdrawn.

The DPDP Act requires Data Fiduciaries to erase personal data when consent is withdrawn or when it is reasonable to assume that the specified purpose is no longer being served, unless retention is necessary for compliance with law.

The practical task is to identify which retention obligation applies to which record. Banks should define retention and erasure rules based on the type of data and the lifecycle event involved.

1. Active and Closed Account Data

   Separate data required for active account servicing from records retained after account closure. Account closure should trigger a retention review—not simply move data into an archive indefinitely.

2. KYC and Verification Records

   KYC data may need to be retained under applicable regulatory or legal requirements. Document the basis and retention period rather than assuming DPDP erasure requirements automatically override sector-specific obligations.

3. Transaction Records

   Transaction data may be required for servicing, reconciliation, fraud investigations, regulatory reporting or legal claims. Apply retention periods based on the specific record and purpose.

4. Loan and Credit Data

   Create different retention rules for approved, rejected and withdrawn applications, closed loans and guarantor records. An abandoned application should not automatically follow the same lifecycle as an active loan.

5. Marketing and Prospect Data

   Review inactive leads, dormant prospects, old campaign lists and historical preferences. These datasets should have defined review and deletion triggers.

6. Call Recordings and Customer Complaints

   Document why these records are retained, who can access them, whether third parties store them and when they should be reviewed or deleted.

Retention is not just about how long banks keep data. It is about knowing when there is still a valid reason to keep it.

Step 8: Strengthen Security and Breach Response Across the Banking Data Ecosystem

Banks should integrate DPDP security obligations into existing information security and incident response programmes by identifying where personal data is exposed across systems, access layers, APIs and third parties. Breach response should enable the bank to determine what data was affected, whose data was involved and which notification obligations may apply.

For banks, security is already a mature discipline.

The DPDP question adds another layer:

Can the bank connect a security incident to the personal data affected?

Prioritise controls around:

• Role-based access
• Privileged account management
• Authentication
• Logging and monitoring
• Encryption and key management
• API security
• Third-party access
• Cloud environments

Build a privacy-aware incident workflow

When an incident occurs, the response should help determine:

1. Which system was affected?
2. What personal data existed in that system?
3. Which Data Principals may be affected?
4. Did a third party contribute to the incident?
5. What regulatory notifications may be triggered?

Cybersecurity identifies the attack. Data governance identifies the impact. Banks need both.

Step 9: Assess Third Parties Handling Bank Customer Data

Banks should assess every third party that processes customer personal data and maintain visibility into what data is shared, for which purpose, where it is processed and what contractual and security controls apply. Under the DPDP Act, a Data Fiduciary remains responsible for processing undertaken on its behalf by a Data Processor.

The Act permits Data Fiduciaries to engage Data Processors under valid contracts for relevant processing activities and places responsibility on the Data Fiduciary for compliance relating to processing undertaken on its behalf.

For banks, the vendor ecosystem may include:

• KYC and verification providers
• Cloud service providers
• Technology vendors
• Call centre and BPO providers
• Collection agencies
• Credit information entities
• Analytics providers

Ask five questions for every vendor

1. What data is shared?

Identify exact data fields rather than describing the dataset vaguely as "customer information."

2. Why is it shared?

Document the specific banking service or operational activity the vendor supports.

3. Where is it processed?

Understand hosting, access and processing environments relevant to the engagement.

4. Who can access it?

Assess vendor personnel, subcontractors and system-level access.

5. What happens when the purpose ends?

Define return, deletion, retention and termination procedures.

A vendor register without data-flow visibility is just a procurement spreadsheet wearing a compliance badge.

Step 10: Establish DPDP Governance Across Banking Functions

Banks should establish a cross-functional governance model because DPDP compliance touches business operations, technology, security, legal, compliance, risk and customer-facing teams. Clear ownership should connect policy requirements with system implementation and day-to-day operational decisions.

The DPDP Act places accountability on the Data Fiduciary and provides additional obligations where entities are notified as Significant Data Fiduciaries based on factors specified under the Act.

A practical governance model should involve:

Establish clear accountability

Define:

• Who owns the data inventory?
• Who approves processing purposes?
• Who updates consent workflows?
• Who handles rights requests?
• Who governs retention?
• Who monitors vendors?
• Who reports compliance risks?

Governance turns a compliance framework into an operating model.

Without ownership, even the best DPDP roadmap becomes another presentation file.

Where Do RBI Requirements and DPDP Obligations Intersect for Banks?

RBI requirements and DPDP obligations intersect wherever banks collect, retain, secure or share customer information. Banks should identify where existing sectoral controls can support DPDP compliance while separately addressing privacy obligations that are not fully covered by existing banking processes. Compliance with one framework should not automatically be assumed to satisfy the other.

The RBI's regulatory framework already governs several data-intensive banking activities, including customer identification and due diligence. The DPDP framework adds obligations relating to personal data processing, notices, consent where applicable, Data Principal rights, security and accountability.

The practical approach is not to build two separate compliance universes.

It is to identify the intersections.

Building DPDP Compliance into Everyday Banking Operations

The most effective approach to DPDP compliance for banks is to embed privacy controls into everyday banking processes rather than operate them as a separate annual exercise. Every major customer-data workflow should have defined ownership, purpose, data flows, access controls, retention triggers and mechanisms for responding to customer rights.

The roadmap is straightforward in principle:

Inventory → Map → Define → Separate → Manage → Protect → Govern

The implementation, of course, is where the real work begins.

For a bank, DPDP compliance should become part of:

• How a customer is onboarded
• How KYC data is processed
• How data moves through core banking
• How lending workflows use personal information
• How digital banking generates new data
• How marketing preferences are managed
• How customer rights requests are fulfilled
• How long records are retained
• How vendors access information
• How security incidents are assessed

Conclusion

DPDP compliance for banks is ultimately a data operations challenge with legal consequences.

A bank does not become DPDP compliant simply by publishing a privacy notice, implementing a consent banner or conducting a one-time assessment.

It needs a working architecture that connects data inventory, mapping, purpose management, consent, rights, retention, security, vendor governance and accountability.

Because customer data does not move according to an organisation chart.

It moves through the bank's operations.

And that is exactly where DPDP compliance needs to work.

Key Takeaways

• DPDP compliance for banks starts with visibility—understand what personal data the bank holds, how it moves and why each processing activity takes place.
• Consent and data use need clear operational controls, especially when separating essential banking activities from optional uses such as marketing and cross-selling.
• Banks need scalable workflows for customer rights, retention and erasure that work across interconnected banking systems and data lifecycles.
• Security, breach response and third-party governance must extend across the entire banking data ecosystem, not just internal systems.
• RBI and DPDP requirements should be aligned through a unified compliance approach, with clear ownership across compliance, legal, IT, security and business teams.
• The ultimate goal is to embed DPDP controls into everyday banking operations, making privacy part of how customer data is handled from onboarding to closure.

Related Blog

Liked the post? Share on:

FacebookWhatsAppLinkedInX