First time I became aware of the consent layer iSPIRT was working on was sometime around late 2016, when my then boss (who happened to meet Nandan during some event they both attended and heard about it from him), asked my keep my eyes on it because this is going to be something really big for Indian digital ecosystem. I scanned to through my contacts and found out that it was work in progress and I will get to know when they are ready. After that conversation I put it in the back-burner.
Then sometime during July 2019, I came across this article and I was eager to find more about the next big thing happening in Indian digital ecosystem so I attended a workshop on Sahamati conducted by iSPIRT in Aug, 2019. In this post I will attempt to explain what all the noise is about, what excites me and my disappointments with this entire venture based on what I know about it through various sources and what I learned in the workshop I attended.
What is an Account Aggregator?
Around the time when I had joined HDFC Bank in 2005, HDFC Bank used to have a product called Oneview. If you happened to have multiple accounts in different banks, you could register for Oneview and provide Netbanking credentials for all the bank accounts and we will do something called “screenscaping” through all those bank’s netbanking sites, use the credential provided by you to show the information available across all these places as a single view.
Then few years later I heard about Yodlee and then Perfios, who were offering similar services to customers or businesses, who needed to access data across multiple bank relationships. Later came multiple other businesses with similar offering and most of them were dependent on screenscaping.
The problem with screenscaping is that every time a bank made any changes to their netbanking pages, it needed changes at aggregator’s end as well. In short if was not a very efficient way of managing access and data and to top it all they were all self regulated. Considering the sensitive information they were accessing RBI decided to come up with guidelines governing these “Account Aggregators”. After these guidelines everyone was confused how to approach this. Nobody knew what to do, not even RBI (based on my conversations with some of the players in the space, who happened to seek clarifications from RBI on this subject matter). Some of these players applied for the license from RBI under AA-NBFC category but there was still confusion, till came Sahamati.
As per the information shared at the time of workshop there were total eight entities who had received in principle approval from RBI to set up AA-NBFC. The names I remember from those 8 are, FinServ (CAMS), FinVu (Cookiejar Technologies), OneMoney (FinSec AA Solutions), Jio Information Solutions, Yodlee Finsoft and National E-governance Services (NeSL).
What is Sahamati?
As their website says: DigiSahamati Foundation is a Collective of Account Aggregator ecosystem set up as a non-Government, private limited company (With the new Companies Act of India, not for profit companies are governed under Section 8).
What Sahamati has built is a consent protocol that is approved by government and a way for customers to legally provide their smart and informed consent to the information user (FIU) for then to use one of the Account Aggregators (AA) to access your data from information providers (FIP).
How it works?
Step 1: Account aggregator will be establishing connectivity with various FIPs like Banks, Mutual Fund AMCs, Insurance Companies, Government Portals like Tax/GST etc (the scope might be extended to non-financial data sources as well, depending on the adoption of the platform). Once that connectivity is established AA will be ready to access the customer information from these institutes.
Step 2: Customers will have to register with one or more of these AAs and link his/her various financial relationships with his profile created on the AA platform. AA will seek one time authentication as prescribed by FIPs from the customer and link the details, upon successful validation.
Step 3: When customer visits the FIU for any service (could be Financial Advisor or Loan Application etc) that requires them to access his/her financial information they will ask the customer to select their AA and provide their consent to access the information to the AA.
Key Attributes of the Consent: The consent given by user will clearly state the duration for which the data is to be pulled, the time period for which the data can be accessed, frequency, revocation allowed or not, access type along with the purpose of the consent. This is to make sure the user is clearly aware of the access being granted and tag the usage of this information along. Use of this information for any other purpose than what is stated in the consent artifact is not allowed.
Step 4: After validating the consent AA will access all the information requested from respective FIPs and transfer it to the FIU in encrypted form. AA will have no access to this information and they will just act as a pass-through.
Why is this the next big thing in Indian Digital Eco-system?
In order to enhance the digital eco-system ownership, access and sharing of data is very important. AAs coupled with consent architecture proposed by Sahamati is a great first step in that direction because it enables seamless transfer of data from FIPs to FIUs, with informed consent of the user, while restricting the use of data thus shared with-in the stated purpose. This is a certain upgrade over sharing photocopies of various statements and other documents at the time of application.
Why am I disappointed?
Imagine you buy a SIM card from Airtel and you are told that with this SIM card you will be able to call only Airtel numbers and not Jio or Vodafone numbers, in order to do that you will have to buy Jio and Vodafone SIM cards. Would you like this scenario. In the current way it is structured there is no interoperability among these AAs, meaning an FIU or FIP will have to partner with all the AAs to ensure full coverage. It may even mean that customer may end up registering with multiple AAs. Forcing organizations or users to maintain multiple relationships for the same service seems like a very inefficient way of doing something. Imagine multiplication of resources needed to run this kind of set-up, setting aside the inconvenience it would be for all the parties involved. This one problem can prove to be the biggest reason this entire exercise will fail to reach its full potential. What disappoints me even more is that this comes from same set of people, who proposed UPI, where one of the key strengths of the protocol is the interoperability it offers. This is one of the key aspects, why it could be even called a wallet-killer. If wallets were interoperable, a user would have found lesser motivation to switch to UPI (I am not saying this is the only point of comparison, but in the context of this post I am sticking to this one.) After working of so many years and coming from an independent body, I would have expected this construct to provision for interoperability. We may need to create a new central body for this purpose or assign this responsibility to one of the existing and capable organizations like IDRBT or CERSAI. We may even explore to build this entire thing on blockchain to eliminate the need of having a trusted central body.
In fact I would really be happy to see this entire thing was built on blockchain based trustless architecture and I am sure we have enough capable minds among us to give this a shot and come up with something genuinely innovative and superior than what has been proposed.
EDIT: An error was pointed out by one of our readers regarding the interoperability bit. While what I meant with interoperability was AAs connecting among themselves, there is no need for all FIU and FIP to tie up with all AAs. I am copying below the relevant section from Sahamati website that highlights how it can be achieved.
As an AA, does an AA have to seek out, build partnerships with, and integrate with each new FIP or FIU separately?
No. The AA ecosystem is designed so that each FIP and FIU is enabled to work with every AA in the ecosystem network, rather than only with those with whom they have a bilateral situation. Once any FIP/FIU is certified and added to the Central Registry, any approved AA can connect with them. This Central Registry is akin the DNS server of the internet world.