AI Agents in Treasury and Risk: What the Reclassification Means for Your Controls

When an automated workflow becomes a regulated AI agent under model risk rules

Your team probably has at least one process that runs on a schedule, pulls data, applies logic across several steps, routes outputs, and flags exceptions. Nobody calls it an AI agent. The question you need to answer is whether a regulator would.

Regulatory thinking on agentic AI systems is moving faster than formal rulemaking. In the UK, there is no dedicated AI financial services rulebook. The PRA and FCA have published joint discussion papers (including DP5/24, the 2024 joint paper on AI in financial services from the PRA, FCA, FPC, PSR and CMA) that signal the direction of travel, but no AI specific regime yet exists. What does exist is SS1/23, the PRA's Model Risk Management Principles for Banks, published April 2023. That is the framework your automated workflows are most likely already sitting inside, whether or not your inventory reflects it.

This post sets out how to determine whether your automated workflows are in scope under SS1/23, what good controls evidence looks like, and what a supervisor will ask for first. The four practical tests are in the section below if you want to go there directly.

What regulators mean by an agentic system

Across published regulatory discussion papers and emerging supervisory thinking, the concern with agentic AI centres on three behavioural characteristics working together rather than on any specific technology.

Autonomy: the system initiates and completes actions without human approval at each step.

Sequential action: it executes a sequence of tasks where later steps depend on earlier outputs.

Environmental adaptation: it modifies its behaviour based on what it observes, which can include data inputs, system responses, or prior outputs.

The important word is adaptation. A static rules engine that always runs the same logic is not adapting. But a chained process where one module's output changes the parameters used by the next module, and that behaviour shifts across runs based on observed data, is adapting. The distinction is narrow in practice.

Consider three workflow types common in treasury and risk teams.

Controls testing scripts that loop through a portfolio, apply multiple checks in sequence, and escalate based on a threshold comparison across results. Liquidity forecasting chains that pull actuals, apply stress overlays, and generate LCR or NSFR inputs with routing logic that selects which methodology to apply based on the data it sees. Regulatory reporting assemblers that collect inputs from multiple sources, reconcile differences, and produce a submission file, with conditional logic at each junction.

None of these are marketed as AI agents. All three potentially meet the behavioural description above. That is the risk event: existing systems needing reclassification, not new ones needing approval.

Why the UK position requires more judgement than a rulebook

Because the UK applies a regulatory approach based on principles rather than prescriptive rules, agentic systems do not fall into a dedicated AI regime. They fall into whatever regime governs the thing they are doing. For treasury and risk work, that is primarily SS1/23.

SS1/23 applies to any tool used in decision making that involves a quantitative methodology of material complexity. It does not explicitly address AI or agentic systems. The PRA has not issued guidance that maps agentic systems to SS1/23 by name. But an agentic system making routing or escalation decisions across a liquidity workflow almost certainly qualifies as a model under SS1/23's scope, and the firm must make that determination itself.

This is the harder regulatory position. A prescriptive rulebook tells you when something is in scope. A framework based on principles requires you to reason about your own systems and document why you reached the conclusion you did. If your reasoning later proves wrong, the inadequacy of your self-assessment is itself a finding.

The 2024 AI discussion paper (DP5/24) noted significant gaps in how firms understand and document the AI and automated tools they use, particularly where third party models are involved. The point is not the percentage. The point is that supervisors have already signalled this is an area of active scrutiny, and that inventory and tiering gaps are a known weakness across the industry.

If you want broader context on how liquidity risk governance sits within the bank's three lines of defence model, the post on who owns liquidity risk covers the organisational design questions underneath this.

Four tests to apply this week

Before a firm can document its position, it needs to identify which processes are in scope. Run these four tests across your automated workflows.

Test one: the step count test. Does the process execute more than one action in sequence, where the output of step one influences step two? If yes, it is a candidate.

Test two: the approval gap test. Between the first action and the final output, how many human approvals occur? If the answer is zero or one at the end, the system is operating autonomously across most of its steps.

Test three: the variability test. Does the system produce a different sequence of actions or apply different logic on different days, based on what it observes in the data? If yes, it is adapting.

Test four: the documentation test. Can you retrieve a complete description of what the system did on a specific date, including which rules fired, which thresholds were applied, and which outputs were routed where? If no, you already have a traceability gap, regardless of classification.

Any workflow that passes tests one and two, and either of tests three or four, should go on your inventory as a candidate for tiering under SS1/23.

What good evidence looks like

Supervisory expectation in this space centres on traceability. Every decision the system makes, every escalation it triggers, every override a human applies, needs to be logged with a timestamp and retrievable in a format an examiner can read without specialist explanation.

That is a higher bar than many teams currently meet. Logging that a report ran is not the same as logging what decisions were made during the run. A timestamp on a file delivery does not tell a supervisor why the system chose the methodology it applied that morning.

Good evidence has four characteristics.

It captures decisions, not just process completion. The log records what was decided at each material step, not merely that the process finished.

It is readable in context. An auditor should be able to reconstruct the logic without needing to read source code.

It is searchable by date and by decision type. A supervisor asking about a specific day's LCR input should be able to get a complete decision trail for that run in a reasonable amount of time.

It includes override records. Where a human intervened, the log records who, when, and what they changed, and ideally why.

The question of how meaningful human oversight remains when a system can change its own approach between runs is genuinely unresolved under SS1/23. The practical answer most firms are landing on is to define which decisions require mandatory human review before the output is used, and to make those review steps auditable and separate from the automated log. That is a judgement call, and firms should document the reasoning behind where they drew the line.

For practitioners thinking about how coding and automation decisions interact with control frameworks, the post on AI coding agents in finance covers the delivery side of that question.

What a supervisor will ask for first

When a supervisor or internal audit function reviews an agentic or potentially agentic system, the first request will not be a technology explanation. It will be documentation.

Specifically, expect requests for: the inventory entry and the rationale for its tier, the validation evidence proportionate to that tier, the oversight design including where human review points sit and how they are evidenced, the override and escalation procedure and the log showing it has been followed, and the change management record showing how the system has been updated and who approved each change.

If your inventory entry does not exist, that is the finding. Everything else follows from it.

The practical priority for this week is straightforward. Take the four tests above and run them across your automated workflows. Identify candidates. Create or update inventory entries with honest tiering rationale. Define your human review points explicitly and make them auditable. Do not wait for an explicit AI rule from the PRA or FCA. The framework based on principles means the obligation already exists under SS1/23.

For teams building out their understanding of the liquidity risk landscape these systems operate within, the post on the five types of liquidity risk banks manage provides useful grounding.

The regulatory risk here is not that your system does something harmful. It is that you cannot demonstrate what it did, why, and who was responsible for overseeing it. That gap is closable. Start with the inventory.