FIP vs FIU: Understanding the Two Core Roles in India’s Account Aggregator Ecosystem

Every Account Aggregator transaction involves two financial institutions in distinct roles: the Financial Information Provider (FIP), which holds the data, and the Financial Information User (FIU), which consumes the data. The AA sits between them as the consent and routing layer.

Understanding the difference between FIP and FIU is essential for any organisation building on the AA ecosystem. The roles carry different regulatory obligations, technical responsibilities, and commercial implications. This guide clarifies both roles in detail, including which institutions qualify for each and what the operational requirements entail. To understand the broader system context, here’s what the account aggregator framework is and how these roles fit into it.

What Is a Financial Information Provider (FIP)?

A Financial Information Provider is an institution that holds financial data belonging to individuals or businesses and has the technical capability to respond to data requests from the AA ecosystem.

FIPs are the data sources. When a borrower’s bank account data is shared through the AA pipeline, the bank is the FIP. It receives the data request (validated against the consent artefact), retrieves the relevant transaction data, encrypts it using the FIU’s public key, and transmits it to the AA. To see how this fits into the full data flow, here’s how the account aggregator process works from data source to data user.

Institutions that can be FIPs under the AA framework include scheduled commercial banks (regulated by the RBI), NBFCs (regulated by the RBI), insurance companies (regulated by IRDAI), mutual fund asset management companies (regulated by SEBI), pension funds (regulated by PFRDA), and depositories and depository participants (regulated by SEBI).

To become a live FIP, an institution must integrate with the AA network’s technical APIs, implement the data schema for the financial information types it holds, and complete the network’s certification process. The Sahamati website maintains a public registry of live FIPs.

What Is a Financial Information User (FIU)?

A Financial Information User is an entity that requests financial data from FIPs through the AA to make financial decisions about an individual or business.

FIUs are the data consumers. A lending NBFC that wants to assess a borrower’s bank transaction history is an FIU. A wealth management platform that wants to aggregate a client’s investment portfolio is an FIU. An insurance company that wants to assess a policyholder’s financial health is an FIU. This is exactly how lenders use account aggregator data in underwriting decisions.

To become a registered FIU, an entity must enter into a commercial agreement with one or more licensed AA operators, integrate the AA’s FIU-side APIs, implement the cryptographic infrastructure to decrypt FIP-delivered data (the FIU’s private key infrastructure), and comply with the AA operator’s data governance requirements.

FIUs must be regulated entities under at least one of the four financial sector regulators (RBI, SEBI, IRDAI, PFRDA). Unregulated entities cannot be FIUs.

Key Differences: FIP vs FIU

Role in the data flow: FIPs supply data; FIUs consume data. The AA sits between them, managing consent and routing.

Regulatory basis for participation: FIPs participate because they hold customer financial data. FIUs participate because they need customer financial data for regulated financial services.

Technical responsibilities: FIPs must implement the data provision API, receive data requests, retrieve transaction data, and return encrypted packages. FIUs must implement the data consumption API, initiate consent requests, manage sessions, and decrypt received data.

Data exposure: FIPs send data out; they never receive borrower data from other institutions through the AA pipeline (unless they are also registered FIUs). FIUs receive encrypted data from FIPs; they cannot read data from other FIUs’ requests.

Liability: FIPs are responsible for the accuracy of the data they provide. FIUs are responsible for how the data is used; they must comply with purpose limitation, retention limits, and the Digital Personal Data Protection Act 2023’s processing requirements.

Consent relationship: FIPs validate and honour consent artefacts; they verify the artefact before releasing data. FIUs initiate consent requests; they specify what data they need and for what purpose. To understand this interaction in motion, here’s how account aggregator data flows securely between institutions.

Can an Institution Be Both FIP and FIU?

Yes. Many institutions hold financial data and also consume financial data for service delivery. A bank, for example, holds customer account data (FIP role) and may also want to access a credit applicant’s data from another bank for lending decisions (FIU role).

Institutions operating in both roles must maintain separate technical infrastructure for each role, the FIP API set and the FIU API set, and must comply with the governance requirements of both roles independently.

For regulatory purposes, the FIP and FIU roles are treated as distinct even when the same institution holds both. A bank cannot use its FIP access to its own customers’ data for FIU purposes; each data access must follow the AA consent flow regardless of the institution’s dual role.

Which Data Types Do FIPs Currently Support?

The AA framework defines specific financial information types that FIPs can provide. As of 2025, the active financial information types include:

Banking data (deposit accounts): savings accounts, current accounts, overdraft accounts, transaction history, balance, and account details.

Banking data (term deposits): fixed deposits and recurring deposits, principal, interest, and maturity details.

Securities data: Demat accounts, mutual fund holdings via depositories.

Insurance data: Life and general insurance policies via IRDAI-regulated insurers.

Pension data: NPS account holdings via PFRDA-regulated entities.

The coverage of data types is expanding. GST return data (via NeSL), ITR data (via the Income Tax Department), and EPFO data have been discussed for inclusion. Each addition would significantly expand the analytical value of AA data for lending decisions.

✅  Key Takeaways

• FIPs are data holders (banks, insurers, and mutual funds) that respond to data requests with encrypted, borrower-consented financial data.
• FIUs are data consumers (lenders, wealth managers, and insurers as consumers) that request data through the AA to make financial service decisions.
• The AA is not an FIP or FIU; it is the regulated intermediary that manages consent and routes encrypted data between the two.
• Institutions can be both FIP and FIU simultaneously but must maintain separate infrastructure and governance for each role.
• FIUs must be regulated entities under the RBI, SEBI, IRDAI, or PFRDA to participate in the AA ecosystem.
• Active data types from FIPs cover banking, securities, insurance, and pension data, with expansion to tax and GST data expected.

Frequently Asked Questions

Conclusion

The FIP-FIU architecture is the structural foundation of the AA ecosystem’s security and trust model. By separating the data holder from the data consumer and placing a regulated, consent-managing intermediary between them, the framework ensures that financial data can flow for legitimate purposes without creating surveillance infrastructure or unregulated data access.

For institutions evaluating AA participation, whether as FIPs building data provision capability or as FIUs building data consumption workflows, understanding this architecture is the starting point for both the technical integration and the regulatory compliance work that follows. This is how an account aggregator is transforming digital lending ecosystems.