The idea of a “Consent Manager” – with the lack of footnotes or rationale explaining the framework – is ripe for critical evaluation. This review does not intend to undermine the efforts involved in formulating these regulations but rather seeks to highlight potential practical challenges in their implementation (as the way I have interpreted the law, and could differ from your own views). As next steps before the dpdp rules are fully formulated and published, it may be beneficial to consider alternative perspectives or, if necessary, propose a revised framework that better addresses the needs of Data Principals and Data Fiduciaries with respect to consent management. I do not intent to cover such a framework in this article but would be happy to be part of any policy think-tank to share my thoughts.
But first let’s look at the definition as given in the DPDP Act 2023:
“Consent Manager” means a person registered with the Board, who acts as a single point of contact to enable a Data Principal to give, manage, review and withdraw her consent through an accessible, transparent and interoperable platform;
A ‘person’ is defined as an individual, a Hindu undivided family, a company, a firm, an association of persons or a body of individuals, whether incorporated or not, the state, every artificial juristic person, not falling within any of the preceding sub-clauses;
‘Board’ means the Data Protection Board of India established by the Central Government under section 18;
“Data Principal” means the individual to whom the personal data relates and where such individual is – (i) a child, includes the parents or lawful guardian of such a child; (ii) a person with disability, includes her lawful guardian, acting on her behalf;
‘Consent’ has not been defined separately, but it is well articulated throughout the Act regarding its form and function.
‘Platform’ has not been defined in the act so is interpreted as a digital or software application.
When listening to a complex musical composition without sheet music, tabs, or composer’s notes and foot notes, the listener has to unravel the mystery, aura, and beauty of the piece, making sense of the melody and the reasoning behind the arrangement of the notes and interludes (those who are ardent music learners can relate this analogy). Similarly, when I first read about ‘Consent Manager’, my initial thought was toward the diverse nature of our country and the services we sign up to – some impulsively and others for specific needs. As an individual, if I have signed up with hundreds of businesses (Data Fiduciaries) over time, it would be nearly impossible to keep track of all of them. If I need to make changes, I would have to update each one individually, first identifying who they are, a task made even more challenging by name changes, mergers, and acquisitions over time. In this context, it would be incredibly useful to sign up for a Consent Manager (an App is what I thought of initially) that consolidates all the fiduciaries I have engaged with, allowing me to instruct the app to make changes as and when I needed.
But herein lies the difficulty. Let’s set aside, for a moment, the challenges of creating an interoperable platform and assume that one is developed within the shortest possible timeframe mandated by the authorities to meet compliance requirements. From the perspective of the Data Principal, the first hurdle is finding a Consent Manager (or a Consent Manager App) that has integrated all the fiduciaries I have signed up with – and those I may want to engage with in the future. This means I need to research Consent Managers to determine if they are even useful for my needs.
Even if I find one, there’s no guarantee that the fiduciaries will continue using the same Consent Managers over time. Much like merchants switching between e-commerce platforms, both fiduciaries and principals may want to move to different platforms as they see fit. If I have no control over this, I might end up having to sign up with multiple Consent Managers. In such a scenario, the original purpose is defeated entirely. Instead of searching for different fiduciaries, I would now have to search for different Consent Managers to exercise my rights.
The law refers to an “accessible, transparent, and interoperable platform” as though it were a public good already available for use, much like UPI. However, it fails to account for the cost of developing such a platform in a country like India, as well as the economic impact (slowing down onboarding and adding friction and litigation to an already burdensome process) and complexity (lost time due to tech issues, frustration and middlemen who will have certain control without accountability or care) it could introduce into our daily lives.
That said, let’s consider this from the perspective of a Consent Manager. The Consent Manager must integrate all Fiduciaries to be of any value to a large populace. While there are millions of fiduciaries, let’s simplify this by focusing only on listed companies – a quick Google search suggests there are approximately 7,500 as of 2024. The Consent Manager must establish an interoperable platform with a standardized protocol that allows all fiduciaries to integrate seamlessly. Now, imagine there are hundreds of Consent Managers. In this scenario, each fiduciary would need to integrate with all of them, as there are no super aggregators to consolidate data from one Consent Manager and share it with others (unlike CKYC, which operates through CERSAI and allows change propagation through KRAs). Developing such a system would require millions in investment and several years to perfect.
Now, let’s assume someone with significant resources creates an interoperable platform. This could lead to a monopoly situation, which would likely prompt regulatory intervention. To avoid this, let’s imagine there are three or four such platforms in the market – similar to the telecom sector. Over time, more rules would follow, particularly around portability and other operational aspects, which could result in Consent Managers becoming more heavily regulated than the Data Fiduciaries themselves. And an entire law or act has to be brought into make Consent Managers accountable.
There is also another question on how Consent Managers will monetise their service. In essence, who will pay for using the Consent Manager? Will it be the Data Principal (for ease of use) or Data Fiduciary (for offloading some of the liability and keeping the entire DPDA compliance light with a small team). For sake of argument, let’s say I want to sign up with a Consent Manager and the Consent Manager is going to charge me a subscription to hold on to my data and manage my consents. What happens if I accidentally stop the subscription (say credit card has expired)? Will all my data be deleted. And what happens to all of the consents that I have already given to Data Fiduciaries? Is there way to now approach the Fiduciary directly to manage them. In such cases, how does the Consent Manager transfer over the data to multiple Fiduciaries with whom I have shared my data and consent in the past.
To some extent, this can be compared to food delivery platforms like Swiggy and Zomato. These platforms integrate a vast range of stores and restaurants and charge a platform fee along with a delivery fee, which can range anywhere from 25% to 35% of the restaurant’s listed price. As a result, customers end up paying for convenience and restaurants end up paying to be discovered and removing overheads such as ordering, payments, and delivery. In the case of a Consent Manager platform, would I be willing to pay such a significant fee when I could access the same service directly from a fiduciary for free? Consider this: Imagine a plate of sandwich costs INR 100 on a restaurant’s menu. When ordered through a food delivery app, the price might rise to INR 150 + 20 for delivery (as restaurants often add the platform fee of 30% to the product cost which is passed on to the customer). However, if I call the restaurant directly and order the same sandwich for delivery at INR 100 + 20 delivery, the platforms would lose their appeal.
Similarly, if Data Principals have the option to sign up directly with Data Fiduciaries for free, they would likely choose that route. To further stifle the business model of Consent Managers, the DPDPA rules could include annual reminders from Data Fiduciaries, prompting Data Principals to review and update their preferences. These reminders could include direct links to privacy settings, making it even easier for users to manage their data and consents without relying on Consent Managers.
There is a strong school of thought that connects the possible origin of Consent Managers to that of Account Aggregators, which is architected based on DEPA (published in 2020). This in itself is not a novel idea as it has already been well established in countries like US with private players like Plaid. I believe this idea comes closest to the concept of a Consent Manager, as Account Aggregators also serve as intermediaries, connecting consumers with financial institutions through explicit consent to access financial information. Additionally, the DPDP rules and the illustrations cited in Part B of the First Schedule closely mimic the Account Aggregator model, almost like-for-like as presented in DEPA. Advocates of this idea (although the law or the rules don’t mention anything about monetisation) also propose a monetisation model similar to that of Account Aggregators. However, there is a world of difference between the two.
Account Aggregators solve a real problem (financial inclusion and real-time credit worthiness assessment), whereas Consent Managers do not – in fact, they introduce an additional layer of friction (thinking through the best interest of the data principal versus the needs of the data fiduciary). Account Aggregators enable customers to share their financial data with service providers (e.g. a lending company), allowing it to be processed for instant lending decision without the need for submitting paper statements or waiting for days. That said, this does not negate the KYC process, which is still handled directly by Data Fiduciaries. For obtaining KYC, the Data Fiduciary must present the consent notice at the point of onboarding, as per Sections 5(1) and 6(1) of the DPDP Act 2023. This notice could also include consent for obtaining data through an Account Aggregator if the customer so chooses at the point of onboarding negating the need for another consent layer.
Let’s for a second see how the AA framework works. Let’s say you sign up with Bank A for a loan and that Bank A is requesting for details from your Salary Account, say Bank B. Bank A will now initiate a data request through an AA. The AA sends you a consent request via its App. You provide your consent for the data sharing to happen from Bank B to Bank A facilitated through the Account Aggregator. One key thing to note is that you must also be signed up with an Account Aggregator to make this process happen. Now the consent is for ‘sharing’ data between parties and not for ‘onboarding’ for which all parties here Bank A, Bank B and AA will need your person data + consent to be presented to get you on board. Along with your financial details, ‘if’ [I am adding emphasis on if] the law also allows you to share your KYC with Bank A (which I have already provided to Bank B), then it will be a lot more useful function as I don’t have to go through KYC again and the whole process can be quick and easy. In such scenarios the Account Aggregators are in a far better place to become Consent Managers as originally desired by DEPA architecture. I am not quite sure this is the case as Master KYC regulations from RBI require the Data Fiduciaries (e.g. Banks) to obtain KYC directly for each new service obtained by the Customer (the rules are slightly different for SEBI regulated intermediaries who use the KRAs for sharing KYC data but will leave out for this discussion).
Aside, Account Aggregators operate under heavy regulation, making it financially less viable for aspiring entrepreneurs to become Consent Managers. There are only 16 Account Aggregators serving a population of over a billion, and some have already surrendered their licenses – the latest being PhonePe, which cited “its inability to onboard as many Financial Information Providers (FIPs) as it would have liked.” This is particularly significant, given that PhonePe’s app is used by over 550 million and backed by Walmart. Now, imagine the challenges Consent Managers would face in trying to work with banks to integrate into their platforms – it would be anything but fun. Even a public – private partnership such as Sahamati building out the interoperable rails and private players building Apps on top may not be enough to counter the complexity in integrating thousands of fiduciaries and service billions of customers in a frictionless manner. We should innovate to remove friction, not add more. And it may take a decade or more to get there just the way the law is portrayed at the moment.
However, much like the way Account Aggregators facilitate the sharing of financial data (as illustrated in Part B of the First Schedule of the DPDP rules), Consent Manager Platforms could serve as a useful tool in the health and insurance sectors. For instance, they could enable individuals to securely share their health data – such as X-rays, MRIs, blood reports, or discharge summaries – stored in one hospital with another hospital. Alternatively, this data could be shared with insurance companies to streamline claims processing or even reduce premiums for maintaining good health. This could lead to the emergence of specialised Consent Manager Apps focused solely on specific sectors, such as healthcare. These apps could integrate all hospitals in India or connect hospitals with health insurance companies. In fact, I think the ABHA App by the National Health Authority already accomplishes some, if not most, of this functionality. The broader idea is that one or more such Consent Managers could evolve into major platforms, facilitating a wide range of data-sharing scenarios that require explicit consent at the point of data transfer. For this, I believe, the Account Aggregators themselves can evolve to fill this gap once the customer is onboarded and require a new consent for a new purpose.
A Consent Manager acting merely as an agent or advisor in an individual capacity (similar to a concierge service) would be ineffective without a sophisticated platform to support its operations. This limitation excludes many small companies or seasoned auditors who aspire to become Consent Managers but lack the resources to develop or maintain such platforms. Unlike the insurance agent model, which operates without the need for advanced technological infrastructure and caters to specific segments of the population, Consent Managers require robust systems to provide personalized services effectively. Without these systems, their ability to manage consents at scale and meet regulatory requirements is severely constrained.
Finally, let’s look at this from the perspective of Data Fiduciary. As we’ve seen earlier, the customer has the choice to interact directly with the Data Fiduciary or through a Consent Manager (the law does not mandate that the Data Principal should go through a Consent Manager). In most cases, the customer is likely to choose the option that incurs no cost and aligns with an entity they already trust to share their personal details and provide consent.
For the Data Fiduciary, however, there are no significant cost savings or perceived value in relying solely on Consent Managers. This is because DPDP compliance extends far beyond just managing consents – it encompasses a wide range of policies, processes, and systems that are intertwined with consent management, and therefore, will need to invest in their own Consent Management Platform. Additionally, allowing multiple Consent Managers to integrate adds extra costs, especially if customers decide to use both direct and Consent Manager routes (as nothing prevents them from doing so). It will, at best, best be treated as a nice to have rather than a must have function for Data Fiduciaries. Moreover, the DPDP Act and the Rules (Registration and Obligations of Consent Managers) do not assign additional responsibilities to Consent Managers, such as handling disputes, processing activities, data subject requests, or grievances. These responsibilities remain within the ambit of the Data Fiduciary, further necessitating their own consent management platform.
As a footnote on the evolving technology landscape, reasoning AI agents are just around the corner. These agents will be capable of handling mundane tasks such as searching, ordering, and paying for services – think booking flights or ordering food. It’s only a matter of time before they extend into financial services, where managing consents for personally identifiable information and data sharing could be seamlessly handled by personal AI agents. These agents could integrate directly with platforms like Aadhaar or DigiLocker, or even interact with Data Fiduciaries independently, potentially rendering Consent Manager Platforms obsolete.The future of consent management may well rest in the hands of intelligent, autonomous agents that operate on our behalf, under our oversight. This possibility should not be dismissed outright.
Finally, the ultimate goal of the DPDP law should be to build trust between Data Fiduciaries and Data Principals, fostering interactions that drive economic growth – a mere compliance for sake of compliance is simply a burden for the entire nation and we cannot afford one at this time. For instance, let’s say I have an insurance policy and would like to compare it to find a better deal – perhaps because my current provider offers poor service. If I trust that a platform will not misuse my data, I would be more likely to sign up to compare my current policy with other options available in the market. Once I find a better deal, I can switch to a new provider while ensuring my current provider does not misuse my data. And with consent, I can also share my previous insurance claims (or no claims) history with the new one to obtain a better deal and share my KYC through Aadhaar or Digi Locker. This cycle of trust and transparency can continue, encouraging market participation and importantly removing friction for consumers.
Without such trust, the fear of data abuse – such as data being sold without consent or my data profiled and sold to advertisers indiscriminately – can discourage people from engaging in the economy in any meaningful way. This often leads to individuals either withdrawing from the marketplace or settling for subpar services from their current providers, stifling innovation. To move toward a thriving economy, we need to prioritize market participation, where trust plays a pivotal role in driving growth. While compliance may involve short-term challenges, the long-term benefits – such as improved economic activity and a culture of innovation and above all ‘digital trust’ – are well worth the effort.
And does the DPDPA Consent Manager (in its current form) lead us toward this goal?
References:
https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
https://www.meity.gov.in/writereaddata/files/259889.pdf
https://www.niti.gov.in/sites/default/files/2023-03/Data-Empowerment-and-Protection-Architecture-A-Secure-Consent-Based.pdf
https://www.naavi.org/wp/why-should-the-role-of-consent-manager-be-restricted/
https://sahamati.org.in/what-is-account-aggregator/
https://www.business-standard.com/companies/news/phonepe-to-wind-down-account-aggregator-business-surrender-nbfc-aa-licence-125020701145_1.html
https://financialservices.gov.in/beta/en/account-aggregator-framework
https://sahamati.org.in/account-aggregators-in-india/
About the author: Shankar is the founder and ceo of FRSLABS.
