Account Aggregator Just Got a Price List: What Changes for Lenders from 1 November

From 1 November 2026, a lender pays a standard fee of roughly ₹5.88 to ₹6.55 for each bank account whose data is successfully shared through the Account Aggregator network. Banks start earning ₹2.80 of it from 1 December, but only above a delivery success floor, and the RBI expects every aggregator to be interoperable by 31 December. Over-collection now costs money, monitoring frequency becomes a budget decision, and the interpretation problem stays exactly where it was.

Three changes land in the Account Aggregator ecosystem over the next eleven weeks, and together they alter the economics of consent-based data for every lender using the network.

One distinction worth holding onto: the pricing comes from a circular issued by Sahamati, which the RBI recognised on 5 June 2026 as the self-regulatory organisation for the Account Aggregator ecosystem. Interoperability is the RBI's own decision, announced in its Statement on Developmental and Regulatory Policies on 7 October, with the implementing detail still to come. The two sit at different levels of the regulatory stack. The circular itself has not been published; the fee detail below is as reported by Business Standard on 13 October. Anyone building a compliance position should get the primary documents from their aggregator rather than rely on commentary, including this.

The fee structure

Using the circular's own benchmark of a seven-month bank statement, a lender pays between ₹5.88 and ₹6.55 per bank account whose data is successfully shared, with the exact figure depending on how many months are requested. The full rate card by month range has not been made public.

The lender receives a single bill from the AA and the AA distributes the shares. Under the circular, entities in the network cannot charge the customer directly for sharing their own data. Aggregators can still bill lenders separately for value-added services, such as custom software, on top of the standard fee.

The charge is termed a DPI utility fee, framed as covering the compliance cost of running the network: two-factor authentication, consent dashboards, cybersecurity. Two things are genuinely new. Data providers are being paid for the first time, having previously borne integration and delivery cost for no return. And pricing is common across the network under one standard contract, replacing separate bilateral deals, including those negotiated through technology service providers.

The first-order consequence: AA data now has a marginal price

Until now, the cost of an AA fetch has been bundled, bilaterally negotiated, and largely invisible at the level of an individual credit decision. From 1 November it is a line item with a per-account price attached to success.

That changes behaviour in one specific way: requesting more than you need now costs money.

Pulling twenty-four months when twelve supports the decision has always been questionable practice and, under the DPDP data minimisation obligation, a compliance exposure. It now also has a price. The same applies to pulling every account a borrower holds rather than the accounts the assessment requires.

This is a rare case of three pressures pointing the same way. Minimisation is now simultaneously a privacy obligation, a cost saving and, because a shorter and better-targeted pull produces a cleaner analysis, usually better practice anyway.

The arithmetic worth running before 1 November

Two numbers every lender should compute for their own book. The second is the one that will surprise people.

Origination. At roughly ₹6 per account, a borrower with four accounts costs about ₹24 per full pull. At 5,000 applications a month averaging two accounts each, that is in the order of ₹60,000 a month. Material but manageable, and comfortably below the cost of the manual collection it replaces.

Monitoring. This is where the model needs thought. A portfolio of 10,000 live accounts, each borrower averaging two bank accounts, refreshed monthly, is 20,000 account-fetches a month: in the order of ₹1.2 lakh monthly, or roughly ₹14 lakh a year, for the data alone at the seven-month benchmark rate. A refresh that requests only the latest month may price lower, since the fee varies with the range requested, but the rate card that would settle it is not public.

That figure is not prohibitive against the credit losses early detection prevents. But it does convert monitoring frequency from a technical default into a budgeted design decision, and it rewards being deliberate:

• Risk-tiered refresh frequency. Monthly on watchlist and higher-exposure accounts, quarterly on the performing book, with promotion between tiers driven by signal rather than by calendar.
• Event-triggered fetches on top of a slower baseline: a bounce, a limit breach, a missed collection.
• Targeted account selection. Refreshing the operating account monthly does not require refreshing every account the borrower holds.

One caveat, stated because it changes the arithmetic materially: the available reporting does not establish whether each fetch under a recurring consent is charged separately, or whether recurring consents are priced differently from one-time pulls. Confirm this with your AA before modelling. If each refresh is charged at the per-account rate, the tiering above is not an optimisation but a requirement. The consent itself already sets a ceiling: Sahamati's loan monitoring consent template allows at most five fetches a month, with up to six months of history per fetch.

The success-rate floor is the most underrated change

Banks will receive their share only on meeting a minimum monthly data-delivery success rate: 80% from 1 December, rising subsequently.

This is the first time FIP data quality has had money attached to it, and it addresses the ecosystem's most persistent practical complaint. Until now, a data provider that returned errors, timed out, or served thin narration bore no consequence. It was absorbing integration cost for no revenue, so the incentive ran the wrong way entirely.

For lenders, the material question is not whether fetch success improves in aggregate but whether narration quality improves. As we covered in our post on what AA does and does not solve, the transaction narration an FIP populates is the field all categorisation depends on, and richness varies substantially between institutions. A success-rate floor measures whether data arrived. It does not obviously measure whether the narration that arrived was usable.

Worth tracking directly on your own fetches from December onward: success rate by FIP, and separately, narration completeness by FIP. If the second improves alongside the first, this change is more significant than the pricing.

Interoperability, and a correction to what we wrote earlier

In our earlier post on Account Aggregator we wrote that there is no universal interconnection, that a borrower's bank might be reachable through one aggregator while their insurer is reachable only through another, and that "your AA choice constrains your coverage, and that constraint is not visible from licence status."

That was accurate when written and is now being deliberately fixed. The RBI has decided to implement interoperability among NBFC-AAs, so that customers can share their financial information from different providers through any aggregator of their choice, with implementation expected by 31 December 2026.

How it will be wired has not been specified. Whether providers keep integrating with each aggregator or aggregators connect to one another is, in the words of Sahamati's chief executive, a technical design choice, and as of mid October the specifications had not been issued. Nor is it yet defined how aggregators pay each other when a fetch crosses from one network to another.

The problem this solves is specific and has been expensive. A lender signs with one or two aggregators. The borrower may not be registered with either. Data providers, facing separate onboarding work and legal process for every new aggregator, did not onboard all of them. The result was drop-off at the point of consent for reasons entirely unrelated to the borrower's willingness to share.

For scale: Sahamati lists 17 operational aggregators, 176 data providers and 1,076 data users, and its dashboard shows about 380 million data deliveries in September 2026, up from 295 million in June.

The same RBI statement also brings bank deposit information into the Consolidated Account Statement that depositories send investors, routed through NBFC-AAs, on the same 31 December timeline.

The practical consequence is that aggregator selection stops being a coverage decision and becomes a service decision. Once interoperability is live, you choose an AA on reliability, support, latency and commercials rather than on which banks it happens to have onboarded. Multi-AA arrangements maintained purely for coverage become redundant, which is worth reviewing against contracts signed on the old assumption.

Check your technology service provider contracts

Under the new model, technology service providers sitting between lenders and aggregators receive no share of the standard fee and are not directly regulated within it. Industry participants expect their margins to compress, and some aggregators with their own technology arms may offer that layer to lenders at no cost. One TSP founder told Business Standard the model has "a fundamental incentive misalignment, with no benchmarking on costs"; aggregator executives in the same report countered that TSPs had been unreasonably profitable compared with AAs.

If your AA integration runs through a TSP, the commercial basis of that arrangement has changed. Two things to establish: what you are actually paying the TSP for now that fee distribution excludes them, and whether your aggregator provides the same integration layer directly.

What none of this changes

Fee standardisation makes the network's economics transparent. The success-rate floor should improve delivery reliability. Interoperability removes the coverage constraint and should reduce consent drop-off materially.

All three improve the pipe. None of them touches what arrives through it.

Structured JSON still gives you a date, an amount, a direction and a narration string. Whether that debit was an EMI or a supplier payment, whether that credit was a sale or a loan disbursal or the borrower moving money between their own accounts, remains an inference from the narration. The spread between tools on exactly that inference was 92.8% against 80.3% on 200,001 identical transactions.

There is a second-order effect worth naming. Cheaper, more reliable, more widely reachable data means more AA volume and more lenders moving more of their book onto the channel. The extraction problem recedes further. The interpretation problem does not. It simply arrives faster and in greater quantity, which makes it a more binding constraint rather than a less binding one.

Two other things also remain untouched. Borrowers still choose which accounts to link, so a clean structured feed from three of five accounts still looks complete, and cross-verification against GST filings and bureau data remains the only way to catch the gap. And consent scope is still decided at origination: a one-time consent taken to underwrite does not authorise a fetch in month seven, whatever the fee model says.

Before 1 November

1. Confirm fetch pricing for recurring consents with your aggregator. This determines whether your monitoring model works as designed.
2. Model origination and monitoring data cost separately against your own volumes and account counts.
3. Review your data range defaults. If you pull twenty-four months by habit, that default now has a price as well as a compliance exposure.
4. Design risk-tiered refresh frequency rather than refreshing the whole book on one schedule.
5. Audit your TSP arrangement against the new fee distribution.
6. Plan to consolidate aggregators once interoperability is live, when coverage stops differentiating them.
7. Instrument success rate and narration completeness by FIP from December, so you can see whether the quality mechanism is working on your own traffic.

Frequently asked questions

What is the new Account Aggregator fee from 1 November 2026? A standard per-account fee set by a Sahamati circular, benchmarked at ₹5.88 to ₹6.55 for a seven-month bank statement depending on the months requested, payable by the lender on each account whose data is successfully shared. Of that, ₹2.80 goes to the data provider and ₹0.40 to Sahamati, with the remainder to the aggregator.

Who pays the AA fee, the lender or the customer? The lender, as the financial information user, receives a single bill from the aggregator, which distributes the shares. Under the Sahamati circular, entities in the network cannot charge customers directly for sharing their own data.

Do lenders pay for AA fetches that fail? The fee is described as payable on data successfully shared, which implies failed fetches are not charged. How partial fetches and timeouts are treated is not settled in public reporting, so confirm it in your aggregator contract.

Why are banks being paid under the new model? Data providers previously bore integration and delivery costs with no revenue, which left no incentive to maintain reliable service. Their share is conditional on meeting a minimum monthly data-delivery success rate, beginning at 80% from 1 December 2026 and rising thereafter.

What is AA interoperability and when does it apply? The RBI announced on 7 October 2026 that it will implement interoperability among NBFC account aggregators, expected by 31 December 2026, so a customer can share information from any provider through any aggregator of their choice. The technical design, including whether providers still integrate with each aggregator, had not been specified by mid October.

How much will AA monitoring cost for a loan portfolio? It depends on portfolio size, accounts per borrower and refresh frequency. A 10,000-account portfolio averaging two bank accounts per borrower, refreshed monthly, is around 20,000 account-fetches monthly, in the order of ₹1.2 lakh a month at the benchmark rate. Whether each refresh under a recurring consent is charged separately should be confirmed with your aggregator.

Does the new fee model change what AA data contains? No. Pricing, success-rate obligations and interoperability affect cost, reliability and reach. Categorisation, income derivation, obligation discovery, fraud detection and conduct analysis all still have to be performed on the data after it arrives.

---

Fee figures are from the Sahamati circular as reported by Business Standard on 13 October 2026; the circular itself has not been published. The interoperability timeline is from the RBI statement of 7 October 2026. Verify against the primary documents before acting on either. Fiscus ingests AA-delivered data natively and applies the same analysis to AA and document paths. Book a parallel evaluation.