How We Helped a Digital Lender Reduce Manual Loan Reviews by 70% with AI Loan Underwriting

Quick Summary

Introduction

57% of financial institutions plan to add AI underwriting in 2026, according to Forbes Business Council. That number reflects urgency, not certainty. Most lenders moving toward AI loan underwriting are doing it without a clear picture of what breaks first: the model, the data, or the compliance process built around neither.

One of our lending clients found out the hard way. Loan applications had grown 40% year over year, but underwriting headcount had not moved with it. A decisioning tool the client had bought the year before sat mostly unused, unable to talk to the loan origination system it was meant to serve. Underwriters were still opening two separate credit bureau reports per file and making a judgement call by hand, one application at a time, for thousands of files a month.

This is what broke first for them and what we built to fix it before a single line of model code was written.

The Underwriting Bottlenecks We Discovered

The client’s underwriting team was not failing at the work. They were buried under the volume of it. Four bottlenecks made the case for AI loan underwriting well before a single model got built.

Manual Document Verification

Every income statement and bank record was checked by eye, adding 45 to 60 minutes to a single file before an underwriter even reached the risk decision itself.

Fragmented Borrower Data

Two credit bureaus fed the process, each in a different format, with no shared view of the applicant. Underwriters were manually cross-referencing two reports for every file that needed a second look.

Inconsistent Risk Decisions

Two underwriters reviewing the same borderline file reached different approve or decline conclusions close to 28% of the time, based on individual judgement rather than a documented policy.

Approval Delays

A routine application still took 2 to 4 days from submission to decision, regardless of how straightforward the file actually was.

None of this needed a faster form to fix. It needed the kind of ground-up platform work our team does for lenders rebuilding core decisioning infrastructure, not a plugin bolted onto the old process.

What Our Discovery Phase Revealed

Before choosing the models and the architecture, several weeks were dedicated to understanding what had caused the failure of the lender’s past efforts in AI loan underwriting. This discovery process revealed three problems that radically impacted not only our approach but also our end result.

Legacy Automation Could Not Integrate

Three weeks of discovery explained why the client’s earlier attempt at AI for loan underwriting never got past a pilot. The vendor tool scored applicants well enough in isolation, but it could not write a decision back into the loan origination system, so every score still needed a human to re-enter it by hand. Automation on paper, manual work in practice.

Inconsistent Loan Labels

A second problem surfaced once we reviewed three years of loan history: the good loan and bad loan labels had been applied inconsistently across different operations staff, with no shared definition of default. Part of discovery went into rebuilding a labelled dataset of roughly 50,000 loans against one consistent definition, working alongside the client’s risk team.

Thin-File Borrowers Were Being Rejected

The last finding reset the project’s priorities. A significant share of applicants had too little bureau history for the old rules engine to score with confidence, so it declined them automatically. Many had steady income and consistent cash flow that the rules engine never looked at. That segment became a core design requirement, not a footnote, which is exactly what a proper discovery phase is supposed to catch. It is also why we work as a BFSI Software Development partner rather than a pure staffing vendor. The engagement needed domain judgement before it needed code.

The AI Loan Underwriting Architecture We Built

With discovery findings in hand, our engineers designed the architecture around three requirements: it had to score thin file borrowers using more than bureau data, explain every decision it made, and write straight into the client’s existing loan origination system without a rebuild on their side.

The one decision that shaped everything downstream was picking gradient boosting over a deep learning model for the core risk score. XGBoost matched the accuracy of more complex models on this data while keeping every prediction traceable to a handful of clearly weighted features. For a lender legally required to explain every decline, that traceability was worth more than a small accuracy gain a black-box model might have offered.

This is the same reasoning we bring in our engagements across lending platforms. The stack should match the compliance reality of the business, not the newest model architecture available.

How We Designed the Underwriting Workflow

Architecture explains what we built. The workflow explains how an application actually moves through it, start to finish, and where a human still has the final word.

The AI loan underwriting workflow begins the moment a borrower submits an application; intelligent document processing takes the first pass. It pulls income statements, bank records, and identity documents and checks them for completeness and consistency, the same checks an underwriter used to do by hand in the first 15 minutes of a review. Anything that fails an automated check, such as a mismatched name or an unreadable scan, gets flagged and routed to a human before it ever reaches the scoring stage.

From there, the system pulls credit and alternative data in parallel: both bureau reports and, where the applicant has consented, a Plaid connection to their bank account. This is where it once took an underwriter several minutes of manual cross-referencing. It all takes place in seconds here, and the result is not two different reports but a single profile of the applicant.

The profile then goes into the risk assessment by the AI system, returning a probability of default score together with a SHAP reason code that describes it. It then enters the decision engine and gets scored using the client’s policy rules, thus entering one of the three lanes – auto-approve, human underwriter referral or auto-decline.

This routing step matters as much as the scoring step. We built it closer to a loan underwriting AI agent than a single-shot scoring API: it does not just return a number; it decides what should happen next with that number, based on policy rules the client’s risk team controls directly. A referred file lands in front of an underwriter with the full reason code breakdown already attached, so the human reviewer is not starting from a blank screen. They see exactly what the model saw and why it flagged the file for a second opinion.

Auto-approved and auto-declined files post straight into the loan origination system, no queue, no manual re-entry. Nothing sits waiting for someone to key it in by hand, which was the exact failure that sank the client’s first attempt at AI loan underwriting automation. Only the files that genuinely need a person’s judgement reach a person, and by the time they do, most of the groundwork is already done.

Solving Bias, Explainability & Thin-File Borrower Challenges

Three problems surfaced only after the build was underway, and each one shaped the final system just as much as the decisions made during discovery.

Thin-File Accuracy Was Poor at First

Early model versions, trained mostly on applicants with long bureau histories, performed poorly on the exact segment the project existed to serve. Adding Plaid cash-flow features measurably improved accuracy here, and it became the single highest-impact change in the build.

Underwriter Labeling Disagreement

The 28% disagreement rate found in discovery reappeared once calibration for the training dataset began. We ran structured sessions with senior underwriters to define concrete criteria for each risk tier, using real files from the client’s own portfolio. Disagreement dropped to about 10%, a level the risk team accepted for training a model they would stand behind.

A Fair-Lending Proxy Variable

During mandatory bias testing ahead of launch, one engineered feature turned out to correlate with a protected class through zip-code-linked information, even though no protected attribute was used directly. This is precisely the kind of risk that AI governance best practices and CFPB fair lending guidance are designed to catch, yet many AI loan underwriting projects still treat this review as a formality rather than a deployment gate. We removed the variable, retrained, and reran the disparate impact analysis until the model cleared the client’s fair lending threshold. It pushed go-live back three weeks.

Every score the AI loan underwriting system produces still carries a SHAP-based reason code, mapped to the same adverse action language the client’s compliance team already used for manual declines. That was not a feature added as an afterthought. It is the reason the compliance team signed off on the system without asking for a single exception.

AI Loan Underwriting Results: Before vs. After Implementation

The numbers above did not arrive all at once. In the first 30 days, the system was live but conservative: manual review had dropped to 55% and decision time to under 4 hours, while underwriters kept a close watch on anything borderline. By 90 days, with more data behind it and a few policy tweaks in place, the system was doing the harder job, separating genuinely risky thin-file applicants from creditworthy ones the old rules engine had been rejecting by default. That is where the full 70% reduction and the sub-hour decision time became consistent, not just a good week.

The client’s own numbers landed at that range largely because the thin-file segment gave the model the most room to outperform a rules engine that had rejected those applicants outright.

Conclusion

Frequently Asked Questions (FAQs)

What is AI loan underwriting?

It uses machine learning models to assess credit risk and automate approve, refer, or decline decisions in place of or alongside manual reviews. It typically combines bureau data, alternative data sources, and a rules layer that enforces the lender’s credit policy.

How long does it take to implement AI loan underwriting for a mid-size lender?

A focused build covering one core risk model and integration with an existing loan origination system typically takes 4 to 6 months from discovery to production.

Does AI-based loan underwriting comply with fair lending laws like ECOA and CFPB guidance?

It can, but only when fair lending testing is designed into the system rather than checked after the model is built. That means a documented reason for every decision and disparate impact analysis run before and after go-live.

Can AI loan underwriting handle thin-file or alternative-data borrowers?

Yes, when the feature set includes alternative data such as bank transaction history alongside bureau data. This matters most for personal loans that use AI underwriting, where bureau-only scoring tends to reject applicants who’d otherwise qualify. Models trained only on thick-file history typically perform poorly on thin-file applicants, so this segment needs deliberate design rather than an assumption the model will generalize to it.

How much manual review can AI loan underwriting realistically automate?

This engagement reduced manual review by 70%, in line with what a well-scoped hybrid rules-and-ML system can achieve once data quality and labelling problems are resolved. The remaining share is intentional, since certain exception cases should stay with a human reviewer.