Update (September 11, 2020 12:30 pm): The deadline to submit comments has been extended to November 30.
NITI Aayog has released a framework on Data Empowerment and Protection Architecture (DEPA) which it calls a “consent-based data-sharing framework to accelerate financial inclusion”. The apparent aim of this framework is to allow people to access their data and securely share it with third party institutions. The framework essentially proposes the implementation of an RBI Account Aggregator system in all sectors as a way to manage users’ consent. Account Aggregators are basically consent managers within the financial sector and seven such aggregators have already received their “in-principle regulatory licence” and two have received “operational licences”. Comments can be submitted via email until November 30, 2020 at annaroy@nic.in.
As per the report, this framework is “set to launch in 2020”. The scale of the project is evidenced by the spectrum of government ministries and regulators involved in the project: RBI, SEBI, PFRDA (Pension Fund Regulatory and Development Authority), IRDAI, Finance Ministry (Department of Revenue, Department of Economic Affairs, Financial Sector Development Committee), Ministry of Health and Family Welfare, the National Health Authority, the Ministry of Information and Technology, and TRAI.
According to the acknowledgements page which has been signed by Anna Roy, senior adviser at NITI Aayog, iSPIRT team, specifically Siddharth Shetty and Kamya Chandra, prepared this paper. Shetty is a Fellow at iSPIRT and leads their work on DEPA while Chandra is a Fellow at iSPIRT who has worked on the National Health Stak in the past. iSPIRT has been working on DEPA since at least May 2019. Read more about its framers here.
DEPA is the ‘final layer of India Stack’
DEPA, which the report calls “a layer of secure digital data sharing through consent”, is the “final layer of India Stack”. India Stack is a set of APIs that allows government, businesses, start-ups and developers to use India’s digital infrastructure to deliver private services. An API, or application programming interface, is a small piece of code through which two different software/apps can interact and exchange a limited amount of data, as determined by the API creator. iSPIRT’s Open API team, that have also developed APIs for the National Health Stack and OCEN, have developed and “evangelised” these India Stack APIs.
India Stack and its different layers. Source: DEPA draft
Building blocks of DEPA
The report argues that three key building blocks are required to “empower individuals with their data”:
- Enabling regulations
- Cutting edge technology standards
- “new types of public and private organisations with incentives closely aligned to those of individuals”.
‘Private’ consent managers will be used to enable consent
The framework envisions a “new type of private Consent Manager institution” that will allow individuals to give access to give consent as per MEITY-defined standards that use standard application programming interfaces (APIs) such as the ones used in RBI’s Account Aggregator ecosystem.
Within this system, any new private platers will be allowed to use public digital infrastructure to “plug in to a network of information providers and users without setting up expensive, duplicative, and exclusive bilateral data sharing rails”.
How will these help?
- No more data silos: The framework argues that this architecture will replace “costly and cumbersome data access and sharing practices” such as getting multiple physical documents notarised, physical submissions, screen scraping, username/password sharing, providing blanket consent, etc.
- Easier data portability and harmonised regulation: Since data is often stored in different formats across different databases, the report argues that porting it is an issue. Moreover, harmonised regulations for data sharing do not exist within and across sectors. DEPA would create a seamless framework for data sharing and porting.
- Data sharing with consent: The framework claims that data sharing will occur with “granular, revocable, auditable, and secure consent” by default.
- Competition between consent managers: Within the framework, consent managers are expected to compete with each other to “reach different customer segments with accessible and inclusive modes of obtaining informed consent”.
- Financial inclusion: The framework claims that the undocumented financial background of individuals in poverty prevents them from benefitting from credit, insurance and other financial management products. By consolidating this data in one repository, that can then be shared with other players, it will help the financially excluded create a digital and financial trail.
How do consent managers work?
The report draws on the concept of “consent managers”, as introduced in the Personal Data Protection Bill. According to the Bill, a consent manager is “a data fiduciary which enables a data principal to gain, withdraw, review and manage his consent through an accessible, transparent and interoperable platform”.
The DEPA framework envisions these consent managers as “data blind” entities that “will not see or use personal data themselves” and instead “serve as a conduit for encrypted data flows”. They are not permitted to store user data. These consent managers will mediate the flow of information between an individual, a potential data user, and the data fiduciary that holds the user’s information. These managers will also maintain an “electronic consent dashboard” and will; ensure no individual data is shared without the user’s consent.
The report distinguishes between consent managers and personal data storage (PDS) solutions that enable storage of data in a secure place under the direct control of an individual custodian. “[T]he data itself is not necessarily streamed through the servers where the account [of a consent manager] is hosted.” The framework calls DigiLocker the first “aggregator of digital data from multiple official sources with individual consent”. For it to become an official consent manager, it would need multiple government departments to become Government Information Providers (GIPs).
Interestingly, the framework doesn’t explain how consent will flow from financial information users (the consent requesting entity), to users (who will give consent for data sharing) to financial information providers (who will share data one they receive consent via the consent manager). It only provides the following graphic at least thrice in the report, which mirrors the RBI Account Aggregator schemata:
Source: DEPA draft
Compare this to the account aggregator framework used by the RBI and explained by Sahamati:
Source: Sahamati
- Consent Managers hold consent logs that determine how data can flow from data sources to data users in an authorised system.
- For personal data management, it is sufficient for the authorisation consents to be centralised in the account. Data can flow directly between the source and the user.
- Due to account portability, individuals can easily choose and change their Consent Manager operator service. The service provider lock-in is minimal.
Creation of Self-Regulatory Organisations: The framework has proposed the creation of a self-regulatory organisation in certain sectors to “ease the burden on regulators”. These would be non-profit collectives of consent managers, data providers and consumers that would look out for “user interests, design procedural data sharing guidelines specific to the sector, enable data providers and users to operationalise the framework quickly, and monitor adherence and compliance by all players”. Sahamati is precisely that.
Business model for consent managers: The DEPA framework proposes that to make the model financially viable, consent managers could charge a nominal fee to facilitate a data exchange. Instead of charging individuals/data principals, DEPA proposes charging the data users instead in a subscription model. Information Providers could charge a service fee in the future, but as of now, in the financial sector, they have agreed to provide data without charges. The framework has acknowledged four theoretical frameworks:
- Consent management accounts or operators: Here the operator would be an independent entity that just acts as a consent manager. They merely allow and manage data and consent flows to the data principal and data user. This is the RBI Account Aggregator model.
- In house model: Here the operator and data user are the same where the data user incorporates a consent manager along with the other services it provides to the data principal. This is the model used in the UK, but the report doesn’t see it working out in India given the diverse user groups.
- Public Sector Model: Public sector entities could offer a subsided, low-cost consent management service. This model could be appropriate for some sectors.
- Privacy based model: Some consent managers could offer additional services related to data privacy and security in the future.
Dealing with proprietary data: “DEPA as a framework could apply to personal data (data with personally identifying information) and to derived data (data with masked personally identifiable information but could reveal confidential data of a company). When sharing the latter, care ought to be taken to maintain a company’s earned competitive advantage – although personally identifying information may be masked, proprietary company algorithms or techniques may be revealed through data sharing. Therefore, the application of DEPA to new data sub-categories will need to be decided in an evolving manner through more specific procedural guidelines with sector-specific nuances.”
Building Blocks of the Technology Foundation
1. Electronic Consent Artefact that will replace the typical terms and conditions form that users currently click. Instead, it envisions consent to be given as an answer to the question: “Share Data X with ABC until X?”. Its specifications would be managed by MEITY. This consent will adhere to the ORGANS principles, that is:
- Open standards: the approach needs to be interoperable across institutions
- Revocable: individuals must be able to revoke consent
- Granular: consent must be provided each time, should stipulate how long certain data is accessed, etc.
- Auditable: machine-readable logs of consent should be provided
- Notice: must be provided to all parties
- Secure by design
How a consent artefact is envisioned. Source: DEPA draft
This way, companies will not be able to proceed without consent or with just blanket consent, will have to state the purpose for seeking data, will have to define the time period for which data access is required, and will have to simplify jargon.
- However, the framework doesn’t see the same standards of consent for all transactions. The validity of consent will be determined on the basis of sensitivity of data, and size/reversibility of transaction on a sector-wise basis. It is not clear how these standards will be determined and by whom.
- The framework envisions strong roles for the Data Protection Authority and for non-profit collectives to build sector-specific procedural guidelines.
2. Open APIs for data sharing and standards to allow new consent managers to “plug in” to a common sharing system instead of building bilateral relationships with information providers. Institutions that adopt DEPA APIs will provide data in a machine-readable format to all licensed consent managers. Any service provider can build a consent manager API and enable their service to be connected with the accounts directly so that the whole ecosystem is interoperable.
3. Data Information Standards so that data recipients can quickly interpret and understand information from a new institution. These would need to be sector-specific. For instance, the Financial Information Standard would explain the required shared elements of a bank statement across institutions.
- Technology standards around data storage and processing will have to be designed and regulated by the Data Protection Authority, as per the DEPA framework. These include data localisation mandates for sensitive and critical personal data.
- Future components of the technology framework would include tools to prevent over-consent or lack of informed consent, etc. and are being developed “under the leadership of Sahamati”. These will be implemented within and across sectors as the market develops. Others include:
- Strong data governance enforcement, and certification framework: Strong FIU data governance would need to be defended by both the RBI, a future Data Protection Authority, and by Sahamati. Sahamati could support the design of a world-class certification framework for every agent in the ecosystem.
- Minimalist data request templates for different purposes (with clear definition of a bad template): These could ensure that for a specific purpose, there is a standard set of minimal data that is requested. Adoption of these templates could be encouraged by the collective Sahamati or led by AAs.
- Data/Institutional trust scores, as recommended in the Srikrishna report, can only come to life using technology standards. Consent Managers in each sector or a collective of these can start to build multidimensional trust rating scores for information providers and users.
- Standards for nudge tactics towards more informed consent. These could include planned speedbumps in consent prior to data sharing, cooling-off periods or time lags for consent for particularly sensitive data, etc.
- Enhancement of access permissions: The “Access permissions” supported by consent artifacts need to be enhanced to enable different levels of privacy protection when data about users is shared by one entity to another. Currently, the Consent Artefact provides clarity only on how to implement the STORE permission. The ecosystem needs to lay down a technical standard or a set of guiding principles for implementing the VIEW, QUERY and STREAM permissions. These standards will invoke either existing privacy-preserving utilities or create new ones along the way. Other permission types may also need to be enabled.
- Secure Multi-Party Computation (SMPC) Standards: SMPC will allow data consumers to query or to compute on certain “aspects” of the data (e.g., did the customer have enough cash flow for the past 6 months to be eligible for a loan of X rupees) without getting a full copy of the data. SMPC is designed to be a way to securely share data between multiple parties – however, we may need to use only two-party versions of it in most of our use cases.
- Secure Vault Technology: Secure vault technology will allow data consumers (FIUs) to view the data in a secure environment without the ability to copy the data into their domain. Variations of this will be needed to implement the VIEW access permission. An industry collective, RBI, or the Data Protection Authority will need to lay down a set of standards on how this should be used by data providers and users
The chronology: GST, Finance, TRAI, Health
DEPA Roadmap. Source: DEPA draft
1. GST will be the first government department to become a Government Information Provider
GST had written to RBI in August 2020 to join the Account Aggregator framework. The DEPA framework envisions that future departments with data on individuals and MSMEs could use this as a template to improve the ease of business and to improve data portability of “individual education, jobs, or transaction data”.
- For data held by various government institutions, each department could adopt the technology standards required to become a Government Information Provider, allowing individuals and businesses to access and share their data housed within different departments.
The report does not give information about when this will actually be implemented or how it will help with GST.
2. DEPA will go live in the finance sector in Fall 2020
From the framework, the main purpose behind DEPA is to enable access to loans, insurance, savings, and “better financial management products” for individuals and small entrepreneurs by reducing the “cost and risk premium” of offering them loans “by creating frictionless and secure access to data used to establish creditworthiness with individual consent”.
It will go live in the finance sector as a network of Account Aggregators in fall 2020 under the joint leadership of the Finance Ministry, RBI, PFRDA, IRDAI and SEBI. Account Aggregators are basically consent managers within the financial sector and seven such aggregators have already received their “in-principle regulatory licence” and two have received “operational licences”.
About 10 banks and NBFCs are in various stages of adopting the Financial Information Provider and Financial Information User technical modules that will allow them to work with account aggregators across the ecosystem.
Sahamati supports existing financial institutions to adopt the technical standards to qualify as account aggregators. “They are also establishing open data governance and legal working groups to innovate on the technology architecture to further protect data rights and drive empowerment — those keen to shape the space are encouraged to join,” as per the DEPA framework. Sahamati will also give “procedural and best practice guidelines for all participating institutions, support organisations to adopt and go live” and create “new shared technology building blocks”.
Those who wish to help DEPA evolve as an ecosystem have been asked to join Sahamti’s Data Governance Working Group at least twice in the framework (“the team is looking for more volunteers and suggestions”).
3. DEPA to be launched for the telecom sector
As per the framework, DEPA will also be launched for the telecom sector at an undetermined data through which telecom operators would become financial information providers and users in the account aggregator system via a TRAI-RBI partnership. TRAI had published a report on privacy, security and ownership of data in the telecom sector in July 2018, followed by a workshop in August 2020 with major participation from major telcos.
4. DEPA will be piloted in the health sector in 2020
This follows Prime Minister’s Narendra Modi’s announcement about the National Digital Health Mission on August 15. The NDHM is based on the National Digital Health Blueprint that was released by the MoHFW in July 2019 which in turn is based on the National Health Stack Strategy paper published by NITI Aayog in July 2018. The National Health Stack paper had proposed a federated personal health record system. Despite being a public policy, the demonstrations for the Health Stack, including its APIs, processes to get certified as consent managers, etc. have been conducted by iSPIRT.
- Depending on how the Personal Data Protection Bill is enacted and how the proposed Data Protection Authority comes into force, DEPA will be applied in other sectors including education, urban affairs and jobs/skills
DEPA for financial sector: A sprawling network of tech stacks and networks
For finance, it will work with layers of India Stack that have been built since 2010. These include Aadhaar, Aadhaar-based eKYC, Aadhaar-based eSign for digital contracts, UPI, DigiLocker, etc, and the Open Credit Enablement Network (OCEN) for lending. All these are iSPIRT projects. To “democratise access to credit along the full cycle”, the DEPA framework envisions integration with the following:
- RBI’s Public Credit Registry seeks to share credit information of an individual with a central agency to resolve the information asymmetry while underwriting loans.
- Credall’s Loan Service Providers’ Bridge which is a set of APIs that can enable any institution with “a touchpoint with customers” to become loan service providers and thus allow frictionless loan applications. These APIs include OCEN-related APIs as well.
- NPCI’s eMandates and e-NACH through which anyone with a bank account can enable automatic recurring payments, especially for loan repayments.
How will this help beyond cash flow-based lending?
- More lending products and more sophisticated and cost-effective credit scoring
- Better personal financial management through tailored recommendations based on overall financial status and history
- Better advice from wealth managers and digital advisory firms that will have access to the user’s banking and financial circumstances
- “Unforeseen use cases” (like Uber used GPS)
Guiding design principles for DEPA
- Restoring individual agency and user control
- Promoting informed consent for every data transaction (rather than blanket consent for data use);
- Building in accountability for institutional data controllers so that consent is not the only backstop;
- Creating accessible and affordable repositories of personal data that are machine-readable and accessible via secure, standardized APIs
- Building an open, shared infrastructure for data sharing to minimise bilateral or closed-loop networks, and allow interoperability across the many decentralised platers
- Building incentive alignment between new public or private institutions and the needs of individuals around their data
- Remaining technology-agnostic through open standards
- supporting data minimisation;
- Ensuring reciprocity of data use and data provision (institutions cannot be users of data in the system without also being providers);
- enabling other key data rights;
- ensuring evolvability of technology and institutions by design;
- using penalties as deterrents to data misuse where required
