PRA model risk and AI: what must a UK bank evidence under SS1/23?

Under the Prudential Regulation Authority's supervisory statement SS1/23, a UK bank must evidence five things for every model it relies on, and this now expressly includes artificial intelligence and machine learning: a complete model inventory with risk tiering, clear governance with board and senior management accountability, documented development and use, independent validation with effective challenge, and mitigants for any model that is not fully validated. SS1/23, which took effect on 17 May 2024, treats a model a firm cannot identify, validate or evidence as an unmanaged risk on its own balance sheet.

In 2026 the pressure is no longer theoretical. Banks are moving generative and predictive AI into credit decisions, financial crime screening and pricing, and supervisors expect the same discipline they demand of a traditional risk model. The hard part is not building the model but proving, months or years later, which version made a decision, on what data, and who approved it, without the record being altered. That is where many AI deployments quietly fail.

What does SS1/23 actually require a bank to evidence?

SS1/23 sets out five principles. Read as an evidence checklist they are concrete:

• Principle 1, model identification and risk tiering: a firm must maintain a complete inventory of its models and rank each by materiality and risk.
• Principle 2, governance: a named accountable owner, board and senior management oversight, and policies that are actually followed.
• Principle 3, development, implementation and use: documented design, data, testing and limitations, so a model's behaviour is explainable after the fact.
• Principle 4, independent validation: review by a party independent of the model's developers, with effective challenge and a recorded outcome.
• Principle 5, model risk mitigants: for any model not fully validated, compensating controls and monitoring that are written down.

SS1/23 applies to UK banks, building societies and PRA-designated investment firms with internal model approval. It makes no exception for AI. A machine learning model that scores a loan is a model, and it must sit in the inventory with everything else.

How does a sovereign runtime evidence each principle?

A Sovereign Intelligence Operating System, a SIOS, makes the evidence a by-product of running the model, not a document assembled afterwards. Mickai is a SIOS that runs offline on operator-owned hardware, with every action cryptographically sealed, and each principle maps to a control:

• Identification maps to model provenance: every model version carries a signed record of its origin, weights hash and configuration, so the inventory is generated, not typed.
• Governance maps to hardware-attested identity: approvals and role changes are bound to a verified operator identity and written to the same sealed chain.
• Development and use map to recorded execution: inputs, outputs, model version and parameters are captured for every inference.
• Validation maps to recorded validation: an independent review, its challenge and its verdict are stored as signed entries an examiner can locate.
• Mitigants map to cross-model consensus and monitoring: where one model is not fully validated, several sovereign models can be run in consensus and divergence recorded.

What can a PRA examiner verify independently?

The test that matters is offline verifiability: an examiner should be able to take the audit ledger and confirm its integrity without trusting the bank, the vendor or the internet. In our architecture the ledger is sealed with post-quantum digital signatures: FIPS 204, ML-DSA, is the primary signature standard, with FIPS 205, SLH-DSA, as a stateless hash-based alternative. These are signature schemes: anyone with the public key can verify that an entry is authentic and unaltered. FIPS 203, ML-KEM, is key encapsulation and never signs, so it plays no part in the verifiability of the record. Because each entry is chained and signed, a single changed byte breaks the chain and is visible.

“Model risk management is ultimately an evidence discipline, and a control a supervisor cannot independently verify is not a control at all.”

Why can public AI services not satisfy SS1/23?

Public AI services such as ChatGPT, Claude and Gemini are useful, but a regulated UK bank cannot evidence SS1/23 through them. The model version can change without notice, so provenance is unstable, and inference runs on infrastructure the bank does not control, so it cannot produce a complete, independent record. Data leaves the perimeter, which raises GDPR and, for firms exposed to it, US CLOUD Act questions about foreign access. A sovereign runtime answers this with a zero-egress perimeter: models and data stay on the operator's hardware, and the audit trail is held by the bank, not a third party.

Which other rules make this necessary?

SS1/23 does not sit alone; the same evidence base supports adjacent obligations:

• DORA, in force since January 2025, requires operational resilience and control over ICT third parties, which favours systems a firm can run and audit itself.
• NIS2 raises security duties for essential and important entities across the EU.
• GDPR governs the personal data these models process, including automated decisions.
• ISO/IEC 42001 provides a certifiable AI management system that aligns with the governance SS1/23 expects.
• The EU AI Act still applies to many UK firms operating in the EU. Its high-risk Annex III obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

What should a UK bank put in place first?

Start with the inventory, because Principle 1 is the foundation for the other four. Then make evidence automatic: capture provenance and execution records at the point of inference, keep validation as signed entries rather than static reports, and seal the whole ledger so it can be checked offline. The capabilities described here are the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. When a supervisor asks which model made a decision and whether the record is intact, the answer should be one query away.

Frequently asked questions

What is PRA SS1/23 and when did it take effect?

SS1/23 is the Prudential Regulation Authority's supervisory statement on model risk management principles for banks. It was published in May 2023 and took effect on 17 May 2024. It sets five principles, covering identification, governance, development and use, independent validation, and mitigants, and applies to firms with internal model approval.

Does SS1/23 apply to AI and machine learning models?

Yes. SS1/23 is deliberately technology neutral and expressly brings AI and machine learning into scope. A machine learning model used for credit scoring, fraud detection or pricing is a model under the statement and must be inventoried, governed, validated and monitored like any other.

What evidence does a PRA examiner expect for an AI model?

An examiner expects a model inventory with risk tiering, a named accountable owner, documented development and testing, an independent validation record with effective challenge, and mitigants for anything not fully validated. Crucially, those records must be verifiable after the fact, not reconstructed on request.

Can a UK bank use ChatGPT or similar services and still meet SS1/23?

Not for regulated model use. Public services change model versions without notice and run on infrastructure the bank does not control, so the firm cannot guarantee stable provenance or a tamper-evident record. A sovereign runtime that runs offline on the bank's own hardware keeps provenance, validation and the audit trail inside the firm's control.

How does a tamper-evident audit trail actually work?

Each entry in the audit ledger is cryptographically chained to the one before and signed with a post-quantum signature scheme, FIPS 204 as primary and FIPS 205 as an alternative. Anyone holding the public key can verify offline that an entry is authentic and unchanged. Altering a single record breaks the chain and is visible.