The MeitY is now trying to finalize the rules under DPDPA 2023. From the indications now available, the ministry is trying to release a complete set of 25/26 rules rolled into one notification.
In the last couple of days we have discussed Why Not the Consent Manager under DPDPA be different from Consent Manager under DEPA.
Similar Why Not? questions will be raised in this series of articles so that some thoughts can be implanted in the minds of the rule makers so that they may consider them in the draft rules to be released for public comments or enable a discussion on the same.
It is noted that the MeitY is under closed door discussion with industry so that there is a prior approval of the rules from them.
It is noted that the “Data Sovereignty” principle of Cross Border restriction on data transfer which was present in the earlier drafts has been diluted. Similarly Section 9(5) was perhaps introduced at the behest of FaceBook that the restrictions on parental consent should be relaxed for children below the age of 18 upto the age of 12/13.
Now the delay in the issue of rules is perhaps influeced by the fact that there is no consensus on some of the aspects of the rules..
Hence we are trying to put up some suggestions in the “Why Not Series” so that a record is created that these issues were raised whether they are accepted or not.
The discussion on “Why Not the Consent Manager under DPDPA be different from the Consent Manager under Account aggregator/DEPA scheme was also in this direction.
We shall raise more such “Why Not” questions in the next days till the rules are finally notified after public debate.
I invite professionals to actively participate in this debate. Some of the good practices that come forth here would be also incorporated in the DGPSI implementation recommendations so that the DGPSI framework becomes “A Voice of the Data Protection Professionals”.
One of the major issues of AAs (Account Aggregators) is the need to ensure the strict following of the “Fit and Proper” criteria to ensure that the valuable personal data that may come into the hands of the AA from the Banks is not used in contravention of DPDPA.
While the RBI is responsible to check the “Fit and Proper” criteria at the time of providing provisional license, REBiT is responsible for ensuring that the technology platform is set up as per the RBI directives. In the coming days the system needs to be compliant also with DPDPA.
We are not aware that RBI and REBiT are taking adequate steps to ensure that personal data of the Indian public which may be accessed by AAs are adequately secured from the perspective of Data Privacy.
There is also a distinct possibility that the “Fit and Proper” adherence of an organisation may change after the licensing. Hence it has to be followed up at periodical intervals and monitored continuously.
We may recall the experience with CIBIL which started as a trusted organization of Indian Banks and once it accumulated nearly 500 million data sets of Indian Bank customers, quietly sold itself to a US private company. Who benefitted in this multi billion dollar deal remains a mystery which even the ED has ignored.
There is already an attempt by some US based tech companies to enter themselves into NPCI and it is not known how successful they have been at present. If they are accommodated like TransUnion was, in the original CIBIL capital structure, they will eventually take over NPCI control. We should remember the famous story of the Arabian Camel getting into the tent and guard against it.
Similar possibility exists in the AA system and the risk of inadequate fitness at the time of licensing and change in the “Fit and Proper” criteria after licensing as well as change in the “Security posture” after REBiT audit needs to be flagged and countered.
Presently there is no publicly accessible report about the licensed AAs and how RBI documented the “Fit and Proper” criteria or recorded the technology audit.
We donot see the AAs subjecting themselves to the “Right to Information Act” and provide for any information disclosure on their websites.
Some quick observations indicate:
Anumati ownership has already changed hands from Agya Technologies Pvt Ltd to Perfios AA pvt Ltd.
CAMS FinServ grievance redressal page does not seem to work.
Finvu has a Grievance redressal officer contact but no DPO at present. The escalation of the grievance is to RBI which needs to change if DPB becomes the authority under law.
CRIF CONNECT is a company with parentage in Italy and operates in data analytics indicating the potential conflict.
Privacy Policies of all the companies are not in compliance with DPDPA 2023 and some are not even updated after August 11th 2023 nor even under the CERT In guidelines.
Owners of Saafe seem to have co-interest in some FUPs .
I am sure that if I go through with all the 14+3 entities listed by RBI, every one of them may have some conflicting interest, lack of compliance to ITA 2000 or insufficient disclosure.
The system of AA licensing may be under equipped to meet the requirements of DPDPA 2023.
We are not aware if Meity will consider the sensitivity of information gathered by AAs as a criteria to classify them as Significant Data Fiduciaries when the rules are finalized. We have a feeling that the “Consent Manager” rules to be notified by MeitY can be a repetition of the RBI rules for AAs and hence all AAs will automatically be also recognized as Consent Managers.
Will Meity ignore the deficiencies in the AA licensing system and let AAs be completely under the sectoral regulation or subject them to the rigours of Significant Data Fiduciaries?
Let us wait and watch. If MeitY cannot resolve these turf related issues, they may chose not to release the draft rules and let things drift. We also need to watch whether the DPB does not get infiltrated with vested business interests.
Naavi
PS: It appears that more I look at the way AAs are being regulated now, I will be mentally disturbed. So I am stopping further exploration on this issue for some time. Assuming that RBI as well as the AA s are aware that there is now a law to catch up with and some body to watch what they are doing, we hope that they will take corrective steps themselves asap.
We may therefore wait and pray that responsible actions will be initiated by RBI soon. For the time being until the Ram Mandir in Ayodhya is inaugurated, Naavi.org would prefer not to raise such issues. Let us all spend time in saying Jai Shriram.
RBI has been a powerful sectoral regulator and has assumed leadership for regulating the entire financial sector including the FinTech companies. In the process, some of its regulations clash with the implementation of DPDPA 2023. It would be interesting to know how MeitY will proceed in the framing of rules regarding “Consent Manager” which has a direct conflict with the Account Aggregator licensing system that RBI has introduced and the Cross Border transfer of data.
Just as overlapping regulations between CERT-In and DPB affect Data Breach Notification, RBI regulations on Account aggregators have overlapping effect on the “Consent Manager” concept as well as the Data Fiduciary concept.
Account Aggregators are a category of licensed bodies from RBI as per the Master Directions of 2016. They may be referred to as NBFC-AAs by RBI. The list of NBFC-AA s licensed by RBI is not easily accessed on the RBI website. As of 30th October 2023, RBI website records that there are 12 registered AAs . However Sahamati.org.in lists the following AAs as of date.
RBI in its Master Direction of 2016 has indicated certain criteria for registration of an entity as an Account Aggregator and obtain the Certificate of Registration.
Various conditions prescribed in the Master Directions include the following.
Entity must be a NBFC, registered as a “Company” with a net owned funds of a minimum of Rs 2 crores. (Registration under SEBI, IRDAI and PFRDA and restricting its activities to the sector is excluded from registration with RBI)
Initially an In-Principle approval would be provided and needs to be converted to a full registration within 12 months after setting up the technology platform.
Account Aggregator shall not undertake any other business other than the business of account aggregator. Deployment of investible surplus by an Account Aggregator in instruments, not for trading, shall however be permitted.
No financial asset related customer information pulled out by the Account Aggregator from the financial service providers should reside with the Account Aggregator.
Appropriate agreements are to be entered into between the AA and the customer.
The entity shall satisfy the “Fit” and “Proper” criteria for the proposed/existing directors
RBI has delegated the authority for managing the required architecture to REBiT. The technology architecture could be subject to an audit by REBiT
The NBFC-AA is envisaged to be a “Data Gateway” between a “FIU” or Financial Information User who needs certain financial information about an individual and one or more “FIP” s (Financial Information Providers” who may have that information .
Normally the individual (prospective client of the FIU) has to fetch the information from FIPs and provide it to the FIU. AA system tries to provide an alternative for a data exchange system which helps the Data Owner who is a customer of the AA and FIP and a prospective customer of the FIU.
In order to simplify this process, the Account Aggregator (AA) provides his service to the individual (Customer of AA). If the individual has an account with an AA, the information required by FIU can be re-directed to AA who in turn will fetch it from the FIP and provide it to the FIU. This entire mechanism needs to have a “Consent” framework which has been defined under the scheme.
The customer of an AA can be an individual or a non-individual. The Financial assets maintained by FIPs may therefore be personal or non personal information and FIUs may request for both types of information.
Where the requested information is related to an individual, the information becomes personal information under DPDPA 2023 and therefore needs to be compliant with the DPDPA 2023 requirements.
The RBI master direction has set a “Consent Artefact” as a standard format in which information has to be collected by the FIU from the Customer. This being a standard format can facilitate the data flow through the different participants such as the FIU, AA and the FIP.
The DPDPA is recognizing “Consent Manager” as a special kind of Data Fiduciary with all the obligations under DPDPA 2023 and the corresponding penalty possibilities. The legal basis for processing any personal data under DPDPA 2023 is “Consent” and hence there is a direct link between what a Consent Manager under DPDPA does and what the Consent Artefact under the AA framework represents.
We are yet to know the criteria to be fixed by MeitY for the Consent Managers under DPDPA 2023. It is presumed that there is already some pressure being brought upon Meity that all the entities already registered as Account Aggregators are to be considered as registered Consent Managers under DPDPA 2023.
The objective of our discussions is to debate if the activity of AA conform to the Consent Manager’s duties under DPDPA 2023 and whether the two services are similar. In the process we may be pointing out why the current functions of AAs as “Data Gateway Managers” do not fit into the requirements of Consent Managers under DPDPA who are Significant Data Fiduciaries.
For this purpose, apart from drawing the attention of the readers to the AA scheme as it exists now and integrated into the business of the 16 AA registered entities, we can explore the details of their operations to see if they are compliant with DPDPA 2023 as of today.
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 Principaland 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.
Intellectual Property created out of the IPR laws and Personal Data as a property recognized out of a law like DPDPA has some interesting relationship.
IPR is associated with an author or an inventor and hence by default discloses the owner’s personal information. Personal Data as a property is a right of the data subject and the disclosure may be subject to the condition that it is held anonymous.
IPR transfer from one person to another is fairly well understood and a licensing mechanism works to ensure that the multiple sequential owners can exercise their rights and derive return on investment over their contribution to the value life cycle of the product.
On the other hand, the transfer of rights in Personal Data is as yet not mature. When X creates a profile document or a medical report or a financial report about P, while X can claim IPR on the creation of the intellectual property such as the profile or the report, the right of ownership may be claimed by the data subject. The creator of the Intellectual property may not have the right to disclose or distribute or use the creation unless the consent at the time of providing of the personal information permits such use.
In many cases the “Profile” or a “Report” represents a “discovery” of use and the consent mechanism except under a forward looking framework like DGPSI may not cover the new uses that the report generator can find.
Thus laws such as GDPR or DPDPA need to develop in such a manner that the IPR of the Data Fiduciary is properly recognized even for the purpose of “Monetization”.
This debate will be taken into the World Intellectual Property Forum annual convention which is happening at Bangalore.
At a time the MeitY is finalizing the rules to be notified under DPDPA 2023, we need to flag some of the erroneous practices of e-mail providers and domain name registrants that gives raise to Cyber Security concerns under the false pretext of “Privacy”.
It is well known that WhoIs data of domain name registrants are mostly blocked under the pretext of “Privacy” which prevents or at least delays any investigation about cyber crimes committed with the use of fraudulent domain names.
Similarly e-mail providers donot reveal the originating IP address and substitute it with a proxy IP address. As a result any investigation requires the service provider such as GMail to be contacted for knowing the originating IP address. The service provider in such circumstances refuses to provide the information and a long legal process making the service provider liable under Section 79 of ITA 2000, is involved to get the details.
The e-mail service providers also quote “Privacy” as a reason for withholding the information.
We need to point out that “WhoIs” information is about maintaining a domain name visible to the public and posting content of any type which includes legal and illegal activities. This is not involving “Personal” activity and has to be classified as a “Publishing” activity and a “Business”. As a result the concept of “Privacy” of an individual under the “Right to Privacy as a fundamental Right” does not apply to domain name registration service.
Hence MeitY has to declare that all Domain Name Registrars are “Intermediaries” under ITA 2000 and the practice of hiding the name and address of registrants is unacceptable. Further, registration of any domain name under a false name is an act of “Impersonation” which violates ITA 2000 as well as the DPDPA 2023 and hence makes the registrar liable for any crimes committed with the publication.
As a part of “Due Diligence” of Domain Name registrars, Government should introduce a notification declaring that the registrars are required to verify the e-mail address and mobile number of the Registrant, Admin and Technical contact of every registered domain name. In the event that any of the details provided are “False” and the fact is brought to the notice of the registrar, the domain name must be immediately notified for de-activation within 48 hours and if no response comes forth from the registrar or the registrant/admin contact of the domain, the domain activity must be suspended.
Similarly, service providers like Gmail need to accept that the “Recipient” of an e-mail particularly if he is also using the gmail ID, is a customer of Google and if a sender of an e-mail is a fraudulent person or a terrorist, Gmail has no business to assist such fraudster or terrorist to hide his originating IP address and use the services in a manner which is considered as an “Offence”.
Hence under the Section 79 due diligence, MeitY has to issue a notice to Google that for all gmail recipients, Gmail should either drop the substitution of the originating IP address or introduce a one click access to the originating IP address from the menu bar of the e-mail inbox.
The same procedure should be made mandatory to all e-mail service providers including the Proton mail and other service providers who are assisting Criminal syndicates around the world to commit Cyber Crimes with impunity. Service providers like Protonmail as well as Topmail which served terror threat emails to Bangalore schools recently must be declared as “Terror Abettors” and charged accordingly under terrorist acts. Such services need to be black listed and blocked under Section 69 of ITA 2000.
There is no “Free Speech” rights for either the criminals who use E-mail as a tool of threat and a tool of spreading fear in the community with bomb threats under a fake ID and this must be made known to all the service providers.
India being a country ruled by Supreme Court, any directions in this regard by Meity as an executive wing of Governance or even the Parliament as a legislative wing of Governance under the Constitution, will be challenged in the Supreme Court. Hence, in the end it would be the responsibility of the Supreme Court to determine what is more important…the rights of a criminal or the rights of a victim/potential victim of a cyber crime. Let the Supreme Court take the responsibility for prevention of Cyber Crimes on its decision.
It is unfortunate that the law enforcement often does not initiate action against e-mail service providers and it emboldens them to indulge in such activities and claim protection under “Privacy”.
After the recent CERT IN Guidelines, many of the VPN service providers who did not want to abide by the Indian laws have moved out of India. This is more a loss to them though it is also a small irritant to many genuine users of the service.
India today has services such as e-mail and chat services such as LegerMail or LedgerChat that are a replacement of G mail and WhatsApp providing both security and privacy and more such service providers will come in India to replace Proton mail and others who are “Law Compliant secure email providers”.
The suggestions made here on invoking ITA 2000/DPDPA 2023 also may raise some objections including from Google/Gmail who are perhaps drafting the DPDPA 2023 rules on behalf of the Meity in the backrooms, but in the interest of Cyber Security of India, Government must introduce the recommended measures.
I request the MeitY/CERT-IN and NiXi to take the necessary measures.
