Account Aggregator Consent: What a Lender Actually Sees When You Tap Approve

Somewhere in most loan applications now there is a screen asking you to select your bank and approve a consent request. Tap through it and your statements reach the lender in seconds without a single PDF changing hands. Having worked on the lending side through this transition, we can tell you it is a genuinely better system than uploading documents, and also that almost nobody reads the consent parameters they are agreeing to. Those parameters determine what is shared, for how long, and whether the access continues after your loan is disbursed.

What the framework actually is

The Account Aggregator framework is an RBI-regulated data sharing system. An Account Aggregator is a licensed NBFC whose only function is to move financial data from institutions that hold it to institutions you want to share it with, based on your explicit consent.

Three roles matter. The Financial Information Provider is the institution holding your data, typically your bank. The Financial Information User is the entity requesting it, in this case the lender. The Account Aggregator sits between them and moves the data without being permitted to read or store it.

That last point is the structural safeguard. The aggregator is data-blind by design, and it cannot retain the information passing through it. It is a pipe with a consent register, not a repository.

The consent artefact itself is the part worth understanding, because it has parameters you can inspect before approving.

The five parameters in every consent request

Each consent request specifies these, and they are visible in the approval screen if you look.

Purpose states why the data is being requested. For a loan application, it should read as loan underwriting or a similar description. A purpose that does not match what you are actually doing is a reason to stop.

Data range specifies the historical period being pulled, commonly six, twelve, or twenty-four months of transaction history for a lending decision.

Data type specifies what is being fetched. Bank transaction data is the usual one for lending, but the framework also covers deposits, mutual funds, insurance, and pension data. A personal loan application has no business requesting your investment holdings.

Frequency and fetch type is the most overlooked. A one-time fetch pulls your data once. A recurring fetch pulls it periodically for the life of the consent, which can be perfectly legitimate for a lender monitoring an active loan, and is not appropriate for an application that was declined.

Consent validity is the duration of the arrangement. This is where borrowers routinely approve far more than they intend, agreeing to a year of recurring access for a single application decision.

What the underwriter does with the data

The data arrives structured rather than as images, which means analysis is automated and complete. Every figure below is computed on every application.

Income verification is the first step, identifying recurring credits that match a salary pattern by amount, date regularity, and narration. This is why a salary credited through NEFT from an identifiable corporate account supports a stronger application than an identical amount transferred from an individual’s account.

Obligation detection is the second. Recurring debits matching EMI patterns are identified and compared against what you declared and what your bureau report shows. Undeclared borrowings surfacing here damage a file more than the borrowing itself would have.

Balance behaviour is the third. The system computes average daily balance, the number of days the account ran below a threshold, and the balance position immediately before each EMI date. An account that reaches zero just before every EMI is treated as thin liquidity regardless of income.

Return and bounce history is the fourth and it carries heavy weight. Our guide on what an EMI bounce actually costs covers why these entries matter so much.

Spend pattern flags come last. Payments to multiple lending apps, gambling platforms, or frequent small-value borrowings all register and are treated as risk signals independent of income.

One consequence of this completeness is worth internalising before you apply. Because obligations are detected from your actual transaction flow rather than from what you declare, the eligibility you will be offered is computed from your real fixed outflows, not your estimate of them. Borrowers routinely underestimate their own committed EMIs by a few thousand rupees a month and are then surprised by a smaller sanction. Add up every recurring debit yourself and check what that leaves against our Eligibility Checker before you apply, so the offer you receive is the one you expected rather than a disappointment.

Your rights and how to use them

Four things you can do that most borrowers never exercise.

Revoke consent at any time. This is a legal right, not a favour, and it is done through the Account Aggregator app you used to grant it rather than through the lender. Revocation stops future fetches; it does not delete data already lawfully received.

Inspect your consent history. Every aggregator app maintains a log of active and past consents showing who requested what and when. Reviewing this once a quarter is worth the five minutes, particularly if you have applied to several lenders.

Refuse consents that exceed the purpose. A personal loan application requesting mutual fund and insurance data is asking for more than the decision requires, and declining that specific data type is usually possible.

Verify that the aggregator is licensed. Only RBI-licensed entities may operate as Account Aggregators, and the list is published on the RBI website. Any app claiming to fetch your bank data outside this framework is not operating under it. Our guide to the RBI-verified digital lending app directory covers how to confirm the lender itself is regulated.

A word on what the framework does not protect you from. Consent is genuine consent, which means data you approve is lawfully shared and the lender may retain and use it in line with the stated purpose and its own privacy policy. Revoking a consent stops the tap; it does not recall what already flowed. This is not a flaw in the design, but it does mean the decision point that matters is the approval screen, not the revocation screen afterwards. Treat the moment of approval with the same care you would give to signing a document, because that is legally what it resembles.

What this means for how you manage your accounts

Two practical consequences follow from the shift to structured, complete data.

Selective disclosure has stopped working. Where you consent to one account and your bureau report or salary pattern implies another exists, the gap is visible and reads worse than the contents of the account you withheld. Plan on full visibility.

Recent conduct matters more than it used to. Because the analysis is automated and covers every transaction, three months of clean account behaviour genuinely shows, and so does three months of stress. If you know you will apply for a significant loan in six months, the account you run in the intervening period is the account the lender will read.

The practical next step is to open whichever Account Aggregator app you used for your last loan application and look at your active consents. If any are set to recurring fetch for an application that was completed or declined months ago, revoke them today. It takes under a minute, and there is no reason for a lender you are not borrowing from to keep receiving your transaction data.