Financial Services and AI: Regulatory Constraints

Financial firms have governed models for decades, and the discipline — inventory, development standards, independent validation, monitoring, governance — transfers to language models more cleanly than most people expect. What does not transfer is worth knowing precisely, because that is where the work is.

This is engineering guidance rather than legal or regulatory advice. Which supervisory expectations bind you depends on your licence, your jurisdiction and your activity; the frameworks named below are starting points to look up in their current form, not a statement of what applies to you.

The lifecycle finance already has

Model risk frameworks in banking and insurance tend to share a shape, whatever the local supervisor calls it. The five stages, and what each means once the model is a language model behind an API:

Three places it breaks on an LLM

• You cannot inspect the model. Validation traditionally assumes access to the specification, the training data and the coefficients. For a third-party model you have none of those. The workable substitute is behavioural: validate the system rather than the model, with a held-out evaluation set drawn from your own cases, acceptance thresholds agreed in advance, and the results re-run on every change. Document that this is what you are doing and why, rather than leaving a gap where the model documentation would be.
• The model changes underneath you. A hosted model can be updated without a version bump you control, which means the validated artefact and the deployed artefact can silently diverge — a situation the framework was never designed for. Pin versions where the provider allows it, record the exact model identifier with every decision, and treat a provider-side change as a change requiring re-validation. If a provider cannot offer version pinning, that is a material fact for the risk assessment rather than a procurement detail.
• Outputs are not deterministic. Monitoring built around a stable score distribution does not apply to free text. What works: sample and score continuously against a rubric, track refusal and error rates, track the rate at which output fails a structural check, and set alert thresholds on those series. Non-determinism is manageable and measurable; it is only unmanageable if you were expecting the old metrics.

The model inventory entry

If you produce one artefact, produce this one. It is the thing a supervisor, an internal auditor and a new engineer all want, and it is the same document:

model_use:        "Retail complaint triage — category + severity"
owner:            <named individual>
risk_tier:        medium — informs routing, does not decide outcomes
decision_type:    assistive   (assistive | automated | advisory)
customer_facing:  no — output is shown to an agent, not to the customer
provider:         <vendor>    model_id: <exact, pinned>
fallback:         <second model / rules path / queue to human>
prompt_version:   git sha
eval_set:         500 labelled historical complaints, refreshed quarterly
thresholds:       category accuracy >= 0.90; severity recall >= 0.95
monitoring:       daily sample of 50 scored by ops; weekly report
last_validated:   <date>  by: <independent reviewer>
change_triggers:  model id change, prompt change, threshold breach

Note decision_type and customer_facing. Those two fields determine most of the regulatory weight, and they are the two most likely to change without anyone updating the record — a feature that starts as a suggestion to a human tends to become the default the human accepts, and at some point that is an automated decision in everything but the field name.

The adjacent regimes that catch people

• Outsourcing and third-party risk. Financial supervisors have long-standing expectations about reliance on external providers — due diligence, exit plans, concentration risk, audit rights. A model API is an outsourcing arrangement even though it feels like a library import, and the exit plan question (“what do we do if this provider becomes unavailable tomorrow”) is one you should be able to answer anyway.
• Operational resilience. Regimes in several jurisdictions require mapping important business services to the resources they depend on and setting tolerances for disruption. A single-provider dependency inside a customer-facing service is exactly what those exercises are designed to surface.
• Advice versus information. The line between informing a customer and advising them is regulated, and a conversational interface is unusually good at crossing it without anyone deciding to. Guardrails on this are a product requirement, not a compliance afterthought.
• Fairness in credit and insurance. Where a model influences access to credit or pricing, anti-discrimination duties apply and testing for disparate outcomes is the expectation. A language model reading free-text applications is capable of picking up proxies for protected characteristics from writing style alone.
• Record-keeping. Communications with customers are often subject to retention duties that will not be satisfied by application logs. If a model wrote something a customer read, the record of it needs to live wherever your other customer communications live.

Where to start if you are not regulated yet

Firms outside financial services increasingly get asked for this material by financial-services customers, which is a cheaper way to discover the gap than a supervisory visit. Two things move the needle furthest for the effort: build the inventory, because you cannot govern what is not listed and the exercise itself usually finds two features nobody knew were live; and build the evaluation set, because every other control in the framework ultimately reduces to “show me it still works”, and without a held-out set of your own cases you have no way to answer.