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 performs four core functions:
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 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.
Parallels with 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 and high consent change volumes.
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.
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.
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 corporate 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.
