The RBI Account Aggregator framework has moved beyond its early-adopter phase, and lenders now need to focus on operating within it correctly. For a lender that has not integrated with an Account Aggregator as a Financial Information User, the issue is no longer whether the framework is mature enough to rely on. It is. The practical question is what compliant day-to-day use requires.
This article examines consent architecture from a lender's operating perspective, the obligations that come with FIU registration, and the implementation work that is commonly underestimated.
The Consent Artifact: Scope and Obligations
Every AA data fetch starts with a consent artifact. It is not simply a checkbox in an onboarding form. It is a structured, digitally signed object registered with the Account Aggregator. It records the financial data you may access, the accounts covered, the stated purpose, the permitted period, and how long fetched data may be retained.
For a lender operating as an FIU, the most important consent parameters include:
Purpose: The AA Technical Standards specify permitted purpose codes. Credit underwriting uses codes covering loan application processing and creditworthiness assessment. Consent for loan processing cannot later support ongoing account monitoring. That requires separate consent.
Data type scope: The consent must identify the financial information requested, such as savings account transactions, current account data, or a term deposit summary. Account types absent from the consent artifact are outside the permitted scope.
Date range: The artifact defines the historical transaction period available for fetching. A six-month range does not permit a twelve-month request. If policy later requires more history, the lender must start a new consent with revised date range parameters.
Fetch type and frequency: A one-time underwriting fetch permits a single pull. A periodic monitoring consent for portfolio surveillance records the permitted frequency, such as weekly or monthly, together with the validity window.
Data life: The consent states how long fetched data may remain in your systems. Once that period ends, the data must be deleted or anonymized under your data retention policy.
FIU Registration and Operating Requirements
A lender must register as a Financial Information User with the RBI to access data through the AA framework. Registration requires technical compliance with the AA Technical Standards, an AA agreement with at least one Account Aggregator, and the data security and audit logging controls required by the framework.
FIU compliance continues after registration. Your audit system must record each consent initiation, every attempted data fetch, whether successful or not, each revocation received, and every consent expiry. These records must be available for RBI inspection and, in some circumstances, for a borrower seeking their data access record.
Revocation needs particular operational care. A borrower can withdraw consent at any time through the Account Aggregator app, after which you receive a revocation notification. Your systems must immediately stop further fetches under that consent. If a loan application is already in progress, the workflow must record the revocation and address the resulting incomplete data state. You may assess whether alternative data sources support a decision, or tell the applicant that the application cannot continue without consent.
Where Lenders Underestimate the Work
Connecting to an Account Aggregator API is generally the simpler part. The more demanding work sits in the operating systems around access. Teams commonly underestimate the following areas:
Consent lifecycle management: You need to track every active consent, identify upcoming expiries, respond to revocations in real time, and preserve compliant audit records. That calls for a dedicated system layer, rather than a spreadsheet or improvised logs.
Multiple-account handling: One borrower may link accounts held across different FIPs, with a single consent covering accounts at three banks. The fetch returns data from each FIP. Your system must link every payload to the correct account and present a consolidated view to the underwriter. This matters particularly in business lending, where current account history across banking relationships can be relevant.
FIP availability variation: A scheduled fetch from a registered FIP may not succeed on its first attempt. FIPs have maintenance windows and API rate limits. The lender needs controlled retries with suitable backoff, a notification to underwriting when the fetch cannot finish within the application's required time, and an audit record of failed attempts.
Data minimization in practice: The AA framework requires access to be limited to the data types and date ranges needed for the stated purpose. Credit policy therefore needs translation into precise scope parameters, rather than a general request for everything available. Credit and compliance teams should define the minimum necessary scope for each product and encode it in that product's consent parameters.
Borrower Journey and Consent Completion
The lender starts the consent journey on its own platform, but the borrower completes it in the Account Aggregator app or interface. That hand-off affects completion. A borrower who begins a loan application, moves to the AA app, and leaves before completing consent becomes a dropped application.
AA consent completion varies with the borrower profile and the design of the hand-off. Borrowers familiar with AA and already using an AA app may complete the flow smoothly. Someone seeing the framework for the first time, or without the relevant AA app installed, may need clearer guidance.
Completion is partly a UX question: does the lender explain clearly what access is requested and why? It is also a product design question: does the consent step fit naturally into the application, or feel like an abrupt redirect? Both deserve attention because an application that drops at consent has already progressed further than one lost earlier in the funnel.
Limits of the AA Framework
The AA framework covers financial data held by registered FIPs, including banks, insurance companies, pension funds, and certain regulated financial institutions. It does not include informal financial activity, payments on unregistered platforms, or income that does not pass through the formal financial system. For a borrower with substantial informal income, AA data is therefore only part of the picture.
It also excludes credit bureau data, GST returns, income tax filings, and property registry data. Each requires separate access arrangements and consent mechanisms. Underwriting will often combine AA-sourced bank data with bureau pulls and, for business borrowers, relevant formal financial records from other sources.
We are not saying that the consent framework supplies every input a lender may want. We are saying that it provides a strong foundation for the bank transaction data layer of underwriting. A credit operation built on AA data must distinguish what this channel can show from what requires separate sourcing.