In many of my recent discussions with experts on the role of “Consent manager” under DPDPA 2023, I have encountered a view that the role of a consent manager under DPDPA is similar to what is envisaged under the Data Empowerment and Protection Architecture (DEPA) which has been adopted by RBI in the Account Aggregator scheme.
With the advent of DPDPA 2023, there is a need to understand the differences and distinguish two types of consent managers one under DEPA and another under DPDPA.
MeitY is presently framing the rules, and it is possible that they may simply import the DEPA architecture of Consent Manager into the DPDPA.
However, we need to debate if this is desirable.
If both DEPA Consent Manager and DPDPA Consent Manager are similar, in my view we may be losing an opportunity to create a new genre of Data Fiduciaries which would enrich the Data Protection eco system in India and elsewhere.
It has been difficult to convince professionals that DPDPA is different and perhaps better than GDPR. In the sameway, it is difficult to convince people that Consent Manager under DPDPA can be different and better than the Consent Manager under the DEPA framework.
I will try to put up my arguments in this regard in this article but agree that more debate is required to accept that there can be an innovative way of implementing the “Consent Manager” system under DPDPA.
If however MeitY wants to give it a miss, and decide to adopt the DEPA architecture in full, we can only say, it would be disappointing.
The Consent Manager under DPDPA can be of great help in the Indian scenario since the data principals may be unable to appreciate the nuances of Privacy as a Right and can be easily manipulated by smart data fiduciaries to extract information which is not required for a given purpose.
The difficulties of consent fatigue and language can also be overcome with the Consent Manager system if it is structured not in the mould of how it is used in the Account Aggregators but in the mould of the “Certifying Authorities” in the Electronic Signature under ITA 2000 where a combination of a Certifying authority and a registration authority can effectively maintain close customer contact along with management of technical challenges.
In the DPDPA scenario there are thousands of data fiduciaries including mobile app providers who will be seeking consent from the data principals. The purposes for which the personal information is sought are relatively innumerable as compared to the AA scenario. Each Consent artefact under DPDPA would have to be therefore customized to the purpose and linked to a process.
A Data Fiduciary may not be able to obtain one consolidated Consent for all the purposes for which the personal data of an individual can be used. Such an effort would defeat the “Data Minimisation” and “Data Retention” principles of Privacy.
We must appreciate that a Data Fiduciary may use multiple processes in which personal data is processed and the purpose of processing may vary from purpose to purpose. In process A, he may be a Data Fiduciary with all the responsibilities of compliance under DPDPA. In another Process B he may be Data Processor and not have the responsibilities of a Data Fiduciary. In yet another Process C, he may be a Joint Data Fiduciary sharing the responsibilities with another data fiduciary. In a certain process he may be a Significant Data Fiduciary while in several other processes he may not have the processing of high volume of sensitive data that makes him liable as a “Significant Data Fiduciary” with additional obligations.
In a traditional approach, if any one process of an organization qualifies as an activity of a “Significant Data Fiduciary”, then the entire activity of the organization becomes a Significant Data Fiduciary (SDF).
The question we need to raise is ..
Is it necessary to define the role of an organization based on the single SDF activity or segregate the activities by process so that there could be a more efficient compliance.
It is for this reason that the consent artefact for DPDPA cannot be standardised as easily as it is being attempted in the Account Aggregator (AA) eco system.
The following diagram provides a rough indication of this “Process Centric Consent” required under DPDPA with different artefacts for different consents.
We must note that DEPA was envisioned before DPDPA 2023 came into existence and its objective was to enable smooth flow of information from the data provider to data requester. . DEPA was not created for protection of Privacy as per the law.
The objective of Consent Manager under DPDPA 2023 is however different. DPDPA applies only for digital personal data and the objective of “Consent Manager” under DPDPA is to establish a legal basis for processing as per Section of DPDPA 2023.
Section 6 of DPDPA 2023 states :
The consent given by the Data Principal shall be free, specific, informed, unconditional and unambiguous with a clear affirmative action, and shall signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose.
Each Consent in DPDPA is a contract and it is customised to a specific purpose.
The definition of “Consent Manager” as it evolves from Section 6 of DPDPA 2023 suggests that the MeitY may provide a detailed guideline on the consent manager in its rules to be notified. Going by the Act,
“The Consent Manager shall be accountable to the Data Principal and shall act on his/her behalf in such manner and subject to such obligations as may be prescribed and Every Consent Manager shall be registered with the Board in such manner and subject to such technical, operational, financial and other conditions as may be prescribed.”
The scheme under DEPA is a technology platform that empowers to seamlessly and securely access their data and share it with third party institutions. Design guidelines have been provided by RBI at sahamati.org.in calling “account Aggregators” as the “Future of Data Sharing”.
The above diagram released by Niti Ayog indicates that the information providers are institutions like the Banks, Insurance Providers or Taxation entities. It indicates that the information users request the information from the consent manager who gets a consent from the data principal the permission to request the information providing institutions and collect the required information from them and forward it to the information requesting entity.
This is the broad framework architecture provided. This framework has been designed to ensure that the “User” who is the data principal under DPDPA 2023 is able to provide consent whenever a request for data is submitted.
DEPA Objective is oriented towards the Data Users and not the Data Principals. While attempt can be made to fit DEPA framework to DPDPA, it would not be a perfect fit.
The RBI has come up with its own “Master Directions” for Account Aggregators which follows the DEPA.
I have tried to look at some of the terms of service and privacy policies posted by the 14 account aggregators mentioned in the sahamati.org in in website (Agya Technologies Private Limited, CAMS, Finvu, CDigio Internet, Finsec AA solutions, NADL, , Protean, Perfios, PhonePe, Tally, UnaCores, Yodlee) to understand how the registered account aggregators have implemented the guidelines from the DPDPA perspective.
Needless to say that the policies are yet to be updated, some additional points can be observed in the activities of these account aggregators.
The key aspect of the framework is what is the “Consent” artefact used by the consent manager to request permission from the user and where from the information is provided.
The consent artefact suggested by RBI includes the following information.
- identity of the customer and optional contact information;
- the nature of the financial information requested;
- purpose of collecting such information;
- the identity of the recipients of the information, if any;
- URL or other address to which notification needs to be sent every time the consent artefact is used to access information
- Consent creation date, expiry date, identity and signature/ digital signature of the Account Aggregator; and
- any other attribute as may be prescribed by the Bank.
This artefact indicates that it is a “Purpose oriented” consent and “recipient specific consent”. It means that as and when the request is received from a data requester, based on the purpose the consent should be obtained along with from whom the said information has to be collected.
The advantage of this approach is that the data principal keeps the control over the provision of consent with himself for each consent request.
However this appears to serve the purpose of only enabling automatic filling up of a consent request form and nothing else. It does not add any other value to the process and does not relieve the data principal from the burden of deciding about the different permissions sought.
A similar process is used by the E-Sign Certifying Authorities to receive E-KYC confirmation based on Aadhaar. Just to avoid the use of Aadhaar based information verification system, DEPA seems to have decided that information request goes through the Consent Manager. Otherwise a similar system of E-Aadhar information verification with a few additional fields to which the data provider can respond could have sufficed.
If “Virtual Aadhaar” is considered as “Not Aadhaar”, Supreme Court could have been requested to modify its order and allow use of “Virtual Adhaar” for the data subject to request for authentication cum provision of data to the data requester without the need of a DEPA Consent Manager.
In the AA system, the content of the data passes through the Consent Manager though he is not expected to store the same. Though the Consent Manager is not expected to view the data, the system envisages that the data provider sends a digitally signed set of data which has to be passed on to the data requester. Data therefore lands on the systems of the consent manager and technically there is access to the information by the consent manager.
While studying each of the Terms and Privacy Policies of different Account Aggregators would be a separate exercise, it appears that AAs may be retaining visibility to the personal data of the users and are not acting only as pure technical intermediaries. The RBI’s master directions for AAs also may be interpreted as providing a permission to the sharing of the user’s financial information provided by the providers to the aggregators and by the aggregators to the data requesters and in the process provide access to data to the consent managers,
Now that DPDPA is present as a law, and AA would be a data fiduciary, it would be better if the AA model of consent management is suitably modified and merged with the DPDPA model.
On the other hand, the DPDPA 2023 also has the option of adopting the Account Aggregator framework into its recommended consent manager rules and make the consent manager under DEPA just an intermediary under ITA 2000.
At present it appears that MeitY may yield to RBI and adopt the DEPA model of Consent Manager also as the DPDPA model.
I would like MeitY to take a different approach.
There is now an opportunity to define the DPDPA model of Consent Manager to provide a greater role to the consent manager than the AA model.
The data principals’ of DPDPA 2023 need the expertise of a “Consent Manager” to evaluate the different permission requests of data fiduciaries and provide guidance to the data principal on which of the permission requests to accept and which to reject. They can also provide some kind of checks on the data fiduciaries to ensure that they act responsibly. They can also provide support for withdrawal of consent if required.
In this system the consent manager can provide value added services such as de-identification, pseudonymization and anonymisation and filter the disclosure requests by evaluating the purpose of the request and putting its foot down when excess permissions are sought.
This will relieve the data principal from evaluating the consent permissions and take a decision on what is legitimate and what is not.
In my view this will be a necessary value addition to the service of the Consent Manager who will act as a trusted repository of personal data of its clients, white-list and black-list data fiduciaries on the basis of his expert evaluation of the privacy practices of the data fiduciaries (He may use such criteria as Data Trust Score, audit certifications etc for evaluation), watch the environmental scenario to observe changing profile of risks and initiate withdrawal of consent when required etc.
In case this suggestion can be debated further, we will be able to create an innovative business proposition which enables evolved entities to create a Privacy Secure Consent Manager services and bring a difference to the Indian data protection ec0system compared to the international standards of privacy management.
INVITE COMMENTS
Naavi
