For MRM heads & SS1/23 validators
Yes, an LLM-powered agent is a model under SS1/23.
The debate is over in most UK banks I've spoken to; the answer is yes. The real question is tiering, validation, ongoing monitoring — and none of those emerge from a Vertex AI Model Registry entry alone. That's the substrate, not the MRM evidence trail.
The five tests that decide whether your LLM agent is a "model" under SS1/23
PRA Supervisory Statement SS1/23 (effective 17 May 2024) defines a model in Principle 1 as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques and assumptions to process input data into output." An LLM agent making credit decisions, fraud assessments, or KYC determinations meets every limb of that definition.
- Does it process input data into output? Yes. Prompts in, decisions out.
- Does it use statistical / economic / financial / mathematical theory? Yes. Transformer architecture is statistical.
- Are the techniques used internally? Yes. Even if the LLM is third-party, the agent wrapping it is internal.
- Does it affect a financial decision the bank takes? Yes for credit/fraud/KYC agents.
- Is the output relied upon by the bank? Yes in production deployments.
What SS1/23 expects, and where Regulus delivers it
The PRA's principles map to runtime artefacts:
- Principle 1 (Model Identification). Regulus model-risk plugin tags every model invocation with a registered model ID, tier, and validation evidence pointer.
- Principle 2 (Governance). The audit chain captures the SMF accountability — which Principal authorised this model's deployment, which tier authority claim authorised this invocation.
- Principle 3 (Implementation). Implementation artefacts (prompt templates, tool registrations, profile YAML) are versioned and tagged in the audit chain.
- Principle 4 (Independent Validation). Tier-3 model invocations require dual-control authorisation; the validator's Principal is captured in the audit envelope.
- Principle 5 (Ongoing Monitoring). The audit chain is the monitoring substrate. Filter by model_id × outcome × tier; export to ServiceNow IRM for the second-line dashboard.
And the cross-cutting regimes
- FCA SYSC 4 + Consumer Duty. Outcomes monitoring on a cross-cutting-rule basis. Audit events tagged with the resolved consumer-segment and the Duty rule (PRIN 12.1–12.4) hit.
- PRA SS2/21 (Outsourcing). LLM providers (OpenAI, Anthropic, Google) are third parties. Regulus GRC adapter ships third-party register entries on each model invocation; concentration risk surfaces as a configurable alert.
- NHS DSPT (if you're in health-finance crossover). The 10 NHS standards map through the privacy + audit + residency plugins.
The question a PRA walkthrough actually asks
A real second-line walkthrough on an LLM-agent credit decision will look like:
- "Show me your model inventory." Regulus model-risk plugin maintains it; export as YAML or CSV.
- "Show me the validation evidence for model X." The audit chain has the validation events tagged with the validator's Principal and the validation report URL.
- "How are you monitoring model X's ongoing performance?" The eval harness emits outcomes events; filter the chain by
model_id = X AND tag = OUTCOMES. - "What happens if model X degrades?" The kill-switch plugin can collapse the agent's tool surface, requiring dual control to re-enable. Audit event captures both authorising Principals.