Most of the time a loan application spends with a lender, nobody is working on it. It sits in an inbox waiting for a missing payslip, in a queue waiting for someone to key in the numbers, and in another queue waiting for an underwriter to have an hour free. The credit decision itself, once someone looks at a complete file, often takes minutes.
This case study asks one question: what if a mid-sized lender could decide a clean loan application in 30 minutes instead of 5 days, and only pay in full if that happened? Below we set out the challenge, the outcome contract, the AI system we would build (document intelligence, financial data extraction, risk assessment and an automated underwriting workflow), the projected results and the risks that could stop it working.
The challenge: lending is slow because it is waiting
The lender in this scenario is a regional non-bank with a book of personal and small-business loans. It receives about 2,500 applications a month through its website, brokers and branches. Underwriting is done by a team of 22 people working through a loan origination system (LOS) that was built for storing decisions, not for making them.
A typical application arrives as a bundle: an application form, ID, payslips or tax returns, three to six months of bank statements and, for businesses, financial statements and a trading history. Someone checks that everything is there, someone types the figures into the LOS, someone verifies identity and income, an analyst builds the affordability view, and an underwriter applies policy and decides. When we mapped the median file, it took five days of elapsed time to get through that chain. Hands-on work was about four hours of the 120.
Three problems stood out:
- Documents are the bottleneck, not judgement. Payslips, bank statements and tax returns come in dozens of formats, as clean PDFs, phone photos and multi-page scans. Turning them into structured data by hand is slow, and it is where most errors enter. In our baseline, about 3.5% of critical fields are keyed wrongly, and each one has to be caught by a second reviewer or it flows into the decision.
- Every file gets the same treatment. A salaried applicant with a clean bank history and a modest request goes through the same queue as a complex self-employed case. Simple rules approve about 8% of applications automatically. Everything else waits for a person.
- Speed has a price. A lender that takes five days to answer gives the applicant time to accept someone else's offer. Slow decisions lose good borrowers, and the ones who stay disproportionately include those no one else would approve.
The lender had tried to fix this before. It bought a document capture tool that read some fields from some documents, and added a rules engine on top. Throughput barely moved, because the tool needed a person to check every extraction, and nobody could say whether the risk decisions were any better. Our blog post on the three most common reasons AI initiatives fail covers that pattern in more detail.
Why Outcome as a Service fits this problem
The lender did not want another licence or a team of consultants billed by the hour. It wanted decisions in minutes, at the same or better credit quality, and it wanted to be able to prove to its regulator that they were fair. That is a result you can baseline and verify from the LOS audit trail, which is the test we apply before taking on any Outcome as a Service engagement.
So the contract would be written around the result. Accubits takes responsibility for the approach, the models, the compute and the work of changing course if the first method does not perform. The lender keeps what it is best placed to do: own the credit policy, make the final call on risk appetite and verify the readings independently through its risk and compliance teams. Part of our fee is held back and paid only when the outcome gates are met.
| Time & materials AI team | Per-document capture licence | Outcome as a Service | |
|---|---|---|---|
| What is bought | Data scientists’ hours | Pages processed | Decisions in minutes at agreed quality |
| Who owns the method | Lender directs the work | Vendor’s fixed product | Accubits, within agreed guardrails |
| If the first approach fails | Lender pays for the rework | Lender pays for professional services | Accubits absorbs the cost of changing approach |
| What settles the invoice | Timesheets | Volume | Gates verified from the lender's own audit trail |
Defining the outcome: six measurable gates
Before any modelling starts, the goal is turned into numbers that both sides agree on and that the lender can measure without us. Each gate is a pass or fail threshold. A speed gate on its own would be easy to hit by approving everything, so three of the six gates protect accuracy, credit quality and fairness.
| # | Gate | Baseline (manual) | Target | Verified by |
|---|---|---|---|---|
| 1 | Median time from complete application to decision | 5 days | ≤ 30 minutes | LOS timestamps |
| 2 | Straight-through rate: applications decided with no human touch | 8% | ≥ 60% | LOS audit log |
| 3 | Field-level accuracy on critical fields (income, employer, balances, identity) | 96.5% | ≥ 98.5% | Lender's QA team, blind double-keyed sample of 1,500 documents |
| 4 | Bad rate at today's 70% approval rate (90+ days past due within 12 months) | 4.0% | ≤ 3.5% | Lender's risk team, out-of-time backtest |
| 5 | Adverse impact ratio on every protected group tested, and a reason code on every decline | Not measured | ≥ 0.80, 100% coverage | Lender's compliance team and independent model validation |
| 6 | Fully loaded cost per application | $210 | ≤ 50% of baseline | Finance records |
Gates 3 and 4 matter most for trust. Before the system touches a live application, the extraction has to prove itself on documents it has never seen, and the risk model has to show on historical applicants it was not trained on that it separates good borrowers from bad ones at least as well as the lender's current scorecard. If either fails, the programme stops early and cheaply, before integration work begins.
What Accubits would build
The system is not one model. It is a pipeline in which each stage removes one kind of delay or risk, followed by a decision layer that decides which applications a machine can approve and which need a person. We have built document-heavy AI systems before, for example our LegalDoc AI assistant, and the same layered approach applies here.
1. Get complete, usable files at the door. As soon as an applicant uploads documents, the system classifies each page, checks the bundle against the product's checklist and asks for anything missing or unreadable on the spot, before the applicant leaves the page. Where the applicant consents, bank data comes in through open banking or account aggregation rather than as PDF statements, which removes extraction error for that data entirely. See our post on getting started with open banking.
2. Read documents the way an analyst would. Layout-aware models extract fields, tables and line items from payslips, bank statements and financial statements, and attach a confidence score to every value. Cross-document validation then asks the questions a careful analyst asks: does the salary on the payslip match the deposits in the statement, do the names and dates agree, and do the totals add up? Values below a confidence threshold are not guessed. They are sent to a person with the source region highlighted.
3. Assess risk from the evidence, not the paperwork. The extracted data is turned into categorised cash flow, income stability and affordability measures. A credit risk model combines these with bureau data to estimate the probability of default, and every score arrives with its main drivers so it can be turned into the reason codes a regulator expects, following the principles in our post on why explainable AI matters. Fraud and tamper signals run alongside, using ideas from our work on machine learning for fraud detection.
4. Decide only what a machine should decide. The decision engine combines the lender's credit policy with the model's output and routes each application one of three ways. Clear approvals are decided automatically. Everything borderline, flagged or likely to be declined goes to an underwriter with the evidence laid out. The system never issues a decline on its own. A person reviews every adverse decision, which also keeps the lender on the right side of adverse action rules.
Proving the system before go-live
Gates 3 and 4 are checked together in a go or no-go review at week 9, before the system is wired into the LOS. For the risk model, the team trains on older applications and tests on a later period it has never seen, which is how the model would face live conditions. The chart below ranks applicants from lowest to highest predicted risk, approves them in that order and shows the bad rate among those approved. A better model has a lower line.
The 16-week plan
With the gates agreed, the programme runs as a tight sequence. The longest single risk is integration with the LOS, so that work starts as soon as the go or no-go review passes. The system then runs in shadow mode, making recommendations that underwriters can see but customers cannot, before it is allowed to decide anything.
Projected results
Time: 5 days down to 30 minutes
Every stage gets shorter, but the biggest change is that stages stop waiting for one another. Intake and extraction run the moment a document lands, verification and risk analysis run in parallel, and a clear approval does not join a queue at all. Files that do need an underwriter arrive pre-spread and pre-checked, so those decisions typically take less than a day instead of five.
Cost: about a quarter of the baseline
The savings come from people no longer typing numbers from documents or waiting between steps. The AI-first process still costs money: bank data and bureau pulls are paid per application, underwriters still review the exceptions, and the models need monitoring. Those are small numbers next to the manual alternative. At 2,500 applications a month, the difference of $152 per application comes to roughly $4.6M a year.
Every gate cleared
What could go wrong
A hypothetical case study that only shows the upside is not much use. These are the risks we would write into the contract, and what happens if each one occurs.
What this would mean for the lender
- Customers get an answer while they are still interested. A decision in minutes means fewer applicants walk away to a competitor, and the good borrowers are the ones most likely to have somewhere else to go.
- Underwriters do underwriting. With 68% of applications decided straight through and the rest arriving pre-spread, the team of 22 spends its time on the cases that need judgement. The same people can handle more volume without hiring.
- Better decisions, not just faster ones. A lower bad rate at the same approval rate, or more approvals at the same bad rate, means the speed gain does not come at the expense of the portfolio.
- A better audit trail. Every field, score and decision is traceable to its source document and its reason codes. Regulators and auditors get evidence rather than recollections.
- A reusable asset. The trained models and pipeline stay with the lender and extend to new products. Running them reliably in production is an engineering problem of its own, which we cover in why scaling AI is fundamentally different from building it.
- Risk shared, not just moved. The lender pays in full only when the result is verified from its own records.
Key takeaways
- Loan delays are mostly waiting, not deciding. The largest saving comes from removing hand-offs and re-keying, not from making the credit model cleverer.
- Prove the models before integration. A blind extraction test and an out-of-time risk validation at week 9 turn an uncertain AI bet into a cheap go or no-go decision.
- Speed needs guardrails. Gates for accuracy, credit quality and fairness stop a speed target from being met by cutting corners.
- Automate the clear cases, not the contested ones. Machines approve what is clearly approvable. People review everything else, including every decline.
- Outcome contracts suit lending problems. “A decision in 30 minutes at equal or better credit quality” is measurable, verifiable and valuable, which is what an outcome needs to be.
Frequently asked questions
Is this a real client engagement?
No. This is a hypothetical case study. The lender, portfolio and numbers are illustrative and are based on how consumer and small-business lending typically works and on how Accubits structures Outcome as a Service contracts. For a completed engagement, see the nutraceutical absorption case study.
How can AI cut loan processing time from 5 days to 30 minutes?
Most of the five days is waiting: for missing documents, for someone to key in figures and for an underwriter to be free. An AI-first pipeline checks completeness at upload, extracts and validates data from documents in minutes, runs verification and risk assessment in parallel, and lets a decision engine approve clear cases automatically. Applications that need judgement go to an underwriter with the work already done.
What is AI document intelligence in lending?
It is the use of layout-aware machine learning models to classify and read loan documents such as payslips, bank statements, tax returns and IDs, extract fields and tables with confidence scores, and validate them against each other. Values the model is unsure about are sent to a person instead of being guessed.
Does automated underwriting mean no human reviews the loan?
Not for every loan. In this scenario clear approvals are decided automatically, and everything borderline, flagged or likely to be declined goes to an underwriter. The system never issues a decline on its own, and a person reviews every adverse decision.
How do you keep AI credit decisions fair and explainable?
By testing for adverse impact before launch and on an ongoing basis, searching for less discriminatory model alternatives, producing reason codes from the model's main drivers for every adverse decision, and keeping model documentation, validation and monitoring to the standard of established model risk guidance such as SR 11-7.
What is Outcome as a Service?
Outcome as a Service is Accubits’ engagement model for problems where the result matters more than the process. The client and Accubits agree a measurable outcome and how it will be verified. Accubits chooses and builds the approach, and part of the fee depends on the verified result.
What happens if the AI models do not perform?
The contract includes an early go or no-go review at week 9. If extraction accuracy or risk model performance does not meet the gates on data the models have never seen, the programme stops before any integration work or live traffic, and the at-risk part of Accubits’ fee is not paid.
Who owns the models and the data?
The lender. Applicant data stays in the lender's cloud environment, models are trained there, and the trained models and pipeline are handed over at the end of the engagement.
Related reading
References
- Consumer Financial Protection Bureau (2022). Consumer Financial Protection Circular 2022-03: Adverse action notification requirements in connection with credit decisions based on complex algorithms.
- CFPB. Regulation B (12 CFR 1002.9): Notifications.
- Board of Governors of the Federal Reserve System and OCC (2011). SR 11-7: Supervisory guidance on model risk management.
- European Union. Artificial Intelligence Act, Annex III: High-risk AI systems.
- Xu, Y. et al. (2020). LayoutLM: Pre-training of text and layout for document image understanding. Proceedings of KDD 2020, 1192–1200.
- Lundberg, S. M. & Lee, S.-I. (2017). A unified approach to interpreting model predictions. Advances in Neural Information Processing Systems 30.
Have a process bottleneck you can put a number on?
If you can measure it and verify it, we can talk about contracting against it. Tell us the outcome you need, and we will tell you whether we would put part of our fee behind it.
Scope an outcome with usOr read how the model works on the Outcome as a Service page.
