Consent Management for Banks: A DPDPA Compliance Guide

Only 34.7% of financial-services respondents in EY’s 2026 survey had started their DPDP compliance journey.

Now consider one customer who has been with a bank for ten years.

They opened a savings account, took a loan, applied for a credit card, used mobile banking, and received marketing offers. Their data has moved through several systems along the way.

If that customer asks, “What have I consented to, and where is my data still being used based on that consent?” can the bank give a clear answer?

Under the DPDPA, that answer cannot be buried across old forms and disconnected systems. Banks relying on consent need to know the purpose it covers, keep proof of it, and act when it is withdrawn.

This guide explains what the DPDPA requires and how banks can manage consent across customer records, internal systems, and service providers.

TL;DR - What Banks Should Know Before the DPDPA Consent Rules Take Effect

• Do not ask for consent just because customer data is being processed. Under the DPDPA, consent is one route for processing personal data, not the route for every banking activity. Banks first need to identify why the data is being used and which provision allows that use.
• Account opening should not become permission for everything that happens later. A customer providing data for one banking purpose does not automatically give the bank permission to use it for unrelated marketing, cross-selling, profiling, or partner offers.
• DPDPA consent and RBI consent are not interchangeable. Digital lending, KYC, cross-selling, and Account Aggregator data sharing can have separate RBI requirements. A bank may therefore need to check both sets of rules for the same customer journey.
• A withdrawal is only useful if it reaches the places still using that consent. If a customer withdraws consent in one channel, the bank needs to identify the systems and relevant processors that still rely on it and stop the consent-based processing where required.
• The real test is whether the bank can prove the customer’s choice later. Where processing relies on consent, the bank should be able to show what the customer agreed to, the purpose it covered, and what happened when that choice changed or was withdrawn.
• 13 May 2027 is the date to work back from. Banks should use the remaining time to find broad, unclear, or disconnected consent records and fix the underlying process before the main DPDPA consent provisions take effect.

Why Is Consent Management a Challenge for Banks Under the DPDPA?

Banks have a difficult consent problem because of:

• Scale: Large Indian banks can serve 10-50+ crore customers, with consent records spread across different products and channels.
• Multiple touchpoints: Customer data can enter through branches, mobile apps, internet banking, ATMs, loan and credit card applications, call centres, and payment services.
• Large amounts of customer data: Banks process account details, PAN, Aadhaar information, transaction records, credit information, and contact details for different purposes.
• Third-party processing: Customer data may also be handled by credit bureaus, KYC providers, payment providers, cloud services, and IT vendors. The bank remains responsible for processing done on its behalf.
• Overlapping rules: RBI KYC rules can require certain records to be retained for at least five years, even when consent for another use of the data has been withdrawn.

DPDPA penalties can also reach ₹250 crore for certain contraventions. This makes it important for banks to know what a customer agreed to, which systems rely on that consent, and what needs to change when it is withdrawn.

When Do Banks Need Customer Consent Under the DPDPA?

Consent is not required every time a bank processes personal data.

Under Section 4 of the DPDPA, personal data can be processed for a lawful purpose based on consent or certain legitimate uses under Section 7. Section 17 also provides exemptions for specific types of processing.

For banks, the answer depends on why the data is being used.

A bank therefore should not treat one consent collected during account opening as permission for every later use of the customer's data.

For example, RBI rules specifically restrict the use of information collected for account opening for cross-selling or other purposes without the customer's express permission. Digital lending rules go further and require prior and explicit consent for data collected through digital lending apps.

Before collecting consent, the bank should first identify why the data is being processed and which provision permits that processing. Consent should be used where it is actually required, rather than as one blanket permission for the entire customer relationship.

What Are the DPDPA Consent Requirements for Banks?

When a bank relies on consent to process personal data, Section 6 of the DPDPA requires that consent be free, specific, informed, unconditional and unambiguous, with a clear affirmative action from the customer. Consent must also be limited to personal data necessary for the specified purpose.

A consent request must meet each of these conditions before a bank can rely on it for processing.

1. Consent Must Be Freely Given

Customers should have a genuine choice where the processing is optional.

For example, a bank should not make consent to receive insurance offers a condition for opening a savings account when those offers are not necessary for providing the account.

2. Consent Must Be for a Specific Purpose

The bank should clearly identify what the customer is agreeing to. Consent given for one purpose should not automatically cover another. A customer agreeing to the use of personal data for a loan application does not mean they have also agreed to credit-card, insurance, or partner marketing.

3. Customers Must Know What They Are Agreeing To

Customers need enough information to make an informed choice.

Before requesting consent, the bank should explain what personal data will be processed and why. The consent notice should also tell customers how they can withdraw consent, exercise their rights, and make a complaint.

4. Consent Must Be Unconditional

A consent request cannot require customers to give up rights provided to them under the DPDPA.

For example, a bank cannot make a customer agree that they will never withdraw their consent.

5. Consent Must Be Unambiguous

There should be no doubt that the customer agreed to the stated use of their personal data.

The consent request should make it clear what the customer is agreeing to instead of relying on vague or broad wording.

6. Customers Must Take a Clear Affirmative Action

Consent requires an action that clearly shows agreement.

For example, a customer could select an unchecked consent box or click an “I agree” button after seeing the consent request. Silence or inactivity should not be treated as consent.

7. Consent Must Cover Only the Personal Data Needed for the Purpose

Consent should be limited to personal data necessary for the specified purpose.

For example, if particular financial information is needed to assess a loan application, the consent request should not include unrelated personal data that is not needed for that assessment.

These requirements mean banks cannot rely on one broad consent to cover every future use of customer data. Where consent is the basis for processing, it should be tied to a specific purpose, the personal data needed for that purpose, and a clear action from the customer.

What RBI Consent Requirements Do Banks Need to Follow?

Banks cannot rely on the DPDPA alone when deciding where consent is needed. RBI also has consent rules for some banking activities. For example:

• During KYC, banks can collect the information required to verify the customer. If they want extra or optional information, RBI says they should get the customer’s explicit consent after the account is opened.
• For digital loans, data collected through the bank’s app or an LSP’s app must be need-based and collected with prior and explicit consent. The borrower must also be able to agree or refuse the use of specific data and revoke consent later.
• If personal information collected for digital lending is shared with a third party, the borrower’s explicit consent is required unless the sharing is required by law or regulation.
• When financial data is shared through an Account Aggregator, the customer must explicitly agree before the data is retrieved, shared, or transferred. The consent record must show what data is being requested, why it is needed, who will receive it, and when the consent expires.

So a bank may need to follow both the DPDPA and an RBI-specific consent rule for the same customer journey.

How Should Banks Manage Consent Across Different Channels?

A customer may give consent through one banking channel and withdraw it through another. For example, consent may be collected during a digital journey and later withdrawn through the bank’s app.

The bank needs to make sure that processing based on the withdrawn consent stops wherever that consent is being used.

RBI has additional rules for digital lending. Borrowers must be able to give or deny consent for specific data, restrict its disclosure, and revoke consent already given. RBI also requires prior and explicit consent for need-based data collection through digital lending apps.

How Can Banks Prepare for DPDPA Consent Compliance?

Banks have until 13 May 2027 before the main DPDPA consent rules take effect. They can use this time to fix the gaps in their current consent process.

Step 1: Review where consent is taken

Banks should go through account opening, loan and credit card applications, mobile banking, marketing, cross-selling, and other customer journeys where consent is collected.

Step 2: Check what each consent is for

A consent collected for one purpose should not automatically cover another. Banks should check which uses of customer data rely on consent and keep those consents tied to their stated purpose.

Step 3: Separate consent from mandatory banking work

KYC and other processing required under banking rules should not be mixed with optional consent for marketing or other uses of customer data.

Step 4: Keep proof of what the customer agreed to

The bank should be able to show what the customer agreed to and what notice was shown when the consent was given.

Step 5: Make withdrawal work across systems

If a customer withdraws consent, the bank should know which systems and service providers are still using that consent and make sure the relevant use stops where required.

What Should Banks Look for in DPDPA Consent Management Software?

A bank may collect consent through a branch, mobile app, loan journey, or marketing form. The software needs to keep those consent records usable even when the customer later changes or withdraws their choice.

When comparing consent management software, banks should look at:

• Purpose-based consent so each consent is tied to the specific purpose for which the customer gave it.
• Consent records that show what the customer agreed to, when they agreed, and the notice presented at the time.
• Withdrawal management so a change or withdrawal can be passed to the systems and processors that rely on that consent.
• Support across banking channels so consent collected through apps, websites, branches, and other customer journeys does not remain in separate records.
• Audit history so the bank can see when consent was given, changed, or withdrawn.
• Connections with existing systems such as CRM, customer apps, and other systems where consent status needs to be used.

These are the areas banks should check closely when comparing DPDPA consent management software.

How Can ConsentIQ by IQWorks Help Banks Manage DPDPA Consent?

ConsentIQ by IQWorks is a consent management platform for collecting consent, keeping evidence of it, and carrying the customer’s latest choice into connected systems. 

It records consent separately for each purpose and supports collection through web, mobile, email, and offline channels.

Here is where ConsentIQ can help banks.

• Purpose-level consent records keep different permissions separate. A bank can record a customer’s marketing consent separately from another optional purpose. The customer can agree to one purpose without agreeing to all of them.

• Cryptographic proof makes old consent records tamper-evident. ConsentIQ gives each record a cryptographic fingerprint and links records through a hash chain. If an old record is changed later, that change can be detected.

• Web, mobile and offline capture covers more than a cookie banner. Banks can collect consent through a hosted page, QR code, embedded form, web or mobile SDK, or REST API. This gives them options for adding consent to different customer journeys.

• CRM sync keeps marketing choices aligned with the consent record. ConsentIQ connects with Salesforce, HubSpot, Zoho CRM, Dynamics 365, Marketo, and LeadSquared. It matches customers using hashed email or phone details and writes the opt-in or opt-out decision back to the CRM.

• The preference center gives customers a place to change their choice. Customers can update or withdraw consent themselves, and ConsentIQ can pass the new choice to connected systems.

This means a bank can trace a customer’s consent from the purpose they agreed to through to a later change or withdrawal, without relying on separate records across each channel and CRM.

Conclusion

The DPDPA will require banks to take a closer look at how they collect and manage customer consent.

The first step is to understand where consent is actually needed. From there, banks need clear consent requests, reliable records, a simple way for customers to withdraw consent, and a process for carrying that change across the systems where their data is being used.

This is especially important for banks because DPDPA requirements sit alongside existing RBI rules. Getting the distinction right will help avoid collecting unnecessary consent or relying on consent where a different rule applies.

With the main DPDPA provisions taking effect on 13 May 2027, banks still have time to review their current consent process and fix the gaps.

If managing these records across different channels and systems is difficult, ConsentIQ by IQWorks can help banks manage consent from collection through withdrawal while keeping proof of each customer choice.

Frequently Asked Questions

1. What is consent management for banks?

Consent management is how a bank collects, records, updates, and withdraws customer consent when consent is the basis for processing personal data. It also helps the bank show what the customer agreed to and for which purpose.

2. Do banks need consent for all customer data under the DPDPA?

No. The DPDPA allows personal data to be processed based on consent or certain legitimate uses under Section 7, and Section 17 provides specific exemptions. Banks should first determine which provision permits the processing instead of asking for consent for every use of customer data.

3. What makes customer consent valid under the DPDPA?

Consent must be free, specific, informed, unconditional, and unambiguous, and it must involve clear affirmative action. It should also cover only the personal data necessary for the specified purpose.

4. Does withdrawing consent mean a bank must delete all customer data?

No. A bank may still need to keep certain records because of RBI requirements or other applicable laws. Withdrawal affects processing based on that consent; it does not automatically require every customer record to be deleted.

5. What happens when a bank customer withdraws consent?

The bank must stop processing that depends on the withdrawn consent within a reasonable time and cause relevant processors to stop as well. Processing that is required or permitted without consent may still continue.