Show me your model inventory and tier assignments.

regulus model-risk inventory export --format yaml produces the inventory. Tier assignment is per-model with the assigning Principal recorded. The audit chain shows every tier change with the approving SMF.

Show me the independent validation evidence for model X.

The Model Registry's validation-evidence field is a URL to the validation report. The audit chain has the validation events tagged with the validator's Principal. regulus model-risk validation model-x assembles the chain.

How are you monitoring model X's ongoing performance?

The eval harness (if wired) emits outcome events; filter the chain by model_id = X AND tag = OUTCOMES . Aggregate by month for the second-line dashboard. FAIRNESS_DELTA_ALERT events surface drift.

What happens if model X degrades?

The kill-switch plugin can collapse the agent's tool surface, requiring dual control to re-enable. The audit event captures both authorising Principals, the reason (MODEL_DRIFT, OUTCOME_THRESHOLD_BREACH), and the operational state at engagement.

What's your model retirement process?

Models in the Registry have review-due and retired-at dates. Once retired, invocations fail closed ( DENY_MODEL_RETIRED ). The retirement event captures the retiring SMF, the reason, and the replacement model ID.

PRA SS1/23 — what Regulus delivers for ADK agents

Who does it apply to?

UK PRA-regulated firms — Category 1 banks, building societies, PRA-designated insurers, large investment firms (PRA-regulated PIDFs).
Any of the above running AI agents that affect business decisions (credit, fraud, KYC, AML, treasury, capital adequacy, risk modelling).
Internal Model Risk Management (MRM) teams (typically Second Line of Defence) responsible for tiering and validating models.
Heads of Model Risk and Chief Risk Officers (SMF-7 / SMF-20) personally accountable for the firm's model risk framework.

Two-minute explainer

PRA Supervisory Statement SS1/23 (effective 17 May 2024) is the PRA’s model-risk-management framework for UK PRA-regulated banks and PRA-designated insurers. The supervisory statement is built around five principles that establish the firm’s model-risk framework end-to-end.

The most consequential question for agentic AI builders is whether an LLM-powered agent is a “model” under SS1/23. The supervisory statement 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 processing customer prompts to produce decisions about credit, fraud, or KYC meets every limb. The debate is over in most UK banks I’ve spoken to. The answer is yes.

The five principles, applied to LLM agents:

Principle 1 — Model Identification. Every model — including every LLM the agent uses, and arguably the agent itself as a composite model — must be registered in the firm’s model inventory with a clear definition of its purpose, scope, and limitations. The Regulus Model Registry is the runtime version of this inventory.
Principle 2 — Governance. The firm must have a model-risk policy approved by the management body, with clearly defined roles and responsibilities. The Chief Risk Officer (SMF-7) is the accountable executive. The policy translates to runtime as the set of profile rules and the SMF-Principal chain in the audit log.
Principle 3 — Model Development, Implementation and Use. The development lifecycle is mostly upstream of Regulus. The implementation and use sides are runtime: tier-3 models require dual-control authorisation, deployment events feed the audit chain, the agent’s tool dispatch is the use surface.
Principle 4 — Independent Model Validation. Tier-2 and tier-3 models require independent validation evidence. The Registry’s validation-evidence field links to the validation report; the audit chain captures validation-related events tagged by the validator’s Principal.
Principle 5 — Model Risk Mitigants. Ongoing monitoring, including performance monitoring and outcomes analysis. The audit chain carries every model invocation; the eval harness (when wired) emits outcome events; alerts surface on drift via FAIRNESS_DELTA_ALERT and similar event types.

The Regulus pra-ss1-23 profile composes with fca-sysc (for firms dual-regulated by PRA and FCA — most UK banks), with pra-ss2-21 (outsourcing risk), and with gdpr / uk-gdpr (personal data handled by a model in scope of MRM).

What the profile doesn’t cover: model development methodology, validation techniques (back-testing, sensitivity analysis), the firm’s overall capital-modelling stack. These are upstream of the agent. Regulus’s value is in delivering the runtime evidence the MRM framework references — the inventory, the tier-assignment audit trail, the ongoing-monitoring substrate, the kill-switch as the operational mitigant.

What it actually requires of an engineer

An LLM-powered agent making business decisions IS a model under SS1/23. The Principle 1 definition explicitly covers AI/ML. The debate is over; the question is now tiering and ongoing monitoring.
Principle 1 (Model Identification) requires an inventory. Every LLM your agent uses must be registered in the model inventory with an ID, tier, and validation evidence pointer. The audit chain is the runtime view of the inventory.
Principle 4 (Independent Validation) requires Second Line of Defence sign-off. Tier-2 and tier-3 models need independent validation evidence; the validator's Principal must be captured.
Principle 5 (Ongoing Monitoring) is the daily runtime obligation. Outcome monitoring, performance drift detection, periodic re-approval — all evidenced by the audit chain.
SMF-7 (Chief Risk Officer) is personally accountable. The CRO must approve the model-risk framework and the tier-assignment policy. Their Principal claim is the chain of accountability.

What Regulus does for you

Regulus control	Delivers
`RegulusModelRiskPlugin`	Principle 1 model identification — the Model Registry is the runtime inventory. Each registered model has an ID, tier (0–3), validation evidence pointer, approving SMF Principal, and review-due date. Unregistered model invocations fail closed.
`RegulusAuditPlugin`	Principle 5 ongoing monitoring substrate — every model invocation in the audit chain, filterable by model_id × outcome × tier. The Consumer Duty / FCA outcomes are the same data; SS1/23 just asks different questions of it.
`RegulusKillSwitchPlugin`	Principle 3 implementation safety — dual-control kill switch is the operational response to model-degradation events. Engagement is itself an MRM event.
`RegulusGovernanceEvidencePlugin`	Quarterly MRM board pack export — model inventory, tier distribution, outcome aggregates, review-due-date status, validation evidence pointer status. Routes to ServiceNow IRM / OneTrust automatically.
`RegulusPolicyPlugin`	Principle 2 governance enforcement — model risk policy clauses encoded as policy rules. Decisions outside model authority are denied.

Saves you ~16 engineer-weeks

Estimate based on the following honest assumptions:

Model Registry with tier + lineage + approval chain (4 weeks).
Ongoing monitoring integration with outcomes-tagging (4 weeks).
MRM board-pack format with FCA/PRA expectations (3 weeks).
Independent-validation evidence linkage (2 weeks).
Model retirement workflow + audit trail (2 weeks).
Assumes existing MRM team with established 2L processes; integration time only.

What an auditor will ask

The questions you'll see in a real walkthrough — and where to point them.

Show me your model inventory and tier assignments.

regulus model-risk inventory export --format yaml produces the inventory. Tier assignment is per-model with the assigning Principal recorded. The audit chain shows every tier change with the approving SMF.
Show me the independent validation evidence for model X.

The Model Registry's validation-evidence field is a URL to the validation report. The audit chain has the validation events tagged with the validator's Principal. regulus model-risk validation model-x assembles the chain.
How are you monitoring model X's ongoing performance?

The eval harness (if wired) emits outcome events; filter the chain by model_id = X AND tag = OUTCOMES. Aggregate by month for the second-line dashboard. FAIRNESS_DELTA_ALERT events surface drift.
What happens if model X degrades?

The kill-switch plugin can collapse the agent's tool surface, requiring dual control to re-enable. The audit event captures both authorising Principals, the reason (MODEL_DRIFT, OUTCOME_THRESHOLD_BREACH), and the operational state at engagement.
What's your model retirement process?

Models in the Registry have review-due and retired-at dates. Once retired, invocations fail closed (DENY_MODEL_RETIRED). The retirement event captures the retiring SMF, the reason, and the replacement model ID.

What this doesn't cover

Model development — Regulus runs against deployed agents; the model development lifecycle (training, evaluation, internal challenger testing) happens upstream.
Validation methodology — Regulus captures the validation evidence pointer; the methodology itself (back-testing, sensitivity analysis, stress testing) is your MRM team's domain.
Capital adequacy modelling — Regulus covers operational models in agents; ICAAP/SREP capital models are out of scope for this profile.
Compensation calibration — SS1/23 doesn't cover compensation; that's CSC/RemCo.

Citations

Activate this profile in your agent

regulus init my-agent --profiles=pra-ss1-23

Install the CLI All 10 regulations