This post has been authored by Vishal Rakhecha, currently in his 4th year at NALSAR University of Law, Hyderabad, and serves as an introduction for TLF’s upcoming blog series on Account Aggregators.
A few days back, Nandan Nilekani unveiled an ‘industry-body’ for Account Aggregators (AAs), by the name of ‘Sahamati.’ He claimed that AAs would revolutionise the field of fintech, and would give users more control over their financial data, while also making the transfer of financial information (FI) a seamless process. But what exactly are AAs, and how do they make transfer of FI seamless?
We as individuals share our FI with various organisations in the course of applying for loans, insurance, etc. The manner in which we do so, though, betrays the sensitivity of the information. We usually do it by either printing our financial statements and submitting them to the relevant authorities. Or, we use the decidedly unsafe method of sharing the log-in credentials with third-parties or with the service provider that is providing the loan or insurance— known as screen scraping.
The AA framework has been suggested as a possible solution to these unsafe data-sharing . It relies on a series of licensed entities— AAs—who are connected to, and act as intermediaries between all regulated financial bodies, allowing for secure transmission of FI between them. This FI can only be transferred between them after the customer has consented to such transfer.
This has been made possible under a Master Direction published by the Reserve Bank of India in September 2016. The Reserve Bank had also given to set shop as AAs, but this was predicated on these organisations being able to demonstrate a workable technical method. Only now is the project coming to life, after these aspects have been finalised. Despite the immense importance of this framework, there is still very little discussion about it, especially given that there are several concerns with the current nature of the framework.
While there are many overlapping issues between the legal and technological aspects of this framework, I will be discussing them in distinct contexts to ensure clarity.
The Master Direction provides details with regards to the kind of information that would be covered under this framework, the organisations that would be a part of it and nature of work that the AAs would be performing.
What it Covers
While the Direction was released by the Reserve Bank, it is going to cover financial bodies that are regulated by other financial sector regulators as well including the Securities Exchange Board of India; Insurance Regulatory and Development Authority; and Pension Fund Regulatory and Development Authority. Users will be able to transfer financial information stored with financial bodies such as banks, insurance companies, asset management companies, etc. that are regulated by these regulatory authorities, through the AA framework.
These financial bodies can be put into two categories depending on the role that they are performing at a specific time. When a financial body provides a user’s FI, they will be called a Financial Information Provider (FIP); and when they receive the information, they will be called a Financial Information User (FIU). The Direction has also exhaustively identified the kind of data that would fall under the meaning of FI. These include information relating to bank deposits, structured investment products, bonds, insurance policies, debentures, among others.
Role of Account Aggregators
To become an Account Aggregator, an entity would have to take a license from the RBI for an NBFC-AA. According to the Direction, an AA cannot engage in any other business apart from:
- Retrieving or collecting FI of the customer as is required; and
- Consolidating, organising and presenting FI to the customer or any other FIU, according to the customer’s consent.
The AAs can only transfer FI after receiving user consent. The transfer of information can happen from the FIP to the FIU or to the customer herself. Sharing or transfer of FI with the customer would mean that the information would be presented on the customer’s AA application screen. However, the guidelines explicitly state that the AA should not be able to read the data at any point in time and disallow the storage of any data with itself. They also impose restrictions on the nature of activities that the AA can engage in, disallowing them from undertaking any business other than that of account aggregation. AAs are also required to ensure that there are appropriate agreements with the customer, FIP, and FIU to effectuate the data transfer.
The technical infrastructure for AA works in much the same way as it does for Unified Payments Interface (UPI) – where all the financial bodies use common Application Program Interfaces (APIs) to communicate with the payments application. Here too, the AA would be able to connect with all FIUs and FIPs using open and common APIs after receiving the license from the Reserve Bank. And just like UPI, the customer can join an AA application, through some kind of identifier like, for example, a phone number. They would then be able to connect all the accounts that are connected to that identifier.
Under the AA framework, after having connected their accounts with the AA, the users will be able to see their own FI. When the need arises, say when they need to apply for a loan, the FIU generates a consent request with the user’s AA identifier. The request includes, among others, the FI that they require, the reason for it, and the manner of usage. The user can then choose the nature of the information that is to be sent, the frequency with which it has to be shared, among others. This gives the user granular control over the kind of data that they share, and also provides them with knowledge of which FIUs have their information. The user can consent to information being shared at periodic intervals with FIUs; this frequency can be in terms of weeks, months, etc. After the user consents to the transfer, a consent artefact is generated, which contains information regarding the purpose of the information, identity of the recipients, digital signature of the AA and the customer, etc. This artefact is then sent to the FIP which after verifying the artefact, sends the FI to the AA, in an encrypted manner. The AA then transfers the information to the FIU.
The customer would be able to see the details of the information that is being shared at all times, while also being able to revoke consent at any time and stop the transmission of data to the FIU.
The Account Aggregator framework is a novel approach in dealing with the data-sharing problem that plagues the financial system. This is in line with the growing call for ‘Open Banking’ in Europe and UK, where there is a call to equip the financial system to capitalise on the opportunities presented by the digital world. The framework also allows for innovation in the field of data privacy, where it gives a greater degree of control to the users over their own data. It could also allow for sticky policies, which were impossible previously, as there were no standardised forms in which data was stored. It must be noted that AAs only provide for second-order consent, which would not prevent the FIU from exploiting the data beyond the purposes for which the user allowed.
There are, however, concerns with the present nature of the guidelines and the technical setup. The nature of the business model that these AAs are going to follow is still unclear, and some models could be harmful for customer privacy. Then there are concerns about the RBI having regulatory authority over matters that are under the jurisdiction of other financial bodies. After the passing of the Personal Data Protection Bill, it could also lead to a conflict of jurisdiction with the Data Protection Authority. This is especially important to engage with given the apprehensions that RBI has been attempting to become a super-regulator.
Apart from this, there are also issues with how the AAs themselves would present the consent dashboard to the customers, and how these could also be discriminatory in nature, perhaps in showing different screens for taking consent from associated parties. Special attention would have to be paid to the design of the applications itself. This would range for example, from making the system more accessible in vernacular languages, to ensuring that users are provided with meaningful choices while they are using the application. Last but not the least, there is the issue of exclusion. If customers are unable to or choose not to utilise AAs for whatever reason, they should still be able to utilise traditional forms of FI sharing.
At present, the feasibility of this system still remains cloudy and its true merits can only be tested once it is fully implemented.