India’s Investments in the digital financial infrastructure—known as “India Stack”—have sped up the large-scale digitization of people’s financial lives. As more and more people begin to conduct transactions online, questions have emerged about how to provide millions of customers adequate data protection and privacy while allowing their data to flow throughout the financial system. Data-sharing among financial services providers (FSPs) can enable providers to more efficiently offer a wider range of financial products better tailored to the needs of customers, including low-income customers.

However, it is important to ensure customers understand and consent to how their data are being used. India’s solution to this challenge is account aggregators (AAs). The Reserve Bank of India (RBI) created AAs in 2018 to simplify the consent process for customers. In most open banking regimes, financial information providers (FIPs) and financial information users (FIUs) directly exchange data. This direct model of data exchange—such as between a bank and a credit bureau—offers customers limited control and visibility into what data are being shared and to what end. AAs have been designed to sit between FIPs and FIUs to facilitate data exchange more transparently. Despite their name, AAs are barred from seeing, storing, analyzing, or using customer data. As trusted, impartial intermediaries, they simply manage consent and serve as the pipes through which data flow among FSPs. When a customer gives consent to a provider via the AA, the AA fetches the relevant information from the customer’s financial accounts and sends it via secure channels to the requesting institution. implementation of its policies for consensual data-sharing, including the establishment and operation of AAs. It provides a set of guiding design principles, outlines the technical format of data requests, and specifies the parameters governing the terms of use of requested data. It also specifies how to log consent and data flows.

There are several operational and coordination challenges across these three types of entities: FIPs, FIUs, and AAs. There are also questions around the data-sharing business model of AAs. Since AAs are additional players, they generate costs that must be offset by efficiency gains in the system to mitigate overall cost increases to customers. It remains an open question whether AAs will advance financial inclusion, how they will navigate issues around digital literacy and smartphone access, how the limits of a consent-based model of data protection and privacy play out, what capacity issues will be encountered among regulators and providers, and whether a competitive market of AAs will emerge given that regulations and interoperability arrangements largely define the business.

Account Aggregators (AA’s):

ACCOUNT AGGREGATORS (AAs) is one of the new categories of non banking financial companies (NBFCs) to figure into India Stack—India’s interconnected set of public and nonprofit infrastructure that supports financial services. India Stack has scaled considerably since its creation in 2009, marked by rapid digitization and parallel growth in mobile networks, reliable data connectivity, falling data costs, and continuously increasing smartphone use. Consequently, the creation, storage, use, and analyses of personal data have become increasingly relevant. Following an “open banking “approach, the Reserve Bank of India (RBI) licensed seven AAs in 2018 to address emerging questions around how data can be most effectively leveraged to benefit individuals while ensuring appropriate data protection and privacy, with consent being a key element in this. RBI created AAs to address the challenges posed by the proliferation of data by enabling data-sharing among financial institutions with customer consent. The intent is to provide a method through which customers can consent (or not) to a financial services provider accessing their personal data held by other entities. Providers are interested in these data, in part, because information shared by customers, such as bank statements, will allow providers to better understand customer risk profiles. The hypothesis is that consent-based data-sharing will help poorer customers qualify for a wider range of financial products—and receive financial products better tailored to their needs.

Data Sharing Model : The new perspective:

Paper based data collection is inconvenient , time consuming and costly for customers and providers. Where models for digital-sharing exist, they typically involve transferring data through intermediaries that are not always secure or through specialized agencies that offer little protection for customers. India’s consent-based data-sharing model provides a digital framework that enables individuals to give and withdraw consent on how and how much of their personal data are shared via secure and standardized channels. India’s guiding principles for sharing data with user consent—not only in the financial sector— are outlined in the National Data Sharing and Accessibility Policy (2012) and the Policy for Open Application Programming Interfaces for the Government of India. The Information Technology Act (2000) requires any entity that shares sensitive personal data to obtain consent from the user before the information is shared. The forthcoming Personal Data Protection Bill makes it illegal for institutions to share personal data without consent.

India’s Ministry of Electronics and Information Technology (MeitY) has issued an Electronic Consent Framework to define a comprehensive mechanism to implement policies for consensual data-sharing. It provides a set of guiding design principles, outlines the technical format of the data request, and specifies the parameters governing the terms of use of the data requested. It also specifies how to log both consent and data flows. This “consent artifact” was adopted by RBI, SEBI, IRDAI, and PFRDA. Components of the consent artifact structure include :

1. Identifier : Specifies entities involved in the transaction: who is requesting the data, who is granting permission, who is providing the data, and who is recording consent.
2. Data : Describes the type of data being accessed and the permissions for use of the data. Three types of permissions are available: view (read only), store, and query (request for specific data). The artifact structure also specifies the data that are being shared, date range for which they are being requested, duration of storage by the consumer, and frequency of access.
3. Purpose : Describes end use, for example, to compute a loan offer.
4. Log : Contains logs of who asked for consent, whether it was granted or not, and data flows.
5. Digital signature : Identifies the digital signature and digital ID user certificate used by the provider to verify the digital signature. This allows providers to share information in encrypted form

The Approach : 

THE AA consent based data sharing model mediates the flow of data between producers and users of data, ensuring that sharing data is subject to granular customer consent. AAs manage only the consent and data flow for the benefit of the consumer, mitigating the risk of an FIU pressuring consumers to consent to access to their data in exchange for a product or service. However, AAs, as entities that sit in the middle of this ecosystem, come with additional costs that will affect the viability of the business model and the cost of servicing consumers. FIUs most likely will urge consumers to go directly to an AA to receive fast, efficient, and low-cost services. However, AAs ultimately must market their services directly to the consumer. While AA services are not an easy sell, the rising levels of awareness among Indian consumers that their data are being sold without their consent or knowledge may give rise to the initial wave of adopters. While the AA model is promising, it remains to be seen how and when it will have a direct impact on the financial lives of consumers.

Differences between Personal Data Protection & GDPR ?

There are some major differences between the two.

First, the bill gives India’s central government the power to exempt any government agency from the bill’s requirements. This exemption can be given on grounds related to national security, national sovereignty, and public order.

While the GDPR offers EU member states similar escape clauses, they are tightly regulated by other EU directives. Without these safeguards, India’s bill potentially gives India’s central government the power to access individual data over and above existing Indian laws such as the Information Technology Act of 2000, which dealt with cyber crime and e-commerce.

Second, unlike the GDPR, India’s bill allows the government to order firms to share any of the non personal data they collect with the government. The bill says this is to improve the delivery of government services. But it does not explain how this data will be used, whether it will be shared with other private businesses, or whether any compensation will be paid for the use of this data.

Third, the GDPR does not require businesses to keep EU data within the EU. They can transfer it overseas, so long as they meet conditions such as standard contractual clauses on data protection, codes of conduct, or certification systems that are approved before the transfer. 

The Indian bill allows the transfer of some personal data, but sensitive personal data can only be transferred outside India if it meets requirements that are similar to those of the GDPR. What’s more, this data can only be sent outside India to be processed; it cannot be stored outside India. This will create technical issues in delineating between categories of data that have to meet this requirement, and add to businesses’ compliance costs.