Why AI is killing the loan application form

There’s a loan officer I spoke to some months ago at a mid-sized NBFC. His team spent roughly half their day calling people who had started applications and gone quiet. They had typed their name, their phone number, what they needed, raised their hand as clearly as anyone does in lending, then vanished somewhere around page 3.

His read was that they got confused and had nobody to call. The more useful reading is mechanical. The system asked for something the borrower genuinely struggled to provide in the format it expected, then offered nothing useful about what to do next. The industry has spent years optimizing for the psychological version of this story. The evidence points toward the mechanical one.

What the loan application form is actually asking for

A loan application form is a set of encoded assumptions about who’s sitting on the other side of it. That they have one bank account, or know which account is relevant. That their ITR is from the right financial year, correctly labeled, in a format the parser accepts. That they can tell a Form 16 from a salary slip at 11pm on a 4-inch screen.

This description fits a salaried employee in a metro city with prior credit experience. It stopped describing the majority of borrowers Indian lenders are trying to reach some time around 2020.

The person in Surat running a small trading business. The woman in Coimbatore with income spread across two accounts she opened in different cities. The first-time applicant in Ranchi with documents in Hindi and a bank statement three years out of date. These are creditworthy borrowers in many cases. They produce documentation that the intake system struggles to process, and when a document gets rejected, the system offers nothing useful about why.

The sequence is the real drop-off problem

A loan application form is a synchronous collection, asynchronous validation system. It gathers everything first, in a fixed sequence, in a fixed format. Then, after submission, a separate process validates what came in — usually a processor, sometimes an automated check, always hours or days later. The applicant is gone by the time the system has an opinion about what they submitted.

This architecture made sense when the borrower population was homogenous enough that you could predict what they’d submit and design the form accordingly. When the borrower population is a first-generation credit user in a tier 3 city submitting documents across three formats in two languages, the architecture produces a 40% completion rate and a large volume of incomplete files that nobody has a systematic way to recover.

The AI fix is an architectural inversion. Collection becomes adaptive — the system asks only what is relevant for this borrower, in their language, adjusting the question sequence based on what they have already shared. Validation becomes synchronous — bureau checks run as the applicant responds, document checks run the moment a file is uploaded, errors surface in the session rather than days after it ends. The result is that a file arriving at the credit team has already been reasoned about. An ITR year mismatch was caught and corrected while the applicant was present. The bureau pull already happened, the fraud check ran, and the credit manager is reviewing a structured, pre-validated package rather than assembling one.

The 85% completion rate that conversational intake produces against the 40% industry average is real. What it represents beyond the number is a different credit population reaching underwriters — including people who were creditworthy all along, producing documentation the old system was built for someone else to handle.

Lender ranking encoded the same assumption

Assume the borrower gets through intake. Documents verified, bureau checked, eligible. They are looking at a list of lenders. The configuration deciding who appears first was written at setup time — eligibility rules, category logic, sometimes commercial arrangements, set by people with a view of the lender panel at a point in time. The sequence looks identical for a salaried borrower in Pune and a self-employed borrower in Coimbatore, even though those two profiles activate completely different lender appetites.

This is the same assumption the loan application form made, just one stage later. The form assumed a homogenous borrower. The ranking assumed a homogenous borrower. A better-qualified file arriving at this stage still gets routed by logic that was calibrated for someone else.

The rule-writer’s knowledge is the ceiling of a rule-based system. Every rejection resulting from a mismatch between a borrower profile and a lender’s actual credit appetite is information the system collected and discarded. What AI changes here is structurally identical to what it changed in intake: a static, assumption-baked architecture gets replaced by one that learns from outcomes. The ranking changes per borrower. And unlike a rule set that stays fixed until someone manually updates it, a model trained on disbursal outcomes gets sharper with every cycle.

The number your funnel reporting isn’t showing you

Indian lending infrastructure was built for a borrower who was always a fraction of the market lenders are now competing for. The loan application intake form assumed them. The ranking logic assumed them. AI, in both cases, is doing the same thing: replacing a system designed around a fixed assumption about who the borrower is with one that responds to who the borrower actually is.

Getting intake right means a different credit population reaches underwriting. Getting ranking right means they reach lenders whose policies fit them. Each stage compounds the other.

That is the problem worth building a system around.