Skip to main content
JOJonas Osman
· 4 min read

PRA SS1/23 in Practice

By , Actuary & Quantitative Risk Expert

SS1/23 is five principles long and deceptively demanding. The gap between a compliant framework and a working one is almost always ownership and evidence.

This article relates to my work on Model Validation & Model Risk, AI & Quantitative Risk Models and Climate & Catastrophe Risk.

By Jonas Osman Abdelghafour.

The PRA's SS1/23 sets out five principles for model risk management: identification and tiering, governance, development and implementation, independent validation, and the management of model risk from deployment onwards. Read quickly, they look like a description of what most banks already do. Implemented honestly, they expose the places where a framework exists on paper and not in the operating model.

Principle 1: you cannot manage what you have not defined

Model identification is where implementations most often fail, because the definition is drawn narrowly to keep the inventory manageable. The consequence is a shadow estate — spreadsheets that set pricing overlays, deterministic rule engines in financial crime, vendor tools whose calculations nobody has inspected, and increasingly AI assistants embedded in workflow software.

A defensible approach defines a model by the use of its output and applies proportionate treatment through tiering. Tier 1 attracts full independent validation and annual review; lower tiers attract registration, ownership, and a lighter periodic assessment. The test of the definition is simple: if a supervisor picked any decision that materially affects earnings, capital, or customers, could you name the models behind it?

Principle 2: governance is accountability, not committees

SS1/23 expects a senior manager to own model risk as a discrete risk type, with board-level visibility. In practice this means a named accountable executive, a policy with real teeth on unapproved use, and a risk appetite for model risk that is expressed in something more decision-useful than "low". Appetite statements that work usually combine limits on unvalidated Tier 1 exposure, tolerances for overdue findings, and explicit conditions under which a model must be restricted or withdrawn.

Principle 3: development discipline before validation

Independent validation cannot repair a badly documented build. The development standard should require a statement of intended use, data lineage, rejected alternatives, testing evidence, known limitations, and the compensating controls attached to each limitation. Limitations are the most neglected section and the most useful one: a model with clearly stated boundaries and enforced use restrictions is safer than a model whose weaknesses are discovered in production.

Principle 4: what effective challenge means

Validation adds value by testing what the developer could not or would not test. The productive questions are about conceptual soundness given the intended use, the sensitivity of outcomes to material assumptions, the quality and representativeness of the data, performance under stress and across segments, and whether monitoring will actually detect deterioration. Re-performing the developer's calculations proves arithmetic, not soundness.

Independence needs to be structural — reporting line, budget, and the authority to impose conditions or block use — otherwise "effective challenge" becomes editorial.

Principle 5: life after go-live

Most model risk is realised long after approval. A working post-implementation regime specifies, per model, what is monitored, at what frequency, against which thresholds, and what happens when a threshold breaks. Breach responses should be pre-agreed: recalibration, overlay, use restriction, or withdrawal. Post-model adjustments deserve particular attention — they are a legitimate short-term tool and a common way for unmodelled judgement to become permanent and unowned.

Where implementations go wrong

  • The inventory is a list, not a control. Nobody reconciles it to production systems.
  • Findings age. Overdue validation findings are the clearest leading indicator of a framework that is not working.
  • Tiering is negotiated. If business lines can argue their way into a lower tier, materiality has become a budget conversation.
  • Vendor models are exempt in practice. Limited access to internals is a reason for compensating testing, not for skipping assessment.
  • Board reporting counts models. It should report exposure, drift, and open decisions.

A pragmatic sequencing

Institutions building or rebuilding a framework generally get further by fixing the estate before refining the methodology: complete and reconcile the inventory, assign owners, tier by materiality, close the Tier 1 validation gap, then invest in monitoring automation. Sophisticated validation methodology applied to an incomplete inventory protects nothing.

SS1/23 rewards evidence. The institutions that implement it well are not the ones with the longest policies; they are the ones that can show, on any given day, which models are live, who owns them, how they are performing, and what management will do next.

Primary sources: Bank of England / PRA Supervisory Statement SS1/23, Model risk management principles for banks.