Framework · Model risk
SS1/23 evidence for every LLM and AI model your organization calls.
The PRA's model risk principles are technology-neutral, and their model definition covers models developed externally, including vendor models. Every LLM provider your organization calls is one. Meilynx evidences that slice of the estate. PRA SS1/23 explained, with the April 2026 update covers the statement, its scope and what changed.
A narrower population than the name suggests.
SS1/23 is relevant to UK-incorporated banks, building societies, and PRA-designated investment firms that hold internal model approval for regulatory capital. If your organization has no internal model permission, the statement does not apply to you. The PRA notes the principles may still be useful.
What the model definition covers
- Models developed in-house or externally, including vendor models, used to inform business decisions.
- Material, complex deterministic methods and algorithms that bear on business decisions, under Principle 1.1(b).
- Complexity factors that name unstructured data, interpretability, explainability, transparency, and potential designer or data bias.
- Third-country branches, credit unions, insurers, and reinsurers are explicitly out of scope.
Five principles, across the model lifecycle.
Identify and classify the models you run, govern them, control how they are developed and used, validate them independently, and hold mitigants for when one misbehaves.
- Principle 1 — model identification, a firm-wide inventory, and risk-based tiering.
- Principle 2 — governance, SMF accountability, and the use of externally developed and vendor models.
- Principle 3 — model development, implementation, and the systems models run in.
- Principle 4 — independent validation, review, and ongoing performance monitoring.
- Principle 5 — mitigants: restrictions on model use, and exception escalation.
Each expectation, to a control.
A specific Meilynx control for each expectation we evidence, and the artifact it produces.
SS1/23 → Meilynx controls
| Requirement | How Meilynx maps | Examination artifact |
|---|---|---|
Maintain a complete, accurate model inventory SS1/23 · Principle 1.2 | The inventory is populated from live proxy traffic: every model that actually reached a provider, held against the approved allow-list. A model in use cannot be missing from it. | Model inventory, generated from traffic |
Compare a model's intended use against its actual use SS1/23 · Principle 1.2(c)(i) | Each model carries an approved tool and capability envelope. Calls outside it are blocked and recorded, so the gap between intended and actual use is a record rather than an assertion. | Intended-use envelope and deviation log |
Monitor vendor model performance using your own outcomes SS1/23 · Principle 2.6(b)(iii) | Every call to an external provider is recorded, by model and provider. Your model risk team runs the outcomes analysis against your own business outcomes and draws the conclusion; Meilynx supplies the call-level record it starts from. | Vendor model call record, by model and provider |
Change control over the systems a model runs in SS1/23 · Principle 3.6 | System prompts and tool grants are pinned to approved baselines, and any unapproved change is detected against them rather than discovered later. | Configuration baseline and drift record |
Place restrictions and limits on model use SS1/23 · Principle 5.2(a) | Restrictions are enforced inline at the data plane. A model prohibited for a purpose is refused, not merely described as prohibited in a policy document. | Enforced restrictions and the blocks they produced |
Escalate exceptions to approved model use SS1/23 · Principle 5.3 | Use outside the approved envelope routes through an approval gate and lands in the record with its disposition, which is what the escalation procedure needs to point at. | Exception log with approval disposition |
Maintain a complete, accurate model inventory
SS1/23 · Principle 1.2
Maps to · The inventory is populated from live proxy traffic: every model that actually reached a provider, held against the approved allow-list. A model in use cannot be missing from it.
Examination artifact · Model inventory, generated from traffic
Compare a model's intended use against its actual use
SS1/23 · Principle 1.2(c)(i)
Maps to · Each model carries an approved tool and capability envelope. Calls outside it are blocked and recorded, so the gap between intended and actual use is a record rather than an assertion.
Examination artifact · Intended-use envelope and deviation log
Monitor vendor model performance using your own outcomes
SS1/23 · Principle 2.6(b)(iii)
Maps to · Every call to an external provider is recorded, by model and provider. Your model risk team runs the outcomes analysis against your own business outcomes and draws the conclusion; Meilynx supplies the call-level record it starts from.
Examination artifact · Vendor model call record, by model and provider
Change control over the systems a model runs in
SS1/23 · Principle 3.6
Maps to · System prompts and tool grants are pinned to approved baselines, and any unapproved change is detected against them rather than discovered later.
Examination artifact · Configuration baseline and drift record
Place restrictions and limits on model use
SS1/23 · Principle 5.2(a)
Maps to · Restrictions are enforced inline at the data plane. A model prohibited for a purpose is refused, not merely described as prohibited in a policy document.
Examination artifact · Enforced restrictions and the blocks they produced
Escalate exceptions to approved model use
SS1/23 · Principle 5.3
Maps to · Use outside the approved envelope routes through an approval gate and lands in the record with its disposition, which is what the escalation procedure needs to point at.
Examination artifact · Exception log with approval disposition
Independent validation stays yours.
Principle 4 asks for a validation function independent of model development.
Stays with your validation team
- Principles 4.1–4.3 and 4.5 — the independent validation function, independent review, process verification, and periodic revalidation.
- Principle 2.1 and 2.5 — board responsibilities and internal audit.
- Principles 3.1 and 3.3–3.5 — model purpose and design, development testing, adjustments and expert judgement, development documentation.
- Principle 5.1 — post-model adjustments.
What you hand a supervisor.
The record renders into a package structured on the statement's own five principles, so a supervisor reads it in the order they already think in.
In the package
- Model inventory, populated from traffic, with intended use against actual use.
- Vendor model use, recorded call by call for your own outcomes analysis.
- Restrictions in force and the exceptions they produced.
- A scope statement naming the principles that stay with your validation function.
- SHA-256 integrity hash over the audit chain.
Model risk management in the UK.
What is SS1/23?
SS1/23 is the Bank of England Prudential Regulation Authority's supervisory statement on model risk management for banks, effective 17 May 2024 following PS6/23 and revised in April 2026. It is built on five principles: model identification and risk classification, governance, development and use, independent validation, and model risk mitigants.
Does SS1/23 apply to AI?
Not by name. SS1/23 does not mention artificial intelligence or machine learning anywhere in its text. It is technology-neutral model risk management. It reaches AI through its model definition, which covers models developed in-house or externally, including vendor models, used to inform business decisions. An LLM your organization calls is a vendor-supplied model under that definition, and the PRA has run roundtables with regulated firms on exactly this question.
Does SS1/23 apply to my organization?
Only if you hold internal model approval. The statement is relevant to UK-incorporated banks, building societies, and PRA-designated investment firms with permission to use internal models for regulatory capital. Firms without that permission and third-country branches are outside its scope, and credit unions, insurers, and reinsurers are excluded explicitly. The PRA notes other firms may find the principles useful.
Build the evidence.
See exactly what an examiner receives
Request a sample examination package: model inventory, control coverage, a governance policy snapshot, and a SHA-256 integrity hash.