What AI Actually Does in Loan Underwriting
(Part 2): Where It Breaks and Who Still Signs Off

Part 2 of the AI loan underwriting walkthrough. The numbers lenders like to quote, the three ways our stack broke in production, and what a senior underwriter still owns when 88% of loans never reach their desk.

In Part 1, I walked through the underwriting stack we rebuilt with a mid-size NBFC over 14 months. Five lanes, 14 components, five scoring models, one rules engine. That was the clean diagram. What Part 1 did not cover is where the mechanics fail, and they do. Ours failed three times in ways that cost real money, and I have the incident reports open as I write this. This part goes through those failures, the public numbers from Upstart and J.P. Morgan that give the whole thing some scale, and the question our CRO kept asking me: what does a senior underwriter do all day when 88% of loans are approved before a human sees them?

By Shri Director of Technology at GetSetLive and Bagful Cloud Hosting, with 25 years across infrastructure, datacenters, cloud platforms, and modern AI/ML. Day-to-day work focuses on consulting clients to make their existing systems AI-aware and AI-ready, and architecting AI/ML solutions tailored to each customer environment. Every article here comes from direct field exposure, written to help the next batch of professionals design and deploy more sophisticated solutions in their own careers. Read all posts by Shri →

Editor, GetSetLive Technical Blogs18 min read

Key Takeaways

What Is Inside

The Numbers Everyone Quotes, Checked Against Ours

Every AI loan underwriting deck I have seen in the last two years quotes the same handful of statistics. Before we signed off on our own board numbers, I sat down and sorted those claims into three piles: real, marketing, and real but misleading. The image below is what came out after running them against audited filings and against our own scorecard.

Upstart, the US consumer lending platform, reported in its Q4 2025 earnings that it processed 456,000 loan transactions, an 86% jump year on year, and onboarded over 300,000 new borrowers. That number is real. It comes straight from the earnings call, so it has been through an audit.

J.P. Morgan cut payment account validation rejection rates by 15-20% using AI-assisted processing. Also real, also audited, and also about one narrow workflow. It is account validation, not loan approval. People mix the two up in pitch decks all the time, and I have had to correct it in our own slides twice.

The ones to squint at are “18-32% increase in approval rates” and “50%+ reduction in bad debt.” Those come from vendor case studies for unnamed lenders. They show up in pitch deck after pitch deck. For specific customer segments they are plausible. But they are not audited, and they leave out the segments where AI made things worse. On our book, and at the two other lenders whose risk teams I have compared notes with, bad debt improved by 10-25%. The real gain was on the cost side, not the top line.

Here is what our internal scorecard looked like after the first full year. Origination cost fell from ₹1,840 per loan to ₹310, an 83% reduction. That was the single biggest real win. Median cycle time fell from 3.4 days to 47 seconds for auto-approved cases, which is 98% faster, but only for 62% of volume, so the blended median is about 4 minutes. Bad debt fell from 5.1% to 3.9%, a 24% reduction. That is meaningful, and nowhere near the 50% in the glossy decks. Approval rate rose from 51% to 58%, a 14% increase, again real and again not the 32% on the slides.

The pattern I keep seeing: cost reduction is always the biggest win, and it is always the one talked about least, because cost does not sell loans and speed does.

Where Our AI Lending Stack Broke

This is the section that gets cut from every vendor pitch. I am including it because the failures taught us more than the build did. The diagram below shows the three categories of failure our risk team now monitors every week. Each category has a real incident behind it, and each incident cost the NBFC money before we caught it.

Failure 1: Thin-File Borrowers

A thin-file borrower is someone whose credit bureau history is under 12 months old. In India that covers roughly 85 million adults who are creditworthy and invisible to the bureau. Fresh graduates, gig workers, first-time salaried employees, small-town earners who have never taken a loan. Our XGBoost model trained on about 4.6 million historical loans, and nearly all of those borrowers had 3+ years of credit history. So when the model met an applicant with zero bureau history, it had no signal to work with and fell back to conservative scoring.

We did not notice for months. Then an internal audit in early 2024 found that our system was rejecting thin-file applicants at 61% against a policy target of 35%. The model was not doing anything wrong mathematically. It was confident in its own uncertainty, and the rules engine was treating that uncertainty as risk. The fix took us three months. We added a separate thin-file scoring track that uses bank statement features and employer stability signals and deliberately ignores bureau features. The two tracks now run in parallel, and the decision engine picks one based on how deep the bureau history goes.

What caught me off guard was how ordinary the problem was. Nothing exotic. Upstart built its entire early positioning around this exact gap, and it is why their US originations skew younger than incumbent lenders. If an AI underwriter is rejecting 60% of thin-file applicants, it has a model problem and a policy problem at the same time. Nobody will see it until someone specifically goes looking, and in our case that someone was an auditor, not us.

Failure 2: Model Drift During Festival Spending

Model drift is the boring, expensive, operational reality that nobody talks about on the conference circuit. Our model learned from two years of application data. The world in November 2024 did not look like the world the model saw during training. The model did not know this. It kept scoring applicants as if the training distribution was still the real one.

Diwali 2024 is the incident I still use in every internal training session. In the three weeks before the festival, the model started approving borderline cases at a much higher rate than usual. When we dug in, we found the LSTM income stability model was reading pre-Diwali bonus credits as structural salary increases. (An LSTM, or long short-term memory network, is a recurrent neural network that learns patterns across a time series such as monthly salary credits.) It bumped the stability score by 8 points on average. The rules engine read those inflated scores as stronger applicants. Files that should have gone to a senior underwriter auto-approved instead. Default on that cohort came in at 6.8% against a portfolio average of 3.9%. On a one-month disbursal of ₹210 crore, the excess default cost the NBFC about ₹6 crore before we caught it.

The fix was not a better model. The fix was a drift detector we built on top of Evidently AI, the open-source ML observability library, with Grafana for the dashboards. We picked the six features that move the LSTM score most and set up a daily distribution check. The configuration that runs every night looks roughly like this.

 1# Watches six features that move the LSTM income stability score
 2# Runs at 02:30 IST on the previous day's batch, posts to #risk-drift Slack
 3report:
 4  name: lstm_income_stability_drift
 5  schedule: "30 2 * * *"
 6  reference_window:
 7    source: feature_store_offline
 8    window_days: 90        # training distribution baseline
 9  current_window:
10    source: feature_store_online
11    window_days: 1         # yesterday's live applications
12
13features:
14  - salary_credit_avg_3m
15  - salary_credit_date_stddev_days
16  - salary_dip_count_last_6m
17  - upi_outflow_30d
18  - employer_tenure_months
19  - device_location_drift_30d
20
21drift_method: ks            # Kolmogorov-Smirnov, p-value below 0.05 = drift
22share_threshold: 0.33       # alert if 2+ of 6 features drift on the same day
23
24alert:
25  channel: slack
26  webhook: ${RISK_DRIFT_SLACK_WEBHOOK}
27  cc_email: ${RISK_DRIFT_CC_EMAIL}

The detector compares yesterday’s live feature distributions against a 90-day training baseline. When the Kolmogorov-Smirnov test fails on two or more of the six features in one batch, it pings the risk channel and the engineering group decides whether to retrain or tighten a threshold by hand. The first real alert fired at 2:34 AM on a Saturday in October 2025, three weeks before Diwali, and the on-call engineer tightened the auto-approve threshold that morning. That is the whole point. In my experience this kind of monitoring is the most underrated piece of infrastructure in a production ML system, and it is also the first thing cut when budgets tighten.

Failure 3: Proxy Discrimination via Pincode

This is the failure that worried our compliance head the most, and rightly so. In late 2024, an internal fairness audit found that applicants from 14 specific pincodes in Mumbai and Delhi got approved at 21% lower rates than applicants with equivalent credit profiles from adjacent pincodes. Pincode was not a feature in the model. What was in the model was a blend of UPI merchant patterns, employer cluster density, and device location drift over 30 days. Taken together, those three had become a proxy for pincode. In those 14 cases, pincode was in turn a proxy for religious community.

Nobody told the model to discriminate. It learned to. That is the most dangerous property of tree-based models on rich feature sets: they find whatever signal correlates with default, and some of those signals are ethically toxic. We pulled the 14 pincodes into a fairness audit, retrained with a fairness constraint (demographic parity across pincode clusters, enforced through a reject-inference layer), and now run a disparate impact ratio check every month. The CFPB (the US Consumer Financial Protection Bureau, which enforces consumer credit and fair-lending law) and the RBI have both started asking about disparate impact testing in examinations. Any lender not doing this at least monthly is exposed.

The check itself is simple. Compute approval rate by pincode cluster, divide by the overall approval rate, and flag any cluster below 0.80. That is the four-fifths rule US fair lending law has used since 1978. It is not a machine learning technique. It is a policy check applied to model outputs. The model knows nothing about it. Only the risk team does.

The Adverse Action Problem

When a loan gets declined, the borrower has a right to know why. The US calls this an adverse action notice under ECOA (the Equal Credit Opportunity Act of 1974, which bans credit discrimination on race, religion, sex, age, or marital status) and the FCRA (the Fair Credit Reporting Act, which governs how bureau data may be used). In India, the RBI’s Fair Practice Code for NBFCs requires something similar. The rule is that the lender has to give a specific reason, and it has to be actionable. “You were rejected by our AI model” is neither, and regulators have made it clear that it does not count.

This is where the SHAP values from the XGBoost model pay for themselves. (SHAP, or Shapley additive explanations, breaks a prediction into per-feature contributions.) When a file is declined, our pipeline pulls the top 5 SHAP values that pushed the score over the rejection threshold and translates them into plain language. “Your application showed 7 gambling-related UPI payments in the last 30 days” is actionable. So is “Your declared income was 38% higher than the salary credit pattern in your bank statement.” But “Your AI score was high” is not, and that was roughly what our first version produced before compliance sent it back.

We keep a shadow log of every adverse action notice the NBFC sends, and a senior underwriter spot-checks 50 of them each week. The reason is not compliance, or not only compliance. If the reason codes stop making sense to a human, that is often the first sign the model has drifted into using features in ways nobody intended. Adverse action review is the cheapest, earliest drift detector we have, and since it is a regulatory requirement anyway, we get it for free.

What a Regulator Examination Looks For

The gap between “the rule says explain your decisions” and what happens when an examiner walks into the office is wider than we had prepared for. We have now sat through two RBI inspections with this stack in place. The playbook converged on the same five questions each time, and colleagues at US lenders tell me the CFPB list is nearly identical. Knowing the questions in advance turns the meeting from defending the model into walking the examiner through controls that already exist.

1. Show me the model card. Both ECOA examiners and RBI inspectors ask for a written document describing what the model predicts, what features it uses, who owns it, when it was last retrained, and what its known limitations are. One page is fine. Forty pages looks evasive. The point is that someone takes accountability for the model in writing, and in our case that someone is the head of risk analytics.

2. Show me a sample of declines with reason codes. The examiner picks ten declined applications at random and asks the team to walk through the reason codes. If three of the ten read “high AI risk score” without naming a specific feature, that is a finding. We failed this exercise the first time. We had built the reason-code mapping once, at launch, and nobody revisited it after the first retrain.

3. Show me the disparate impact monitoring evidence. The four-fifths check from earlier in this article is what the examiner wants to see. Not a one-off audit, but a running monthly report with timestamped outputs. A regulator does not expect zero disparate impact. They expect the lender to know about it before they do.

4. Show me what changes when the model is retrained. Drift between model versions can introduce new bias without anyone noticing. Examiners ask for a side-by-side: champion versus challenger on a held-out test set, with disparate impact metrics for each cohort. Because we shadow-test for two weeks before promotion, that artefact already exists. A lender that promotes on accuracy alone will not have it.

5. Show me the override log. When a senior underwriter overrules the model, what does the audit trail look like? This is the most under-built artefact I have seen at AI lenders, ours included at the start. RBI inspectors ask specifically: who overrode, on what date, with what reason, and what was the outcome 90 days later. A lender that cannot produce this log on the spot is exposed. We can now, but only because the first inspection made us build it.

None of these five requests is about the math. They are about operational rigour around the math. The model can be wrong as long as the lender knows it can be wrong, has a process to detect it, and has a paper trail of what the team did about it.

What the Senior Underwriter Does Now

The assumption I hear most often is that senior underwriters lose their jobs to AI. At the NBFC the opposite happened. Their queue got longer and the cases got harder. The diagram below maps how the human-model partnership splits responsibility inside the stack as it runs today.

A senior underwriter on our floor handles roughly 28-35 cases a day. Every one of them is from the 12% the rules engine routes to human review, and every one of them is ambiguous. Either the risk score sits in the middle band, or the profile has a contradiction the model cannot resolve, or the amount is above the auto-approval ceiling. Their screen shows the LLM-written summary of the file, the top 15 SHAP values from XGBoost, the graph model flag, and the raw bank statement. They spend 8 to 14 minutes per case.

What they do in those minutes is the interesting part. They look for the thing the model cannot see, which is usually a story. An applicant has been steady for four years, the salary credits look right, and there is one odd ₹18,000 debit labelled SWIGGY that makes no sense at that income level. Is the applicant running a cloud kitchen on the side? So the underwriter makes a phone call. Our senior underwriters pick up the phone on about 30% of their cases. The model cannot do that, and it never will. A lot of the real risk assessment happens on that call. I sat in on a few of them in the first year and they changed how I think about what “automation” means in this business.

The Chief Risk Officer does something different again. Individual cases no longer cross that desk; distributions do. Every Monday morning, two hours go into the week’s approvals, declines, and defaults, sliced by pincode, age band, employer type, and loan size. The CRO is hunting for patterns the model cannot see, because a model cannot see its own aggregate behaviour. When a pattern turns up, the response is either to tighten a threshold or to commission a retrain. Those decisions are what shape the NBFC’s risk posture, far more than any model version.

That is the split we ended up at, and every serious AI lender I have compared notes with ended up somewhere close to it. The model does the tabular, repeatable, fast work. Senior underwriters do the narrative, judgement-heavy exception work. And the CRO does the aggregate, policy, and accountability work. None of the three can do the others’ jobs. The slogan “AI replaces underwriters” is wrong in both directions. AI does not replace them, and underwriters do not replace AI.

What This Means If You Are a Borrower

A few practical notes for anyone who will apply for an AI-underwritten loan, which now covers roughly 70% of consumer personal loans in India. These come from watching our own system make mistakes, so take them as an insider’s view rather than advice.

First, the system is faster, not fairer. Faster means a decision in 47 seconds. Fairer would mean the decision is consistently good across borrower types. The honest answer on fairness is: mostly yes, sometimes no. And the “sometimes no” cases are exactly the edge cases most likely to involve first-time borrowers, small-town applicants, or anyone whose financial profile does not look like a metro software engineer’s.

Second, you have a right to know why you were declined. If the decline arrives with no specific reason, or with a reason you cannot act on, push back. Every NBFC in India has to furnish a specific reason under RBI’s Fair Practice Code. Ask in writing. Keep the response. It matters if you appeal.

Third, the thing that moves the score most is not what most borrowers think. CIBIL is one of 1,200 features. The features that move our score the most are consistency of salary credits, absence of gambling merchant patterns, EPFO employer tenure, and stability of UPI counterparty concentration. If you want better odds: stop the Dream11 payments two months before applying, stay with the same employer for at least 18 months, and get salary credited on the same date every month.

Fourth, if the model got it wrong, ask for human review. Every responsible lender has a manual review path. Use it. Our senior underwriters reverse roughly 18% of decline decisions when applicants push back with additional context. The model gets things wrong. That is not a secret inside the building. The system is designed to let humans correct it, and not enough borrowers know to ask.

Anti-Patterns: Things Vendors Sell That Do Not Work

The same pitch decks that overstate the gains also push architectures that look impressive in a demo and fall over in production. We were offered all five of these during the build. Two of them we tried before backing out.

1. One foundation model that scores everything. The pitch: a 70B-parameter LLM ingests the application, the bank statement, and the bureau record, and outputs a probability of default. The reality: large language models are bad at tabular reasoning, slow, expensive to serve within the millisecond budget a loan application needs, and impossible to defend to an examiner. We ran a two-week bake-off and the LLM lost to XGBoost on every metric that mattered, including cost per decision by a factor of about 40. Every production lender I know uses an LLM for one narrow job, the summary for human review, and never lets it touch the decision.

2. Synthetic data from a GAN for fairness training. Vendors sell this as a generative adversarial network that produces thin-file applicant data so the model can learn on a balanced cohort. What you get is synthetic borrowers with synthetic outcomes. Your model trains on fiction and then meets real applicants whose patterns the GAN never produced. This is the other one we tried. Better fixes exist (reject-inference layers, sample reweighting, separate scoring tracks), and they survive contact with regulators, which the GAN approach did not once we walked our compliance head through it.

3. “Explainable AI” dashboards that do not satisfy regulators. You get shown a colourful dashboard with feature importance bars and a SHAP waterfall, and it looks like the compliance problem is solved. Examiners, however, ask for actionable per-applicant reason codes, not aggregate feature importance. A dashboard built for engineers is not a reason-code generator built for the borrower-notice pipeline. You need both. Most vendors ship one and call it the other.

4. Fairness fixes applied at inference time. This one arrives as a post-processing layer that rebalances the model output to enforce demographic parity. Any halfway competent auditor will spot it, and it reads as “we knew the model was biased and patched the symptom.” Fixing bias at training time (constrained optimisation, reweighted samples, removed proxy features) is harder, and it is defensible. Fixing it at inference time satisfies no one.

5. “AI-powered” KYC that hides a manual review queue. Sold as automated identity verification in seconds. In practice, several vendors route ambiguous cases to an offshore human queue and call the latency “model processing.” That is fine as a business choice. It is not fine when the vendor charges AI prices for it and the lender finds out after onboarding. Always ask for the fallback rate. We asked, and one vendor’s number was 31%.

The pattern across all five: the technology in the pitch does exist, just not in the role the pitch claims. A buyer who knows where the model ends and the glue begins will not get sold the wrong thing.

What I Am Writing Next

Next on this blog, I am taking the same lens into banking, specifically how AI sits inside a modern fraud detection and AML pipeline. The banking stack adds streaming infrastructure, graph neural networks for mule-ring detection, and the unpleasant arithmetic of false-positive economics at scale. Different domain, same questions: which parts are real engineering, which parts are marketing, and where does it break in production. Look out for it over the next few weeks.

Related Reading

References

• PYMNTS, Earnings Show AI Lending Platforms Scaling Originations, 2026
• Reserve Bank of India, Fair Practice Code for NBFCs, latest amendment
• Consumer Financial Protection Bureau, Regulation B (ECOA) adverse action guidance
• Bonadio, Practical Applications of AI in Financial Institutions: Lending, 2026
• Canopy Servicing, AI in Lending: How It Is Used Today, 2026

Frequently Asked Questions