If you take keen interest in data governance and privacy, you might have come across the draft Data Empowerment and Protection Architecture (DEPA) published by Niti Aayog in association with iSpirit - the think tank actively involved in the formulation of the India Stack. India Stack in nothing but a set of open APIs for developers and includes e-KYC using Aadhaar Authentication (digitizing KYC process for Aadhaar holders), UPI (money transfer), Digilocker (storage of verified digital copies of documents) and eSign (electronic execution of documents using Aadhaar).
As summarized in the framework itself - DEPA empowers people to seamlessly and securely access their data and share it with third party institutions. The primary objective of DEPA is to utilize the existing data that is available in silos i.e. with the existing players in the industry be it fintech, e-commerce, healthcare or insurance. The aim is to utilize such data sets along with the India stack to build new services. DEPA enables a service provider to concentrate on the service aspects, with the consent now being managed by a new type of private consent manager institution (Consent Manager). This is done by separating the consent flow and the data flow. The Consent Manager can draw into existing network of information existing with the market players and the service provider is spared from setting up parallel data procuring and consent mechanism. This ensures that service providers do not have to take consent time and again, it will be done through the consent manager at one time, for a specific purpose and for a time period. The whole process will ensure compliance with the requirements under the Draft Personal Data Protection Bill, 2019 (PDP Bill), as well.
The DEPA seeks to ensure consent based sharing, granularity of the information that is being shared (as opposed to all or nothing approach), thereby restoring individual agency over data sharing transactions. This is a move away from data fiduciary centric model who have historically acted as the custodian of the data. These are usually the incumbents of an industry (for example - Amazon, Flipkart or e-commerce, large banks such as HDFC, SBI or ICICI for financial data, technology companies such as Ola and Uber for the mobility and transportation, Google Pay and Paytm for the fintech. DEPA effectively forms the final layer of the India stack as a layer of secure digital data sharing making it accessible to all (specially small businesses) with appropriate authorization.
The idea is to implement DEPA sectorwise - financial, health, telecom etc. In fact, DEPA has been rolled-out in the financial sector through the Reserve Bank of India’s -Account Aggregator Framework. An account aggregator is basically the Consent Manager for the financial sector data. As the roadmap indicates this will now be implemented in the health sector next followed by telecom. Given that DEPA is a framework, the government will be required to enact laws in various sector to integrate this framework of consent sharing. DEPA already fits into the Personal Data Protection Bill, 2019 which also envisages consent management through consent managers which remains a crucial piece for DEPA.
How does the DEPA architecture work?
The diagram below represents the process:
Image: Niti Aayog
Simply put, if you are a service provider using data (this can be financial information for providing services/ products such as personal finance management or small ticket loans to individuals/ MSMEs) you can request data from the Consent Manager. The Consent Manager then channels the data access request through its electronic consent dashboard and the data principal/ subject can approve such request. The request for data is then channeled to the information provider (can be financial information providers) as depicted in the picture. Do note that the actual flow of data is separate from the consent flow which happens between the information provider and the information users. The Consent Manager in this case is data blind. The framework envisages that there will be several Consent Managers and the architecture will enable data portability and an individual can change and choose between various market players available.
Business Model: The business model for Consent Managers is simple. They can charge a nominal fee from the data principals. However, given that we as individuals are generally used to free service, such charge can be borne by the data users. It is possible that the information providers may charge a fee going ahead. For the time being the financial information providers have agreed to provide data free of cost. This is likely to be the case initially for other sectors as well. The paper also envisages a in-house model where the data user incorporates a Consent Manager. A Consent Manager may also provider additional services for data privacy and security. It will be interesting to note how the business model evolves. As of October 2020, seven account aggregators have received approvals from the RBI.
DEPA’s Technical Architecture
The technical architecture consists of (i) an electronic consent framework or the consent artifact; (ii) data sharing API standards; and (iii) data information standards.
Consent Artifact is a machine readable electronic document that specifies the parameters/ standards and the scope of data sharing that an user agrees to in a transaction. It replaces all permissive terms and conditions forms. The standard ensures that the consent provided is - revocable, granular, auditable, provides notice to all parties and is secure by design. The consent artifact will be managed by the Ministry of electronic and information technology (MEITY), which has already published the technology specifications for the same. The consent artifact is required to be digitally signed. The consent flow is separate from the data flow as depicted in the image above and the consent artifact can be used initiate the data flow and thereafter used repeatedly. A high level structure of the consent artifact can be found in the technology specifications.
Open API allows consent managers to plug in to a common interoperable sharing system and ensure seamless flow of encrypted data through the systems. The data information standards allow the data recipient to interpret and quickly understand the data from a new source. For example for the financial institutions there may be a standard based on common elements.
Some thoughts on DEPA
Overall DEPA seems like an ambitious step towards data democracy and presents an opportunity for market players across financial and technology sectors so that entrepreneurs can leverage this framework to build new products and services. Consent Managers and account aggregators are already providing new business opportunities. The aim is that this will be replicated across sectors like healthcare, insurance and telecommunications. Niti Aayog says the DEPA if successfully implemented will create a new journey towards data empowerment and financial inclusion. Let us take a closer look at some of the shortcomings and potential pitfalls.
Existing data sharing structures and friction caused due to migration
Currently, the market players to a large extent use OTP or click and browse-wrap agreements along with processes such as screen scraping and requesting for confidential passwords to collect consent. Companies have built their products and system around the existing mechanism for consent procurement. Incentivizing incumbent players to move to DEPA will be a major challenge. Incumbent players in any sector will have their own set mechanism. Therefore, changing the same and moving to a new framework will involve implementing the new standard APIs to build the common sharing system. This is why it is likely that there will be a considerable resistance if DEPA is made mandatory sectorwise. Companies who rely on data their data resources as an economic moat to ensure competitive advantage over competitors are likely to try and opt out of this. Granted that for players in the financial / fintech sector DEPA is set to reduce friction across the board. The banks and NBFCs are more likely to see the utility of DEPA rather than say an incumbent e-commerce or a social media company. Hence, it remains to be seen how this will be implemented in other sectors which lack organization and supervisory authority and where there may be asymmetry in terms of data resources between the market participants.
The Right to Data Portability under the PDP Bill
The narrative around DEPA relies a fair bit around the right to data portability as provided under the PDP Bill. The right of data portability as provided under the PDP Bill currently is very wide in its ambit and covers personal data generated in course of providing services or as a result of profiling activity undertaken by the data fiduciary. The PDP Bill itself is undergoing consultation and I understand that there is objection from the existing market players regarding this specific mandate of data portability as sharing generated data through analysis and profiling outcomes can be argued to be against the business interest of a company. In essence, this provision may be revised to only include the data that is provided by the data principal/ subject. Further, DEPA relies on a standard consent architecture, which effectively involves interoperable accounts which allows the data subject to switch consent managers. While the consent architecture can be standardized, interoperable data formats are harder to achieve in practice, specially in sectors which do not generate structured data. This may be easier for the financial sector as the data stored is structured and regulated. This may not be true for other sectors such as healthcare.
Inherent problems with the Self Regulatory Organizations
According to the draft, a non-profit collective ‘consent managers, data providers and consumers’ will form a self-regulatory organization (SRO) and design the procedural data sharing guidelines and ensure compliance with the sector specific rules. We already know that Sahamati has been created as the SRO for Account Aggregators. This will be replicated across different sectors. The RBI has even come out with the Framework for Recognition of a Self-Regulatory Organisation for Payment System Operators. One does not have to look far to see that the inspiration of SRO comes from NPCI. Although wildly successful, one must not forget that this is basically a consortium of banks having a disproportionate amount of control over the retail payments in India. While the RBI acts in the broader regulatory role, the guidelines and much finer details of working of the UPI (or other NPCI products) comes from NPCI itself. Problems with industry led self regulatory organization will be its disregard for consumer issues in favour of the banks it represents.
Sahamati or any SRO poses a similar problem. Although the DEPA framework envisages that SROs will be a collective of consent managers, data providers and consumers, in practice it may be hard to balance the needs of such a diverse group of stakeholders. Further, the DEPA does not flesh out how such SROs will be coming up with the procedural data sharing guidelines and what will be the consultation process in such cases. SROs role and procedure for policy formulation should be transparent. One may argue that these will be left to the regulators as has been done in case of SRO for payment system operators. Therefore, the role of SROs can be limited as a bridge between regulators and industry players. SROs should not be the ones deciding the technical standards and the finer details of working of an ecosystem (and other such core-regulatory functions) which should be left to the regulators.
Visibility over processing activities
The framework does not set out clear guidelines on how the data principal will have visibility over any data processor engaged by the data fiduciary. Given the emphasis on granularity of the consent it is necessary to allow the data principal to see who all have access to his/ her data. Further, the notice requirement under the PDP Bill requires that the notice must contain the details of individuals and entities including other data fiduciaries or data processors with whom such personal data is shared. Therefore the consent dashboard built by the Consent Managers/ account aggregators will need to take this into account. Obviously as reiterated by Niti Aayog, DEPA is only a framework and granularities such as this will need to be slowly developed.
That summarizes my thoughts on DEPA. Apart from this there are certain issues such as - (i) the framework does not provide concrete timelines for implementation; (ii) the technical standards for data storage and processing needs clarity. One would hope that these are aligned with international standards in light of global businesses operating in India; and (iii) although DEPA gives us an idea of the stakeholders in this framework, the liabilities of the entities involved are not etched out clearly. I understand that much of these conditions will have to be formulated by the Data Protection Authority to be created under the PDP Bill or will be left to the sectoral regulators, and will therefore take time.
It is important to note that DEPA only concerns itself with personal data and any non-personal data (NPD) which is derived or analytical data can be handled by the system participants. Please do refer to the report on non-personal data here, to see the evolving thoughts on regulation NPD. So DEPA may not be the one stop shop for your data woes. However, as far as individuals are concerned it does in fact provide a certain amount of control that has been lacking so far. Moreover, from my experience so far, the account aggregator framework has caused some stir even among smaller players who are gearing up to take licenses. Whether this enthusiasm translates into the other sectors, remains to be seen.