By Swastik Sharma

NITI Aayog recently released the draft of Data Empowerment and Protection Architecture (“DEPA”) for public comments. DEPA is the last layer of India Stack and the next significant digital public utility after UPI, as it scales and expands the financial sector NBFC-AA (Account Aggregator) model to other sectors. Apps built upon DEPA can offer services on the basis of one’s personal data like tax returns, expenditure behaviour or invoices raised through Amazon. Although the draft DEPA has few creases to iron, let’s first discuss what makes it so special that it is being compared to inventions like GPS.

How does DEPA work

To understand the functioning of DEPA in the simplest terms, imagine it as an ever-expanding platform where four entities meet:

  1. Data Principal: owner of the data
  2. Data Provider: any data fiduciary, including government data fiduciaries, that process relevant personal data, such as banks, the GST Network, and hospitals
  3. Data Consumer/Data User: data fiduciary that uses personal data to offer its services. For example, a FinTech offering medical loans, and an InsurTech offering micro insurance
  4. Consent Managers: entities which facilitate “consent” of the Data Principal, like Account Aggregators (though there are few differences between Account Aggregators and Consent Managers which are discussed later)

Now let’s assume that you are an InsurTech, that is, the Data User in this schema. I, the Data Principal, want to purchase a health insurance policy from you. You want access to my personal health data that lies with a hospital. The hospital here becomes the Data Provider. By developing your app upon DEPA, you can obtain consent for the data transfer through an electronic consent dashboard operated by a Consent Manager (and you can also incorporate an in-house Consent Manager). Once I consent for the transfer, the Consent Manager will generate a “Consent Artefact” and transfer it to you or the hospital, depending upon push or pull options. Consent Artefacts will replace the non-negotiable take-it-or-leave-it terms of a clickwrap agreement. It will present simple questions like “share ECG tests with ABC” with choices on the purposes of processing, period of access, revocation of consent and more.

Push and pull options for data transfer will be available, similar to payment options in UPI. In the pull option, the hospital will verify the parameters of the consent from the Consent Artefact before transferring my relevant personal data directly to you (or through the Consent Manager). In the push option, you will verify my consent before accepting data from the hospital. You will then put your algorithm to work and offer me an appropriate insurance policy. For the transfer of consent, the Consent Manager may charge me or you or both of us. The change in utility of personal data to a “reusable resource” was summed up in the draft of DEPA as: “…monetisation of raw data will … shift to monetisation of predictions, analytics, decisions, and scoring – forms of ‘value add’ on the data”. Therefore, DEPA is a significant development in India because for the first time, ownership over personal data means something of value to the Data Principal! Apps built upon DEPA will act as bridges between the needy and the provider, and for these bridges to accommodate the immense Indian traffic, it is instrumental that DEPA is leveraged by the startup ecosystem. Let’s discuss about the Consent Managers first.

Opportunities as Consent Managers

The term “Consent Managers” is an umbrella term. The first Consent Managers were the “Account Aggregators” regulated by the RBI since 2016. The Justice Srikrishna Committee called them “consent dashboards”. Since then, Consent Managers have found a place in all similar policy documents going by names like “Consent Collector” and “Health Data Fiduciaries”. The primary difference between Account Aggregators and Consent Managers is that the former cannot offer any services other than account aggregation whereas the latter may, depending upon the regulation imposed, offer other services than consent management. Therefore, there can be essentially three kinds of Consent Manager apps on DEPA:

  1. Private sector Data User or Data Providers which have incorporated an in-house Consent Manager for their consumers. Generally, these will be big corporate houses like Flipkart and Apollo Hospitals.
  2. Consent Managers which are Public Sector Undertakings offering cheaper rates for transfer in relevant sectors, like DigiLocker or BSNL.
  3. Private sector Consent Managers which are engaged only in the business of consent management, like Account Aggregators.

Just like you have the option to port your phone account from Google Pay to PhonePe, you will have the option to port your account from one Consent Manager to another. However, portability leads to greater competition in the ecosystem. To stay relevant in the competition, the third kind of Consent Managers will have to offer additional services regarding privacy and security wherever permissible.

In the present draft of DEPA, to address “consent fatigue or notice fatigue”, consent can be centralised in the account for transfer of personal data and therefore the consumer may not need to give consent again and again (like one-time authorization given for recurring payments). However, for select categories of consumers who prefer giving consent for every transfer, the Consent Manager may as an additional service obtain consent for each and every personal data transfer. Few other examples of additional services may be rating privacy and security measures of Data Users, or offering the most reliable and impregnable servers for “data transfers”. Can Consent Managers offer transfer of data through their own servers? Yes, they can, but they will be “data blind” by design. The technical underpinnings of managing consent are available here.

Offering own servers for data transfers will necessarily mean “processing personal data on behalf of a” Data User or Data Provider, and therefore invite obligations related to a “Data Processor” under the Personal Data Protection Bill, 2019 (“PDP Bill”).

Why India needs more and more Data Users

DEPA was essentially launched in the financial sector in 2016 through NBFC-AA Directions and several Account Aggregators have been licensed since then. However, going through the draft of DEPA, one will realise how eagerly the government wants more and more FinTech start-ups to integrate and innovate with DEPA, and not merely as Account Aggregators and Consent Managers. FinTech Data Users are also needed because of the deplorable condition of the Indian economy. The draft of DEPA illustrates how “92% of small businesses in India lack access to formal credit” and advocates strongly for “Cash Flow-Based Lending” on the basis by various categories of data. In due time, Data Users will also have to take up the role of Data Provider, and the Data Providers may charge a service fee for transmission of data.

For apps built upon DEPA to run high traffic, different brackets of population will need to be targeted by different Data User apps. Few apps cannot serve the vast population diversity in India as they have different needs and generate different kinds of personal data. For example, a rural poultry farmer does not have the same personal data and the same loan requirements as an urban solar equipment manufacturer. Lending service is only one example and there are committee reports accessible here and here which discuss in detail the potential of FinTech services in Indian economy. Besides, there can be innovation unforeseen.

While regulators other than the RBI have not announced when they will come up with their own sector-specific DEPA, NHA is the exception. The NHA is going to launch DEPA for the National Health Stack later this year. The recent Telemedicine Practice Guidelines have also legitimized “Telehealth” and “Telemedicine” which are becoming the new normal. The number of e-pharmacies is on the rise in India and so is their success. Much is already in the public domain about the National Health Stack and need not be discussed in this article. What needs to be discussed is the government’s role in DEPA.

Government’s role

Not just private players, but even governments can leverage DEPA for transfer of “personalised benefits” on the basis of personal data. For example, people in a particular region disproportionately affected by natural disasters may be rendered financial assistance. At the same time, it is accepted that to achieve the degree of personalisation for transfer of benefits as illustrated, personal data required will have to more accurate and much more “personal”. This may be a future use for DEPA.

At present, the central government’s most important role is developing DEPA as a public utility and promoting innovation upon it. It will lay down the technical specifications for consent artifact, data sharing app standards to allow interoperability, and data information standards for the launch of sector specific DEPA (like DEPA for Health Stack). Equally important are measures to promote innovation and therefore, regulatory sandbox frameworks were released earlier by IRDAI, SEBI and RBI. Presently, only IRDAI’s window is open for applications which can be submitted before October 14, 2020. It is suggested that innovators keep an eye out for new cohorts of other sandbox frameworks as well.

Discussion around privacy issues lie outside the scope of this article. To state briefly, DEPA has adopted all the data protection principles and recognised all the modern rights of the data principal. Nevertheless, there are obvious, but valid concerns like non-existence of a data protection law, the possibility of Consent Managers becoming “white elephants” or the lack of transparency in the consultation process. However, the author believes that the civil society will ensure during the public consultation that the government addresses these concerns.

Ironing the creases

DEPA might end up giving one actual control over one’s personal data. However, there are four creases that need to be ironed:

  1. Allowing big corporate houses to incorporate in-house Consent Managers will give them obvious advantages over their startup competitors, and therefore their reach must be limited to their existing customers.
  2. The fact that one regulator may preclude its Consent Managers from offering additional services (like Account Aggregators) perhaps solely on the basis of category of personal data may also create an unreasonable classification between Consent Managers.
  3. In case a Consent Manager is allowed to offer additional services, whether these services can be in a sector different than the one in which Consent Management is being offered is unclear.
  4. It is clear that Consent Managers in the unregulated sector will be licenced by the Data Protection Authority of India (“DPA”) envisaged under the PDP Bill. However, whether DEPA for unregulated sector will also be launched by the DPA is unclear.

*

Swastik Sharma is a law student at Dr. RMLNLU, Lucknow, interested in the interplay between law and technology. He is available on LinkedIn and Twitter.

Edited by Aditi Agrawal