Become a Member
Become a Member
Blog

AA Hackathon Masterclass: Masterclass on Account Aggregator Technical Architecture

04 Jul 2020

The first masterclass during the AA Hackathon 2020 was held by Siddharth Shetty, Fellow, iSPIRT. The topic covered was “Technical masterclass on Account Aggregator Technical Architecture”.

The masterclass covers the technical topics related to Account Aggregator in detail. The entire session’s video can be seen here. In the video below, Siddharth covers the following.

We strongly recommend you to invest the time in going through this entire article and video to get the best introduction of the Account Aggregator Ecosystem.

Introduction to iSPIRT Foundation (2:38m)

iSPIRT is a non-profit and volunteer-driven organization that facilitates the building of world-class digital infrastructure. iSPIRT takes a long-term view of the problems (typically in the range of 20-30years). It believes that any significant change takes a long time (from getting people to segregate garbage or self-driven cars). iSPIRT, as an institution, will play an anchoring role in facilitating such change

iSPIRT has taken financial and health inclusion as the two major societal problems and building digital infrastructure. It believes that innovation typically happens on the back of a robust public infrastructure (either Uber using GPS, smartphone, and digital payments or emails built on SMTP/POP servers or browser built on top of the HTTP protocol)

Introduction to IndiaStack (6:47m)

IndiaStack is a set of APIs that allows governments, businesses, startups, and developers to build applications on top of this digital infrastructure.

IndiaStack has multiple layers with Aadhaar at the top that accelerated the adoption of bank accounts. It builds eKYC and eSign capability that allowed consented consumers to share their KYC documents safely and digitally Sign documents. It also has a payment layer, with UPI being the mass market payment system. Companies like PhonePe, Google Pay, BHIM, and BharatPe have built payment systems built on top of the digital infrastructure run by NPCI.

The IndiaStack is unique compared to other countries such as

  1. In China, the money remains in a private wallet. The innovation is built on top of the wallets, limiting innovation that can be created.
  2. Or countries like the USA, where the traditional banking system and clearing houses unable to accelerate the innovation. Entrepreneurs started to disintermediate the current banking system and build their own walled garden using bitcoin and blockchain.

IndiaStack empowers developers in India to develop complex and scalable solutions on top of the public data infrastructure. This will allow India to move from a data-poor to a data-rich country.

IndiaStack puts the users in front of innovation. In a western model, data is captured from the user first. Based on that data, companies provided different services, such as targeted ads. IndiaStack turns the model on its head and looks for ways to empower the user with their data once they share the consented data about themselves with service providers.

Account Aggregator (23.17m)

Methods of Sharing Financial Information (23.17m)

The methods of sharing financial information available to consumers are broken (not just in India, but worldwide). They can be classified broadly into the following three categories.

  1. Visit FI branch: The consumer has to walk into the respective financial institution and request the person to provide a record or hard copy of their financial information. This is time-consuming for the consumer and the entity processing this data, not to mention the data’s safety in the hard copy.
  2. Read SMS: Certain FI with a mobile application would request their consumers to allow the app to read their SMS messages on the phone sent by FIs and extract data. This not only has significant security concerns but is being disallowed by regulators.
  3. Screen scraping tools: The FI will use APIs provided by screen scraping tools and ask the customer to enter their username/password (say NetBanking) on a specific website. The tool will log in to the customer bank account and scrape the HTML page data. This not only opens up phishing attacks by unsuspecting entities but also unreliable. Some companies build direct integration with every bank, which is not scalable beyond a point.

As part of its Data Protection Framework, the Ministry of Electronics and Information Technology (MeitY) has defined and published artefacts for electronic data consent. As per this framework, an individual needs to consent for the electronic sharing of personal data. The artefact establishes standards and codifies data consent. The consent will be provided to an Account Aggregator (or consent manager) instead of a Financial institution. It is very similar to UPI’s permission artefact (consent for payment) and based on an open standard principal called ORGANS.

Data Empowerment and Protection Architecture (DEPA) (32:01m)

The India regulation (Personal Data Protection Bill and its precursor, the Justice Srikrishna Committee Report) mandated that.

  1. Sharing of unconsented data (other than National security) is illegal.
  2. The consent should be provided through a consent manager rather than to the individual FIs and
  3. The consumer should have the right to port their data from one service provider to another.

The Account Aggregator was conceptualized to solve the problems with data sharing mentioned above. It provides a framework (based on Data Protection Framework) by which consenting consumers digitally share any of their financial information with requesting entities. The sharing will be time-saving (just a click of a button), highly secure, and in real-time. The framework is in compliance with Data Empowerment and Protection Architecture (DEPA).

[Video] Masterclass on Account Aggregator Technical Architecture

Overview of Account Aggregator System (34:27m)

The account aggregator ecosystem consists of the following entities.

  1. Financial Information Provider (FIP): FIPs are institutions that generate and hold consumer data. Some of the examples are
    1. Banks: (information on current/savings account, transactions, and balances),
    2. Mutual Funds (information of funds held, investment and withdrawal),
    3. Insurance: (information about insurance schemes, the premium paid, and maturity date)
    4. **GST Network: (**Information about the amount of tax paid and when)
  2. Financial Information Users (FIU): FIUs are institutions that consume that data generated by the FIPs. Some of the examples are
    1. Lenders: Lenders (either banks or NBFC) who provide a loan to the consumer. They would need data from FIPs to assess the consumer’s credit risk and later to monitor asset quality.
    2. Private Entities: Private companies such as companies that provide personal finance management or wealth management offer respective services. Innovative personal finance management solutions can be built for users for MSMEs (in tier 2 and tier 3 markets who use applications such as KhataBook and OkCredit)
  3. Account Aggregator (AA): Account Aggregators are regulated entities that operate with a license obtained from the Reserve Bank of India (RBI). They are the consent manager for financial information, and they manage consent for financial information sharing.

The Account Aggregator system defines a standard API infrastructure (a set of APIs and schemas) that allows any FIPs to plugin to any AA to receive consent and provide data. Similarly, FIUs can plugin to any AA to request for consent and receive data from FIPs. The consumer can share the data with other FIUs and use this framework to download the data and store it in their local storage.

The FIPs will be driven by market incentives to share the data they produce with the Account Aggregator ecosystem. The FIPs play a dual-role as FIP and FIU as well, and by the principle of reciprocity, they share the data they produce so that they can consume from other FIPs. The FIPs believe that there will be an explosion of the financial services market with the AA ecosystem, eventually helping them grow.

There are already seven account aggregators licensed by RBI. The expectation is that the Indian market is large and diverse enough to accommodate more account aggregators. Different AAs may emerge for various market segments such as tier 2 and tier 3 users (say, assisted onboarding), SMEs, and large enterprises.

Software Ecosystem (42:05m)

The Account Aggregator system defines standards and APIs infrastructure of data sharing. However, the ecosystem players would require additional software modules to successfully share and consume the data. There are opportunities for software vendors to build

  1. Middleware system: To build middleware systems such as data governance systems for FIUs on how to use the data received from AA and per the consent or AI/ML companies who can consume the data and predict consumers’ credit risk and creditworthiness.
  2. Developer Tools: These are tools (such as Stripe or Twilio) build on top of the existing API infrastructure. They will allow the ecosystem players to quickly create mobile applications or integrate with AA.

Account Aggregator Technology Architecture (55:48m)

The technology architecture of Account Aggregator consists of

FI Schemas

These are the standard definition of schemas (available on REBIT website) for various financial information such as current account, deposit account, insurance, and mutual funds.

Account Aggregator APIs

The AA APIs (available on the REBIT website) enable AA to serve as an intermediary between FIPs and FIUs. The AA APIs consist of

  1. Consent Management APIs: These APIs are used to interface with FIUs. It allows AA to receive consent requests from FIU and generate consent artifacts such as consent handle. APIs will enable FIUs to check the consent status and fetch information associated with specific content.
  2. Data Flow APIs: These are APIs for FIUs to submit the digitally signed consent to AA and fetch the requested financial information in AA (from FIPs). The architecture maintains data privacy, and the FIP will not know which FIU the data is being shared.
  3. Notification APIs: These are the APIs used by the FIPs and FIUS to submit notifications to AA. There are separate APIs to manage notifications during consent flow, data flow, and account linking.
  4. Monitoring API: These are APIs used by the FIPs and FIUs to monitor the health of AA.

Financial Information Provider (FIP) APIs

FIP APIs (available on the REBIT website) provide interfaces that allow an AA to discover consumer accounts, send consent artifacts, and fetch the data from FIPs. The FIP APIs consist of

  1. Account Discovery and Linking APIs: These APIs allow a AA to discover the different accounts that belong to a consumer, link, and unlink an account with a consumer. These APIs will enable the passing of verified attributes such as mobile number, PAN, or customer-id. In return, it provides the account associated with the attribute. The link APIs later will allow the user along with the OTP/Token and link the account.
  2. Data Flow APIs: These are APIs for FIPs to receive the request, validate the request, and allow AA to fetch consented data. These APIs are used by AA when a FIP requests data after consent. These contents or digitally signed and encrypted so that AA cannot view the data. AA is like a postman who carries the envelopes and will never open the envelope and read what is in it.
  3. Consent and Consent Notification APIs: These are APIs that will allow AA to send the consent artifact to AA and API that handles notifications such as CONSENT-CREATED, CONSENT-REVOKED, CONSENT-PAUSED, CONSENT-RESUMED, and CONSENT-EXPIRED.
  4. Monitoring API: These are APIs used by AAs to monitor the health of FIP.

Financial Information User (FIU) Callback APIs

FIP APIs (available on the REBIT website) are a set of callback interfaces hosted by the AA Client or FIU to receive an asynchronous status update notification on the aggregation request. These APIs notifies either the AA or FIU about the consent and data flow notifications.

Sequence Diagrams for the end-to-end data flow (1:06:20m)

Account discovery and linking

This sequence diagram describes how various actors (such as consumers, AAs, and FIPs) work together to allow consumers to discover and link (or authenticate) their accounts.

  1. The consumer visits the account aggregator (let’s say a mobile app or website)
  2. Consumers request a list of FIPs that are supported.
  3. AA provides a list of FIPs that are currently active.
  4. The consumer provides the demographic details (such as a mobile number) to AA.
  5. The AA passes this information to FIP.
  6. FIP returns the masked account details.
  7. The AA displays the accounts and requests the consumer to select anyone to be linked.

This completes the discovery of various accounts held by the consumer with FIPs. The next sequence is to link the accounts with the customer.

  1. Consumers select one or more accounts to be linked.
  2. AA sends the chosen accounts to FIP
  3. FIP then sends an OTP to the customer’s phone number (or email address) based on the customer profile information with them
  4. Consumes enters the OTP in AA application of website
  5. AA sends the OTP to FIP
  6. FIP validates the OTP and, if the OTP is correct, links the account with the consumer.
  7. FIP sends the linked account list AA
  8. AA stores the linked account list for future transactions
  9. AA confirms to the consumer that accounts are linked.

The FIU initiates the request for getting consent from the consumer as described in this flow

  1. FIU creates a consent request with AA
  2. AA sends a notification to consumer that certain FIUs is requesting consent for data
  3. Consumer logs in to AA application and authenticates themselves
  4. On successful authentication, AA displays the FIU consent request and requests the consumer to either approve or deny the request.
  5. Consumers select a linked account and provide consent to AA.
  6. AA validates and saves the consent
  7. AA notifies FIU about the consent status
  8. AA creates a digitally signed consent and notifies the FIP (selected by consumer) for the consented accounts
  9. FIU requests the AA for consented artifact
  10. AA provides the digitally signed consent artifact to FIU

FIU Request for Financial Information

The FIU will request the AA to provide the financial information that the consumer has consented to from the relevant FIPs. The following sequence diagram describes the flow

  1. FIU sends a request to AA for the accepted user consent
  2. AA validates the consent and will request the FIP for the financial information.
  3. FIP will generate a session if for this request and sents it to AA
  4. FIP will validate the financial information request and will fetch the data from its backend
  5. FIP will notify AA that the financial information is available and ready to fetch by the AA.
  6. AA will use the session id and send a request to fetch the financial information with FIP
  7. FIP will encrypt and sign the financial information and will send it back to AA
  8. AA will send the financial information back to FIU
  9. FIU will decrypt the data and store it in their database for further processing.

View Financial Information on Device

  1. The sequence flow describes how consumers view their financial information from various FIPs on their device instead of sharing with FIUs.
  2. The consumer provides consent for a linked account to view the financial information
  3. AA store the consent
  4. AA notifies FIP of the consent and provides consent details
  5. The consumer AA client generates a DH key pair and makes a request for financial information.
  6. AA server forwards that request to FIP
  7. FIP fetches the FI data requested
  8. FIP generates a DH key and encrypts the data using the generated DH key of the customer and public/private key pair.
  9. FIP sends the encrypted account details too AA
  10. AA stores the data in the server
  11. AA forwards the encrypted account details to the consumer app
  12. The consumer app decrypts the data using a private DH key
  13. The consumer app will display the data in the device to the consumer

Frequently Asked Questions (1:12:08)

This section covers some of the questions asked by the participants that include questions such as

  1. Can FIs work with multiple AAs (yes, as long as they are registered),
  2. What happens when a consumer uses a recycled mobile number (the FIP should validate it),
  3. Does the reciprocity principles apply to technology companies (no, because they are not custodians of financial information),
  4. Does the consent ever expire (yes, based on configurations in consent artifact)
  5. Why is the registration workflow with AAs not standardized? (because it is dependent on AA’s internal processes)