Founder
User Interface Design
The account aggregator framework is a Reserve Bank of India-regulated system that moves financial data between institutions through a licensed consent manager. It was introduced under the RBI’s Master Direction on Account Aggregators and went live commercially in September 2021.
Four roles make it work: the User, who owns the data; the Financial Information Provider (FIP), the bank or institution holding it; the Financial Information User (FIU), the lender or fintech requesting it; and the account aggregator itself, a licensed NBFC that only moves consented data and never stores or views it.
Participation now extends well beyond banks. Insurers regulated by IRDAI, depositories and mutual fund registrars regulated by SEBI, and pension fund entities regulated by PFRDA have all joined as FIPs. That means a single consent can pull data across savings accounts, mutual fund folios, and insurance policies in one request rather than one integration per data type, extending the same open finance data-sharing model founders are already evaluating for other product decisions.
A request starts when an FIU asks a user to link accounts and approve a specific, purpose-bound consent. The account aggregator validates that request with the relevant FIPs and, once approved, encrypted data flows from FIP to account aggregator to FIU without the aggregator ever reading it.
Every request carries a consent artifact specifying purpose, data types, validity window, and frequency. Users can view or revoke that consent at any point, and access expires automatically once the window closes. The framework exists largely to address the fragmentation of financial data across providers, a long-standing barrier to comprehensive credit assessment in India’s lending market
Manual document collection is slow, error-prone, and a major reason loan applications stall. This framework gives fintechs verified, structured data directly from the source instead of asking customers to email PDFs or share net-banking logins.
Sahamati’s own ecosystem dashboard puts the network at over 31 crore cumulative linked accounts and nearly 50 crore cumulative fulfilled consents as of June 2026. That scale is why most lending and wealth platforms now treat this integration as a baseline expectation rather than an optional add-on.
NBFCs, registered investment advisers, and stockbrokers currently generate the largest share of completed consents on the network, reflecting how quickly credit and capital markets use cases have scaled past early lending-only adoption (Business Standard, citing Sahamati FY25 data). A wealth platform verifying holdings, or a lender assessing repayment capacity, both draw from the same consent-based pipeline instead of separate document requests.
| Approach | Typical timeline | Engineering effort | Best fit |
|---|---|---|---|
| Build in-house | 4 to 6 months | High: dedicated team for consent APIs, encryption, compliance testing | Large lenders with long-term scale and compliance teams already in place |
| Use a TSP | 6 to 10 weeks | Moderate: TSP handles FIU module, you handle product integration | Mid-size fintechs that want ownership without building core plumbing |
| Use an account aggregator gateway | 2 to 4 weeks | Low: single API layer across multiple account aggregators | Startups and product teams prioritizing speed to market |
Beyond the build path itself, a few factors consistently drive timeline and budget. Certification is one of them: every FIU must complete an information security audit through an empanelled certifier before going live, and re-certification is required whenever the specification changes.
Fixed deposits and recurring deposits, for example, remain unsupported by a large share of banks on the network even now, which means product teams often need a fallback flow for accounts that cannot be fetched.
Budgeting for certification is where most timelines slip. An empanelled auditor has to sign off before an FIU can go live, and any change to the underlying specification can trigger a re-certification cycle. Sequencing this correctly is a technology roadmap planning problem, not something to leave for whichever team notices it first.
Most integration problems show up after launch, not during development. The framework itself is standardized, but participation across banks and account aggregators is not.
A single account aggregator is not connected to every bank. A customer’s savings account might sit with one while their insurer only connects through another, which breaks a single-consent experience into multiple approvals. Consent screens that bury purpose and duration in fine print also drive higher abandonment than any technical failure does.
Data arriving structured but unparsed catches many teams off guard as well. The account aggregator delivers a machine-readable file, not a categorized summary, so a lending team still needs a parsing and categorization layer before that data becomes usable in an underwriting model. Skipping this step is a common reason integrations look complete in a sandbox but stall once real transaction data starts arriving in production, a gap that usually traces back to how the surrounding fintech software development was scoped in the first place.
Getting this right comes down to three things covered throughout this piece: sequencing certification alongside the build instead of after it, designing consent UX so it doesn’t quietly drive abandonment, and planning for the parsing layer a lending team needs once data starts arriving in production. Most integration delays trace back to one of these being treated as an afterthought rather than part of the core build. Zethic builds FIU modules for lending and wealth platforms with that sequencing in mind, mapping certification and consent design alongside the core data pipeline from day one. For a fintech deciding how to approach this integration, whether through a TSP or a gateway, Zethic scopes both paths against actual data needs before committing engineering time to either one.
Let Zethic help you build smarter Not just faster
