Blog

Polarising Website

UK Banks: 5 PRA SS1/23 Model Risk Management Controls for AI

Analyst comparing bank model validation outputs

Model risk management is a firm-level discipline that ensures models, including AI, are identified, governed, validated and monitored to keep business decisions safe and auditable. The regulatory baseline in the UK comes from PRA SS1/23 and evolving Bank of England and FCA thinking on AI. The single most urgent action for any firm reviewing its position is to confirm a complete model inventory, apply risk-based tiering and switch on monitoring before anything else.

TL;DR:

  • Confirm a complete model inventory and apply risk-based tiering to prioritize models according to decision materiality, not technical complexity.
  • Maintain rigorous version control and lineage documentation to support auditability and enable reconstruction of model histories.
  • Use continuous monitoring with performance, data quality, and drift metrics tailored to each tier to detect issues promptly and trigger revalidation.
  • Conduct thorough due diligence on third-party models, including vendor testing evidence, contractual remedies, and operational fallback plans.
  • Embed governance into the build pipeline through automated validation and logging, with a shift towards system-level oversight as AI scales.
Polarising
Build More Accountable AI Systems
Polarising integrates AI into enterprise processes with governance and accountability designed into the system from the outset.

Explore Polarising

Table of Contents

Core principles and governance: the regulatory baseline

PRA SS1/23 sets out five principles that apply to every model type a firm runs, whether built in-house, bought from a vendor or generated by machine learning. Each principle turns into a specific obligation rather than a slogan.

  • Model identification and classification means every model that influences a decision is named, defined and entered into an inventory, no exceptions for spreadsheets or shadow tools.
  • Governance assigns clear ownership, from board oversight down to the accountable individual under senior manager regimes.
  • Model development and use requires documented build standards and defined boundaries for what a model is, and is not, licensed to do.
  • Independent model validation separates the people who build a model from the people who approve it for use.
  • Model risk mitigants cover the fallback plans, overlays and manual controls that apply when a model is wrong or unavailable.

Senior management owns the outcome, not just the policy document. The essential artefacts are an MRM policy, a defined reporting line into the board or a risk committee, and audit evidence that each principle is being applied, not merely written down.

Model lifecycle, inventory, tiering and versioning

A model, for MRM purposes, is any quantitative method or algorithm that transforms inputs into an output used to inform a business decision. That definition deliberately catches AI systems, statistical models and rule-based tools alike.

  1. Build the inventory first. Capture the model’s purpose, owner, data sources, build date, last validation date and current tier for every model in scope.
  2. Apply risk-based tiering. Tier by the materiality of the decision the model drives, not by its technical complexity: a simple model behind a large lending decision can outrank a sophisticated model used for internal reporting.
  3. Set tier consequences. Higher tiers demand more frequent validation, tighter monitoring thresholds and faster escalation paths.
  4. Maintain version control and lineage. Log every change to code, data or parameters, with a timestamp and a named approver, so a validator or auditor can reconstruct the model’s history without asking the build team.

This lifecycle record is what turns an ad hoc collection of models into an auditable estate, and it is the artefact regulators ask for first.

Validation and testing: standard approaches and AI/ML caveats

Validation exists to answer one question independently: does the model do what it claims, within understood limits? Deliverables should be reproducible, tied to defined acceptance criteria, and documented well enough for someone outside the build team to repeat the test.

  • Standard validation covers conceptual soundness, data quality, outcome testing and sensitivity analysis.
  • AI and machine learning models introduce specific caveats: overfitting to historical data, sample bias in training sets, and correlated features that can distort explainability outputs.
  • Explainability techniques such as SHAP and LIME can mislead when input features are correlated, so the FCA’s research on machine learning treats them as governance enablers rather than proof of safety on their own.
  • For high-stakes decisions, a simpler, more interpretable model with a known error profile can be a safer choice than a marginally more accurate black box.

Pro Tip: Keep a pre-approved fallback model on standby for any tier-one AI system, so a validation failure triggers a switch rather than a scramble.

Challenger models, run in parallel without making live decisions, give validators an independent benchmark against which to judge the primary model’s stability over time.

Ongoing monitoring, drift detection and re-validation triggers

Periodic validation catches problems too slowly for models that learn or drift between review cycles. A monitoring pack converts validation into a continuous discipline.

  • Metrics and dashboards should track predictive performance, data quality and infrastructure health together, not in isolation.
  • Threshold rules define exactly what performance drop or drift level triggers a review.
  • Cadence by tier means tier-one models are watched weekly or daily, lower tiers monthly or quarterly.

Bank of England roundtable findings identify overfitting risk and slow, cumulative model drift as a distinct control gap in dynamic models. Firms should maintain a change ledger and a cumulative-change metric, because a series of small, individually approved tweaks can add up to a materially different model without ever triggering a single-change review.

Operational levers matter as much as the metrics: automated alerts, human-in-the-loop approval for high-impact actions, live challenger models and a defined kill switch for when a model must be pulled from production immediately.

Ongoing monitoring, drift detection and re-validation triggers — overview diagram

Third-party models and vendor due diligence

Vendor models carry the same risk as in-house ones, with less visibility into how they were built. Enhanced due diligence is necessary because vendors are not always required to self-assess, so firms must verify quality independently, a point made directly in guidance on third-party model due diligence.

  1. Request documented evidence of the vendor’s own testing, data sources and integration logic before signing.
  2. Negotiate contract terms that guarantee documentation access, change control notice and audit rights, not just service uptime.
  3. Set remediation service levels for when the vendor’s model misbehaves in production.
  4. Map dependence on any single vendor and keep an operational fallback for models the business cannot function without.

Monitoring contracts should extend the firm’s own dashboards to cover vendor model outputs, not just the vendor’s internal reporting.

Setting model risk appetite, exceptions and escalation procedures

Risk appetite for models needs measurable metrics tied directly to tiering, such as maximum tolerated drift, minimum acceptable accuracy, or a hard limit on the number of overdue revalidations.

  • Express appetite in numbers a model owner can check against a dashboard, not in general statements of caution.
  • Exceptions to policy should carry a time limit, a named approver and a mandatory revalidation date, never an open-ended waiver.
  • Temporary mitigants, such as manual review of every model output, should be documented as a condition of the exception, not an informal workaround.
  • Breaches above appetite escalate to senior management immediately, with the audit committee informed at its next scheduled reporting cycle.

Practitioner perspective: implementing MRM in enterprise AI programmes

Governance works best when it lives inside the build pipeline rather than bolted on afterwards, as detailed in AI Consulting & Transformation as a Service | NEXTmsp. Embedding validation checks and audit logging into CI/CD gives every model change a traceable record automatically, which is a more effective control than a periodic, manual sign-off exercise. Senior nearshore delivery teams can sustain this discipline across the working day by holding change control and monitoring cadence steady as the estate grows.

A workable rollout sequence runs: complete inventory, apply tiering, stand up a monitoring dashboard, complete independent validation, then hand over to operational owners.

Five-stage AI model risk rollout sequence

Pro Tip: Treat the integration layer between systems as part of the model estate: undocumented data flows are a common source of hidden model risk.

Where model risk management is heading as AI scales

Expect the centre of gravity to shift from periodic validation towards continuous, system-level monitoring, including oversight of agentic models that act with less direct human sign-off at each step. Explainability will keep functioning as a governance enabler rather than a standalone proof of safety, which means risk, engineering and data science teams need to build shared fluency rather than working in separate silos. The sensible investment priorities for the next few years are monitoring infrastructure, vendor resilience and automated assurance.

— Polarising Team

How Polarising supports model risk management delivery

Turning an MRM framework into working controls means building inventories, dashboards and validation pipelines that engineering teams can actually maintain, not just policies that sit in a document library. Polarising’s AI engineering services cover exactly that build work, from pilot through to production, backed by senior nearshore teams in the UK and Portugal with experience in regulated, high-volume environments.

Polarising

For firms assessing where their current model estate stands against these controls, or looking to embed monitoring and audit trails into an existing AI programme, Polarising’s AI pods provide dedicated delivery capacity without a long procurement cycle. Book a discovery call to scope an assessment.

Sources

FAQ

What is model risk management?

Model risk management is the discipline of identifying, governing, validating and monitoring every model a firm uses, including AI systems, so that decisions based on those models remain safe and auditable. In UK financial services, the baseline expectations come from PRA SS1/23.

What are the five steps of a risk management model?

A practical MRM cycle runs through identification and inventory, risk-based tiering, independent validation, ongoing monitoring, and mitigation or escalation when problems arise. This mirrors the five core principles set out in PRA SS1/23: identification, governance, development and use, independent validation, and mitigants.

What are the three types of model risk?

Model risk is commonly grouped into risk from incorrect or poorly specified models, risk from models used outside their intended purpose, and risk from weak implementation or data quality. AI and machine learning models add a further layer of risk around drift and correlated features that can undermine explainability tools such as SHAP and LIME, as noted in FCA research on machine learning.

What is the model risk management guideline in the UK?

The core UK guideline for banks is PRA SS1/23, which sets five principles covering identification, governance, development, validation and mitigants for all model types. The FCA supplements this by expecting firms to adapt existing frameworks such as SM&CR and SYSC to AI risks, as described in analysis of the FCA’s evolving expectations, while the UK AI risk management toolkit offers practical lifecycle guidance across sectors.