Account Aggregator Data in Credit Decisions: Consent-Led Underwriting

What the Account Aggregator framework changes

Under the RBI's framework for Account Aggregators, financial data moves from the institutions that hold it to the institutions that need it, only with the customer's consent. The Account Aggregator carries the data without being able to read it. The consent itself is a structured, signed artefact that states the purpose, the types of data, the date range covered, how long the recipient may keep the data and how often it may fetch it.

The detail matters for anyone designing a pipeline. In Sahamati's published example of a one-time consent for a loan application, the stated purpose is processing the borrower's loan application, and the consent allows about six months of transactions to be kept for fifteen days. Those fields are commitments the lender makes to the borrower, and they travel with the data.

The data is also better than what it replaces. Statements arrive directly from the bank in a structured format, so there is no PDF to tamper with and no extraction step to get wrong. For thin-file borrowers with little credit-bureau history, a clean record of inflows and outflows is often the strongest evidence of repayment capacity a lender can obtain.

Underwriting on consented transaction data

Transaction data supports a richer view of repayment capacity than a bureau score alone. Models can measure the regularity and seasonality of inflows, and the patterns that signal stress, such as cheque returns or recurring overdraft use. For the textile business, seasonal peaks around festivals and the wedding season are part of a healthy pattern, and a model that understands seasonality avoids penalising them.

These models carry the same obligations as any credit model. Reasons for a decline have to be explainable to the applicant, and the variables have to be checked for proxies that stand in for protected characteristics. A model that learns from transaction descriptions, for instance, can pick up signals the lender would never knowingly use, and those features need review before they reach production.

The position: the consent artefact governs the pipeline

Most lending pipelines treat consent as a gate at the front door. Once the data has arrived, it moves into the feature store and the training sets like any other data. That design ignores what the borrower actually agreed to. A consent for processing a loan application, with a data life of fifteen days, does not cover keeping derived features for a year or training a model to sell the borrower an insurance product.

The pipeline has to carry the consent with the data. Every record fetched through an Account Aggregator should be tagged with its consent identifier and expiry. Storage should delete raw data when its data life ends, automatically. Features derived from that data should inherit the same purpose and expiry, because a cash-flow ratio computed from a borrower's transactions is still her data in a different form. Any job that reads consented data, including model training, should check the purpose before it executes.

India's Digital Personal Data Protection Act points the same way, with its emphasis on using personal data for the purpose the person agreed to. Sahamati's guidance on fair use for lending journeys adds an industry expectation on top. A lender that cannot show where every derived feature came from, and under which consent, will struggle to answer either.

The features that outlived the consent

A digital lender based its underwriting on Account Aggregator data and configured its storage carefully. Raw statements were deleted when their data life expired, and the deletion logs were clean. Separately, the data science team kept a feature store of derived variables, such as monthly inflow averages and EMI burden ratios, which had no expiry at all.

A year later, the marketing analytics team asked for a propensity model to identify borrowers likely to want a top-up loan. The feature store was the obvious source, and it held features for applicants whose consent had expired long before, including applicants who had been declined. The model was trained and ready for a campaign when the data protection officer, reviewing the campaign plan, asked which consent covered the training data.

The campaign was stopped before any customer was contacted. The lender rebuilt its feature store so that every feature carries the consent identifier and expiry of its source data, and features expire with that consent. Training jobs now query a purpose register before they read anything, and marketing models draw only on data customers consented to share for that purpose.

Account Aggregator data gives lenders a faster, cleaner basis for credit decisions, and it gives borrowers real control over their financial information. The two depend on each other. A chief risk officer should ask whether the lender could show, for any feature in any model, which consent it came from and whether that consent is still valid. A lending pipeline that can answer that question is one whose outcomes survive scrutiny.