Part I of this series set out three levels of our AI strategy: organisation-wide adoption, an AI-first approach to product and engineering, and complex agents. Part II and IIa covered product engineering. Part III began the dive into agents with our growth team – this blog covers our approach to lending agents.
Why secured SME lending is the hard test
Established SME lending combines volume with value and complexity. Complexity is driven by:
-
Different documents, data types and formats (e.g. emails, APIs, PDFs, Excel, scanned, open banking, audited vs management accounts, business plans)
-
Different business and borrowing dimensions (e.g. industry sub sectors, types of collateral, different corporate structures, personal and company guarantors).
Conventional software and machine learning hits a ceiling in fully encoding these dimensions, but agents are particularly well suited to solving this ‘last mile’ of complexity.
It is also where accuracy is everything. An agent that is right 90% of the time makes a good demo but is certainly not good enough for high value credit decisions. In a regulated bank, the question is also not only whether the agent is right, but whether we can audit how it got there.
So we have not treated AI in lending as a set of standalone tools. We build in tandem with our proprietary cross-channel and product end-to-end lifecycle loan software, so that AI activity is part of the system’s state, visible and auditable.
A clear example: from days to minutes
While we offer digital routes via API and portal, many of our intermediary partners still send asset finance applications as unstructured emails with attachments. Historically, that meant someone reading the email, opening each document to check we have what’s needed, then analysing and keying the data into our loan software, chasing the broker for missing items, and only then able to run the case through our decisioning.
In April we launched our agentic system that does this end to end. It:
-
Reads the email and every attachment;
-
Checks the application is complete and, if not, emails the broker explaining exactly what is missing;
-
Extracts and analyses the content, and maps it to our application fields;
-
Where the data is within our approved confidence thresholds, it then calls our auto-decision model;
-
Returns the decision to the broker by email.
Where confidence in the data is lower or the decision model refers the case, it goes to an underwriter with the evidence in front of them.
Half of cases received are auto-decisioned end-to-end, with decisions returned in a mean of 12 minutes.
This example uses a number of individual agents, and we track performance in detail for each of them. For example, the financial statement reading agent reads PDF financial statements and populates financials in our underwriting software. A variant of the financial statement reading agent is also used for other product types – such as secured business loans. This is currently covering 68% of all applications, and has 99% accuracy in evaluation monitoring. We have released 33 fields so far, including depreciation, amortisation, dividends and EBITDA.
Other such agents assist with analysing commercial property valuation reports, or checking in our portal that all required documents have been uploaded for an application.
Four patterns to determine how to use AI
We group our lending AI into four archetypes. Each has its own pipeline, delivery method and monitoring cycle:
-
Unstructured to structured. Ingest emails and documents, classify them, extract fields, score how reliable each field is, then validate and log.
-
Human-in-the-loop generation. Retrieve the deal file, draft a summary or response, and have a person review and edit it before it is sent.
-
Auto-decision. Take extracted application data, apply policy, then accept, decline or refer, with rationale and references attached.
- Monitoring and quality checking. Compare AI and manual outputs on a schedule, detect drift, and sample for manual checks.
The asset finance email agentic system combines the first and third, with a controlled communication step back to the broker. The point of the patterns is reuse, which not only saves time in development, but also means we do not reinvent governance for every agent. Each new use case plugs into a pattern whose risk assessment, controls and monitoring already exist, and we add use-case-specific controls on top.
Confidence as the automation boundary
Every AI output carries a confidence score built from several signals. These might include whether the value can be grounded in an exact snippet of the source, how authoritative and consistent the source is, whether the value is plausible for the domain, and whether repeated or independent model runs agree.
That score decides what happens next. High confidence, typically comparable or better than human accuracy, can proceed automatically within pre-approved guardrails. Low confidence is referred for review by a person. In the email agent, it is this threshold that decides whether a case is decided automatically or handed to an underwriter.
Provenance at point of use
When a colleague opens an application, every AI-touched field shows its source, the page and table it came from, the method of capture (entered by a user, an override, an API or AI-derived), the confidence score and reasons, and the full edit history. Example below:
We distinguish two audit events. One is a value change, where someone overrides the AI. The other is a confirmation, where someone reviews an AI value and agrees with it. Logging only hides the second, which is arguably the more important evidence, because it shows what a human actively checked and not just what they changed. This provenance and audit trail is now a shared component, so each new service can adopt it instead of rebuilding it.
How our thinking has evolved with model capability
Our design has not stood still as models have improved. In Part I we described dual-LLM validation, where independent models had to agree before an output was accepted. In v2.0 of our financial statement agent, a single current model with confidence scoring replaced the earlier multi-model setup, whose models are now deprecated. On a 100-statement test it achieved 99.0% exact accuracy, and only 0.1% of values routed to manual review.
Our latest models can read a full set of accounts in one pass, return answers in an enforced structure, explain their reasoning, and cite page and line behind every figure. That lets us take a lot out. Our instructions shrank by three quarters, with most fields now defined by a schema rather than written rules (which is much better supported by the latest LLM models), and derived figures such as EBITDA are calculated in code rather than by the model.
What we kept are the controls that do not depend on any one model: a confidence score on every value, testing against verified ground truth, and referral to a person when confidence is low. The Evaluation Hub runs whenever the model changes, so a new model becomes a new set of results against an agreed standard, not a from-scratch governance process.
Our advice to others is to invest in what outlasts any one model, remove scaffolding once the weakness it covered has gone, and never remove the controls that tell you whether the model is right.
Build the platform while delivering
Rather than spending months building our AI platform upfront without delivering tangible value, we have built a shared core platform alongside learning from our live deployments. Document extraction, orchestration, document management, evaluation and monitoring now sit in separate services, with shared libraries for provenance and audit, all running through our LLM control plane (monitoring, logging, content safety and cost control). Most of our agents now incorporate and run on this shared platform.
Four principles guide the architecture:
-
Documents and prompts run in parallel unless the business logic needs them in sequence.
-
Access follows the running user, and AI-generated outputs inherit the same permissions, so a stored summary can’t leak what the reader couldn’t have seen.
-
Failover is explicit at every step. Partial success can be more dangerous than visible failure, so we can't let edge cases sneak past us.
- Logging covers inputs, outputs and usage.
Policy logic also stays separate from the AI layer, so a rule change can be reviewed, tested and explained independently.
We also built an LLM Evaluation Hub, which is now live. A control plane triggers an evaluation run, and a small library embedded in the target service does the scoring and reports back asynchronously. That lets us score realistic document sets rather than small samples, and it makes monthly monitoring against ground truth routine rather than an event.
On robustness, our lending services are integrated with the same Alert & Triage platform we use in engineering. We have an LLM performance dashboard, observability tagging on every GenAI call, and PII masking in application logs, shipped as a shared library and being adopted service by service.
Where we go next
While progress is very encouraging, we have only built a small fraction of what we see as the possible target future state for lending. The next steps are more fields, document types, valuations on the shared extraction service, scheduled evaluation runs, and more of the lifecycle and product range covered.
The principle from Part I still holds. The value comes from letting agents run more of a complex process, with the data, workflow integration and governance that make the result trustworthy. Confidence thresholds, provenance and override mean a person can see what the agent did and step in where judgement is needed. Those controls let us extend that autonomy safely.
