September 28, 2026
An Account Aggregator (AA) API lets a lender or fintech pull a customer's financial data, bank statements, investment holdings, insurance details directly from the source institution, in a structured digital format, only after the customer explicitly consents. It replaces manual document collection and PDF-based bank statements with a real-time, RBI-regulated data pipe.
For NBFCs, banks, and lending-tech teams, this single shift changes how fast a loan can be underwritten, how accurate that underwriting is, and how much manual document-chasing your operations team has to do. This article explains how the framework actually works, what data you can access through it, where it's genuinely useful versus where it still has gaps, and what to check before you integrate one.
The AA framework isn't a niche pilot anymore; it's become one of the largest consent-based data-sharing networks in the world, and it's still growing fast.
As of 31 March 2026, official government data puts the ecosystem at 179 live Financial Information Providers (FIPs), 989 live Financial Information Users (FIUs), over 2.88 billion financial accounts enabled to share data, and 284.6 million accounts already linked by users. In June 2026, the RBI formally recognised Sahamati the industry alliance that coordinates the AA ecosystem as its first cross-sectoral Self-Regulatory Organisation, a sign of how central this infrastructure has become to India's digital lending and open finance stack.
For lending businesses specifically, NBFCs alone account for the largest share of completed data-sharing consents in the ecosystem, using AA primarily to speed up credit underwriting which is the use case most relevant to LetsFin's lending-tech and NBFC audience.
The framework has three core participants, and understanding this terminology is essential before evaluating any AA API vendor.
| Entity | Role | Example |
| FIP (Financial Information Provider) | Holds the customer's financial data | A bank, NBFC, insurer, mutual fund RTA, or pension fund |
| FIU (Financial Information User) | Requests the data to offer a service | A lender, wealth platform, or insurer underwriting a product |
| AA (Account Aggregator) | RBI-licensed NBFC that manages consent and moves data between FIP and FIU it never stores or reads the data itself | Entities like Setu AA, OneMoney, Anumati, FinVu |
The AA is often described as a “consent manager” rather than a data warehouse, because by design it cannot see or retain the financial data passing through it; it only manages the electronic consent that authorises the transfer.
1. Consent request: The FIU (say, an NBFC's loan application) triggers a consent request specifying what data it needs, for what purpose, and for how long.
2. Customer approval: The customer reviews and approves this request inside their chosen AA app, selecting which linked accounts to share.
3. Data pull from FIP: Once approved, the AA requests the specified data from the relevant FIP(s) for example, the customer's bank.
4. Secure, structured delivery: The FIP transmits the data in an encrypted, machine-readable format (not a scanned PDF) directly to the FIU via the AA.
5. Consent expiry/revocation: The customer can revoke consent at any time, and access automatically expires per the terms they approved.
This is a meaningfully different process from a customer emailing a PDF bank statement or granting net-banking screen-scraping access, both of which carry higher fraud, tampering, and data-accuracy risk.
Coverage varies by data category and by institution, which is worth knowing before you scope a build.
| Data Category | Typical Coverage (2026) |
| Savings bank accounts (individual) | Broadly available across most major banks |
| Current accounts (sole proprietor) | Available with most major banks |
| Mutual fund holdings | Available via CAMS and KFin RTAs |
| Equities, ETFs, REITs | Available via CDSL and NSDL |
| Fixed / recurring deposits | Partial only a subset of banks currently support this |
| Insurance policies | Growing, but integration depth varies by insurer |
This uneven coverage is one reason experienced teams treat AA as a strong primary channel for bank transaction data and investment holdings, while keeping a fallback (like statement analysis APIs) for data categories where FIP coverage is still thin.
Most Account Aggregator integrations aren't one single API; they're assembled from a handful of standard TSP (Technology Service Provider) modules, each solving a specific part of the underwriting, compliance, or advisory workflow. Understanding these as separate building blocks makes it easier to scope exactly what you need instead of treating “AA integration” as one undifferentiated project.
| Module | What It Does |
| AA TSP Bank Statement | The core FIU module that connects to and manages consent flows across multiple Account Aggregators, retrieving the customer's raw bank statement data on their behalf. |
| Bank Data AA Analytics API | Takes the raw bank statement already fetched through AA and layers analytics on top categorisation, income patterns, cash flow trends without handling the AA consent flow itself. |
| AA TSP GST | Uses the Account Aggregator framework to pull a customer's GST information, with analytics built on top useful for MSME and business loan underwriting. |
| AA SEBI Analytics | Pulls a customer's mutual fund, stock, and insurance holdings through AA, giving lenders and wealth platforms a fuller financial picture beyond bank accounts. |
| AA Personal Finance Manager (PFM) Module | A front-end layer, including the customer-facing UI, that lets end users see all their linked accounts, expenses, and holdings in one consolidated dashboard. |
These modules are typically combined rather than used in isolation. A lending stack usually starts with the AA TSP Bank Statement module to handle multi-AA consent and retrieval, then layers Bank Data AA Analytics on top to generate underwriting signals from that data. Businesses that need a fuller risk picture add AA TSP GST or AA SEBI Analytics on the same consent rail, pulling in business tax data or investment holdings without a separate integration.
The PFM module is a different kind of building block altogether it's customer-facing rather than backend, and it's most relevant for wealth platforms and neobanks that want to give users visibility into their own finances, rather than lenders using AA purely for underwriting.
Scoping your integration against this list upfront rather than discovering mid-build that you need GST or investment data too is one of the more common gaps teams run into after their first AA integration goes live.
| Method | Data Format | Consent Trail | Speed | Risk of Tampering |
| Manual PDF bank statement | Unstructured, scanned/exported | Manual, hard to audit | Slow depends on customer | Higher PDFs can be edited |
| Screen scraping (net banking login) | Semi-structured | Weak credentials shared | Fast | Requires storing credentials high risk |
| Account Aggregator API | Structured, machine-readable | RBI-mandated electronic consent | Near real-time | Low direct FIP-to-FIU transfer |
• Loan underwriting: Pulling verified bank transaction history to assess repayment capacity without asking customers to upload statements.
• Faster onboarding: Reducing document upload steps during loan or account origination.
• Portfolio and early-warning monitoring: Tracking a borrower's account behaviour post-disbursal, where permitted by consent.
• Personal finance management (PFM) tools: Giving customers a consolidated view of accounts, investments, and insurance in one dashboard.
• Insurance underwriting: Verifying income and existing financial exposure before issuing a policy.
• Eliminates manual document collection and the back-and-forth that slows down loan approvals
• Reduces fraud risk versus editable PDFs or shared banking credentials
• Improves underwriting accuracy with real transaction-level data instead of self-reported figures
• Extends credit access to “thin-file” or new-to-credit borrowers who lack formal credit history but have verifiable transaction data
• Keeps you aligned with RBI's consent-based data-sharing direction, rather than relying on methods regulators are actively discouraging
• Uneven FIP coverage: Not every bank or insurer supports every data category yet fixed deposits and some insurance products are still catching up.
• Dual FIU/FIP obligation: If your business already holds customer financial data (for example, as an NBFC), RBI rules generally require you to also participate as a FIP, not just consume data as a FIU.
• Regulatory eligibility: Only entities regulated by RBI, SEBI, IRDAI, or PFRDA can register as FIUs; this isn't an open API any business can simply plug into.
• Integration overhead: Building and maintaining direct compliance with ReBIT's technical specifications takes real engineering time, which is why most NBFCs and fintechs integrate through a specialist API partner rather than building in-house.
When evaluating providers, compare them on:
• FIP coverage relevant to your customer base (which banks, RTAs, and insurers they're actually live with)
• Consent-flow UX how smooth the approval journey is for your end customer
• Uptime and response times, since a slow AA pull directly slows your loan TAT
• Compliance depth whether they help you meet ReBIT technical specs and RBI direction requirements
• Complementary data layers, such as bank statement analysis or bureau data, to fill gaps where AA coverage is still incomplete
This is exactly the kind of side-by-side comparison LetsFin's Account Aggregator API marketplace listing is built for; it lets you compare vetted AA API partners rather than evaluating each vendor's sales pitch independently. If your underwriting stack also needs statement-level insight beyond what AA currently covers, LetsFin's Bank & Credit Card Statement Analysis API listing is a natural complement.
Is Account Aggregator API free to use?
No. While the RBI-mandated framework itself doesn't charge customers, businesses (FIUs) typically pay their chosen AA and/or API partner on a per-transaction or subscription basis for integration, consent management, and data-fetch services.
Is Account Aggregator API safe?
Yes. Data is encrypted and transferred directly from the FIP to the FIU via the AA, which cannot read or store the data itself. Access requires explicit, revocable customer consent, and the entire framework operates under RBI's Master Directions.
Can any company become a Financial Information User (FIU)?
No. Only entities regulated by RBI, SEBI, IRDAI, or PFRDA can register as FIUs. If you already hold customer financial data, you're also typically required to register as a FIP.
How is Account Aggregator different from screen scraping?
Screen scraping requires customers to share their net-banking credentials with a third party, which carries significant security and reliability risk. AA never asks for credentials; it moves data through an RBI-regulated, consent-driven pipeline instead.
What is the difference between an FIU and an FIP?
An FIP holds the customer's financial data (like a bank or insurer). An FIU is the entity requesting that data to deliver a service, such as a lender assessing a loan application.
Does Account Aggregator replace bank statement analysis tools?
Not entirely. AA is the data-access layer; statement analysis and bureau tools often sit on top of it to categorize, score, or flag that data for underwriting decisions and they remain useful where AA's FIP coverage (like some insurers or deposit products) is still incomplete.
The Account Aggregator API has moved from regulatory pilot to core lending infrastructure, and RBI's mid-2026 recognition of Sahamati as its self-regulatory body signals it's here to stay. For lenders and fintechs, the real decision isn't whether to explore AA; it's which partner offers the FIP coverage, compliance support, and integration speed your underwriting stack actually needs. Compare vetted Account Aggregator API providers on LetsFin to find the right fit without running separate vendor calls yourself.