FAQ

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-customisable 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-customisable 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 an 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.

Any entity registered and regulated by any of the financial sector regulators viz. RBI, SEBI, IRDAI, PFRDA or Department of Revenue, which is eligible to be an FIU, AA or FIP in the Account Aggregator ecosystem.

The annual membership fee would be determined on the basis of a member/applicant’s license type and the corresponding attribute, as per the table below:
[table “” not found /]


* AUM: Assets Under Management
** AAUM: Average Assets Under Management calculated as an average of the quarter-end computation over the previous four calendar quarters preceding the date of submission of the application to Sahamati.

Note: All revenues/financial data should be calculated as per the latest available audited annual financial statements.

All NBFC-AAs shall be classified under Fee Category B.

The following entities shall be classified under Fee Category C:
[table “” not found /]



To know more about the membership fee, please click here.

Members of Sahamati will have access to the following:

• Sahamati Central Registry (UAT & Production environments)
• Token Service API(s) (UAT & Production environments)
• Member dashboards such as sAAns
• Support application
• Governance participation
• Advocacy support
• Other services and/ or technology provided by Sahamati to its Members from time to time

To know more about the membership benefits, please click here.

The Sahamati Membership Terms remain valid and binding for a period of 5 years, subject to due payment of the applicable annual membership fees in a timely manner.

Sahamati’s membership fee(s) are payable on an annual basis i.e. every 12 months from the date of being signed up as a member.

Membership fee can be paid via direct bank transfer. Members should ensure that the annual membership fee is duly paid to Sahamati in a timely manner.

No. Payment must be made via bank transfer.

Yes, all members of Sahamati should adhere to Sahamati’s Certification Guidelines.

To know more about certification, please click here.

Yes. Members may terminate their membership at any point, under notice to Sahamati, as per the Membership Terms.

Sahamati may make existing entries of such entity in its Central Registry non-discoverable, and disable access to its suite of technical services.

No.

Members who fail to pay the requisite membership fee to Sahamati would be liable to be suspended or expelled as Sahamati Members.

To know more about certification requirements, please click here.

The Sahamati Certification Guidelines available here.

No. To sign up to membership, an entity must sign the Sahamati Membership Terms.

The Sahamati Membership Terms supersede the Sahamati AA Ecosystem Participation Terms. Therefore, upon signing the Sahamati Membership Terms, the previously signed Sahamati AA Ecosystem Participation Terms will be automatically overridden.

No. Since the launch of Sahamati’s membership program for REs, the Sahamati AA Ecosystem Participation Terms have been deprecated. Sahamati will no longer be accepting any more signatories thereto. We encourage all Regulated Entities to become Members of Sahamati by signing up to the Sahamati Membership Terms.

Click here to know more about the membership benefits and fee.

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.

Sahamati’s Central Registry is a foundational service that acts as a directory for all registered participants in the Account Aggregator (AA) ecosystem, namely Account Aggregators (AAs), Financial Information Providers (FIPs), and Financial Information Users (FIUs). It provides essential information like API endpoints (also known as callback URLs), public keys, and access control metadata to enable secure discovery and interoperability among ecosystem members.

The Sahamati Token Service (also called Tokenizer) generates secure access tokens used to authenticate and authorize requests between AA ecosystem members. These tokens enable robust security for all data exchanges and API calls, ensuring that only authorized entities can access or transmit sensitive financial information within the ecosystem.

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 Fair Use Template Library is a repository of standardised fair use templates containing reference parameters for FIUs to adapt while leveraging the Account Aggregator (AA) ecosystem. These templates set “outer bounds” for consent attributes (such as frequency of data pulls, consent validity, data range/statement period, etc.) for several known use cases in the AA ecosystem. These aim to promote responsible, reasonable, and consistent practices that enhance transparency, efficiency, and fairness in the collection and usage of financial data for specific purposes.

What it is not:

• It is not a recommendation of consent attributes for any specific regulatory license or business category.
• It does not map or attribute any use case to a specific license type (e.g., PoP from PFRDA, RA from SEBI, Lending from RBI entities, etc.).
• It is not a prescription to use the maximum values defined in the templates.
  Instead, the listed parameters serve as upper bounds, and FIUs are expected to keep their consent attributes within these limits, choosing lower or more conservative values as necessary for their use case/purpose, to ensure data minimisation and safeguard customer interests.

The templates were developed through a collaborative effort anchored by Sahamati: industry participants, mainly FIUs, via various User Councils, proposed these fair use templates, which were reviewed and approved by Sahamati’s Fair Use Committee.The approach considered: protecting customer interests, promoting alignment with the principles of applicable laws and regulations (e.g., relevant guidelines/regulations of RBI, SEBI etc.), and business use-case requirements.

• FIUs (Financial Information Users) and AAs (for customers’ self-use) participating in the AA ecosystem are encouraged to use these templates as reference points of industry alignment and  appropriately incorporate them in their own consent artefacts.
• Regulated entities designing or implementing data-sharing flows in the AA ecosystem can refer to these templates to ensure their consent and data requests are within the industry “fair use” standards.
• Ecosystem participant roles:

• FIUs – Implementors: design and issue consent artefacts aligned with the Fair Use templates.
• AAs – Checkers: validate each consent and data fetch request against the prescribed template limits before execution.
• FIPs – (Optional) Second-level checkers may use the templates to perform internal validations and/or monitor incoming requests.

The attributes covered by a Fair Use Template are the same as those defined by ReBIT in the AA technical specifications.

Each template provides upper-bound values for these attributes to limit disproportional data collection for a given use case.

These attributes typically include:

• Purpose code and purpose text – defining why the data is being requested and how it will be used.
• Consent type – profile, summary, or transactions.
• Fetch type – one-time or periodic.
• Data range – how much past data may be fetched.
• Fetch frequency – how often data can be fetched (for periodic consents).
• Consent validity – how long the consent remains active.
• Data life – how long the FIU can use the fetched data for the stated purpose.

he Fair Use templates do not introduce any new data attributes beyond ReBIT’s specifications; they simply specify the outer bounds within which these attributes should remain, to preserve user trust and promote responsible data collection.

The below image gives a comparison of the fair use template and its implementation in the consent screen show to the customer-

Yes. The Fair Use templates were adopted by the AA/FIU councils and the Fair Use Committee for ecosystem-wide implementation; AAs began validating consent and data fetch requests against these templates in real time from 1st June 2025. Ecosystem participants are expected to adhere to them in their true spirit.

No. The Fair Use templates define the upper bounds for each consent attribute; these limits must not be exceeded. However, FIUs are encouraged to select only those attributes necessary for their stated purpose, in keeping with data minimisation principles. Each organisation remains responsible for ensuring compliance with applicable laws and regulations (such as the RBI Master Directions for NBFC-AAs, the DPDP Act, etc.).

Within the Fair Use Template Library page, you’ll find a table listing the various fair use templates by ID (e.g., CT001, CT003, CT004, etc.) along with use-case category, status, and purpose text. You can click into each template to view full details of attributes and guardrails (for example, template ID CT003 – Account Monitoring).

Consent validity refers to the time period during which a consent remains active and usable by the FIU or AA client. It defines the start and end dates within which an FIU is authorized by the customer to access their financial data for the specified purpose. At the end of the consent, it expires.
For example, if a consent has a start date of 7 June 2024 and an expiry date of 7 July 2024, the FIU can access the customer’s data only within this window, subject to other limits such as the maximum FI data range.

Maximum Data Range defines the longest continuous period of financial data that an FIU can request in a single fetch under a given consent.

While creating the consent request, the statement period is calculated as the consent validity PLUS the maximum FI data range, showing the customer the full window of potential data access. When displaying the data range in a consent request, the FIU indicates the period starting from the consent start date minus the maximum data range up to the consent expiry date.

For example, if a consent is sought on 17th November 2024, with a consent validity of 1 year and 13 months FI data range, the statement period for which the customer approves the consent will be 17th October 2023 to 17th November 2025 as shown in the figure below:

When making an FI Data Request, the FIU can fetch only up to the maximum FI data range in a single pull, even if the whole consent window is longer. This means that for each request, the FIU can select any continuous period within the consented data range, but the period’s length cannot exceed the maximum data range defined in the template. For recurring consents, multiple fetches are allowed over time, each respecting the maximum data range limit.

For example, for the same consent, if a data pull is done on 1st January 2025, with 13 13-month FI data range, the statement period for which the FIU will send the request to AA / FIP will be 1st December 2023 to 1st January 2025, as shown below

AAs enforce Fair Use by checking every consent and FI Data Range against the upper bounds defined in the Fair Use Template Library. Any Consent request or FI (data fetch) request exceeding the limits is rejected by the AA(s) as per the Fair Use Implementation Guidelines (GitHub). Only requests that are within the defined Fair Use limits are processed further by the AA(s).

Your legal and compliance team should always be the point of contact to set consent parameters according to your use case. The Fair Use Template Library only suggests upper bounds and does not recommend parameters specific to your organization or use case.

Most well-known and widely used use cases are already included in the library. If your use case is not listed, please contact us by selecting the purpose field as “Fair Use”. The team will share a form for you to fill out and guide you on the next steps to propose limits before the appropriate participatory governance forum(s).

Each use case/purpose must have a separate consent artefact. A single consent cannot cover multiple purposes (e.g, consent request for both lending and PFM use cases cannot be combined in a single consent request). The principle of purpose-limitation requires a one-to-one mapping between the customer’s understanding of the purpose and the legal basis for the FIU to process the data. A consent artefact must correspond to one specific purpose—whether for a financial service or a process to avail a financial service. Using a single consent for multiple purposes would be non-compliant with applicable legal and regulatory frameworks. Kindly refer to CC026 in the Sahamati Code of Conduct for more details.

No. Even if your compliance team allows the use of the PFM template for dashboards, the consent must always correspond to the actual purpose for which the data is being sought. When offering a loan, the purpose is lending, not personal finance management. Seeking a PFM consent in an AA-journey for lending would misalign the consent purpose with the intended use, violating the principle of purpose-limitation.

Similarly, the same data cannot later be reused for a different purpose without a separate valid consent. To show dashboards under PFM, a distinct consent for PFM must be obtained from the customer. This ensures that customers are fully aware of and agree to each specific purpose for which their data is used (and consequently, customers can manage their consents at a purpose-specific level), maintaining compliance with fair use rules and Sahamati’s Code of Conduct. Kindly refer to the Fair Use Template Library and Sahamati Code of Conduct – Purpose Limitation, CC026.

In general, the loan monitoring template recommends consent validity to be co-terminous with the loan tenure or up to 5 years (whichever is lower). Similarly, the loan collection template recommends consent validity to be co-terminous with the loan tenure or 8 years (whichever is lower).

However, as an exception for short-term loans, consent validity can extend 3 months beyond the loan tenure to accommodate default scenarios, given the short-term nature of the loan, as agreed by the Lending User Council and approved by Sahamati’s Fair Use Committee. Kindly refer to Sahamati Code of Conduct – v2.0, June 11, 2025.

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.