“We Have Consent” Is Not Enough: The Consent Architecture Problem Under DPDP Act 2023

Every BFSI firm says they have consent. What they have is consent forms. The DPDP Act requires something architecturally different — verifiable, purpose-linked, withdrawal-trackable consent records. These are not the same thing, and most legal teams have not yet made the distinction.

Four consent requirements most firms fail

The DPDP Act §6 sets four requirements for valid consent. Most BFSI organisations believe they meet all four because they have consent forms. In practice, the gap between a consent form and a compliant consent record is where regulatory risk lives.

1. Purpose-specific consent

Consent must be specific to a stated purpose. A blanket consent clause in a KYC form that says "I consent to the processing of my personal data for all purposes related to account operations" does not satisfy this requirement. Each distinct processing purpose — credit scoring, marketing, third-party sharing, behavioural analytics — requires a separate, identifiable consent grant. The data principal must be able to consent to account operations without consenting to marketing, and the organisation must be able to demonstrate that distinction in its records.

2. Verifiable at any future point

The consent must be retrievable and verifiable months or years after it was given. A scanned form in a document management system is technically retrievable, but linking that scan to a specific processing activity, confirming exactly which purposes were consented to, and proving the version of the notice that was presented at the time — that requires structured data, not a PDF. When a regulator asks "show me the consent record for this customer's credit scoring," producing the original KYC form is not sufficient if the credit scoring consent was bundled into a general clause.

3. Withdrawal as easy as giving consent

Section 6(4) requires that withdrawing consent must be as easy as giving it. If consent was given by ticking a checkbox during digital onboarding, withdrawal must be achievable through a similarly simple digital action — not by visiting a branch, writing a letter, or calling a helpline. Most BFSI organisations have no withdrawal mechanism at all, or have one that requires significantly more effort than the original consent. This is a clear compliance gap.

4. Post-withdrawal processing cessation with deletion evidence

When consent is withdrawn, the organisation must cease processing for that purpose and — unless retention is required under another legal basis — delete the data. Critically, the organisation must be able to evidence that cessation and deletion occurred. "We stopped processing" without a timestamped record of when processing stopped and when data was deleted is not demonstrable compliance. The deletion evidence must be linked to the withdrawal event and the original consent record.

The onboarding form problem

The most common consent architecture failure in BFSI is what happens at customer onboarding. Consent is collected as part of the KYC process — typically a checkbox on a physical or digital form. That form is scanned or stored as a flat document. Three years later, a regulator or data principal asks for the consent record for a specific processing activity — say, the credit scoring model that determined the customer's loan eligibility.

The DPO cannot produce it. The consent was bundled into the KYC form. The KYC form is filed by customer ID, not by processing activity. The credit scoring activity is not linked to any specific consent event. The version of the privacy notice that was presented at the time of consent is not recorded. Whether the customer was given the option to consent to credit scoring separately from account operations is not documented.

This is not a theoretical risk. It is the standard state of consent management in most BFSI organisations today, and it is precisely the scenario that DPDP Act enforcement will test.

What a DPDP-compliant consent record looks like

A compliant consent record is not a document — it is a structured database record that captures the full lifecycle of a consent event. The minimum fields required to satisfy DPDP Act §6 and demonstrate compliance under audit are:

• Consent event ID: A unique, immutable identifier for this specific consent grant. Not the customer ID, not the form number — a dedicated identifier for this consent event that can be referenced across systems.
• Timestamp: The exact date and time consent was given, recorded in a tamper-evident format. This timestamp must survive system migrations and be independently verifiable.
• Specific purposes consented to: An enumerated list of processing purposes, each linked to the corresponding ROPA activity. "Account operations" is one purpose. "Credit scoring" is another. "Marketing communications" is a third. Each must be individually identifiable and individually withdrawable.
• Version of notice presented: The specific version of the privacy notice or consent notice that was shown to the data principal at the time of consent. If the notice changes after consent was given, the original version must be retrievable to prove what was actually consented to.
• Withdrawal status: Whether consent is currently active or has been withdrawn, with the timestamp of withdrawal if applicable. This field must be queryable — the DPO must be able to answer "is this customer's consent for credit scoring currently active?" without manual investigation.
• Links to processing activities: Direct references to the ROPA activities that this consent authorises. This is the link that transforms a consent form into a consent architecture — the ability to trace from a processing activity to its authorising consent event and back.

Building this architecture requires changes to onboarding systems, CRM platforms, and data governance tooling. It is not a compliance team project alone — it requires IT architecture involvement to create the structured data layer that consent management demands.

Legitimate interests as an alternative basis

Not every processing activity requires consent. The DPDP Act recognises several alternative legal bases: legal obligation, vital interests, and public interest. For BFSI organisations, the most relevant alternative is processing required under other laws — AML/KYC requirements under the Prevention of Money Laundering Act, credit bureau reporting obligations, and regulatory reporting mandated by RBI, SEBI, or IRDAI.

The practical implication is significant: if your legal basis for processing KYC data is a legal obligation under the PML Act, you do not need consent for that specific processing activity. You still need a notice (§5), you still need to document the legal basis in your ROPA, and you still need to implement appropriate safeguards — but the consent management burden for that activity is eliminated.

Most BFSI legal teams default to consent for everything because it feels safest. In practice, this creates unnecessary risk: consent can be withdrawn, and if your legal basis is consent rather than legal obligation, withdrawal forces you to stop processing — even for regulatory-mandated activities. Mapping each processing activity to the correct legal basis is not just a compliance exercise; it is a risk management decision that determines whether a single customer withdrawal can disrupt your regulatory obligations.

The recommended approach is to audit every ROPA activity and assign the most appropriate legal basis: legal obligation where statute requires the processing, contract performance where the processing is necessary to deliver a contracted service, and consent only where no other basis applies. This mapping should be documented in the ROPA with specific statutory references for each legal obligation claim.