June 14th, 2020
Introduction: Account Aggregators as Data Stewards
The management and sharing of data is a crucial function for individuals, companies, and users for a variety of purposes. Financial services, government services, and other utilities such as schools all collect information from users and employees. This data may also be shared with third parties for processing for further purposes, such as analytics or authentication. When this data is shared however, persons sharing the data lose control over the purpose of usage of this data.
In order to account for this lack of user control over their data, the idea of data stewardship has been explored in order to provide a possible oversight mechanism that various parameters of the purpose of use, access, secure sharing, and responsibility to stakeholders including users. Such stewardship may take a variety of forms depending on the context, purpose & structure of governance. Stewards can have different types of responsibility, accountability & legal provisions, depending on the entity leading them — the government or the private sector.
Data stewards can operate in various ways — some involve local storage of data while in others the steward only acts as a conduit for redirecting data between users and organizations. The latter model of stewarding data is referred to as a Data Exchange Layer or ‘Account Aggregator’.
Design of the Account Aggregator model of data stewardship (Aapti Institute, 2020)
Stewarding Design of Data Exchange Layers
Data Exchange Layers, in the general application of the term, are data stewards that enable data sharing for users and companies through a common protocol and a register of participating companies. Users accord consent to the steward, in a form that the steward allows — the granularity of consent and terms of access are design elements under the control of the Data Exchange Layer. The steward establishes protocols which are a common standard accessible to all entities that may wish to register with the steward.
This paper discusses two systems as examples of Data Exchange Layers. In both, the Data Exchange Layer itself does not access the data it shares; it is data blind, being simply a conduit that redirects the data to the appropriate entity that is the intended recipient. A potential outcome of this is overcollection of data, and a consequent need for data scrubbing in order to make it usable. Alternatively, the steward may have greater controls available to users and companies on what subsets of data to request and to grant permission to for sharing. This would allow companies to request third parties for specific data sets or points of information and make for efficient data processing.
The two models of Data Exchange Layers or Account Aggregators that will be examined are the X-tee system in Estonia and the proposed Account Aggregator model in India. Henceforth, the term ‘Account Aggregators’ (or AAs) will refer to the Indian model established by the central bank, the Reserve Bank of India (RBI). The X-tee system is under the control of the Estonia State Information System Authority (SISA) and appointed by an Act of Parliament and a public contract extended by SISA.
Both models focus on providing a platform for peer-to-peer data sharing amongst companies that store and process user data. However, AAs and X-tee differ in terms of system design. Both are designed to be pass-through systems that enable data sharing between different entities, facilitated by a centralized consent layer. This paper compares the two systems on the basis of a few metrics:
- Third-party relationships
- Consent architecture and technical framework
- Accountability and revenue models
Comparison of third-party relationships
The Data Exchange Layer model is based chiefly on the design of the steward acting as a node between various third parties with whom data may be shared. The distinguishing factor between X-tee and AAs is that in the former, a data-sharing system designed primarily for e-governance, the primary sharing controls remain at the nodes, with individual data fiduciaries. The AA system is designed for data exchange amongst companies and represents a model where the steward itself controls tools that redirect information based on agreements and independent protocols between the steward and these third parties. In fact, various AA service providers may compete on the basis of the quality of service, despite all having access to every registered data fiduciary. The X-tee system, though, is primarily used for e-governance services, and the protocol and registration are controlled by a central certifying authority and are common across services.
While the X-tee system enables data sharing amongst entities who have an agreement governing the sharing of such data, AAs enable unrestricted data sharing across all registered participants so long as it is financial information being shared. The X-tee system, as observed, is governed by a central certifying authority and has centralized control of the data-sharing system. The AA system uses the central bank as a certifying authority for AA service providers and it limits itself to prescribing technical standards for sharing and requesting information.
The X-tee System
The central steward in the X-tee system remains SISA. It is the monitoring and approving authority of the complete data-sharing platform provided in the form of the steward. The role of the central authority is to distribute the list of X-tee data service providers.
The center accepts new members, issues the access credentials (certificates) that are needed to access the X-tee services, defines the X-tee Code of Conduct, and monitors the actual usage patterns using special software. The Centre has assigned people and pre-defined procedures for managing the X-tee’s structure.
All third parties are approved by SISA. These are entities that may see and participate in the X-tee interface but still require individual agreements in order to share data through the system. An entity that wishes to process data from X-tee for a specific purpose must first register as a member of the system by entering into a contract with SISA and also an agreement with all the relevant data controllers with whom it expects to deal. These agreements should include details on the nature and frequency of access, such as the number of requests per day.
It must then secure the technological and operational ability to interact via the X-tee system, by obtaining servers, and installing the X-tee software itself or through a third-party technology service provider.
Therefore, while the technical functions can be outsourced, the system of data exchange remains based on data sharing contracts. What the X-tee system does is provide a secure, confidential & integrated system to share data seamlessly.
Account Aggregators
In the case of AAs, the central entity remains the central bank. The RBI in 2016 notified the Account Aggregator Directions to create a legal framework for entities to take up the service in a predictable policy environment. The Directions define Account Aggregators as non-banking financial institutions that offer services such as retrieving/collecting the user’s financial information; and consolidating, organizing & presenting such information to the customer, as may be specified by the Bank. The Bank is the appointing and approving authority for qualifying entities with AA licenses to operate the services.
Once approved, AA services act as contact points for users to allow companies to share their data with other companies. If an insurance company needs health or loan information, a user would authorize the bank/health service provider through the interface provided by the AA to share data with the insurance company. Companies requesting access to data are known as “Financial Information Users” (FIUs) and those providing access are “Financial Information Providers” (FIPs).
The AA need not have in place agreements with each of the parties in play in order to operate requests to share information. The system allows for multiple AAs to operate parallelly and compete with one another. With no limit to service providers being prescribed by the rules, multiple AAs can be licensed by the central bank.
Comparison of consent architecture and technical framework
Both systems have centralized processing of data access requests. In the AA system, data sharing is reliant on the digital consent artifact rather than a sharing agreement. The consent artifact is governed by the terms of consent which only specify the receiver and provider of information, customer identity, and duration of the consent. The protocols on sharing information are therefore more forthright in the case of AAs. It is unclear as to how specific subsets of data, or specific queries on a larger set, can be requested. Users cannot negotiate the specifics of information shared, and data minimization as a principle seems difficult to implement in this system.
The X-tee System
In the X-tee system, individuals’ consent is aggregated at the level of each data fiduciary. The data is managed by fiduciaries in conjunction with the X-tee system. The fiduciaries are in this case “users” of the data-sharing system. They are required to register with the central authority of the system, namely, SISA — either as a consumer-institution or as a data provider.
A consumer, or client, of the X-tee system needs to be validated by SISA to access the services and make requests for data. These data requests form a part of its regular functions as a service or organization and the data is used to carry out its regular business. The consumer/client needs to possess the requisite technical support in order to be registered. The consumer also needs to have an agreement on data sharing with the target of the data access request. This agreement provides the necessary permission as part of the X-tee protocol in order to allow access requests to the target’s data set. Even in cases where both the consumer and target data provider are registered with SISA, if there is no data-sharing agreement between the two, the access request will be denied by X-tee.
Deployment design of X-Road. Source: Estonian State Information System Authority
Illustration of Data Access structure. Source: Estonian State Information System Authority
The terms of consent and sharing in this system still operate as per the agreements between individual users and the fiduciaries, and the agreements between the fiduciaries themselves. SISA prescribes technical security standards and protocols for sharing, but the sharing itself is premised on agreements between fiduciaries.
Account Aggregators
The AA is primarily designed to operate as an aggregator of user consent to authorize data sharing amongst companies, using a common protocol provided by the AA.
The company sharing the information as part of the AA set-up is the FIP, and the one making the request for data is the FIU. The AA requires an existing agreement with the FIP as well as the consent of the user in order to share data. The FIU also needs to have an existing agreement with the AA in order to make a request to access data through the system.
The AA itself needs to apply for a license from the RBI to commence providing data sharing services. The Bank’s specifications include requirements on capital structure and technical capabilities of the entity applying for the AA license. The specifications of this architecture include the Application Program Interfaces (APIs) for collecting consent, through a consent artifact.
The consent artifact contains information such as customer identity and details of the information requested. This piece of information is transferred in order to authorize third-party access to user information. FIUs and FIPs do not need to have individual agreements with one another. A registered AA possesses the attribute of being able to share data amongst all the companies that form the AA ecosystem.
The Account Aggregator framework. Source: DigiSahamati Foundation
Comparison of Accountability and Revenue Models
The aspects of accountability and economic sustainability necessitate a look at the genesis of the two systems — how they were set up, and the legal and policy tools employed in doing so. X-tee, with its constituent elements — both the information as well as the agencies handling them — set up under a concrete national law, is better regulated for transparency and institutional grievance redressal mechanisms.
The AA system is subject to regulations passed by the central bank, the RBI, apart from certain generic financial regulations. The comprehensive accountability provisions of the X-tee system provide reliable policy architecture to ensure that no single stakeholder is able to abuse or exploit the users or the larger system. The AA system does need a broader framework to govern data sharing and better define the rights, roles, and responsibilities of all the actors in the ecosystem.
The major distinguishing factor is that the X-tee system was developed with a public purpose in mind, from a policy and governance perspective, and possesses laws regulating not only the technology but the information itself in order to make data accessible for public-benefit governance services. This makes the regulatory structure simpler, with public contracts and accessibility measures such as price control.
The X-tee System
The Estonian X-tee system is rooted in the government exercise of the population register, initiated in 2006 under the Citizens of the European Union Act, 2006. The register of citizen information, deployed as part of the e-governance services of the X-tee system, is governed by the Population Register Act of 2017 and the Public Information Act. The Population Register Act requires the appointment of a state agency or third-party contractor to maintain the population register under a contract governed by “public law”. This means that the functions and responsibilities would be geared purely towards public purposes — the controller of the information system is not permitted to independently make use of the information.
The controller contracted by the government, apart from being required to possess the technical competence for management of the register of information, must also have the knowledge to maintain the security and integrity of the system against any threat to the data. These officers are also required to organize training and capacity building programs to enable government functionaries to make use of the information system.
The information system, being geared towards public purposes, is also controlled by rules that enable transparency and efficiency. For example, the holders of information are required to actively assist persons in making requests for information. The Public Information Act requires comprehensive documentation of all information received and stored by the controllers of information systems. The organization controlling the information system must maintain a record of details of access granted to data, as well as details of requests made to other organizations.
The organization controlling particular data is required to cover expenses in making the data available to third parties as per the applicable rules. However, it may charge a fee fixed by law to third parties that wish to access the information, except in cases where the request is from government agencies or the request is an exercise of the rights and freedoms of an individual. An organization is permitted to adjust the fee payable for requests for information to account for value depreciation and maintain the viability of the service.
Account Aggregators
The RBI rules on AAs specify that all AA service providers shall have a policy and complete institutional set-up for the handling of customer complaints and grievances, approved by the Board of Directors. They stipulate that no complaint redressal process may take more than a month from receipt of the complaint. The national rules on financial institutions also require the AA to appoint a Nodal Officer to report to the office of the Ombudsman for financial institutions and to institute an Audit Committee as per the rules.
To ensure smooth functioning of the AA, it is required to have a Risk Management Committee and conduct a “fit and proper” test for the appointment of Directors. The investors in the AA are also restricted from selling any measure of a stake in the AA entity without prior approval from the RBI. Any change in control over the entity requires a public notice stating a change in control or management, including information on the transfer of shares, by all parties involved. AAs are also subject to financial regulations that are applicable across the board, such as the Payment and Settlement Systems Act of 2007 and the RBI Directions on Issuance and Operation of Prepaid Payment Instruments of 2017. These regulations on information systems primarily ensure the security of information in the control of financial institutions and service providers, and the interoperability and sustainability of digital payments systems.
The AA, as per the resource shared by the account aggregators’ independent collective body, may charge either the end-users for data requests or the FIU. The distribution of the costs of adopting the technical hardware and protocols necessary for enabling data sharing on the AA system remains unclear.
Conclusion
The fundamental difference between the two systems is the purpose of guiding their inception. The AA system has been designed as a peer-to-peer data-sharing platform to enable data sharing between companies that are related to their customers in order to ease the process of accessing data for providing services. The X-tee system has been designed as a public-facing platform that makes data available to organizations that wish to access data for a public purpose. The system enables easy access to public databases such as the population register, and controllers of information systems within the framework are not permitted to build profits from providing access to data. The AA system, designed to enable easier transactions, allows providers of data to charge for accessing data as of now, both from end-users as well as third parties.
A robust data sharing system, apart from requiring a common protocol, also needs a design framework that adequately accounts for the economic incentives and financial sustainability of the system. The AA system requires a deeper study of how to provide and reorganize incentives so that users are encouraged to share data freely and more frequently, which may not be if the cost of every data transfer is imposed on the consumer/end-user.
The policy framework for such a system also needs to account for the conflicting interests of the stakeholders — users may want to limit the amount of data shared at each instance of a data request, and the consent controls that form part of the underlying protocol need to account for this. Companies that currently control user data may also be unwilling to share data unless this is addressed, as indiscriminate data sharing is harmful to their competitive advantage and interferes with the free market. Simply transferring the entire data set of a particular user between companies completely betrays the principle of data minimization that is enshrined in the draft of the Indian Data Protection Bill as well as the European Union’s General Data Protection Regulation (GDPR). The technical design of the consent engine must enable narrower and less invasive data access requests in order to maximize trust in the system by users as well as data holders.
Even if a data-sharing system is not designed to be a public service, the objectives underlying it must be beneficial to the major stakeholders involved — this is the only reason for its adoption, apart from the interests of the government which gives other stakeholders little choice by virtue of being enforced through the law. A data-sharing system that expects wide adoption and scaling must account for these interests and concerns in order to truly be able to create a thriving digital economy, where the contours of data sharing continue to play a centrally dominant role.
References
- Understanding Data Stewardship: Taxonomy and Use Cases, Aapti Institute, 2020, accessible at https://www.aapti.in/reports/data-stewardship-a-taxonomy.
- “Introduction of X-tee”, Republic of Estonia Information System Authority, 2016, accessible at https://www.ria.ee/en/state-information-system/x-tee/introduction-x-tee.html.
- Sahamati, Collective of the Account Aggregator Ecosystem, accessible at https://sahamati.org.in/faq/.
- “Guide to the General Data Protection Regulation”, Information Commissioner’s Office, Government of the United Kingdom, accessible at https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/data-minimisation/.
- “Introduction of X-tee”, Republic of Estonia Information System Authority, 2016, accessible at https://www.ria.ee/en/state-information-system/x-tee/introduction-x-tee.html.
- “Technical Specifications for all participants of the Account Aggregator (AA) ecosystem”, RBI/2019–20/96, Reserve Bank of India, 2019, accessible at https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11729&Mode=0.
- Section 10, Estonian Population Register Act, 2017, accessible at https://www.riigiteataja.ee/en/eli/502012019008/consolide.
- Section 15, Public Information Act of Estonia, 2017, accessible at https://www.riigiteataja.ee/en/eli/502012019008/consolide.
- Section 26, Public Information Act, 2017 of Estonia, accessible at https://www.riigiteataja.ee/en/eli/502012019008/consolide.
- Section 25, Public Information Act, 2017 of Estonia, accessible at https://www.riigiteataja.ee/en/eli/502012019008/consolide.
- Sahamati, Collective of the Account Aggregator Ecosystem, accessible at https://sahamati.org.in/faq/.
