The UK organisation for the business of Open Technology

When SS1/23’s five principles came into force on 17 May 2024, the PRA explicitly expanded the definition of “model” to cover AI/ML systems with qualitative outputs, which pulls LLMs into scope. This means an LLM drafting a credit decision or flagging a fraud pattern in a UK bank is a model under the SS1/23 enforcement regime. SS1/23 means the LLM should be inventoried and tiered, have a board-approved risk framework and accountable owner, be fully documented and tested, undergo independent validation, and have controlled fallbacks if drift, bias, or unexplained performance issues emerge. It bears the question: how can a closed-ecosystem LLM accessed only via API, such as GPT, Claude, and Gemini, ever fulfil that level of control requirements? Are open source models, such as DeepSeek or Qwen, the only way to fulfil these audit requirements? Or are open-weight models, such as Llama or Gemma, the happy medium for financial institutions looking for a way to easily fulfil SS1/23 requirements?

To ground the debate, I’d like to be precise on what is meant by closed-ecosystem, open source, and open-weight models. Closed-ecosystem models provide access via API only. Open-weight models publish parameters, but not training data and code. Open source models publish their weights, code, and training data/pipeline. Most of what gets called “open source AI” in banking vendor conversations today is actually open-weight, and that distinction changes the answer to the SS1/23 question considerably.

Walking through SS1/23’s five principles, let’s test what openness actually helps fulfil for each one.
* Principle 1, model identification and classification: An LLM is a model whether its weights are public or not, so openness doesn’t help make fulfilment of this principle any easier.
* Principle 2, governance: A bank’s governance maturity doesn’t improve just because the underlying artefact is open, so again openness doesn’t make fulfilment any easier.
* Principle 3, development, implementation and use: Open source models make this step easy. For an open-weight model, a bank can inspect architecture, reproduce behaviour locally, and control its own deployment and fine-tuning pipeline. But for a closed ecosystem model, it bears asking if a bank can independently verify these steps without solely relying on a vendor attestation?
* Principle 4, independent model validation: Validating a closed ecosystem model is limited to black-box behavioural testing against a vendor-controlled API. Validating an open-weight model means the bank’s independent validation function can run its own adversarial testing, interpretability tooling, and reproducibility checks. Open source models allow for full independent validation. The position of open-weight and open source models is materially evidentiary for Principle 4.
* Principle 5, model risk mitigation: Open source and open-weight models allow a bank to implement its own mitigations, e.g., fine-tuning away known failure modes, deploying monitoring at the weight level. This is a materially different risk position compared with relying entirely on vendor-provided guardrails in closed ecosystem models.

In my walkthrough of SS1/23 above, I have often conflated the position of open source and open weight models as compared to closed ecosystem models. The reality is more nuanced. There are many technical challenges for open-weight model safety flags that published weights alone does not resolve, such as training data provenance, fairness documentation, or evaluation methodology transparency. This was widely covered in a paper last autumn from the AI Security Institute which confirmed that the training data black box persists whether the weights are open or not. https://www.aisi.gov.uk/research/open-technical-problems-in-open-weight-ai-model-risk-management
Hence, open-weight is a partial validation shortcut. With open-weight models, SS1/23 principles on data lineage and fairness remain only as satisfiable as the vendor’s disclosure about what the model was trained on, which isn’t widely published by open-weight model vendors.

The ultimate question then becomes how much of the model risk evidentiary stack can the bank’s own independent validation function verify versus how much it has to take on vendor attestation alone? Open-weight models shift Principles 3, 4, and 5 from vendor attestation fulfilment into bank-controlled and evidence-based, which appears a measurable advantage from a model-risk-management perspective. Perhaps then the only gap between open-weight and open source models is the Principle 1/data-provenance gap that only models with open training data would solve for. A model risk management function that can pull the weights into its own test environment, run its own adversarial and drift testing, and reproduce a flagged failure on demand has a fundamentally stronger basis than one relying on a vendor’s terms of service and transparency report. Not to mention that vendor API behaviour can change on the vendor’s schedule and in ways that could silently invalidate a prior validation. This risk does not exist for a bank running its own fixed set of open weights under its own change control.

The decision on whether to use open source, open-weight, or closed ecosystem models in regulated banking environments is a concrete example of why open AI ecosystems matter to UK financial services. It is clear that open-weight and open source models bear a specific advantage against the principles in SS1/23. UK banks should consider open-weight and open-source options when selecting AI vendors specifically because of this advantage. The question was never about what parts of a model is open, but rather whether a team can evidence and verify it.