FAQs

The Data Empowerment and Protection Architecture (DEPA) empowers every Indian with control over their data. It democratises access and enables secure portability of trusted data between service providers. It involves the creation of a standardized technology architecture implemented within the right institutional constructs.

DEPA’s technology architecture is an interoperable, secure, and privacy preserving framework for data sharing through

1. A technology standard for a machine readable Consent Artefact;
2. Open APIs for data sharing; and
3. A standard for Financial information.

The consent artefact is designed to be Open, Revocable, Granular, Auditable, provide Notice, and maintain Security by design (ORGANS). Since data security and protection is a critical prerequisite for empowerment, DEPA also relies on the adoption of related standards for data storage and processing techniques.

DEPA’s institutional Architecture involves the creation of new market players knowns as Consent Managers who play the role of enabling consent management for the user. These consent managers are ‘data blind’ and will not see user data themselves; rather they will serve as a conduit for encrypted data flows. The role of consent managers has been called out in the Economic Survey 2019, and has been termed in the Justice Srikrishna Committee Report as a ‘consent dashboard’. Consent Managers in the financial sector are known as Account Aggregators.

DEPA forms the final layer (more commonly known as the Consent Layer) of India Stack, a series of digital public goods designed to enable private market innovators to introduce improved digital services for India across a range of sectors. The other layers of India Stack include Aadhaar (including authentication and eKYC), the Unified Payments Interface, DigiLocker, and eSign.

Account Aggregator is a consent manager for Financial Data: a new class of NBFC approved by RBI to manage consent for financial data sharing. It was created through an inter-regulatory decision by Reserve Bank of India (RBI), Securities and Exchange Board of India (SEBI), Insurance Regulatory and Development Authority (IRDAI), Pension Fund Regulatory and Development Authority (PFRDA) through Financial Stability and Development Council (FSDC). RBI licenses the AAs.

Refer to the Master Directive issued by the RBI for complete details on getting an Account Aggregator license (NBFC-AA license).

The account aggregators in India is listed here.

We believe there is enough space in the Indian market for multiple Account Aggregators.

• India’s scale & diversity needs many AAs to serve its needs
• There are a number of niche use cases and diverse user profiles with unique requirements
• There will always be room for innovations on modes of gathering informed consent to constantly improve the user experience
• AA can be a springboard to becoming a consent managing organisation for other sectors as they adopt similar frameworks (e.g. health)

FIP stands for ‘Financial Information Provider’ – the data fiduciary. FIPs are the institutions which hold your data, for e.g. For example, your Bank, NBFC, Mutual Fund Depository, Insurance Repository, Pension Fund Repository, etc

FIU stands for “Financial Information User’. An FIU consumes the data from an FIP to provide various services to the end consumer. For e.g. a lending Bank wants access to the borrower’s data to determine if a borrower qualifies for a loan. The lending Bank is the FIU. Banks play a dual role – both as an FIP and an FIU.

No, AA is for both individuals and enterprises.

Companies registered and regulated by any of the 4 regulators – Reserve Bank of India (RBI), Securities and Exchange Board of India (SEBI), Insurance Regulatory and Development Authority (IRDAI), Pension Fund Regulatory and Development Authority (PFRDA) can be a FIP or FIU. See “License types by RBI, SEBI, IRDAI, PFRDA“.

No, players regulated by Reserve Bank of India (RBI), Securities and Exchange Board of India (SEBI), Insurance Regulatory and Development Authority (IRDAI), Pension Fund Regulatory and Development Authority (PFRDA) are not mandated to be part of AA ecosystem. However, the advantages of being part of AA will likely drive a pull based decision to join the AA ecosystem.

No, you cannot be a FIU or FIP if you are not a regulated entity.

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.

As per the press release issued by the RBI dated 13th August 2019, HFCs are recognised as a Non-banking Finance Company (NBFC) and regulated by the RBI. Hence, HFCs can be a part of the AA ecosystem.

Yes. The AA ecosystem is designed on two principles:

1. Citizens being able to freely choose amongst all RBI-licensed AAs, as to which one would act as their “consent manager” and facilitate their data being shared from their FIP to their FIU.

2. All AAs and FIPs being able to interact on the basis of a standard, non-customizable technical (API) protocol amongst each other, thus enabling the technical work done by an FIP to enable connectivity with one AA being reusable for connectivity with other AAs as well.

There is an AA community-driven standard, non-customizable legal framework that all AAs and FIPs can become a signatory to, called the AA Ecosystem Participation Terms, to avoid repetitive legal contracts amongst themselves.

Given this, each FIP and AA indeed have to finish a one-time activity of integrating with each other.

At this stage, the visibility into timelines that we have is as follows:

1. Out of 20 FIPs that are live, 6 are connected to ALL the AAs that are live as on date.
2. It is expected that at least 2 more will finish their one-time onboarding of ALL the remaining AAs within the next 4-8 weeks.
3. Out of the remaining 12, 10 FIPs are live with only one AA. We expect that these will finish one-time onboarding of atleast 1-2 more AAs within the next 8-12 weeks.

Better updates on this will emerge as we continue our efforts to support FIPs’ efforts to be connected with all the live AAs.

Interoperability is a mechanism which allows complete choice to the citizen to choose and entrust an Account Aggregator as his consent manager and being able to use his single entrusted Account Aggregator to link and enable sharing of data of all his accounts with multiple financial institutions.

1. Citizens should be able to link their accounts with multiple financial institutions to a single handle created with an Account Aggregator of his choice

   To take a real life example, a citizen who has bank accounts with ICICI Bank and State Bank of India and an insurance policy with Max Life Insurance. If he now wishes to choose Account Aggregator 1 as his trusted consent manager and link all three accounts to a single handle, he should be allowed to do so. This would mean that the two banks and his insurance company should be integrated with Account Aggregator 1.

   This explains the first guiding principle of interoperability “All FIPs need to be connected to all AAs”

2. Citizens should be able to use his existing handle created with an Account Aggregator of his choice to give a consent to share data with any FIU

   In the above example, if now the citizen wants to apply for a loan with HDFC Bank and hence, has to share his account statements from ICICI Bank and SBI with HDFC Bank through Account Aggregator. He wishes to share the information through his chosen Account Aggregator 1 with which he has a handle created and has already linked his bank accounts. Hence as a superior customer experience best practice, HDFC Bank will be obliged to present an option to the citizen to share data through Account Aggregator 1 and not ask the customer to another Account Aggregator as his consent manager.

   The above explains the second guiding principle of interoperability “All FIUs need to be connected to all AAs”

The Ecosystem is currently in a scale up mode, where FIPs are integrating Account Aggrgeator modules with their system. To begin with, many FIPs have gone live with one or two Account Aggrgegators. 

The link https://sahamati.org.in/fip-aa-mapping/  has the current FIP-AA mapping. 

All FIPs are aligned to the principle of interoperability and are expected to integrate with all Account Aggregators over the next few months. ReBIT has specified standard protocols for APIs and security mechanisms, which ensures that a single implementation with one Account Aggregator is sufficient to be integrated with all Account Aggregators subject to a IP whitelisting and quick testing. Hence, there are no technical challenges to achieving interoperability.

Currently only asset based data is available (bank accounts, deposits, mutual funds, insurance policies, pension funds). Other data types are likely to be added over time.

No. The data being transmitted through the AA is encrypted. Also, AAs are not allowed to store, process and sell the customer’s data. This is designed to ensure AAs do not have a conflict of interest when designing processes to obtain consent for access to user data.

An AA application, not the AA itself, will have access to the balances of your accounts. The decrypting of this happens on the device of the end customer. Very basic analytics can be done on the user’s device but will be limited because of the device’s horsepower.

As per the principle of reciprocity, the entity needs to be a FIP first and then an FIU. Examples include issuer/acquirer in UPI or a bank must report to then access credit bureau data.

Refer to our Resources section of the website. It has all the required technical and policy documents.

See this document for the detailed steps.

See this document for the detailed steps.

See the list of AA Data Standards Technical Service Providers.

Users sign up with an Account Aggregator on their mobile app or desktop app. This AA app shows the user all the consents given, revoked consents and a log of all data requests made by the FIU. You can revoke consents through this AA app.

The AA app is designed by and specific to a particular account aggregator. For a user to access or work on another account aggregator they need to use the app of that particular account aggregator. Hence, the Account Aggregator login ID is not reusable across multiple AAs.

In the AA app, users need to link with their FIPs (bank accounts) by which a user can share the data from that FIP with an FIU. The linking process requires users to enter a unique identifier by which the FIP can discover your account (e.g. PAN number, Customer Registration Number or mobile number – this is FIP specific). The FIP will verify that the user is the owner of that account by sending an OTP.

Yes. An individual or business can create an account in an AA app and not decide to link any of their accounts. However, when a user gives consent to share data with an FIU, users will need to link accounts in your AA app.

The FIP, if it has the requested data, is obligated to share the data.

The FIUs will have to adhere with the Data Governance guidelines to prevent misuse of data. The guidelines are being finalised together with ecosystem players and will be shared when complete.

The FIUs will have to adhere with the Data Governance guidelines to prevent misuse of data. The SriKrishna Report is the gold standard on Data Governance. Existing guidelines on security and privacy already exist for registered/regulated entities by their sectoral regulators.

The identifier used for discovery is a verified Mobile Number, PAN, or a FIP Customer ID.

Yes, the user can decide to close the account.

It has been contemplated (and codified in the AA Ecosystem Participation Terms) that a citizen must be provided the ability by an AA to “download” his/her consents and conversely, to “upload” consents hitherto managed by a different AA.

The technical details of this are yet to be worked out.

However, while this will help provide choice to citizens in the event they wish to change their consent manager, this is not relevant to the issue of whether a user can set up a profile with one AA and share data with an FIU via another AA.

The authorisation chain is derived from each FIP. The Account Aggregator will have workflows to support multi-stakeholder authorisation. The authorisation chain is derived from each FIP. The Account Aggregator will have workflows to support cases.

Yes. All consent provided through AA is designed to be revocable.

No.

If the individual revokes a consent, then the lender needs to engage with the borrower offline to find a remedy.

We strongly recommend FIP/AA/FIU to get their implementation certified. It guarantees interoperability which will enable FIPs and FIUs to seamlessly connect with a network of AAs (and vice versa).

See our certification framework for more details.

An Account Aggregator would require to have a Board approved policy for pricing of services. Pricing of services will be in strict conformity with the internal guidelines adopted by the Account Aggregator which need to be transparent and available in public domain. (Source RBI AA Master Directive).

You can reach out to the AAs for further details on their pricing.