PRA SS1/23 Model Risk Management: validating multi-table banking models without PII exposure.

§ 01 / SS1/23 two years in

From CP6/22 to lived experience

The Prudential Regulation Authority published Supervisory Statement 1/23 on 17 May 2023 as part of Policy Statement PS6/23. The supervisory statement followed Consultation Paper CP6/22 issued in June 2022 and represents the first time the PRA has codified explicit model risk management expectations for UK banks. Five principles came into force on Friday 17 May 2024, applying initially to firms with internal model approval for regulatory capital purposes — Internal Ratings Based approaches for credit risk, Internal Model Approach for market risk, and Internal Model Method for counterparty credit risk.

Two years into the in-force period, the picture is sobering for many in-scope firms. Self-assessments submitted to the PRA in 2024 have triggered detailed follow-up requests, particularly around model governance documentation and the treatment of deterministic quantitative methods (DQMs). Remediation plans typically run two to three years from the in-force date, placing the bulk of the work into 2026 and 2027. The PRA has indicated that several large banks will need to provide further information about their MRM frameworks, policies and standards in the coming supervisory cycles.

The scope question is the operational bottleneck. SS1/23 defines a model as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into output." That definition covers, as confirmed by Bank of England technical officers, marketing decisions, fraud detection, credit decisioning, anti-money laundering, IFRS 9 ECL calculations, and end-user computing artefacts such as significant Excel-based pricing models. Large banks typically discover hundreds to thousands of in-scope models once an honest inventory is performed, and many are owned outside the traditional model risk function.

§ 02 / Five principles

The structure of SS1/23

SS1/23 organises its expectations around five principles covering the entire model lifecycle. Each principle has sub-principles with operational expectations the PRA can examine during supervisory engagement.

The PRA's deliberate design choice was to write principles rather than rules. Principles allow proportionality but place the interpretive burden on the firm. A robust internal interpretation, signed off at board level and tested against PRA expectations through dialogue, is the operational protection. Banks that treat SS1/23 as a checklist exercise produce remediation plans that fail at the validation step, because validation under Principle 4 demands evidence that decisions were genuinely independent and effectively challenged.

§ 03 / Broad model definition

What enters scope you may not expect

The breadth of SS1/23's model definition is the single largest operational consequence for UK banks. Traditional model risk functions are scaled to handle internally developed regulatory capital models, perhaps with extension to IFRS 9 and ICAAP modelling. They are not scaled to handle end-user computing artefacts in business units, vendor-provided fraud detection scoring, marketing propensity models, or the AI-assisted onboarding decisions that have proliferated in retail banking.

Three categories warrant specific attention. Vendor models are explicitly in scope. The PRA expects firms to receive sufficient information from vendors to validate the use of external models, without forcing disclosure of vendor proprietary information. In practice this means contractual amendments for fraud detection providers, KYC verification systems, transaction monitoring platforms and similar third-party scoring tools. End-user computing models — typically Excel-based pricing tools, deal calculators, and capital impact spreadsheets developed by business units — meet the definition of a model when they apply quantitative methods to support business decisions. AI and machine learning models are within scope by default; the PRA acknowledged the complexity of AI/ML during consultation but declined to write a separate framework, expecting firms to apply the principles proportionately.

The PRA's deliberate breadth shifts the validation burden. A retail bank that previously had ten Tier 1 models for capital purposes may discover after honest inventory it has dozens of additional models in fraud, marketing, and customer support that fall into Tier 2 or below but still require documented validation, performance monitoring, and risk classification. The validation function cannot reasonably scale ten-fold; the practical answer is tiered validation depth, supported by automation and high-quality test data.

IFRS 9 expected credit loss models occupy a particular position in this expanded scope. They are not in scope of regulatory capital internal model approval in the same way as IRB models, but the PRA has been clear that material IFRS 9 ECL models meet the SS1/23 definition and warrant Tier 1 or Tier 2 treatment given their direct impact on the firm's reported financial position and on Stage 2 and Stage 3 staging decisions affecting customer outcomes under Consumer Duty.

§ 04 / Principle 4 deep dive

Independent validation in practice

Principle 4 is where SS1/23 most directly intersects with data infrastructure. Independent validation under SS1/23 requires effective challenge of model decisions, conceptual review, outcomes analysis, and ongoing performance monitoring. Each of these activities requires representative data that exposes the model to scenarios it has not seen in training and that exhibits the multi-table dependencies present in production.

Standard validation activities include sensitivity testing under stress scenarios, performance comparison against benchmark models, back-testing on out-of-time samples, and bias and fairness assessment where the model influences customer outcomes. Each of these activities is performed by an independent team — independent in the sense that it does not report into model development. The team's effectiveness depends on the quality of its testing infrastructure. A validation team working on stale or unrepresentative data produces challenge findings that the model development team can rebut on data quality grounds, undermining the independence Principle 4 requires.

Multi-table fidelity is the underappreciated data requirement. A credit decisioning model is not a single-table classifier; it consumes data from customer master, transaction history, product holdings, external bureau scores, and behavioural indicators. Validating that model in a sandbox where one of these tables has been masked or sub-sampled produces validation findings that reflect the data preparation, not the model. Two years of supervisory observations under SS1/23 show this pattern repeatedly: validation work documented thoroughly on data that was not fit for the purpose of challenging the model.

§ 05 / Data dependencies in validation

Why masking fails effective challenge

Independent validation teams under SS1/23 commonly receive copies of production data into a separate environment with documented access controls. The intent is sound: separate the validation environment from production to prevent inadvertent influence on live operations. The execution typically breaks down at the data preparation step.

Three common failure modes appear in PRA dialogue with banks. Masking destroying referential integrity: replacing customer identifiers in a customer table without coordinated replacement across the linked transaction, product, and complaint tables creates orphan records and broken joins. Validation tests on this data produce both false negatives (genuine model issues hidden by data preparation artefacts) and false positives (apparent model issues that are actually data preparation defects). Sub-sampling destroying tail behaviour: validation of a credit model is particularly concerned with the behaviour at the boundary, where small changes in inputs produce material changes in outputs. Random sub-samples typically under-represent these boundary regions, producing validation reports that are confident about average performance and silent about edge-case behaviour. Static snapshots aging out of relevance: validation environments built on snapshots taken six or twelve months earlier drift from current production behaviour. Model performance reports based on these snapshots produce supervisory findings about validation cadence as well as model performance.

The technical answer recognised by mature MRM functions is to maintain test data that preserves the multi-table causal relationships of production at all timescales of analysis, without retaining any specific real customer records. Causal multi-table synthesis is the architectural approach that delivers both properties simultaneously.

§ 06 / UK GDPR Article 32

Personal data in validation environments

The Data (Use and Access) Act 2025 amended UK GDPR but left Article 32 substantively unchanged. The duty to implement appropriate technical and organisational measures to ensure security of processing applies equally to validation environments containing personal data. ICO enforcement under both pre-DUAA and post-DUAA cases has treated validation, UAT, and development environments as in scope for Article 32 enforcement.

Validation environments are inherently higher risk than production environments for three structural reasons. Access patterns are broader: validation teams, internal audit, vendor support engineers, and occasional external consultants all touch the validation data. Audit controls are typically less mature: validation environments do not always have the same logging and monitoring depth as production. Lifecycle pressure is different: validation environments are torn down and rebuilt frequently, producing momentary windows of weaker controls. A breach in a validation environment carries the same Article 32 exposure as a breach in production, and the controller's defence is weaker because the existence of personal data in the environment was an architectural choice.

The PECR alignment in DUAA, increasing maximum PECR fines to £17.5 million or 4% of global annual turnover, raises the financial stakes. A UK bank that loses customer data from a validation environment used for SS1/23 model validation work faces both ICO enforcement under Article 32 and PRA enforcement for inadequate model risk controls. The combined exposure is multiplicative rather than additive.

§ 07 / SMR personal accountability

The senior manager dimension

SS1/23 explicitly integrates with the Senior Managers Regime. The accountable individual for model risk management is typically the Chief Risk Officer under SMF4 prescribed responsibility, with adjacent involvement from the Head of Internal Audit, the Chief Operating Officer, and Chief Compliance Officer depending on bank structure. The Statement of Responsibilities document for the SMF holder must reflect MRM accountability.

The personal liability dimension changes the calculus around remediation. Material findings from PRA supervisory engagement on MRM weakness can lead to enforcement against the responsible SMF holder, including potential fines, prohibition from holding senior management functions, and public sanction. The Chief Risk Officer of a UK bank cannot reasonably leave SS1/23 compliance as a delegated project; the personal exposure forces direct engagement with the operational details, including the data infrastructure underpinning validation work.

The practical consequence is heightened scrutiny from the senior manager level on the data fidelity of validation environments. CROs increasingly ask their MRM teams pointed questions about whether validation evidence would survive a regulatory deep-dive: is the test data current, multi-table consistent, properly governed, and free of personal data risk. Where the answer to any of these is no, the senior manager has both regulatory and personal interest in resolving the gap.

§ 08 / What Infundum is designing

Causal multi-table synthesis for MRM

Infundum's CAUSA AI Data Engine is being designed as a causal multi-table synthesis infrastructure for the financial sector. CAUSA is pre-MVP; what follows describes design intent, not shipped feature set.

For SS1/23 independent validation under Principle 4, CAUSA addresses three specific needs. First, multi-table fidelity for credit and behavioural models: synthesis preserves causal dependencies across customer, transaction, product, complaint, and external bureau data, ensuring that validation tests exercise the same conditional distributions present in production. Second, scenario-controlled stress testing: synthetic counterfactuals where specific tail events, demographic shifts, or stress conditions are amplified, allowing validation teams to test model behaviour in scenarios that production data has not historically exhibited. Third, audit-grade lineage: each generated dataset carries documented generation parameters, model, seed, and privacy threshold, suitable for evidencing the data quality of validation work in PRA supervisory dialogue.

Deployment is self-hosted within the bank's secure perimeter. Production data informs the synthesis pattern but never leaves the security boundary. Specific architecture details are available under NDA during formal evaluation.

§ 09 / Related

Regulatory context

For the related framework on UK data protection see UK DUAA 2025 and FCA Consumer Duty: synthetic data for demonstrable compliance. For PRA SS1/21 operational resilience and continuous testing see PRA SS1/21 Operational Resilience: synthetic data for continuous compliance. For the FCA SDEG governance considerations see FCA SDEG considerations for synthetic data in UK financial services.

Conclusion

Two years into SS1/23, UK banks are confronting the operational consequences of a deliberately broad model risk framework. The scope question is settled — thousands of models per bank, including vendor systems, end-user computing tools, and AI/ML applications. The governance and validation questions remain in flux as remediation plans run through 2026 and 2027. Principle 4 independent validation is the central pressure point: it demands data that is current, multi-table consistent, and representative of production behaviour, while UK GDPR Article 32 demands that validation environments do not become routes for personal data exposure. The two requirements pull in opposite directions for any approach that copies production data into validation environments. Causal multi-table synthesis closes the gap by providing high-fidelity validation datasets without personal data, and by producing audit-grade lineage suitable for senior manager and supervisor dialogue. Infundum is designing CAUSA AI Data Engine for this purpose.