Financial services

Credit decisions
you can explain.

If you decline someone, you generally have to tell them why, in terms specific enough to act on. That single obligation determines where a language model can sit in a credit process and where it cannot.

Last reviewed 4 September 2026 · Engineering guidance, not legal advice.

THE CONSTRAINT THAT SHAPES EVERYTHING

Adverse-action rules in the US, and GDPR Article 22 together with the revised Consumer Credit Directive in the EU, oblige a lender to explain a decline in terms specific enough to act on. Anti-discrimination and fair-lending rules oblige you to show the decision was not driven by a protected characteristic or a proxy for one. Under the EU AI Act, creditworthiness assessment of natural persons is treated as high-risk, with documentation, human oversight and record-keeping obligations that follow. This describes the engineering constraint; it is not legal advice.

A language model is not a credit scorecard and should not be used as one. It does not produce a stable, auditable reason code, its outputs vary across runs, and its decision boundary cannot be characterised in the way a regulator expects. Deploying an LLM as the decisioning function is the mistake this page exists to warn against.

Where it is genuinely valuable is everywhere around that decision — the parts of the process that are currently manual, slow and inconsistent, and that carry no adverse-action obligation of their own.

WHERE IT BELONGS

Document extraction

Bank statements, payslips, filed accounts, tax documents. Turning submitted documents into the structured inputs your scorecard expects, with every extracted figure linked to the page it came from. High volume, tedious, and error-prone when done by hand.

Application completeness

Detecting what is missing or inconsistent before an underwriter opens the file. A large share of underwriting time is spent discovering a document is absent, and that discovery can happen at submission instead.

Policy question answering

An underwriter asking what the credit policy says about a specific circumstance and getting a cited answer from the current policy document. Removes a recurring interruption and improves consistency across a team.

Not: the decision itself

The approve/decline boundary stays with your scorecard and your credit policy, which are explainable, stable and validated. An LLM in that slot cannot produce a defensible reason code, and no amount of prompting fixes that.

WHAT WE INSIST ON

Extraction is verified, not trusted. Every figure the system pulls from a document carries a link to the source page and, where confidence is low, is flagged for human confirmation before it reaches a decision input. An unverified extracted number feeding a scorecard is a silent error with a regulatory tail.

Nothing the model produces enters the decision function without passing through a deterministic validation step your team owns. Schema, range checks, cross-document consistency — the boring layer that turns a probabilistic output into an auditable input.

And the whole path is recorded: which model version, which prompt, which documents, which extracted values, which human confirmed what. That record is the deliverable that makes the system defensible, and it is far cheaper to build in than to reconstruct.

AROUND THE DECISION

DOCUMENT PATH

Applicant documents

statements · payslips · accounts
Extract

every figure linked to its page
Validate

schema · ranges · cross-document
Confirm

human check on low confidence
Scorecard

deterministic, explainable
Adverse-action reasons

from the scorecard, never the model

Solid: the document path we build Dashed: the decision path, which stays with your scorecard

The model never touches the decision boundary. It turns documents into validated inputs, and every input keeps a link to the page it came from.

QUESTIONS

QUESTIONS — 3

To phrase an explanation in plain language for a customer, yes — from reason codes your scorecard already produced. To generate the reasons themselves, no. The explanation must be a faithful account of why the model decided as it did, and a language model writing a plausible-sounding rationale after the fact is producing something worse than nothing.

No. It classifies creditworthiness assessment of natural persons as high-risk, which brings obligations rather than prohibition: risk management, data governance, documentation, logging, human oversight and accuracy monitoring, alongside conformity assessment and registration, with a carve-out for fraud detection. Deployer-side duties, including a fundamental-rights impact assessment for credit institutions, sit with you. The document-processing work described here is likely to be a preparatory task rather than the high-risk decision itself, which your own provider and deployer assessment should document. The classification and the obligations that follow are for your legal and compliance functions to confirm; this is not legal advice.

It varies by how document-heavy your product is and we would rather not quote a number we have not measured on your process. What we would do is measure it on a sample of your real applications before you commit to a build.

Keep reading

Industry

AI for Financial Services

Enterprise AI Governance

→

30-minute technical call · no deck