There is a moment, familiar now to anyone who has sat in a UK mortgage lender’s innovation review, when the demo lands perfectly. Documents feed in. Fields extract. Summaries appear. An underwriter who used to spend forty minutes on case preparation watches the screen do it in four. Someone in the room says the words “straight-through processing.” A director nods.

Then the pilot goes to production.

And the quiet trap closes.

Now let’s get specific about the value potential.

The Blindspot

The past two years have done something unusual to the economics of building software. Foundation models, Claude, GPT-4 and their successors have made document intelligence feel, for the first time, genuinely within reach of an internal engineering team. Tools that once required specialist machine learning PhDs and months of training data can now be assembled, roughly, by a capable team in a matter of weeks. GitHub Copilot accelerates the scaffolding. LangChain-style orchestration chains the logic. Prompt iteration replaces what used to be model fine-tuning.

The result is a generation of well-funded, well-intentioned technology teams inside UK lenders who believe, with reasonable evidence, that they can build what they are currently being asked to buy.

They are not wrong. They probably can build it.

The question nobody is asking loudly enough is whether they should.

 

The Number That Misleads Everyone

There is a statistic that circulates in every build business case I have ever been shown. Field-level accuracy on structured document benchmarks now exceeds 95%. The number is real. The inference people draw from it is that document intelligence in lending is essentially a solved problem.

Lending documents are not benchmark documents. They arrive photographed on phones, skewed, compressed, partially obscured. They come from applicants whose income doesn’t fit neatly into the categories the model was implicitly trained to expect. They come packaged by brokers whose conventions vary in ways that are invisible until the system fails to handle them.

A five percent field-level error rate does not translate to a five percent operational problem. Errors compound. A missed deduction leads to a misclassified income stream leads to an incorrect affordability assessment leads to a case returning to manual review. The straight-through processing rate that justified the investment starts falling.

What I try to explain in those early conversations is that the benchmark measures extraction. What the lender actually needs is a lending system. Those are not the same thing, and the distance between them is where most internal builds get stranded.

 

The Budget Line Nobody Includes

I have never seen an internal build business case that fully accounts for what I think of as the governance layer.

The extraction logic is now genuinely accessible. What is not accessible, what takes years to build properly and requires constant maintenance; is the infrastructure around it. Controlled model updates and structured validation rules, exception management frameworks, audit logging, bias oversight, drift monitoring allow evidence packs to withstand regulatory scrutiny.

In a regulated lending environment, the FCA does not care how accurate your model is in a sandbox. It cares whether you can demonstrate what the system decided, why it decided it, what changed, when it changed, and what effect those changes had on customer outcomes making this a governance architecture problem. Governance architecture is unglamorous, perpetually incomplete, and extraordinarily time-consuming to build.

What I see, repeatedly, is lenders who build the visible part including the extraction, the summaries, the exception flags and then discover that the invisible part is where the real complexity lives. By then, they own the code. They also own every model update, every failure mode, every integration break, and every audit challenge. What began as a cost-saving decision has become a permanent line on the engineering roadmap.

 

The Compounding Advantage Nobody Puts in a Spreadsheet

One of the things that is hardest to quantify in a build-versus-buy conversation is what I think of as the network effect of market exposure.

An internal build learns from one lender’s book. Our platform learns from many. When a high street bank changes its statement layout, when a new manipulation technique appears in income documentation, when a broker packaging convention shifts — we encounter that signal across our client base and incorporate the response. An internal team has to detect the change independently, prioritise it against everything else on the roadmap, and build the fix from scratch.

Over a year, the difference is subtle. Over three to five years, it compounds in ways that genuinely matter: in fraud detection, in the accuracy of exception routing, in the handling of document formats the internal team hasn’t seen yet. The internal capability improves at the pace of one lender’s portfolio. We improve at the pace of the market.

I am not making this argument to position Digilytics. I am making it because I think it is the most important thing that gets left out of the conversations I sit in. The build decision is not just a cost comparison between subscription fees and engineering time. It is a question about what rate of improvement each path makes possible, compounded over the years it takes to achieve the operational outcomes that justified the investment in the first place.

 

The Question I Wish More People Asked Me

The framing I encounter most often is: should we build or buy? The framing I wish I encountered more often is: what should we own because it differentiates us, and what should we industrialise because it enables us?

Those are different questions, and they lead to different answers.

Risk appetite, lending policy, affordability methodology, broker relationships, underwriting judgement, portfolio strategy, these are the things that separate competitive lenders from each other. They are worth owning deeply and defending vigorously. They are not things a technology partner can or should replace.

Document ingestion, field extraction, validation logic, anomaly detection, exception routing, drift monitoring are the infrastructure through which lending policy is executed. They are necessary. They are not differentiating. A lender that builds this infrastructure internally does not gain a competitive advantage in credit markets. It gains an operational dependency, and it diverts engineering and executive capacity from the things that actually do differentiate it.

When I put the question that way, I find that the conversation changes. Not always immediately. But it changes.

 

What the Trap Actually Looks Like

The version of the AI pilot trap I worry about most is not the one that fails quickly and visibly. It is the one that succeeds partially, well enough to attract further investment, accumulate technical debt, and become too embedded to stop and too incomplete to scale.

I have talked to lenders in that position. They have ownership without control. They have spent significantly without transforming materially. The engineering team that built the system is now its permanent maintenance crew. The compliance team is still waiting for the audit framework. The brokers are still experiencing inconsistency. The business case has been quietly revised downward several times, and nobody quite wants to be the person who says out loud that the original thesis was wrong.

I don’t share this to be discouraging. I share it because the pattern is recognisable and avoidable, but only if you look for it before you are inside it.

The lenders I have seen navigate this well are the ones that asked the harder question early: not ‘can we build it?’ but ‘should this be ours to operate?’ The ones that get into difficulty are usually the ones that confused the demo for the destination.

The AI moment in UK lending is real. The capability shift is real. The trap is real too. And it is considerably easier to see from outside it than from within.

 

Reetwija Chakraborty is Director of Revenue at Digilytics AI, which builds document intelligence infrastructure for regulated UK lenders across mortgage, SME and asset-based lending origination.

Share this post