The Consent Manager is the most uniquely Indian element of the DPDP Act.
No other major data protection regime has the equivalent, a regulated intermediary that lets Data Principals manage consents across multiple Data Fiduciaries through a single interface.
The concept is borrowed from the Account Aggregator framework that has been running in Indian BFSI since 2021, and which has now successfully demonstrated that India can build consent-driven data infrastructure at population scale.
For Indian enterprises building DPDP-compliant data architectures, understanding the Consent Manager is essential, both for organisations that will integrate with it directly, and for those whose architectures need to anticipate its role.
What a Consent Manager actually does
Functionally, a Consent Manager is a Data-Principal-facing service that does four things.
1. Issues and stores consent artefacts
When a Data Principal grants consent for a Data Fiduciary to process their data, the Consent Manager records the consent, what was granted, for what purpose, with what scope, with what expiry, in what language, with what evidence of affirmative action. The record is the consent artefact.
2. Presents a unified view of consents across providers
Data Principals can see, in one place, every consent they have granted, to their bank, their insurer, their healthcare provider, their telecom operator, their digital service providers, without having to log into each Data Fiduciary individually.
3. Handles consent withdrawal and propagation
When a Data Principal withdraws consent through the Consent Manager, the withdrawal propagates to the relevant Data Fiduciary. The Data Fiduciary is then required to honour the withdrawal across its systems within defined timelines.
4. Generates audit trails
Every consent grant, modification, and withdrawal generates an audit record. Data Fiduciaries can demonstrate to regulators that they processed personal data only with valid consent, and that they honoured withdrawals.
How it parallels, and extends, the Account Aggregator framework
The Account Aggregator framework operationalised consent-based data sharing in Indian BFSI. A customer who wants to share their bank account data with a lender for credit underwriting can authorise the sharing through an AA, and the AA mediates the data flow, ensuring the customer remains in control.
The Consent Manager under DPDP extends this pattern across all sectors and all personal data, not just financial data, not just BFSI. The token-based consent artefacts, the structured purpose codes, the API patterns for grant and withdrawal, these technical patterns are recognisable to anyone who has integrated with the AA framework.
For enterprises that have already built FIU (Financial Information User) integrations under AA, the engineering investment for Consent Manager integration will be substantially smaller. The mental model is the same; the protocols extend rather than replace.
Three architectural patterns for integration
Pattern 1, Direct integration
The Data Fiduciary integrates directly with Consent Manager APIs, treating the Consent Manager as the source of truth for consent state. Every processing operation checks consent through the Consent Manager. Withdrawal events arrive through Consent Manager webhooks.
Suitable for, large enterprises with engineering capacity, organisations with high consent change volumes, organisations seeking the cleanest separation between consent state and data state.
Pattern 2, Cached consent with periodic sync
The Data Fiduciary maintains a local cache of current consent state, synced periodically from the Consent Manager. Processing operations check the local cache. The cache is updated on a defined frequency or in response to withdrawal events.
Suitable for, high-throughput processing environments where round-tripping every check to the Consent Manager would create latency, with appropriate freshness guarantees and propagation SLAs documented.
Pattern 3, Federated consent architecture
Larger groups with multiple legal entities (e.g., a banking group with the bank, the insurance arm, the AMC) use a federated architecture, entities maintain their own consent records, with a shared identifier layer that connects records when the Data Principal grants consent to multiple entities. Each entity integrates with the Consent Manager for its own consents.
Suitable for, multi-entity Indian groups, particularly those with regulatory boundaries between entities that prevent unified consent stores.
Common implementation pitfalls
● Treating Consent Manager as a UI rather than as architectural infrastructure, leading to consent state diverging between the UI and the data systems
● Caching consent without clear freshness SLAs, leading to processing on stale (withdrawn) consents and regulatory exposure
● Failing to propagate withdrawals to downstream systems, particularly to analytics, AI training stores, and partner systems
● Building consent UX in English-only when the Act requires the chosen language of the Data Principal, Hindi and regional languages at minimum
● Confusing consent for one purpose with consent for another, treating service-delivery consent as covering AI training, marketing, or third-party sharing
● Underestimating the cross-entity complexity when the Data Principal is a customer of multiple entities in the same group
The shift to make
Stop treating consent as a checkbox at the start of a customer journey.
Start treating it as living architectural state, granted with specificity, propagated across systems, withdrawn cleanly, audited continuously. The Consent Manager is the regulated intermediary that makes this possible at population scale in India, building on the lessons of the Account Aggregator framework and extending them across every sector.
Indian enterprises that get Consent Manager integration right gain a structural advantage, they can demonstrate compliance with the highest standard, and they can build new customer-facing products that lean into consent transparency as a feature rather than treating it as friction.
