To begin with, congratulations on taking the decision to join the AA ecosystem!

Financial Information Provider (FIP) and Financial Information User (FIU) modules are available from Technical Service Providers that you could use readily to get onto the AA ecosystem quickly. If you decide to build on your own FIP/FIU module, the steps are below.

To begin with, please refer to the following on our Resources page.

  1. Account Aggregators in India
  2. Account Aggregator Master Directive by RBI
  3. Account Aggregator Ecosystem API Specifications
  4. Account Aggregator Schema Definitions
  5. Account Aggregator Purpose Definitions
  6. Electronic Consent Framework by MeitY

Currently, only players who are registered and regulated by either of the four Financial Service Regulators (FSR)– RBI, SEBI, IRDAI, PFRDA, are allowed to be FIPs and FIUs.

Account Aggregator Sandboxes

The companies listed below offer sandboxes that implement the ReBIT specifications for AAs. Developers wishing to test integrations of their FIU/FIP implementations may use these sandboxes.

CompanySandbox URLSupport Contact Info
Yodlee Finsoft
INK-Account Aggregator

Best practices for FIPs in the Central Registry UAT Environment

FIPs intending to join the Central Registry UAT environment of the AA network are requested to ensure that:

  • All data shared within the UAT environment is strictly dummy data i.e., data that does not disclose any Personally Identifiable Information (PII) or other details of any account(s) of a Customer;
  • Linking, OTP verification, and data fetches should exclusively be from such dummy accounts; and
  • Under no circumstances should any user account(s) or replica(s) of production accounts be discoverable or linkable in the UAT environment.

In other words, for the purposes of UAT, discovery, linking through OTP verification, and the corresponding data fetches should strictly relate to dummy accounts/dummy data.

Please note that in case live/production user account(s) or replica(s) of production account(s) are discoverable or linkable in the UAT environment, there may be entailing risks of PII breach(es) at the instance of such FIP(s).

Onboarding an FIU with an Account Aggregator

  1. Implement (buy or build) an API driven tech platform based on ReBIT FIU specifications. Refer to the FIU API specifications.
  2. Tech platform should enable FIUs to
    1. Request for customer consent. (Call the AA /Consent API)
    2. Process notification from the AA when the customer has accepted/rejected the consent on AA domain (mobile, web). 
    3. Store the customer consent and request for financial information via AA
    4. Process the data ready notification received from AA, and call fetch API of AA to fetch the financial data. Refer to AA API specifications.
    5. Decrypt and store the data for the various use cases.
  3. Enhance the Customer experience on the existing FIU Mobile / Web app to facilitate the customer to provide financial information from AA.
  4. The UI should allow the customer to enter an AA id, and based on the AA handle request for customer consent from the AA (Refer Step 2.1)
  5. Test the platform and the flows with an AA sandbox.
  6. Additionally, FIU should determine consent request parameters for the product(s) – consent purpose, consent frequency, FI Types for which financial information is requested, data range etc. Refer to the FIU API specifications.
  7. Write to for accessing the AA Common Service (Central Registry, Token Server)

Onboarding a FIP with an Account Aggregator

  1. Implement (buy or build) an API driven tech platform based on ReBIT FIP API specifications.
  2. The tech platform should enable FIP to
    1. Allow the AA to discover customer accounts as per the identifiers provided by the customer on the AA domain (eg RMN, Customer ID, PAN, Account No, etc).
    2. Authenticate the customer account via OTP based token that the Customer will receive from FIP and enter on the AA domain (mobile, web). This establishes the linkage of the customer accounts with the FIP.
    3. Receive and store the customer consent as received from AA.
    4. Allow the AA to request financial information based on the customer consent presented in the FI request.
    5. Check the validity of consent and process the received FI request by calling internal FIP source systems to fetch financial information.
    6. Once data is available from the FIP source system to encrypt and notify AA of data availability.
    7. Process the AA call to fetch financial information and return encrypted data.
  3. Determine and leverage existing APIs available with FIP to enable Step 2.
  4. For Step 2 & 3, additional integration work may be required so that the new platform can interact with the existing FIP source system.
  5. Ensure that financial data is as per the standard data schemas provided by ReBIT. Refer to (
  6. Enrich the data being shared based on the ReBIT FI data types and schemas.
  7. Expose APIs implemented as part of the tech platform (Step 1 & 2) for AA to call. Refer to the link of FIP API specifications.
  8. Test with multiple AAs on a sandbox environment.
  9. Additionally,
    1. Determine the FI types that are being supported by FIP and for which data is being shared (e.g. CASA, term deposit, credit card account, etc). Refer to FI Type at
    2. Setup test data based on FI Type so that AAs can test with multiple accounts.
  10. Write to for accessing the AA Common Service (Central Registry, Token Server)

Before your FIP and FIU modules go live we recommend they get certified by one of the Sahamati empanelled auditors.