# A trusted framework for agentic finance: what changed in v1.2.0, sgit.ai

> The changes to the article "A trusted framework for agentic finance" in v1.2.0, paragraph by paragraph.

*Source: <https://newsroom.sgit.ai/articles/versions/a-trusted-framework-for-agentic-finance/v1.2.0.html> · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.*

---

[Home](../../../index.md) / [Articles](../../index.md) / [A trusted framework for agentic finance](../../a-trusted-framework-for-agentic-finance.md) / [Versions](../a-trusted-framework-for-agentic-finance.md) / v1.2.0

# A trusted framework for agentic finance: what changed in v1.2.0

From v1.1.0 (2026-10-19, `831cb1578`) to v1.2.0 (2026-10-20, this release), paragraph by paragraph.

15 paragraphs added, 9 removed, 6 changed in place, 41 unchanged. About 901 words added and 575 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.

[← v1.1.0](v1.1.0.md) · [all versions](../a-trusted-framework-for-agentic-finance.md)

1 unchanged paragraph

Summary: Jessica Rusu, the FCA's chief data, information and intelligence officer, said today that the FCA will work with industry, other regulators and frontier labs on a trusted framework for agentic finance, with clear approaches to agent identity, delegated authority, accountability and execution. Most of what she asks of firms is something we have been writing about and publishing openly here: Agent Behaviour Policies that put what an agent can do beside what it may do, a holder for every risk with a chain to the board, rules kept by something the agent cannot reach, breaks and near misses reported, and policies as graphs. This is a crosswalk from her points to that work, and a worked example:exampletheinbehaviourapolicy ofvault: an invented bank'sbankpaymentswithagent,six agents, each with all four elements filled in, twelveandrows,onethreeday of themtheirgaps,workeachreplayedgapthroughwiththe gate. Every near miss and breach that day came through a holder andgap, a decision.row kept only by the prompt, a setting or nothing; the rows kept by systems the agent cannot reach held. It is all CC BY. The FCA, or anyone building the framework, could adopt it, or write their own; if theirs is a graph too, the two can be connected with edges, without either side adopting the other's schema.

1 unchanged paragraph

!trail pellbridge

6 unchanged paragraphs, under In short {#in-short}

• **A worked example: a payments agent.** Twelve rows, all four elements filled in, three gaps with holders.

• **A worked example, at play.** An invented bank, six agents, all four elements, in a vault.

• **Every incident came from a gap.** Boundary rows held; near misses and breaches came through the gaps.

14 unchanged paragraphs, under What the FCA said {#speech}, Four elements we have been writing about {#four}

## A worked example: aPellbridgepayments agentBank {#example}

The speech mentions the AI Lab seeing firms build "agent-led payments", so heretheisexample starts with one. AnTo show it at play rather than on paper, we built [a vault](https://newsroom.sgit.ai/demos/vaults/pellbridge-agents/index.html) around an invented bankbank,deploysPellbridge, with six agents: a payments assistant, a support agent, a lending pre-check, an AML alert reviewer, a fraud triage agent thatandpaysabillstransactionforreporting agent. Each has a behaviour policy with all four elements filled in, and the vault replays one customer:dayit readsof their accounts, pays existing payees, and asks the customer before anything unusual.work. Everything belowin it is invented and illustrative; the vocabulary is the ABP's. Here is the payments assistant; [the tour](../../inside-the-pellbridge-agents.md) goes through the rest, with the files.

!shot fc-abp-rows.webppa-agent-pay.webp | images/ | Delegated authority and execution: theThe payments agent'sassistant'stwelve rows. For each capability, can it (grant), may it (mandate), what standspolicy in the wayvault,(barrier),withwhoall four elements: identity, from consent to policy hash; delegated authority, twelve rows with three gaps marked; accountability, the chain from the product owner to the board and a decision for each gap; execution, what keeps theeachrule,row, and whoeveryholdsdecisionit.itThreemaderows,thatindayorange,withareitsthe delta.receipt. | conceptscreenshot

5 unchanged paragraphs

Eight of the twelve rows are kept by systems the agent cannot reach: the payment platform checks limits and asks the customer, the API gateway scopes reads, the identity service binds the token to one customer. Two are kept by hooks in the bank's harness. One is kept by a setting the agent could flip, and one by the prompt. In ABP terms, only the first eight are boundaries; a setting is not a control, and an expectation is a hope.

Every decision the platform makes, allow, ask or deny, writes a receipt with the row and the policy version, kept in a vault, encrypted and versioned. The rows are also a test pack. They run on every model change, every policy change and every week, and a failed row stops the release. That is my reading of "continuous, conditional assurance": not a review at deployment, but a policy that is re-proven every time something under it moves.

[figure fc-abp-frame.webp] Around the rows: the agent's identity, the chain of holders to the board, and how the rules are kept, recorded, re-tested and failed safely. Identity and holders are not in the ABP today; they are proposed here. | architecture

Nine of the twelve rows are kept by systems the agent cannot reach: the payment platform checks limits and asks the customer, the API gateway scopes reads, the identity service binds the token to one customer, and the vulnerability signals route the chat to a person. One is kept by an output check that can miss, one by a setting the agent could flip, and one by the prompt. In ABP terms, only the first nine are boundaries; a setting is not a control, and an expectation is a hope.

Every decision, allow, ask or deny, writes a receipt with the row and the hash of the policy it was made under, chained to the receipt before it and kept in the vault. The rows are also a test pack. They run on every model change, every policy change and every week, and a failed row stops the release. That is my reading of "continuous, conditional assurance": not a review at deployment, but a policy that is re-proven every time something under it moves.

3 unchanged paragraphs

Every row has one holder. The head of payments holds six of them, the product owner two, and the heads of advice, support, lending and operations one each. Each holder has a chain to the board through the senior manager whose responsibilities cover retail payments. The three gaps each get a decision from their holder, with a door and an interval: the standing-order flag is accepted for 30 days while it moves into the platform; the crypto block is funded, to land within 60 days; the advice check stays, and every miss is reported as a near miss. Nobody accepts on somebody else's behalf, and their boss sees each decision arrive.

Every broken row and every near miss goes to its holder the same day; the significant ones go into the firm's incident reporting, which is where the speech says they belong. If the model or its provider is down, the agent stops and the customer pays in the app, and operations can revoke every agent token in one action. No payment depends on the agent being there.

### The same policy, as data {#data}

Here is one row with the frame around it. The `capability`, `reach`, `mandate` and `barrier` fields are the ones our published policies use today; `identity`, `kept_by`, `holder` and `decision` are proposed here, to carry the FCA's four elements.

```json { "policy": "Agent Behaviour Policy", "version": "1.4", "identity": { "agent": "payments-assistant 3.2", "deployed_by": "the bank", "acts_for": { "customer": "one", "consent": "in the app", "days": 90, "revocable": true }, "model": { "provider": "recorded", "version": "recorded", "on_change": "re-run the test pack" }, "credential": "15-minute token, bound to this customer and this policy version" }, "accountability": { "owner": "product owner", "chain": ["product owner", "head of payments", "senior manager, retail payments", "the board"], "report": "every broken row and near miss to its holder the same day" }, "rows": [ { "capability": "change.standing_order", "reach": true, "mandate": "approval", "barrier": "setting: the approval flag is in the agent's own profile", "kept_by": "the agent's account", "holder": "head of payments", "decision": { "door": "accept", "days": 30, "while": "the flag moves to the payment platform" } } ] } ```

Every row has one holder. The head of payments holds six of them, the product owner two, and the heads of advice, support, lending and operations one each. Each holder has a chain to the board through the senior manager whose responsibilities cover retail banking. The three gaps each get a decision from their holder, with a door and an interval: the standing-order flag is fixed within 14 days, by moving it into the payment platform; the crypto block is funded, to land within 60 days; the advice check is accepted for 90 days, and every miss is reported as a near miss. Nobody accepts on somebody else's behalf, and their boss sees each decision arrive.

## At play: one day at the gate {#day}

The vault replays one invented day, 40 events from 07:02 to 18:55, through the gate. The gate is the line of systems that keep the rows. An action on a row kept by one of them meets the gate, and the system decides. An action on a gap row goes through the gap below it, where only the prompt, a setting, a check that can miss, or nothing stands in the way, and the model decides.

[figure pa-gate-anim.webp] The gate, animated, from 10:02 to 12:10: a new payee approved by the customer; a hidden instruction in a bill, declined by the model; advice caught by the output check; a vulnerability routed to a person; an alert closed with a second person's approval; a full credit search that nothing stopped; an email the model declined to send. Receipts chain along the bottom. | screenshot

At 15:30 the payments assistant changes a standing order. The approval flag was off that afternoon, so the action goes through the gap, and the row is broken. The receipt records it, and the head of payments hears the same day.

[figure pa-gate-setting.webp] 15:30: the standing-order change goes through the gap, because the approval rule is a setting the agent's own account can change, and it was off. | screenshot

Sorted by what kept each row, the day is plain. The 26 actions on rows kept by a boundary produced no near miss and no breach. The 12 actions on gap rows produced six near misses and three breaches. A near miss is the same row as a breach, on a day the model declined, which is why reporting them matters: they show the next breach before it happens.

[figure pa-split.webp] The day split by what kept each row: 26 actions on boundary rows, no incidents; 12 on gap rows, six near misses and three breaches. | comparison

The rest of the speech is there too. At 14:10 one model provider is down for half an hour, and the two agents on it stop: the customer pays in the app, and fraud signals go to the analysts. At 17:00 the other provider changes version, the test pack runs, two rows that only the model kept fail, and the release stops. And each agent's blast radius shows what it may reach, what it can, and what it can through a secret it can read: the fraud triage agent can reach the core ledger through an old service account.

[figure pa-blast-fraud.webp] The fraud triage agent's blast radius in the vault: its mandate inside, the gaps around it, and the core ledger reachable through a service account secret. | screenshot

8 unchanged paragraphs, under Adopt it, or write your own as a graph {#graphs}, What this does not claim {#limits}

• **The bank and its agentagents are invented.** The rows, limits, holdersholders, the day and numbersevery number are illustrative.

3 unchanged paragraphs, under Where this comes from {#sources}

Jessica Rusu, [Building the future of finance in the age of AI](https://www.fca.org.uk/news/speeches/building-future-finance-age-ai), FCA, 19 October 2026, drafted version, read that day; the quotations are from it. The ABP: [abp.sgit.ai](https://abp.sgit.ai/), version 0.12.1, read 19 October 2026, including the barrier model and the quoted test. The worked example: [the Pellbridge agents vault](https://newsroom.sgit.ai/demos/vaults/pellbridge-agents/index.html) and [its tour](../../inside-the-pellbridge-agents.md). Our earlier work: [what can your agent reach](../../what-can-your-agent-reach.md), [governs, enforces, attests](../../governs-enforces-attests.md), [policy as code needs a policy first](../../policy-as-code-needs-a-policy-first.md), [a policy beside the prompt](../../a-policy-beside-the-prompt.md), [the policy draws the liability line](../../the-policy-draws-the-liability-line.md), [every risk is already accepted](../../every-risk-is-already-accepted.md), [ten questions, one graph](../../ten-questions-one-graph.md) and [the graph companies](../../the-graph-companies.md). Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.

[← v1.1.0](v1.1.0.md) · [all versions](../a-trusted-framework-for-agentic-finance.md)


---

*[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/a-trusted-framework-for-agentic-finance/v1.2.0.html)*
