Framework · Model risk
SS1/23 never mentions AI. It still reaches your LLMs.
The PRA's model risk principles are technology-neutral, and their model definition covers models developed externally, including vendor models. Every LLM provider your firm calls is one. Meilynx evidences that slice of the estate.
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 firm has no internal model permission, the statement does not apply to you — though 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 and joined to the business outcome it produced. The analysis and the conclusion stay with your model risk team; Meilynx supplies the evidence they run it on. | Vendor model monitoring record with outcome join |
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 and joined to the business outcome it produced. The analysis and the conclusion stay with your model risk team; Meilynx supplies the evidence they run it on.
Examination artifact · Vendor model monitoring record with outcome join
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. That is a team, not a telemetry feed, and Meilynx defines no control for it. The examination package says so on its face rather than leaving a supervisor to infer coverage from silence.
Named as out of scope
- 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 monitoring joined to your own business outcomes.
- Restrictions in force and the exceptions they produced.
- A scope statement naming the principles the package does not evidence.
- 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 firm 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 firm?
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 — though the PRA notes other firms may find the principles useful.
Does Meilynx perform independent model validation?
No, and it is not a gap we intend to close. Principle 4 asks for an independent validation function that reviews, verifies, and revalidates models. That is your function, staffed by your people. Meilynx defines no control for it and the examination package names Principles 4.1 to 4.3 and 4.5 as out of scope, alongside board responsibilities, internal audit, model development, and post-model adjustments.
Does the preset make us compliant with SS1/23?
No runtime product could. SS1/23 asks for a model risk management framework across your whole model estate, most of which has nothing to do with language models. Meilynx evidences the AI and agent slice of that estate — the inventory, the monitoring, the restrictions, and the record behind them — so the part you run through the data plane is documented rather than asserted.
Build the evidence.
See exactly what an examiner receives
Download a sample examination package: model inventory, control coverage, a governance policy snapshot, and a SHA-256 integrity hash.