Every referred application arrives with the evidence gathered, affordability worked out and the score explained in plain English. A person makes every referred decline, clear-cut cases stay with the existing decision engine and its safeguards, and fairness is checked every month.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
A typical lender already has a decision engine: policy rules, a scorecard and data from one or more credit reference agencies. Clear-cut applications go through it in seconds. The rest are referred to an underwriter, and that's where the time goes. The underwriter opens the bureau report, the application, uploaded payslips and bank statements, and, if the customer agreed, open banking transaction data. Then they work out income and essential spending by hand, check that the documents match what was declared, and decide.
Each referral can take 20 to 40 minutes, and most of that is gathering and reconciling, not judging. Two underwriters looking at the same file can reach different answers. When a customer asks why they were declined, the honest answer is often a list of scorecard reason codes that nobody outside credit risk understands.
The rules ask for more than a score. CONC 5.2A requires a borrower-focused creditworthiness assessment: not just whether the lender will be repaid, but whether the customer can repay without hardship. The Consumer Duty asks lenders to show that outcomes are fair across customer groups, including vulnerable customers. Since 15 July 2026, deferred payment credit (buy now pay later) has been regulated too, so more lenders are adding products that need the same checks at much higher volumes.
Any AI in this process is also a model. Banks in scope of PRA SS1/23 have to inventory, validate and monitor it like the scorecard. Everyone else will find their auditors and the FCA asking the same questions.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Time moved from gathering data to judging the case.
ExampleFrom 30 minutes to around 12
How long a referred customer waits for an answer.
ExampleFrom 2 days to same day
How often two underwriters reach the same decision on the same test file.
ExampleUp, measured quarterly
How often underwriters disagree with the affordability summary or the explanation. Very high means it isn't helping; near zero can mean people have stopped checking.
ExampleStable, and reviewed weekly
Customers falling behind in their first 12 months, by product. Faster decisions must not mean worse lending.
ExampleNo worse than last year's lending
Approval rates, pricing, arrears and complaints, split by the groups the lender can measure, including vulnerable customers.
ExampleNo group worse off without a justified reason
Cross-sector rules are on the UK regulation map.
The assessment must be borrower-focused and proportionate, covering current income and non-discretionary spending unless that would be obviously disproportionate, with records that show it was reasonable. The AI gathers and calculates. The underwriter checks the figures, decides, and the file keeps the evidence behind every number.
There's no AI-specific rulebook. The FCA applies the Duty to AI like any other change. Every decline, whether from the decision engine or an underwriter, comes with a reason the customer can understand, outcomes are monitored by customer group, and the lender can explain any decision if challenged.
Buy now pay later offered by a third-party lender has been regulated since 15 July 2026, with CONC conduct rules and the CONC 5.2A creditworthiness rules applying, proportionately, even to small agreements. If the lender offers it, the same affordability and fairness controls apply at much higher volume.
Applies to banks and building societies with approval to use internal models for regulatory capital, and is a sensible standard for everyone else. The document reading, the affordability calculation and the explanation layer all go on the model inventory, with an owner, a risk tier, independent validation and monitoring.
Since 5 February 2026, solely automated credit decisions are allowed with safeguards: telling people, letting them make representations and contest the decision, and a person who can step in. The strict limit now applies mainly where special category data, such as health details in a hardship note, is involved. In this design, clear-cut cases stay with the lender's existing decision engine, with those safeguards in place: the customer is told, can challenge the decision, and a person can step in. Applications involving special category data are always referred. A person makes every referred decline, and the AI itself never declines anyone.
Bureau, bank and document data is processed only for this application, in UK regions, with a DPIA before the pilot, a clear retention period, and a contract that stops providers training their models on your data. Open banking data is used only with the customer's explicit consent, through the lender's regulated account information provider.
Protected characteristics aren't used as inputs, and the lender tests for proxies such as postcode that could lead to indirect discrimination. Age can be used in a risk assessment only where it rests on relevant information from a reliable source (the financial services exception). Fairness tests run before go-live and every month after.
Credit scoring of individuals is high-risk under Annex III. Following the Digital Omnibus, those duties apply from 2 December 2027. This only matters if the lender scores customers in the EU, but the documentation, logging and human oversight in this design are the same things the Act asks for.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels and data sources
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Intake: applications and documentsBroker applications arrive in their own formats. Map them once, at the API layer. | API Gateway, S3 | API Management, Blob Storage | Kong or your existing API gateway; Ceph or IONOS S3 Object Storage |
| Reading documentsTest on real uploads: phone photos of payslips, screenshots of banking apps, multi-page PDFs. | Amazon Textract | Azure Content Understanding (includes Document Intelligence) | Open-source parsing (e.g. Docling) plus an open-weight vision model |
| Affordability and transaction categorisationA conventional, explainable model sits on the model inventory and is validated like any other credit model. | Amazon SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Reasoning, summaries and explanationsAWS and Azure both offer a choice of models, including Claude. The language model writes explanations from reason codes; it never scores. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Lending policy knowledge (retrieval)So the agent checks against your current lending policy and its version history, not general knowledge. | Bedrock Knowledge Bases | Foundry IQ, built on Azure AI Search | OpenSearch, or PostgreSQL with pgvector |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| Fairness and drift monitoringSageMaker Clarify and Model Monitor closed to new customers on 30 July 2026, so build the tests into your own pipeline. | SageMaker AI pipelines with open-source fairness tests (e.g. Fairlearn) | Azure Machine Learning pipelines with open-source fairness tests (e.g. Fairlearn) | MLflow and Kubeflow on Kubernetes, with open-source fairness tests (e.g. Fairlearn) |
| Workflow | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| Link to origination and the decision engineThe bureau and open banking connections you already have stay as they are. The AI reads their results; it doesn't call the bureaux itself. | API Gateway, plus your existing integration platform if you have one | API Management, plus your existing integration platform if you have one | Kong or your existing API gateway, plus your existing integration platform if you have one |
| Human reviewUnderwriters decide where they already work, not in a new screen. | In the underwriters' existing origination workbench | In the underwriters' existing origination workbench | In the underwriters' existing origination workbench |
| GuardrailsBlock explanations that mention anything not in the reason codes, or refer to protected characteristics. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protection | IAM Identity Center, KMS, Macie | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every file, every figure, every explanation and every underwriter decision, with the reason. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The loan origination system, the decision engine and scorecard, core banking and the bureau connections stay where they are. In many lenders these are on their own servers or a private cloud, and nothing here needs them to move.
Uses cloud AI
Document reading, transaction categorisation, the policy index and the application file agent can run in AWS or Azure UK regions, or on your own GPUs with open-weight models if credit data must not leave your estate.
How they connect
A private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Only the fields needed for the file are sent, with the application ID in place of the customer's name where possible, and results come back as events onto your queue.
If the link drops
Applications keep flowing through the decision engine as they do today. Referrals queue for underwriters, who work them by hand, and files are built for the backlog when the link returns.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Application file agent
Where a person signs offA person makes every referred decline and every referred approval, and signs off the explanation sent to the customer. Clear-cut cases stay with the existing decision engine, not the agent. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
The loan origination system stays the record, and the existing decision engine keeps doing what it does today. The AI sits beside it: it reads the engine's outputs and the referral, and writes a file and a draft back to the underwriter's workbench through the API layer.
Bureau and open banking calls stay where they are, in the integrations the lender already runs, with their own consent and audit trails. The AI never calls a bureau, so it can't trigger a search the customer didn't agree to.
Each referral becomes a message on a queue. If the origination system is slow, files wait safely, and every message carries the application ID, so a retry never builds a second file or sends a second letter.
The AI can be switched off without stopping lending. If it's paused, referrals go to underwriters exactly as they did before, and the decision engine is unaffected.
Map today's referral process, measure the baseline, confirm data access to bureau, open banking and document data, and agree the model risk tier with validation.
Gate · must be true to passBaseline agreed, data access confirmed, DPIA started, model risk and compliance involved.
One product, such as personal loans, in shadow mode: the AI builds files and explanations, underwriters work as normal, and the two are compared.
Gate · must be true to passFigures accurate within agreed tolerances, explanations faithful to reason codes, fairness tests passed, independent validation and compliance sign-off.
Files and explanations go live for referrals on the first product, with monitoring, support and a rollback plan.
Gate · must be true to passMonitoring, fairness reporting, support model, rollback plan and underwriter training in place.
Add products one at a time, such as cards or deferred payment credit, then reuse the pattern for collections and hardship reviews.
Gate · must be true to passEach new product passes the same pilot and validation gate.
| Activity | Chief credit officer | Product owner | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Model risk | Compliance & DPO | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Consulted | Informed |
| Target architecture | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted | Consulted |
| DPIA, Consumer Duty and Equality Act review | Accountable | Consulted | Consulted | Informed | Informed | Consulted | Responsible | Consulted |
| Model inventory and independent validation | Accountable | Consulted | Consulted | Informed | Consulted | Responsible | Consulted | Informed |
| Build and integration | Informed | Consulted | Accountable | Responsible | Responsible | Informed | Informed | Consulted |
| Fairness testing | Accountable | Consulted | Consulted | Consulted | Responsible | Responsible | Consulted | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted | Consulted |
| Run, monitor and improve | Informed | Accountable | Consulted | Consulted | Responsible | Consulted | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the target architecture, the integration with your origination system and decision engine, the controls that keep every referred decline with a person and the AI out of the decision, and the gates. I'd report to your programme board and work alongside your credit risk and model risk teams.
Option B
If your partner or your own team already has an architect, I'd take on the document reading, the application file agent and the origination integration under their lead, and give them a second senior opinion on the rest. Where the work needs more hands, I bring in people I trust.
Goes wrong
The language model is asked why a customer was declined, and makes up a plausible reason.
How the design avoids it
Explanations are written only from the scorecard's reason codes and the underwriter's recorded reason, and a guardrail blocks anything else.
Goes wrong
The affordability figures look right, so underwriters stop checking the sources.
How the design avoids it
Every figure links to its evidence, override rates are watched, and a sample of files is re-checked every month.
Goes wrong
Nobody puts the AI on the model inventory, and validation finds it six months after go-live.
How the design avoids it
Agree the risk tier and the validation plan at discovery, and pass validation before the pilot ends.
Goes wrong
A postcode or spending pattern acts as a proxy for a protected characteristic, and nobody sees it.
How the design avoids it
Fairness tests before go-live and every month after, reviewed by the credit risk committee.
Goes wrong
Clear-cut declines from the decision engine go out without telling the customer that the decision was automated or how to challenge it.
How the design avoids it
Engine decline letters say the decision was automated and how to ask for a person, challenges go to an underwriter, and challenge rates are part of the monthly review.
Goes wrong
Faster decisions push up approvals, and arrears follow a year later.
How the design avoids it
Track early arrears by product alongside speed, and treat any rise as a gate failure.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Keep open banking data behind your own API layer, so a change of provider or standard doesn't touch the AI.
Read it for the FCA's practical expectations on testing and monitoring, and compare them with your validation plan.
Generate decision letters and disclosures from templates you control, so wording can change without touching the models.
Keep the file, the explanation, the underwriter's decision and the customer's challenge records in a form you could show the ICO.
If you lend in the EU, plan the conformity work now. If not, the same logging and oversight are still good practice.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
