Start Your Project Today
Tell us about your project — we’ll get back within 24 hours
- 8 MIN READ
- Views: 288
How Does the Account Aggregator Framework Work for Fintechs?
By Ram Nethaji
Founder
FinTech app development cost
User Interface Design
Custom software development
FinTech app development services
The account aggregator framework lets a bank, insurer, or fund house share a customer’s financial data with a lender or fintech, but only after the customer gives explicit, time-bound, revocable consent. For fintechs, it replaces manual bank statement uploads with a live, structured data pipeline.
What Is the Account Aggregator Framework?
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.
What Happens Between Consent and Data Delivery?
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
Why Are Fintechs Replacing Bank Statement Uploads With This System?
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.
- Faster underwriting since data arrives in a standard, machine-readable format instead of scanned statements
- Fewer drop-offs during onboarding because customers approve a consent flow instead of uploading documents
- Access to a wider data footprint, including investments, insurance, and pension holdings, not just a single bank account
- Lower fraud risk since data comes directly from the regulated source rather than a self-uploaded document, the same verified-data principle that shapes how a KYC and AML module is built for onboarding
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.
Should You Build In-House, Use a TSP, or Use a Gateway?
Every FIU faces the same fork: build the FIU module internally, work through a Technology
Service Provider (TSP) that specializes in these connections, or use a gateway platform that
abstracts multiple account aggregators behind one integration. Each path trades control against
speed differently, mirroring the broader build versus integrate decision every fintech eventually
faces across its stack, not just for this one connection.
| 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 |
How Long Does Integration Take and What Drives the Cost?
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.
- Scope of financial information requested, since each new data category (deposits, mutual funds, insurance) needs separate FIP connections
- Certification and audit cycles, including quarterly self-tests and periodic security re-certification
- Consent UX design, since a confusing consent screen drives drop-offs regardless of backend readiness
- Ongoing FIP coverage gaps, since not every bank supports every data category yet
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.
Why Do So Many Integrations Stall in Production?
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.
How Does Zethic Help Fintechs Get This Integration Right?
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
Frequently Asked Questions
What is the account aggregator framework in simple terms?
It is an RBI-regulated system that lets a bank or fintech access a customer’s financial data from another institution, but only with that customer’s explicit, revocable consent.
Who are FIPs and FIUs in this system?
An FIP is the institution holding the data, such as a bank or insurer. An FIU is the lender or fintech requesting that data to offer a product or service.
Does the account aggregator itself see or store customer data?
No. The account aggregator is described as data-blind, meaning it routes encrypted data between FIP and FIU without reading or retaining it.
How long does integration typically take?
It depends on the approach. Gateway integrations can go live in 2 to 4 weeks, TSP-based integrations typically take 6 to 10 weeks, and in-house builds often take 4 to 6 months.
Can a customer revoke consent after sharing data?
Yes. Consent is time-bound and revocable at any point, and access expires automatically once the approved window closes.
Is this integration mandatory for every fintech?
It is not legally mandatory, but it has become a practical expectation for lending, wealth, and personal finance products competing on onboarding speed and data quality.
Let’s build your app together
Ram brings deep expertise in product strategy and system architecture across fintech, SaaS, and AI platforms. He specializes in pre-execution planning to help teams build scalable technology foundations and avoid costly rebuilds.
