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.

The Account Aggregator (AA) ecosystem undertakes the implementation of the AA framework. The AA framework is an outcome of the joint consultations of the FSDC– Financial Stability and Development Council with the Reserve Bank of India (RBI), the Securities and Exchange Board of India (SEBI), the Insurance Regulatory Development Authority of India (IRDAI), and the Pension Fund Regulatory Development Authority (PFRDA). The AA ecosystem implements a digital public infrastructure (DPI) for consent-based data sharing in the financial sector.

Account Aggregators (AAs) are a category of RBI-regulated NBFCs that function as consent managers (CMs). CMs act as a single point of contact for consumers to give, manage, review, and withdraw consents from FIUs to access their data from FIPs. With AAs, consumers can access, manage, and share data across all financial institutions (FIs) with explicit, informed consent.

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

No, AA is for both individuals and enterprises.

The account aggregators in India is listed here.

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.

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.

FIPs and FIUs are data fiduciaries that are licensed, regulated entities (REs) under the financial sector regulators (FSRs)– RBI, SEBI, IRDAI, and PFRDA, as well as the Department of Revenue (DoR) under the Ministry of Finance (MoF), Government of India (GoI). See “License types by RBI, SEBI, IRDAI, PFRDA“.

The eligibility of REs to participate in the Account Aggregator (AA) ecosystem as FIUs and FIPs are defined by notifications through the respective regulator.

PFRDA vide its circular no. PFRDA/2022/26/FT&DA/02 has designated Central Record Keeping Agencies (CRAs) as Financial Information Providers (FIPs) of NPS data. Similarly, with circular PFRDA/2023/32/REG-POP/07, Points of Presence under the PFRDA shall act as Financial Information Users (FIU).

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.

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.

1. Citizens should be able to link their accounts with multiple financial institutions to a single handle created with an Account Aggregator of his choiceTo 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 FIUIn 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”

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.

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.

While SEBI issues regulations and circulars governing mutual fund houses and asset management companies and indirectly may govern MF distributors, the definition of an FIU under the RBI regulations clearly states that an FIU is an entity registered with and regulated by any financial sector regulator. Per the present FIU and Financial Sector Regulator definition, MF Distributor would not be eligible to be an FIU.

Based on our understanding, this directive seems to be a part of a set of directives to establish a clear separation between group companies and the AA company. While KYC is a necessary procedure, it is specifically highlighted as one of the directives, along with other points, to emphasize the need for individual processes and independence between entities within the group.

In our interpretation, this directive does not obligate AAs to perform KYC for individual citizens who use AA’s services. Our understanding, having consulted with various AAs, is that AAs are not expected to carry out KYC on citizens who use their services. The term “client” could encompass the beneficiaries of the AA’s services, i.e., citizens and the FIUs.

Given that some AAs have group companies functioning as TSPs, one possible implication of this directive could be to ensure that the due diligence performed by TSPs on FIUs as “clients” is not directly used by AAs while establishing a contract with the same FIUs.

Please note that this is a broad interpretation, and for precise guidance, it’s advisable to consult legal or regulatory experts familiar with the RBI’s directives and the AA framework.

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)

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

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.

The Financial Information exchanged between an FIP and an FIU is encrypted using a protocol called “Diffie-Hellman Key Exchange.” This protocol allows two parties (i.e., the FIP and the FIU) with no prior knowledge of each other to establish a shared secret key jointly.

The FIP uses This shared secret key to encrypt the financial information it sends and the FIU to decrypt it once received. The key exchange protocol guarantees that no other party, including the AA, can get access to this shared secret key.

Please see thisto use an open-source implementation of this protocol that aligns with the AA specifications.
Data is end-to-end encrypted. The library is publicly available here. The signature generation and validation library can be found here

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. According to a recent RBI notification, the central bank has taken a view to ensure efficient and optimum utilization of the Account Aggregator ecosystem. Thus, regulated entities of the Reserve Bank joining the Account Aggregator ecosystem as Financial Information Users shall necessarily join as Financial Information Providers also– if they hold the specified financial information and fall under the definition of Financial Information Provider. Although this notification only applies to RBI-regulated entities, the AA ecosystem believes in the principle of reciprocity and recommends all network participants adhere to the principle in letter and spirit.

Please note that only those Companies that are 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 Financial Information Provider (FIP) and/or a Financial Information User (FIU). The Onboarding Process for Participants in the AA Ecosystem as a FIP and FIU is as follows.

1. Be ready with the technical implementation of the AA Technical Standards as relevant to the role (FIP/FIU) and the use case(s)
2. Be ready with technical implementation to integrate Sahamati Technical Services (such as the Central Registry APIs and Token Service APIs) as relevant to its role. Details of Technology Service Providers (TSPs) who offer technical services for the above can be found here – https://sahamati.org.in/tsp/
3. Test technical implementations using UAT environments for access to Sahamati Technical Services and AA Sandboxes (relevant only for FIP / FIU participants)
4. Once ready for production, write to services@sahamati.org.in for requirements to create production credentials
5. Parallelly put administrative requirements in place (AA Ecosystem Participation Terms (https://sahamati.org.in/participation-terms/) and bilateral commercial terms with the AAs) to activate production.

1. Technical Implementation: Complete technical implementation of the AA Technical Standards relevant to the role (FIP/FIU/AA). These standards can be implemented by your in-house technical team, or you could involve a technology service provider. Details of Technology Service Providers (TSPs) who offer technical services for the above can be found on the Sahamati website (https://sahamati.org.in/tsp/). Sahamati, however, has no role to play in facilitating commercial arrangements between participants and TSPs. For AA data standards, please refer to https://api.rebit.org.in.
2. Testing in UAT Environment: The participant can test its technical implementation using the UAT environment of Sahamati for access to shared Technical Services and AA Sandboxes (relevant only for FIP / FIU participants). Details for accessing the UAT environment of shared Technical Services can be obtained by emailing services@sahamati.org.in.Reference to the sandbox and other necessary details can be found at https://sahamati.org.in/how-to-join-the-account-aggregator-network-to-share-and-access-financial-data.
3. Complete Certification: Undergo the Certification process defined in the Certification Framework. Details of the Sahamati Certification Framework and Sahamati empanelled certifiers can be found on the Sahamati website (https://sahamati.org.in/certification/). Sahamati, however, has no role to play in facilitating commercial arrangements between participants and empaneled certifiers.
4. Sign Shared Ecosystem Participation Terms: The participants must agree to and accept the Common AA Ecosystem Participation Terms at this stage. While this is nonmandatory, it is highly recommended that you sign common participation terms that get you into a legal contract with the same set of terms as all other signatories of the common participation terms in the ecosystem, alleviating the need for signing multiple bilateral agreements. Sahamati, however, has no role to play in facilitating commercial arrangements between participants (FIPs/FIUs) and AAs. Please get complete details at https://sahamati.org.in/participation-terms/, and you can also write to signatories@sahamati.org.in for more details.
5. Entry into production environment: Gain access and integrate with the production environment of shared technical services and other participants in the AA ecosystem. Details for accessing the production environments can be obtained by emailing services@sahamati.org.in.

The currently supported API version for testing is V 1.1.2.

“Soft delete” refers to a process where data is marked as deleted but not immediately removed. For further information, refer to the documentation.

For an existing customer, an account aggregator can rely on FIU’s authentication by an account aggregator. For example, for an existing customer, if an FIU places a consent request and uses an AA client to approve consent, AAs must verify the customer first before allowing the customer to approve/reject the consent request. As per ReBIT, Account Aggregators must independently authenticate the customer’s identity during any interaction with the customer, be it a first-time interaction or a repeat interaction. The AA cannot delegate authentication to the FIU.

A2: For AA apps, only the AA application address information, whether a web address or a mobile app address (for customer access), can be added as metadata in the AA entry if it’s relevant for FIUs redirecting customers to your app. However, it’s important to note that AA apps are downloaded onto customer devices, and the customer’s device receives data. The location of the customer’s device is expected to be private and known only to the customer and the AA app used. This location information is not intended to be known to others; hence, no entry is required in the registry.

A1: No, an FIU ID entry is not necessary for AA apps deployed on customer devices. The Central Registry typically deals with the location of FIU servers, not AA apps, on customer devices. However, suppose you wish to provide AA application address information (web address or mobile app address) as metadata in the AA entry. In that case, you can do so, especially if it’s relevant for Financial Information Users (FIUs) redirecting customers to your app.

The process for notifying API clients about new token generation is explained in the Gitbook documentation related to the token service.

Token issuance is maintained through a high-availability service. The Gitbook details how token issuance works and its SLA maintenance of 99.95%. If you need further information, refer to the Gitbook documentation.

You can access the UAT environment as a TSP independently. To get UAT access, please reach out to services@sahamati.org.in

A Client ID is generated in the production environment when the FIU/FIP is ready to go live and has provided all the required checklist information. For more details, refer to the Gitbook documentation.

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.

No, the customer does not “digitally sign” the consent artefact created by the AA. The tangible evidence that a customer is indeed the person who approved a consent request is expected to be implemented through a combination of Employing multi-factor authentication techniques on the AA clients used by a customer and keeping a log of the consent approval/rejection action performed by the customer through the AA client.

The AA ecosystem vests the responsibility of consent management (i.e. taking the consumer’s decision as to whether to approve or reject a request for consent and further creating a Consent Artefact) with the AA.

The FIP is expected to implement a ReBIT-defined API to “store” the Consent Artefact generated by an AA. The validation of it being a well-constructed Consent Artefact is inherent in implementing the API. No additional guarantees, other than what is necessary to implement the standard API defined successfully, are expected to be performed by the FIP while storing the Consent Artefact provided by an AA.

https://swagger-ui.rebit.org.in/?url=https://specifications.rebit.org.in/api_specifications/account_aggregator/FIP.yaml#/Consent%20%26%20Consent%20Notifications/post_Consent

FIP must validate the consent signature first. Once the signature is validated, FIP should validate the contents of the consent to ensure that all the parameters in the consent are valid and can be supported by FIP. Also, if the consent is periodic, at the time of data request, FIP will need to ensure that validation is performed against the consent to ensure the data request can be made.

Authenticating the customer while authorising the customer’s act of approving (or rejecting) a consent request is the prime responsibility of an AA as an RBI-licensed entity.

Once the AA has authenticated the customer (employing multi-factor authentication on the AA client the customer is using, be it an AA mobile app, web app or an SDK), the AA authorises the customer’s approval of the consent request. It then creates a Consent Artefact and passes it to the FIP through the standard FIP API exposed by the FIP.

The FIP’s role is only to authenticate and authorise the AA (using the API key issued by the FIP to the AA) and to further verify the integrity of the message contents by validating the digital signature received as part of the contents.

The FIP trusts the AA to have done the necessary customer authentication for authorising consent request approval as a fundamental aspect of the AA architecture.

In the AA ecosystem, approval from the customer is sought by AA through the APP or web interface. Only after the customer approves will AA generate the signed consent artefact, which will then be posted to the FIP.

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.

See our certification framework for more details.

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).

The empanelment process has concluded.

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.

A TSP plays a pivotal role within the AA ecosystem by delivering essential services to various entities. Operating as the sole unregulated entity in the AA-enabled data sharing process, a TSP’s responsibilities encompass:

Implementation of AA Data Standards APIs: TSPs are instrumental in implementing AA data standards APIs that establish connections between Financial Information Users (FIU), Account Aggregator (AA), Financial Information Providers (FIP), and individual businesses. This facilitation enables seamless data exchange, including the initiation of data requests, consent management, and secure receipt of encrypted data.

Analytics Engines: TSPs contribute significantly to the AA ecosystem by deploying analytics engines. These engines assist FIUs in comprehending raw data, ultimately generating valuable insights. These insights, in turn, support decision-making processes related to the disbursement of products or services. The analytical capabilities of TSPs enhance the overall effectiveness of the AA ecosystem.

Development of User Interface (UI): TSPs are responsible for crafting user interfaces that adhere to regulated consent artifacts, industry best practices, and guidelines. TSPs contribute to a seamless and secure customer experience by ensuring alignment with these standards. The UI development encompasses creating interfaces for individuals and businesses, ensuring that interactions comply with regulatory requirements and provide a user-friendly experience.

We request you to go through the following links for a better understanding of the framework and the architecture:

1. Technical Resources
2. Sahamati GitHub Page
3. AA community guidelines

The agreement between an AA and a TSP, including specifications of roles, responsibilities, and obligations, is generally a matter to be established between the two parties.

The AA will pass consented customer information to the FIU in an encrypted format. Storage and handling practices of customer data by TSPs may need to align with relevant regulations and agreements.

Data encryption is typically done at the Financial Information Provider (FIP) end, and data decryption occurs at the FIU’s end.

According to the AA Master Directions published by RBI, only regulated FIUs can receive consented encrypted information from the AA. The information will be decrypted at the FIU’s end (Please refer to clause 7.6).

Membership enables listing on the Sahamati AA network. However, to become a member, your organization should develop solutions or intend to develop solutions for the AA ecosystem participants. Simply registering through the membership shop is insufficient; your organization’s commitment to contributing to the AA ecosystem is essential for membership and subsequent listing.

If your technology organization is developing solutions for AA participants or plans to do so, you can join Sahamati. ‘Listing’ is carried out for member TSPs. To get active on the AA network, refer to our GitHub link for technical details. If you have specific queries, we can arrange a call to address them.

The current schema version does not support unmasking folio numbers based on customer requests.

Currently, data is available from inception, but there may soon be a cap of a maximum of two years of historical data.

AMCs will get onboarded through the Registrar and Transfer Agents (RTAs).

Manual checking from the scheme code and scheme master is required to determine the classification between Large-Cap, Mid-Cap, and Small-Cap fund investments.

Yes, scheme option information is available to differentiate between Growth and Dividend investments.

The scheme code is the primary indicator of direct and regular investments.

The rate of return can be derived from the raw data. The category of mutual funds is not currently available but can be determined from the scheme code. SIP dates are available, but the return percentage for each SIP investment is not provided.

All Mutual Funds data, including lump sum and Systematic Investment Plans (SIPs), is available for retrieval through the AA system.

Mutual Funds in the AA framework are identified based on the combination of mobile numbers and PAN cards. Consent requests in the AA platform are initiated using the customer’s mobile number, and linking the phone number to the folio is necessary for data retrieval.

Allocation percentages of any asset class, including tax savings funds, can be derived from the available data points.

The data received includes the purchase Net Asset Value (NAV). Returns over the last two years can be calculated based on the raw data provided.

In the current framework, scheme-level risk profile information is unavailable. The Mutual Fund data is received in raw format, and any derived risk profile data would need to be calculated from the available data points.

While the data received is in raw format, derived values like average withdrawals per quarter can be calculated from the available data points. This derived data, however, is not directly available in raw form.