A credit head at a mid-sized NBFC told me recently about something that had been bothering her. Her team had digitised the loan application flow, integrated AA, plugged in the bureau, parsed bank statements automatically. The journey was faster than it had ever been. And yet, the application her customer was filling out looked almost identical for everyone — a salaried borrower with ten years of credit history, a first-time business loan applicant, an existing-to-bank customer whose salary had been landing in their account for years. Same fields. Same document list. Same flow. 

The data layer underneath had changed completely. The form on top had not. 

The loan application is no longer one thing. It is becoming a function of who is applying — and the lenders who recognise this early will run a structurally different onboarding system from the rest. 

The fixed-form loan application made sense for a long time. Lenders couldn't tell borrowers apart at the start of an application, so they asked everyone the same questions. The form was uniform because the lender's information about the borrower was uniform — close to nothing, regardless of whether the borrower had banked there for a decade or walked in for the first time. 

That is no longer true, and the change is large. 

The Account Aggregator framework now has 284.565 million linked accounts and 431.072 million+ consent requests fulfilled, with 276.22 million monthly data shares as of March 2026. AA-enabled disbursements are running at ₹17,000 crore a month, and all 12 public sector banks are live on the network alongside the major private lenders. Add GSTN's verified business filings. Add the credit bureau's repayment history. For an existing-to-bank customer, add the bank's own systems — salary credits, transaction patterns, prior product holdings, deposit behaviour — sitting in the core banking system and CRM.  

How much of this is already available before the borrower types her first character into the application depends entirely on who she is. For a ten-year salary account holder applying for a personal loan, almost everything underwriting needs is already inside the bank. For a new-to-bank thin-file MSME owner in Salem, very little is. The lender's information about the borrower is no longer uniform. Yet the application form asks the same questions of both. 

This is not just an infrastructure observation. As early as 2024, in Bajaj Finance's Q4 FY24 earnings call, Managing Director Rajeev Jain described the AA ecosystem as "a fundamental shift in the way business will be done… equipping us to collect client consent to access their bank statements in a structured manner and allow us to underwrite them right, price them right, expand exposures, and monitor the portfolio for early warning."  

When the MD of one of India's largest retail NBFCs publicly calls AA a fundamental shift in how the business works, this isn't infrastructure waiting to be adopted. It's already the rail the largest lenders are running on. The application form, in most places, is still running the old one. 
 
For most lenders, AA and source-pulled data have been added on top of the existing checklist, not used to replace it. The borrower consents to AA and uploads the bank statement PDF. The application asks the same questions of the ten-year salary account holder and the new-to-bank thin-file applicant. What's missing is not technology — it is the recognition that the application itself should now look different for different borrowers. 

When the application starts to adapt to the data layer underneath it, five things start happening, and the loan application stops being a single shape. 

The first is that existing-to-bank customers run shorter journeys. The bank already has her salary history, her transaction patterns, her prior products, her deposit behaviour. Asking her to upload six months of bank statements is asking her to give the bank what the bank already has. The application becomes a thin layer of confirmation and intent — directionally, a handful of fields rather than a full document checklist. 

The second is that new-to-bank, thick-file borrowers run medium journeys. AA pulls bank data. GSTN delivers business filings. The bureau provides repayment history. Most of what underwriting needs arrives without the borrower lifting a finger. The application fills the residual gap — declared intent, end-use, anything the source rails do not carry. 

The third is that new-to-bank, thin-file borrowers run longer, deeper journeys — but not the same long form everyone else used to fill. The lender genuinely needs to know more, so the application gets richer, not lengthier. It branches into income context, business operations, intent, co-applicant data. The shape of a thin-file application looks nothing like the shape of a thick-file one. They are different journeys running on the same system. 

The fourth is that correction starts happening inside the application instead of after it. A field is wrong, a document mismatched, the ITR vintage off — the system catches it inside the conversation and asks the borrower to fix it on the spot. Most of what would have triggered a three-day-later rejection email gets resolved before the borrower leaves the flow. This is the layer Atlas Origin operates at — classifying documents at point of capture, flagging missing or mismatched files immediately, and triangulating declared data against documentary evidence before the file moves further into the system. 

The fifth is that cross-checking starts running live. Bureau, AA, GSTN, and borrower-submitted data are reconciled while the borrower is still in the conversation. Inconsistencies surface immediately, not in a credit officer's review queue. 

The first three are structural — they change what the application is for different borrowers. The last two are operational — they change when validation happens. Together, they describe an onboarding system in which credit policy stops being expressed only at design time, frozen into a uniform form, and starts being expressed at runtime, conversation by conversation. 

In FinBox's Atlas Flow deployments, this kind of conversational, source-pulled, adaptive flow runs at around 85% completion. What the lender receives at the end is the file that this borrower's application actually needed to produce — the questions answered are the questions the lender did not already have answers to. 

The institutions that recognise this early will run a structurally different onboarding from the rest. Their existing customers will face shorter applications. Their thin-file borrowers will face deeper ones. Their credit policies will live partly in conversation rather than entirely in a static form. The institutions that don't will keep running the 2019 application on top of 2026 data — and they'll keep wondering why their completion rates and conversion economics look the way they do. 

Atlas Flow and Atlas Origin are two ways to operate on this premise — Atlas Flow at the conversation layer, adapting what's asked to the data already available; Atlas Origin at the capture layer, validating and structuring the file before it moves to credit. They are not the only ways. But the choice in front of credit leaders is not whether to add AI to onboarding. It is whether their application form, in 2026, will still look the same regardless of who is applying. 

 
 
Until next time,  
Srijan