Technical masterclass on Account Aggregator Technical Architecture by Siddharth Shetty

Introduction and Housekeeping

The speaker introduces the session and provides some housekeeping information.

Key Points

• The session is starting with a technical deep dive on the account aggregator platform.

• There will be a presentation from the winners of a competition to come up with use cases and business models for account aggregators.

• A networking page will be open for the rest of the evening.

• Participants can ask questions in the chat, and support team is available.

Technical Deep Dive on Account Aggregator Platform

Sidharth Shetty gives an introduction to I Spirit Foundation and explains their long-term view of problems. He also talks about their goal to build world-class digital public goods in financial inclusion.

Key Points

• I Spirit Foundation is a non-profit volunteer technology think-tank that takes a long-term view of problems.

• They focus on societal problems such as financial inclusion and health inclusion.

• Their goal is to build world-class digital public goods in financial inclusion, specifically democratizing credit for every Indian.

• Innovation often happens on the back of public goods or infrastructure, such as GPS, smartphones, digital payments, or email clients built on top of SMTP standard.

Compatibility Issues and Infrastructure

The speaker discusses the importance of immersing oneself in infrastructure early on to create value. They mention the issues with compatibility across different browsers and operating systems.

Importance of Immersion

• Apps can have compatibility issues across different browsers and clients.

• Immersing oneself in infrastructure early on is important for creating value.

• Getting enthrall by the messiness of uncertainty is necessary to build applications that solve for it.

India Stack

• Account aggregator fits into the data empowerment and protection architecture or consent layer of India stack.

• India has built a range of digital platforms over the past 10 years, including Aadhaar, eSign, ekYC, UPI, etc.

• These platforms have accelerated financial inclusion and facilitated safe sharing of information with service providers.

Understanding UPI Architecture

The speaker explains how UPI architecture works as a three-layer cake. They discuss how NPCI connects to all banks at the base while customers' money resides in their bank accounts.

Three-Layer Cake

• UPI architecture can be thought of as a three-layer cake.

• At the base is NPCI switch which connects to all banks.

• In the middle are banks where customers' money resides.

Unbundling Permission from Bank Accounts

In this section, the speaker explains how UPI unbundles permission from bank accounts and places it into third-party innovators like PhonePe, Google Pay, WhatsApp, Beam, and others.

Unbundling Permission

• UPI essentially unbundles the permission out from your bank account and places that into third-party innovators.

• Third-party innovators like PhonePe, Google Pay, WhatsApp, Beam are purely permission collectors.

• Real-time Amazon sends a collect request to me on my UPI app which I then look at if it checks out okay I approve it using my UPI pin and then in real-time a permissions artifact gets generated that is sent to my custodian Bank who verifies it.

Interconnectivity Provided Through NPCI System

In this section, the speaker explains how interconnectivity is provided through the NPCI system for one bank to talk to another.

Interconnectivity

• This interconnectivity is provided through the NPCI system for one bank to talk to another.

• This architecture is fairly unique globally.

Efforts in Other Countries

In this section, the speaker compares India's payment system with other countries' efforts.

Efforts in Other Countries

• On one end you have what's happening in China right where money remains with wallets and then all innovation is controlled by layers on top of wallets right so any new financial product innovation gets controlled by that.

• America's only eight to ten years behind in their payments right and as a result what's happening is entrepreneurs out there singlets disintermediate the banking system and go down the blockchain bar right so essentially efforts like lebra Culebra and so on our efforts to decide mediate the current banking system in the interest of innovating for the consumer by creating an altogether separate wall garden built on the back of blockchain.

Public Platforms Built to Serve Consumers

In this section, the speaker explains how public infrastructure platforms have been built to serve consumers.

Public Platforms

• Efforts like UPI, Aadhaar, and soon like account aggregator are public infrastructure platforms that have been built to serve consumers.

• Omniscient has essentially been working towards Rajan II for the past 10 years.

• The core needs of a person like Raja knee include a mechanism to share her data to prove trust, see loan offers from multiple lenders, legally accept the best offer, receive the loan, resell her goods and subsequently repay it.

Conclusion

In this section, the speaker concludes by stating that India's payment system is unique globally because it is powered by public platforms at its base.

Conclusion

• India's payment system is unique globally because it is powered by public platforms at its base.

The Birth of UPI and Account Aggregator System

In this section, the speaker explains how UPI and account aggregator system were created to share transactional data trail with lenders in a safe and secure manner.

Reason for Creating UPI

• UPI was created to provide a way for individuals to share their transactional data trail with lenders on the system.

• This sharing can only happen with consent because individuals have agency over their data.

Account Aggregator System

• Any account aggregator can link an individual's bank account and securely share that digital data trail with lenders.

• Lenders can then return back with loan offers in real-time, which the individual can choose from digitally.

• The e-sign feature makes it legally valid under the ID Act.

G Locker

• Individuals who don't have a way to store their information physically can use G Locker to store it on the cloud.

Building Middle Layer for Consumer Needs

In this section, the speaker explains how developers will be building the middle layer to service consumer needs like credit, wealth management, personal finance management, and deeper technology problems.

Programmatic Collections Enabled by Mandates

• Innovations on top of UPI like mandates allow for recurring payments.

• Rajini could now have programmatic collections enabled on top of her daily cash flows.

Range of Use Cases Besides Credit

• Developers may choose a range of other use cases besides credit such as wealth management, personal finance management, robot-y or even deeper technology problems.

Private Innovation on Public Platforms

• Private innovation takes place on the back of public platforms like UPI to serve individuals like Raj and other consumers out there.

Moving with Public Platforms

In this section, the speaker explains how India is moving with public platforms while solving digital infrastructure problems.

Haphazard Development in India

• India is used to haphazard development without planning.

• For example, around a bunch of very haphazardly planned areas, you will see really tall skyscrapers.

Backup Facilities for Skyscrapers

• The folks building those skyscrapers actually have to build backup facilities within it because they know they can't rely on the public infrastructure to take care of needs.

• They'll often have backup power generators, their own sewage treatment plants, backup water facilities, etc.

Solving Digital Infrastructure Problems

• Our goal is to solve digital infrastructure problems where we lay the rails so that developers can go ahead and build these skyscrapers with the infrastructure that's there.

• Along the way, various platforms rolled out as connectivity permeated with likes of Geo coming in right it means all going from data poor to data rich at an extremely exponential pace.

Data Consumption in Emerging Economies

In this section, the speaker explains how data consumption differs in emerging economies like India compared to developed economies like the United States.

Data Rich Users in Developed Economies

• When users became data-rich in developed economies like the United States where they have high amounts of discretionary income, data was fundamentally used to shape the spending patterns of individuals.

• Developers would typically create an application to capture data about the user and then personalize the ads that they show to the user.

Low Levels of Discretionary Income in India

• In a country like India, at scale, most of us don't have money to spend.

• We have low levels of discretionary income, so fundamentally, the advertisement model or data consumption purely for

Democratization of Biomarkers in Healthcare

The traditional form of diagnosis based on symptoms is no longer working, and biomarkers are becoming increasingly important. With the commoditization of biomarker tests, algorithms can drive decision-making and augment doctor capacity within the country.

Paradigm Shift in Data Usage

• Data is being used to sell things to individuals, but there is a paradigm shift happening where data is being inverted.

• The democratization of biomarkers allows for algorithms to drive decision-making and augment doctor capacity within the country.

Broken Data Sharing Experience

The data sharing experience is horribly broken worldwide. Screen scraping and mobile app permissions are unreliable ways of sharing financial information.

Screen Scraping

• Screen scraping is an extremely primitive, insecure, and harmful way of capturing information.

• It opens up users to social engineering and phishing attacks.

• It's flaky and unreliable due to changes in UI elements on websites.

Mobile App Permissions

• Mobile apps that ask for permission to access messaging and other logs are becoming less common due to clamping down by companies like Google.

• Sharing information at a bank branch or through a folder with printed statements is still common practice.

• Electronic sharing of digitally signed information would be safer, more secure, near real-time, privacy-preserving, time-saving, and cost-effective.

Codifying Consent Framework

In order to enable sharing of financial information safely and securely, consent must be codified. Standardizing consent allows users to share specific aspects of their data with service providers for specific purposes.

Standardizing Consent

• Users need to give consent for their financial information to be shared with service providers.

• Codifying consent involves standardizing what aspects of data are shared with whom for what time period and for what purpose.

• Consent can be given for sharing information at a particular frequency, such as with a doctor monitoring health telemetry information.

UPI Ecosystem

• The codification of consent may seem familiar to those who have built applications in the UPI ecosystem.

Unbundling Consent from Custodians in Financial Services

In this section, the speaker explains how data can remain with the custodian while consent is unbundled into third-party innovators like account aggregators. The speaker also introduces the concept of a consent artifact and its features.

Unbundling Consent from Custodians

• Instead of going to the custodian (bank) physically or digitally, users can generate a consent artifact through third-party innovators like account aggregators.

• Data remains federated at source with the company that generated it.

• The consent artifact is an open standard called Dae in Organs that was adopted by all financial sector regulators in 2016.

• The consent is granular, allowing users to share specific information rather than their entire transaction statement.

• The data flows end-to-end encrypted for security purposes.

Features of a Consent Artifact

• A consent artifact is revocable, meaning users can revoke access to their information at any time.

• A consent artifact is very granular, allowing users to authorize access to specific queries on top of their bank statement.

• A structured audit log is generated every time consent is created for accountability purposes.

• Notice is given when data shared about you through SMS and email.

• Data governance parameters are included in the consent artifact so entities receiving data must process it in accordance with the terms of that consent.

Data Protection Bill and Consent Managers

The Data Protection Bill in India requires individuals to consent to data sharing, with few exceptions for national security and anonymized data. Consent managers like the account aggregator are used to capture consent.

Framework for Consent

• Individuals must consent to data sharing, with few exceptions.

• Consent managers like the account aggregator are used to capture consent.

Right to Data Portability

• The right to data portability allows individuals to transfer their data from one service provider to another in a machine-readable structured manner using consent managers.

• This right will soon extend across sectors beyond regulated datasets of finance, health, education, and telecom.

Account Aggregator System

The Account Aggregator system is a framework that enables consented data sharing within the financial services infrastructure.

Financial Information Providers (FIP)

• FIP's are custodians of financial information such as banks, mutual funds, insurers or even the GST system if you're a small business.

• Every FIP implements standardized APIs notified by the Reserve Bank of India.

Standardization of APIs and Financial Information Types

• APIs have been standardized making consumption of this data extremely easy.

• More than twenty types of financial information ranging from deposit accounts to share certificates have been standardized in machine-readable formats.

Financial Information Users (FIU)

• FIUs can be banks performing lending transactions, personal finance management apps or wealth managers among others.

• Users can authorize consent for their data to be shared with any entity besides allowing authorization where their data can be downloaded locally in their own device.

New Borrower Experience

In this section, the speaker discusses how the India Stack infrastructure can be used to create a new borrower experience.

Using GST Data for Lending

• The India Stack infrastructure allows borrowers to consent to share their bank account and GST data with lenders.

• GST information can be used as a leading indicator for loan approval.

• Once a transaction is completed, it gets reflected in the borrower's bank account, allowing them to receive a loan in a matter of minutes.

Personal Finance Management (PFM)

• There is currently no high-quality personal finance management application in the market.

• With the account aggregator system provided by India Stack, creating diverse PFM experiences is possible.

• Different segments of consumers require different PFM apps that cater to their specific needs.

Wealth Management and Robo-advisors

In this section, the speaker discusses how India Stack can be used for wealth management and robo-advisors.

Managing Overall Wealth

• There are currently no tools available that allow an average Indian to manage their overall wealth effectively.

• With India Stack infrastructure, managing day-to-day cash flows, insurances, investments and other aspects of wealth management becomes easier.

Robo-advisors

• With over 17 million mutual fund accounts in India, there is enormous potential for personalized investment products using robo-advisors.

• Developers can build new classes of robo-advisors on top of user data provided by India Stack.

Market-driven Adoption

In this section, the speaker discusses some of the driving forces behind market-driven adoption of India Stack infrastructure.

Principle of Reciprocity

• One of the main market-driven incentives behind adoption has been the principle of reciprocity.

• If you are a consumer of data, you also have to be a provider of data.

Incentives for Financial Institutions

• The incentives for financial institutions to jump into the system are completely market-driven.

• With India Stack infrastructure, there is an enormous space for new classes of financial institutions.

Innovating for Front-End Experiences

In this section, the speaker discusses how the explosion of apps in the FIU segment will significantly expand the market and drive established financial institutions to participate. The speaker also talks about account aggregators and how they can be innovated upon to provide diverse user experiences.

Account Aggregators

• Account aggregators can be focused on individuals or powered segments.

• UX design should simplify yet keep a very informed experience for assisted account aggregation.

• Account aggregation for small businesses should consider datasets like GST.

• Account aggregation for large enterprises should consider complex authorization chains and workflows.

Powering FIUs

• A new software ecosystem is needed to power FIUs.

• New players are expected, including data governance players, prediction service providers, and developer tooling oriented companies.

• Prediction service providers will extract relevant information from multiple types of data to predict default rates and recommend financial products.

• Developer tooling oriented companies will make it easier for people to plug into the system.

Middleware Ecosystem

• An ecosystem of middlewares that power end consumer applications can kick in as well.

• Prizes are allocated to five tracks created specifically for those not interested in building out any consumer-facing applications.

Sharing Core Models in a Virtual Data Room

The speaker discusses the possibility of sharing core models in a virtual data room, allowing computation to happen in a privacy-preserving environment. Special interest topics include homomorphic encryption and multi-party computation.

Special Interest Topics

• Making privacy-preserving computation practical

• Contacting mentors for questions on consent framework design

• Anonymization and sharing anonymized copies for building machine learning models at scale

• Prize structure: seven prizes of 50,000 rupees each, with two additional prizes for teams working on special interest topics

Using Sandboxes for Account Aggregators

The speaker provides information on using sandboxes for account aggregators, including links to sandbox resources and email IDs for support.

Sandbox Resources

• Choosing the most developer-friendly sandbox

• API specifications available at API.dot.webenrol.com or ironrabbit.io

• Comprehensive financial information supported in the ecosystem, including investments and insurance

• Deposit schema definition file available; structure includes profile information (demographic details), summary information about bank account (drawing limit)

Bank Account Deposits Schema Definition File

The speaker provides an overview of the deposit schema definition file, which includes profile information and summary information about bank accounts.

Deposit Schema Definition File

• Profile information contains demographic details of account holders; single or joint account holders are supported (multi authorization workflow not currently supported)

• Summary information includes drawing limit and other details about the bank account

Understanding APIs in Financial Information Ecosystem

In this section, the speaker explains how metadata of a transaction feeds into financial information analysis and categorization. The speaker also introduces three categories of APIs - FIU, Account Aggregator, and Financial Information Provider.

Metadata Analysis for Transaction Categorization

• Metadata of a transaction feeds into financial information analysis and categorization.

• Narration or description in bank statements can be used to allow for categorization of transactions.

• Apps can be built on top of this to provide insights into spending habits.

Three Categories of APIs

Account Aggregator API

• User registers with an account aggregator to discover and link their bank accounts.

• After authorization, consent is shared with the lender or any other FIU.

FIP API

• FIP is the custodian of user's information.

• User links their bank account with their account aggregator through FIP API.

• Discover endpoint allows passing verified attributes like mobile number to return available accounts against it.

Consent Artifact Generation

• AAA sends consent artifact to respective FIs after user approves consent request from lender.

• Consent artifact needs to be sent back to FIP for verification and validation before returning data.

Account Aggregator API Overview

This section provides an overview of the Account Aggregator API and its key features.

How the Account Aggregator Works

• The FIP sends digitally signed and encrypted information to the account aggregator, who then delivers it to the customer FI without being able to access its contents.

• The technical standard for end-to-end encryption is outlined in detail, including diffie-hellman key exchange.

• The account aggregator interfaces with both FIPs and FIs using APIs.

• An FI building an FI app will send requests for consent to the account aggregator, specifying what data they want, for what purpose, and for how long.

Consent Requests and Purpose Codes

• Draft purpose codes have been created that are extensible. These codes include a code, message, category, etc.

• Once a request is accepted by the account aggregator, a consent handle is generated that can be used by the FIU to query status.

• The consent handle can be used as a mechanism to check status during assisted flows of consent.

Requesting Financial Information

• When notification is received that consent has been approved by the user, an FIU will call AAA to request financial information using specific APIs.

• Key material details ensure that data generated by FIP is encrypted with keys only known to the FIU.

• Callback APIs are supported by an FIU app when notification is completed or when data is ready.

Privacy Considerations

• The FIU is not known to the FIP, which is important for privacy reasons.

• When data is ready, a notification is given by AAA to the FIU.

Overall, this section provides an overview of how the Account Aggregator API works and its key features. It covers consent requests and purpose codes, requesting financial information, and privacy considerations.

Linking Demographic Details to Financial Information

In this section, the speaker explains how demographic details are linked to financial information. The user selects which master counts they want to link and passes on that choice to AAA who then passes it on to the FIP. The FI feed then triggers an OTP to authenticate that individual and if the token checks out, the linkage is established successfully.

Linking Demographic Details

• VA passed on demographic details to a respective FIP who did internal checks and returned back a set of master counts.

• The user selects which one of those in master counts they want to link and passes on that choice to AAA who then passes it on to the FIP.

• The FI feed then triggers an OTP to authenticate that individual.

• If the token checks out, the linkage is established successfully.

Request for Consumer Consent

In this section, the speaker explains how a consent request is created in API format. A notification is received whenever that consent request is created as a consumer saying Bindu this lender is asking for your data for this time period for this purpose do you approve it or not right.

Creating Consent Request

• A consent request needs to be created in API format.

• A notification is received whenever that consent request is created as a consumer saying Bindu this lender is asking for your data for this time period for this purpose do you approve it or not right.

Downloading Financial Information Locally

In this section, the speaker explains how financial information can be downloaded locally by users. Users can log onto their AAA app using their own local keys stored on their smartphone key store. Against those keys, they can make a request for their account balance.

Downloading Financial Information

• Financial information can be downloaded locally by users.

• Users can log onto their AAA app using their own local keys stored on their smartphone key store.

• Against those keys, they can make a request for their account balance.

Introduction and Q&A

In this section, the speaker introduces the format for asking questions during the hackathon. They clarify that there are no restrictions on what can be built during the hackathon, but there will be legal sessions to answer any questions about regulations and rules.

Asking Questions

• Two ways to ask questions: via text or by raising your hand to come on stage.

• Legal sessions will cover regulations and rules for account aggregators.

Legal Questions

• There are three legal sessions about account aggregators.

• The first session is an introduction to regulation, the second session covers who can become an FIU or account aggregator, and the third session is an open Q&A with a law firm specializing in this area.

Partnering with Account Aggregators

• An FIU may partner with whichever account aggregator they choose to create a native onboarding experience for new users.

• If a user has an account aggregated ID type, then the FIU can send a consent request to that particular AA.

Security Threats and Reciprocity of Information

The security profile is determined by the financial information providers. Financial information providers request for other demographic details like a validated band number to be sent or your first name last name and gender to be sent. Through outbound SMS and mobile binding, one can prevent attacks. It would be an interesting idea to work upon the possibility of a mobile revocation list.

• Reciprocity principle does not apply to technology companies that are agents of regulated entities.

• Outbound SMS and mobile binding can prevent attacks.

• Possibility of a mobile revocation list can drive better protection.

Reciprocity of Information for FinTech Acting as FIU

Fintech companies that are agents of regulated entities do not have to comply with the principle of reciprocity. For folks building out these pure tech implementations that then need a partner to go live, the principle of reciprocity does not apply.

• Fintech companies that are agents of regulated entities do not have to comply with the principle of reciprocity.

• Principle of reciprocity does not apply for folks building out pure tech implementations that then need a partner to go live.

Customer Registration at an Account Aggregator

Customers register at an account aggregator through their respective banks using their bank account information.

• Customers register at an account aggregator through their respective banks using their bank account information.

Account Aggregator API Standardization

The speaker discusses the lack of standardization in the API for account aggregators. Each aggregator has its own registration flow, which is configurable based on the customer segment they serve. Expiry time for consent requests can also be configured based on the type of flow.

• Each account aggregator has its own registration flow.

• Expiry time for consent requests can be configured based on the type of flow.

• An expiry time must be specified and a new consent request raised if it's not approved.

• Becoming an account aggregator requires an RBI license, but participation in this hackathon does not affect that process.

Purpose Codes and Innovation

The purpose codes provided are only meant as a reference and should not constrain innovation during the hackathon. The purpose codes can be extended programmatically, and there is no limit to their customization.

• Purpose codes are not meant to constrain innovation during the hackathon.

• Purpose codes can be extended programmatically.

• There is no limit to customizing purpose codes.

Q&A Session

During this Q&A session, participants asked questions about generating diffie-hellman keys, central repositories for registering keys, and end-to-end encryption implementation.

• Long-term certificates form part of the study registry; UAD registry is just for sandboxing/testing.

• Production registry has certificates of those who pass procedural checks; UAD registry is just for sandboxing/testing.

• There is an open-source library for end-to-end encryption implementation on the Samedi website.

Overview of the Hackathon

The speaker provides an overview of the hackathon schedule and encourages participants to ask questions during talks and on Slack. Presentations by account aggregators will cover their sandboxes, functionality, and how to use them. Participants are encouraged to brainstorm ideas, meet teammates, and read resources in the hack Bible.

Schedule of Events

• Tomorrow there will be presentations by account aggregators about their sandboxes and functionality.

• There will be master classes on PFM apps, security cryptography, interoperability, insurance tech, UI/UX design for account aggregators, lending technology, AI/ML.

• Legal master classes and a market sizing master class are also scheduled.

• Questions can be asked until 5:30 pm with a small break before the next session.

Extending Framework for Storing and Sharing Data

• A question is raised about extending the framework to include storing and sharing data using W3C global service of verifiable engines. The speaker explains that issuing data against a verifiable credential is the first step towards this goal.

Credential Sharing

In this section, the speaker discusses the issue of US workers having to start from scratch when they move to a new city and how credential sharing can help solve this problem.

Designing an Extension for Credential Sharing

• The speaker mentions that they haven't yet designed an extension for credential sharing.

• They suggest that if the audience is interested in working on this, it would be fascinating.

• The speaker also suggests pulling up the skills spec in parallel and extending it across.

Conclusion

This section concludes the discussion on credential sharing.

• The speaker thanks the audience for clarifying their points.