Consent Requirements Under DPDP Act for Banks

Under the DPDP Act, banks must follow specific requirements when consent is the basis for processing customer data. Consent must be free, specific, informed, unconditional, unambiguous and given through clear affirmative action.

Banks must also clearly tell customers what data is being collected, why it is needed, what it enables, how consent can be withdrawn, how rights can be exercised and how complaints can be made. They must also be able to demonstrate what consent was obtained and manage its withdrawal across relevant processing activities.

The practical challenge for banks, now, is not simply collecting a checkbox.

It is building a consent architecture that connects the customer's purpose, the data being used, the applicable processing basis, the systems involved, third parties, withdrawal and evidence.

Do Banks Need Consent for Every Use of Customer Data Under the DPDP Act?

No. Banks do not need consent for every processing activity. DPDP Act Section 4 permits processing for a lawful purpose based either on the Data Principal's consent or certain legitimate uses. Section 17 also provides specific exemptions for activities such as legal claims, regulatory functions, prevention or investigation of offences and certain loan-default-related financial analysis.

The key is to determine the purpose and applicable legal basis before asking for consent. If consent is the basis, the bank must follow the consent requirements under Section 6; where another lawful basis or exemption applies, consent may not be required for that particular processing activity.

In simple terms: Banks should not ask, “Do we have consent?” first.

They should ask, “Why are we processing this data, and what is the applicable legal basis?”

What Are the DPDP Consent Requirements for Banks?

Section 6 requires consent to be free, specific, informed, unconditional and unambiguous, given through clear affirmative action, and limited to personal data necessary for the specified purpose. For banks, these principles must work across branch forms, mobile apps, internet banking, call centres, lending journeys and partner integrations—not merely inside a single consent screen.

• Free Consent

  Consent must be a genuine choice, not a condition for an unrelated banking service.

• Specific Consent

  Consent must be for a specific purpose. Agreeing to loan processing does not mean agreeing to insurance, credit-card or partner marketing.

• Informed Consent

  Customers should know what data is collected and why it is being used.

• Unconditional Consent

  Consent cannot be used to impose conditions that override the customer’s rights.

• Unambiguous Consent

  The customer’s action must clearly show that they agree to the stated processing.

• Clear Affirmative Action

  Consent must involve a clear action, such as ticking a checkbox or selecting “I Agree.” Simply completing an application is not enough.

• Only Necessary Personal Data

  Consent should cover only data needed for the stated purpose.

What Must a Bank Include in a DPDP Consent Notice?

A bank's consent notice must explain the personal data being processed and the purpose clearly enough for the customer to provide specific and informed consent. Section 5 requires notice before or with a consent request, while Rule 3 requires an independently understandable notice, itemised data, specified purposes, applicable service or use details, withdrawal information, rights information and a complaint mechanism.

1. Itemised Personal Data

   Identify the categories or items of personal data involved—for example, identity information, account information, transaction information or financial information.

2. Specific Processing Purpose

   State why the bank needs the data. “Credit assessment for this loan application” is operationally clearer than “service improvement and other purposes.”

3. Service or Function Enabled

   Explain the banking service, function or use enabled by the processing. The customer should be able to connect the data request with the banking activity.

4. Withdrawal Method

   Provide a practical mechanism through which consent can be withdrawn. Rule 3 requires the ease of withdrawal to be comparable to the ease with which consent was given.

5. Data Principal Rights

   Tell the customer how applicable rights under the Act can be exercised by the data principals and provide the relevant communication route.

6. Complaint Mechanism

   Explain how the customer can make a complaint to the Data Protection Board through the mechanism prescribed by the bank.

7. Clear and Plain Language

   The notice must be independently understandable and written in clear and plain language.

8. Language Accessibility

   Section 5(3) requires the customer to have the option to access the notice in English or a language specified in the Eighth Schedule to the Constitution.

Where Does Consent Arise Across a Bank's Customer Lifecycle?

Consent can arise at multiple points across a bank’s customer lifecycle—not just at account opening. A bank may collect, access, analyse or share personal data for several different purposes within the same customer journey.

1. Account Opening & Video KYC

   Account opening is not one processing activity; it is a bundle of processing purposes. A bank may collect identity and contact information, perform KYC, conduct video-based identification, create the account and separately offer optional services. Each purpose should be mapped before the bank decides whether a consent request is required.

   Consent may arise when customers provide data during digital onboarding, particularly for optional uses beyond what is needed to open and operate the account.

   Example: X opens a bank account through Y Bank’s mobile app or website. To complete KYC, X chooses to undergo live video-based identification. Before collecting X’s personal data, Y Bank must provide a notice explaining what data it will collect and why it is needed.

2. KYC & Video KYC

   KYC should not automatically be treated as consent-based processing.

   For a bank, the KYC data map may include:

   • Identity information
   • Address information
   • Official documents
   • Customer photographs
   • Video-based identification
   • Identification metadata

   The important question is not simply “Did the customer consent to KYC?”

   The bank should identify what data is being processed, for what purpose, under which applicable legal basis, and what notice must accompany the processing?

3. Loan Applications & Credit Assessment

   A single loan application can involve credit-bureau information, income details, bank statements, GST or financial information, and sometimes additional digital data.

   The bank should be able to answer four questions for every data source:

   What data? → From whom? → For what purpose? → On what basis?

   Each data source should be linked to its specific purpose and applicable basis rather than being covered by one broad permission.

4. Account Aggregator & Financial Data Sharing

   Where personal financial information is shared through an Account Aggregator framework, the bank should be able to reconstruct what the customer authorised, for which purpose, what data was involved and how the sharing was handled.

   A practical consent record should capture:

   • Customer request
   • Consent artefact
   • FIP/FIU roles
   • Specified purpose
   • Data categories
   • Authorised duration
   • Withdrawal status
   • Downstream sharing

5. Marketing & Cross-Selling

   A customer may open a savings account and later receive offers for a credit card, insurance, investment product or partner service.

   Banks should maintain clear distinctions between:

   • Account/service processing
   • Product cross-selling
   • Partner marketing
   • Group-company marketing
   • Promotional communication
   • Personalised offers

   Where consent is the applicable basis, the consent should correspond to the relevant purpose rather than becoming a permanent “yes” attached to the customer's profile.

6. Profiling & Personalisation

   Banks may analyse transaction or behavioural data to create customer segments, generate personalised offers or recommend products. When such processing goes beyond what is necessary for the requested banking service, it creates an additional purpose that needs separate assessment.

   Ask: Is this profiling necessary to provide the requested banking service, or is it a secondary use of customer data?

   A bank should document the answer, the data categories involved, the model or process using the data, the applicable basis and the customer-facing explanation.

7. Fraud Detection, AML & Transaction Monitoring

   The DPDP Act provides legitimate uses and exemptions for certain regulatory, legal and offence-prevention activities, so consent is not automatically required for every fraud or AML activity.

   Relevant banking activities may include:

   • Transaction monitoring
   • Fraud detection
   • Suspicious transaction analysis
   • AML controls
   • Cybersecurity monitoring
   • Investigation of potentially unlawful activity

   The compliance question is therefore:

   Is the data being used for a permitted purpose, or is it being reused for something unrelated, such as marketing or profiling?

8. Payments & Digital Banking

   UPI, cards, mobile banking and internet banking involve continuous processing of transaction and authentication data, with device or location data potentially involved for certain purposes.

   The objective is not to obtain consent for every transaction, but to identify any additional processing that has a different purpose or basis.

9. Customer Service & Call Centres

   A customer calling to resolve a complaint may have the interaction recorded for service purposes. The bank may separately want to use those recordings for voice analytics, quality monitoring or AI-assisted analysis, creating potentially different processing purposes.

   Ask of each activity:

   • Is it necessary for service delivery?
   • Is it required by law or regulation?
   • Is it optional analytics use?
   • Is it being used for quality monitoring?
   • Is it being reused for profiling or another secondary purpose?

   The result should feed into the bank's purpose-and-basis inventory rather than being buried inside a generic “customer service” category.

10. Third-Party Vendors & Fintech Partners

    Customer data can move beyond the bank to KYC providers, credit bureaus, cloud platforms, fintechs, lending partners and other processors or Data Fiduciaries.

    DPDP Act Section 6(6) is particularly important where consent is the basis: after withdrawal, the Data Fiduciary must cease and cause its Data Processors to cease processing within a reasonable time unless processing without consent is required or authorised under the Act, Rules or another law.

11. Collections, Recovery & NPA Management

    Recovery activities can involve borrower and guarantor information, recovery agents, collection agencies and NPA-related data transfers. The DPDP Act Section 17 specifically provides for certain processing by a financial institution of the financial information, assets and liabilities of a person who has defaulted on a loan or advance, subject to the conditions in the provision.

    Do not turn “NPA” into a blanket exemption. Determine the precise processing activity, applicable provision, role of each entity and relevant sectoral requirements.

Is KYC Consent Enough to Market Other Banking Products?

No single KYC interaction should be treated as blanket permission for unrelated commercial purposes. KYC, account servicing, credit-card cross-selling, insurance marketing, investment recommendations, behavioural profiling and partner marketing can involve different purposes. Banks should therefore map each use separately and determine whether consent or another lawful basis applies.

The practical rule is:

KYC establishes or verifies the customer's identity for its applicable purpose.

It does not automatically become a universal permission slip for every future use of the customer's data.

How Should Banks Manage Consent Across Branches, Apps, Websites and Call Centres?

Consent management for banks must connect every customer-facing channel to a common evidence and propagation layer. A customer may give a preference in a branch, change it through mobile banking, interact through a call centre and receive communications through a third-party platform; the bank's architecture must preserve the relevant consent state across those touchpoints.

The architecture should prevent a familiar compliance failure: the customer withdraws consent in one system while another system continues behaving as if nothing happened.

What Happens When a Bank Customer Withdraws Consent?

Withdrawal should trigger an operational workflow, not merely change a database field from “Yes” to “No.” Where consent is the basis of processing, DPDP Section 6(4) gives the Data Principal the right to withdraw consent, and Section 6(6) requires the Data Fiduciary to cease and cause relevant Data Processors to cease processing within a reasonable time unless another legal basis permits or requires continued processing.

Bank-Specific Withdrawal Checklist

1. Stop the Relevant Processing

Identify exactly which purpose depended on the withdrawn consent. Do not stop unrelated processing that has another valid legal basis.

2. Stop Relevant Processor Activity

Send the withdrawal state to processors handling the affected purpose. Section 6(6) expressly places an obligation on the Data Fiduciary to cause relevant processors to cease processing, subject to the statutory exception.

3. Propagate Across Banking Systems

Update the relevant consent state across CRM, marketing platforms, digital channels and other systems connected to that purpose.

4. Stop Marketing Workflows

Remove the customer from applicable promotional journeys, campaign audiences and future communications that depend on the withdrawn consent.

5. Handle Third-Party Sharing

Identify whether the customer's data has been shared with another Data Fiduciary or processor and determine what action follows from the withdrawal and applicable legal basis.

6. Separate Withdrawal from Statutory Retention

Do not treat withdrawal as an instruction to erase every banking record. Section 8(7) expressly preserves retention where it is necessary for compliance with law.

Does Withdrawal of Consent Mean a Bank Must Delete the Customer's Data?

No. Withdrawal of consent does not automatically mean that a bank must delete every record relating to the customer. DPDP Act Section 8(7) requires erasure when consent is withdrawn or the specified purpose is no longer served, unless retention is necessary for compliance with law. The Act itself illustrates this with a bank retaining identity records after account closure where applicable banking law requires it.

This creates an important distinction:

Withdrawal of consent → stop the consent-based processing

Retention requirement → preserve data that another applicable law requires the bank to retain

The Act's own bank illustration describes a customer closing a savings account while the bank remains legally required to maintain identity records for ten years beyond account closure. The illustration therefore makes the principle explicit: retention required by another law can continue even when the original relationship has ended.

How Should Banks Maintain Evidence of Consent?

When consent is the basis of processing, banks should be able to reconstruct the consent event: what the customer was told, what purpose was authorised, what data was covered, when and where consent was given, and whether it was later withdrawn. Section 6(10) places the burden on the Data Fiduciary to prove that notice was given and consent was obtained in accordance with the Act and Rules.

1. Consent Record

   Capture the actual consent event. The bank should maintain an identifier linking the customer, purpose, consent status and relevant processing activity.

2. Notice Version

   Preserve the notice presented at the time of consent. A later version of the privacy notice should not silently replace the version that the customer actually saw.

3. Purpose

   Record the exact purpose authorised. “General banking” is operationally weak; a purpose such as “use of financial information for assessing this loan application” is more traceable.

4. Data Categories

   Record the personal-data categories covered by the consent. This allows the bank to distinguish permission relating to financial information from permission relating to marketing, device or other data.

5. Timestamp

   Record when consent was given or withdrawn. This creates a chronological evidence trail and allows the bank to establish which processing occurred before and after the consent event.

6. Collection Channel

   Record where consent was captured. The channel may be a branch, mobile application, internet banking, website, call centre or another approved banking interface.

7. Withdrawal History

   Do not overwrite the original consent state. Maintain the history of consent given, changed and withdrawn so the bank can reconstruct the lifecycle.

8. Processor / Third-Party Propagation

   Record the downstream action. If withdrawal affects a CRM provider, marketing platform, fintech partner or other processor, the bank should be able to demonstrate that the relevant status was communicated and actioned.

9. Audit Trail

   Make the evidence reconstructable. Section 6(10) makes this particularly important because the Data Fiduciary bears the burden of proving that notice and consent complied with the Act and Rules.

For banks, the practical lesson is straightforward: a consent dashboard is useful, but an evidence trail is what makes the dashboard defensible.

Conclusion

Consent under DPDP for banks is not a checkbox problem. It is an architecture problem.

A bank needs to connect the customer, purpose, data, legal basis, notice, consent event, system, processor, withdrawal and retention requirement into one traceable framework. That becomes particularly important when the same customer data travels from a branch or mobile application into lending systems, CRM platforms, analytics engines, fintech partners and processors.

The strongest compliance model is therefore to map the purpose. Determine the basis. Capture valid consent where required. Propagate the decision. Preserve the evidence. Retain only where justified.

Key Takeaways

• DPDP does not require consent for every banking activity; banks must first identify the purpose and applicable legal basis.
• Valid consent must be free, specific, informed, unambiguous and based on clear affirmative action.
• Consent can arise across multiple banking processes, from KYC and lending to marketing, profiling and data sharing.
• KYC or account-opening consent does not automatically cover unrelated uses such as marketing or cross-selling.
• Banks must make withdrawal easy and ensure it reaches relevant systems, processors and partners.
• Withdrawal does not automatically require deletion when data must be retained under applicable law.
• Banks need traceable consent records showing what was consented to, why, when, how, and whether it was withdrawn.

Related Blog

Liked the post? Share on:

FacebookWhatsAppLinkedInX