If you've ever clicked "Sign in with Google" and watched an app request three specific scopes instead of your actual password, you already understand the core idea behind India's Account Aggregator framework. The twist: instead of brokering access to your contacts or calendar, it brokers access to your bank statements, and it was built specifically so lenders could underwrite a loan without ever touching your raw credentials.
That's a more interesting systems problem than it sounds, and almost none of the writing about it treats it as one.
The Three Roles You Need to Know
The framework defines three parties. A Financial Information Provider (FIP) is wherever your data already lives — your bank, your insurer, your mutual fund registrar. A Financial Information User (FIU) is whoever wants that data, typically a lender evaluating a loan application. And the Account Aggregator (AA) itself is a licensed NBFC that sits in between, doing exactly one job: moving a consent artifact from you to the FIU, and moving the data it authorizes from the FIP back to the FIU.
Here's the part that matters for anyone who's built an OAuth flow before: the AA never stores or even sees your financial data. It only ever handles the consent — a cryptographically signed, time-bound, purpose-bound token that specifies what data, for how long, and for what stated reason. The data itself flows directly from FIP to FIU, encrypted, with the AA acting purely as a routing and consent-logging layer. No password sharing, no screen-scraping, no PDF statement uploads that someone's underwriting team has to manually re-key.
How Big This Actually Is
This isn't a pilot anymore. As of March 2026, India had 17 RBI-licensed Account Aggregators operating, with 13 of them already carrying live data traffic, against more than 135 live Financial Information Providers — including 72 banks and 57 insurers feeding data into the network (CASParser, "State of Account Aggregator in 2026", March 2026).
What's notable in that same reporting is the unevenness: a handful of licensed AAs still show zero live FIP integrations, which tells you this is infrastructure still being wired up in production, not a finished, evenly-adopted standard. If you're building anything that depends on it, that unevenness is itself a design constraint — you can't assume every bank a customer uses will actually respond.
Why Lenders Care About This at the API Level
Before this existed, a lender verifying income or transaction history had exactly two bad options: ask the borrower to email PDF statements (which then need OCR or manual review, and which are trivially editable before they're sent), or do screen-scraping with stored bank credentials (which is a security incident waiting to happen and which most banks actively try to block).
Consent-based data sharing replaces both with something closer to a webhook contract. The lender requests a consent with a defined scope — say, six months of savings account transactions, for the stated purpose of loan underwriting, expiring in 24 hours. The borrower approves it once, inside their AA app, the same motion as approving an OAuth consent screen. The data arrives as structured, machine-readable records instead of an image of a bank statement, which means it can feed straight into an underwriting model instead of a data-entry queue.
That's a real reduction in attack surface, and it's also just less janky engineering. Nobody has to write a brittle PDF parser that breaks every time a bank redesigns its statement template.
| Account Aggregator | Screen Scraping | Manual PDF Upload | |
|---|---|---|---|
| Credentials shared | Never | Bank login (stored or proxied) | None, but data is unverifiable |
| Data format | Structured, machine-readable | Scraped HTML/DOM, fragile | Image/PDF, needs OCR |
| Consent granularity | Scoped, time-bound, revocable | All-or-nothing | None |
| Audit trail | Cryptographically signed log | Usually absent | Manual, easy to fake |
The Tradeoffs Nobody Skips Past
None of this is free. Standardizing data formats across 72 different banks' core banking systems, each with its own legacy quirks, is genuinely hard — the AA spec defines a common schema, but mapping every FIP's internal representation onto it consistently is an ongoing integration job, not a one-time conversion. Consent requests can also span multiple FIPs at once, and a lender's underwriting flow now has to handle partial failure gracefully: what do you do when four out of five linked accounts respond instantly and the fifth bank's system is having a bad day?
There's also a real question of whether revocable, purpose-bound consent actually gets enforced downstream once an FIU has the data in hand, versus just being a compliance artifact. The framework gives you the rails for that enforcement; whether every FIU's internal systems actually respect a consent's expiry is a separate, harder-to-audit problem.
Where This Connects to Loan Marketplaces
A single lender plugging into this framework speeds up underwriting for their own product. It still doesn't answer a borrower's actual question: which of dozens of lenders, each with their own appetite and rate, is going to give the best deal for this specific profile? That's the matching problem a marketplace exists to solve, and it's a separate layer sitting on top of whatever data-access framework any individual lender uses underneath.
SwipeLoan, as a loan marketplace comparing offers across 100+ RBI-registered lenders, operates at that layer — it's the thing a borrower actually interacts with, regardless of which underwriting plumbing each partner lender runs behind the scenes. Worth a look if you want to see what the borrower-facing side of all this consent-and-data engineering eventually turns into.
If you've actually integrated with an Account Aggregator as an FIU, I want to hear how you're handling the multi-FIP partial-failure case — that feels like the part most write-ups skip entirely. Drop your approach in the comments.
Top comments (0)