AI Agent Audit Trail for UK Banks: The SYSC 9 Test

A UK bank that lets AI agents prepare reconciliation breaks, triage complaints or assemble remediation files has added a new kind of worker to regulated processes. The FCA's record-keeping rules do not care whether the worker is a person or a model. They ask whether the bank kept records of what was done and whether those records let a supervisor see that the bank met its obligations. For a bank's MiFID business they go further, and ask whether anyone could have altered the records afterwards.

The scale of the question is real. In the Bank of England and FCA survey of AI in UK financial services, published on 21 November 2024, 75% of responding firms said they already use AI, and 55% of all reported AI use cases carry some degree of automated decision-making. An agent that chains several actions on its own initiative makes the record of that work harder to get right, not easier.

This guide is written for the Chief Data or AI Officer and the head of operational risk who have been asked to sign off agent work inside a bank. It covers one thing: what an AI agent audit trail has to prove under the FCA's record-keeping rules, how long it has to last, and what second line and internal audit should test before agents go near regulated work. It deliberately cedes the wider ground. The cross-sector regulator map, PRA SS1/23 model risk and senior manager ownership sit in our AI risk management framework guide. DORA's ICT third-party test sits in our voice AI DORA guide. Where AI pays across a bank, including Consumer Duty evidence, sits in our AI for UK banking guide.

One framing note. Banking is an inferred fit for Cognibl, from DILR.AI, rather than a vertical we hold deck evidence for: our own industry research names an agent desk with a full audit log as a candidate use in banks, not a proven one. We say so plainly, and the tests in this guide apply whichever product a bank chooses.

This guide is shipped by the team behind Cognibl, the work-management platform where a task reaches done only once proof is attached. Or see DATS, our consulting system for placing AI inside regulated operations.

What is an AI agent audit trail in a UK bank?

An AI agent audit trail in a UK bank is the set of records that shows, for each piece of work an agent touched, what it was asked to do, what it called, what it produced, who accepted the result and on what evidence. It differs from an application log because the bank must be able to rely on it as a regulatory record, not just a debugging aid for engineers.

That distinction matters because a trace built for debugging serves a different reader. A trace written to help an engineer find a failed tool call is useful, but it was not designed to answer a supervisor's question six months later about why a particular customer's case was closed. The bank needs both: the engineering trace and a record of the work itself, tied to a named owner and an acceptance decision.

There is also a question of authorship. A log that the agent writes about itself is a claim. A log that something outside the agent writes, as each call passes through it, is closer to evidence. That is why the gateway pattern described in our AI agent work management guide matters for a bank: the record is produced by the layer the agent has to pass through, not by the agent's own account of what it did.

The Bank of England and FCA figures explain why this cannot wait for agents to become common. Very little current AI use in UK finance is fully autonomous, but more than half of reported use cases already involve some automated decision-making.

Only 2% of reported use cases are fully autonomous, and 16% are rated high materiality by the firms that run them. Agents shift that picture, because an agent chains several calls and choices together before a person sees the output. The same survey found that 84% of firms have an accountable person for their AI framework, which is the right starting point, but an accountable person can only sign off what the records let them see.

What does SYSC 9 require a bank to record?

SYSC 9 requires a bank, which the FCA glossary treats as a common platform firm, to keep records of all services, activities and transactions it undertakes, sufficient for the FCA to supervise it and to check that it met its obligations to clients. Work an AI agent performs inside a regulated process is part of the bank's activities, so the record duty does not shrink because a model did it.

The rule itself is short. As the FCA Handbook puts it in SYSC 9.1.1AR, "A common platform firm must arrange for records to be kept of all services, activities and transactions undertaken by it." The second paragraph of the same rule says those records must be sufficient to let the FCA fulfil its supervisory tasks and perform enforcement actions, and in particular to ascertain that the firm has complied with all obligations, including those to clients or potential clients. The definition that brings banks into scope is in the FCA glossary entry for a common platform firm, which lists a bank and a building society alongside MIFIDPRU and designated investment firms. The rule's full text also names MiFID, MiFIR and the Market Abuse Regulation among the regimes the records must serve.

Three practical consequences follow for agent work:

• The duty binds the bank, not the vendor. No agent platform can hold the record duty for a bank. A tool can make the record easier to keep; the obligation stays with the firm, and which senior manager owns it is covered in our regulator map for AI risk.
• The test is sufficiency, not volume. A trace with ten thousand tool calls and no link to the customer case it served is not sufficient. A shorter record that ties each step to the case and the acceptance decision may be.
• Some records are named outright. SYSC 9.1.1BR lists records a common platform firm must keep at least, and among them are each compliance report to the management body, each risk management report to senior management and each internal audit report to senior management. When second line or internal audit reports on agent controls, that report becomes a record in its own right.

Banks are also regulated by the PRA. This guide stays with the FCA Handbook text, and a bank's compliance function should confirm whether any PRA requirements apply to the same records rather than assume the FCA text is the whole picture. The wider regulatory picture for banks is in our banking sector overview.

Before deciding where agents go, a bank should know which records each candidate process already produces and which ones an agent would have to produce instead. Our AI placement diagnostic produces a ranked roadmap of where AI belongs and where it does not, and that record question belongs inside it.

Is an agent's own log good enough as a regulatory record?

An agent's own log is rarely good enough on its own. For a bank's MiFID business, FCA rules ask whether a supervisor can reconstitute each stage of processing and whether the record could have been altered, and a log the agent writes about itself, stored where the same system can rewrite it, fails both. The stronger pattern is a record written outside the agent, append-only, with corrections visible.

For a bank's MiFID business, the FCA spells the conditions out. Under SYSC 9.1.2-AR, records must be kept so that the FCA can access them readily and reconstitute each key stage of the processing of each transaction; so that any corrections or amendments, and the contents of the records before them, can be easily ascertained; and so that it is not possible for the records otherwise to be manipulated or altered. The rule adds that the arrangements must comply irrespective of the technology used, which is the clause that brings an agent platform squarely into scope.

Those conditions are written for MiFID business. For a bank's other business, the FCA's guidance in SYSC 9.1.5G is less prescriptive: a firm should have appropriate systems and controls for the adequacy of, access to and security of its records. A bank may choose to hold its non-MiFID agent records to the MiFID standard because one standard is simpler to evidence than two, but that is a design choice for the bank, not a rule this guide can assert on the FCA's behalf. It is the kind of choice our approach to placing AI settles before any agent is built.

Read against an agent platform, four of the five MiFID conditions translate into questions a bank can put to any vendor. The fifth, which allows IT systems to be used where data volumes make analysis hard, is an enabling condition rather than a test:

The fourth row is the one teams miss. An agent built on one framework this quarter may move to another next year, as our LangGraph work management guide discusses. A record that lives inside the framework's own run history goes with it.

Ownership of those records is an operating model question before it is a tooling one, which is why our AI operating model consulting covers governance, RACI and lifecycle, audit-ready by design.

How long must a bank keep records of agent work?

How long a bank keeps records of agent work depends on the activity the agent supported, not on the fact that an agent did it. FCA rules set at least five years for records of a bank's MiFID business and three years for most complaint records, while other records follow guidance that they be kept for as long as is relevant to their purpose.

The periods come from different parts of the Handbook:

• MiFID business: at least five years. SYSC 9.1.2R requires a common platform firm to retain all records kept under the chapter in relation to its MiFID business for at least five years.
• Complaints: three years for most. The complaints record rule in DISP 1.9.1R requires a firm, a payment service provider or an e-money issuer to record each complaint received and the measures taken for its resolution, and to keep that record for three years for most complaints, or five years for complaints about UCITS collective portfolio management, from the date the complaint was received.
• Everything else: as long as relevant. SYSC 9.1.5G states the general principle that records should be retained for as long as is relevant for the purposes for which they are made.

Complaints deserve particular care because complaints triage is one of the agent uses our banking research names. The Financial Ombudsman Service received 305,726 new complaints in 2024/25, its highest level for six years and 54% more than the year before, with 122,894 of them about banking and payments. Those are complaints referred to the ombudsman, not the larger number banks receive directly, but each referral starts with a bank's own record of how it handled the case. If an agent drafted the triage note or assembled the evidence, the agent's part of the work belongs in that record. Our guide to complaints handling under DISP covers the handling rules themselves.

For banks with EU entities, a further clock is coming. Under the EU AI Act, a deployer of a high-risk AI system must keep the logs it automatically generates, to the extent they are under its control, for at least six months unless other law says otherwise, and a deployer that is a financial institution subject to EU financial services governance rules keeps those logs as part of the documentation those rules already require (Article 26). Creditworthiness assessment of natural persons is listed as high-risk in Annex III, and the Act's tracker shows these obligations applying from 2 December 2027 for Annex III systems. Our EU AI Act omnibus guide explains the delay. Where a Handbook period applies, such as five years for MiFID business or three years for most complaints, it is longer than that six-month floor.

What should second line and internal audit test in an agent trail?

Second line and internal audit should test an agent trail by sampling real cases and trying to rebuild them from the record alone: who asked for the work, what the agent called, what it produced, who accepted it and on what evidence. If the reviewer has to ask an engineer to fill gaps, the record is not yet sufficient for a supervisor either.

The five tests below are our framework, not a regulatory checklist. Each row names the Handbook provision it draws on or supports; the SYSC 9.1.2-AR conditions bind MiFID business only, so for other business they are a design standard the bank chooses rather than a rule. Each test is designed to be run on a sample rather than on the whole population.

The reproduction test sounds dated but is useful. SYSC 9.1.4G says records required under the Handbook should be capable of being reproduced in the English language on paper. A record stored as nested model output that only a developer can read passes a technical retention test and fails this one. If your current agent records would not pass it, talk to our team before the pilot widens. The refusal test matters for a different reason: an agent that was never given a tool cannot misuse it, and a record that proves the refusal happened is stronger evidence than a policy saying it should.

When internal audit reports on these tests to senior management, SYSC 9.1.1BR makes that report a record the bank must keep. The audit of the agent trail therefore becomes part of the trail. Sampling of this kind is easier to sustain when the delivery team is embedded with the business, which is the model our AI execution office follows, with production placements the client owns.

Where does a proof gate fit beside the audit trail?

A proof gate fits beside the audit trail as the control that decides when agent work counts as finished. The trail records every call; the gate refuses a done status until evidence is attached. Cognibl, from DILR.AI, applies this as a database rule: a task reaches done only once a proof version is attached, and the same rule applies to a person and an agent.

The two do different jobs. An audit trail answers "what happened". A proof gate answers "why did anyone accept it". A bank needs both, and the second is what turns a pile of tool calls into a record a reviewer can rely on.

In Cognibl, the proof version is a CSV describing the run, referencing the artefact, screenshots and hashes, and the database refuses the status move without one. The definition of done, the evidence behind it and every tool call are attached to the work. Agents reach their tools through a gateway that is deny by default, so a toolset that has not been enabled is refused rather than quietly missing; every call is traced, every write is attributed by key name, and records are append-only and hash-chained. As the Cognibl connections page puts it, every call through the gateway, whether allowed, refused or failed, is written to the project's trace, and the trace is written by the gateway, not reported by the agent.

Mapped to the five tests above, those properties give a reviewer something to sample: the trace for reconstruction and refusal, key-name attribution for attribution, and the attached proof for the acceptance decision. Cognibl also runs two AI flows, proof validation and project status, that summarise and flag but never decide. One limit matters for reconstruction: the connections page says the trace is redacted at the moment of capture, so a bank should confirm which fields its reviewers will actually see before relying on the trace alone.

The limits need stating as plainly as the features. Cognibl's public site currently describes coding agents on Claude Code and Codex, each opening a pull request that only a person can merge, and its tools for agents are read-only by default, with write access to Google Workspace available only when an admin enables it. The connections page also says that where an admin enables Google Workspace writes, they go straight to the tool with nothing held for approval, so a bank that wants a named approver must design that step into its own workflow rather than expect the platform to hold it. Nothing here means Cognibl satisfies SYSC 9 for a bank: the duty and the judgement stay with the firm. The same evidence discipline applies in other regulated desks, as our law firm supervision record guide shows for solicitors, and our MCP skills library guide covers how the instructions an agent followed stay versioned.

How should a bank pilot an agent trail without creating a records gap?

A bank should pilot an agent trail by naming the record before it names the agent, scoping the agent to read-only or prepare-only work, gating every completion on attached proof, and sampling closed cases from the first week. That order keeps the regulatory record ahead of the automation rather than reconstructed after it.

Name the record. For the process the agent will join, write down which Handbook provision governs its records and which retention period applies: MiFID business, complaints or other. Writing it down first means the pilot's records are designed for the rule rather than retrofitted to it.

Scope the agent. Start with work where the agent prepares and a person decides: drafting a reconciliation break summary, assembling the documents for a remediation file, proposing a complaint category. Read-only access is a feature at this stage, not a limitation. KYC work has its own cost and document questions, covered in our corporate KYC review cost guide and in our separate guide to KYC document extraction.

Gate on proof. Define what evidence a finished task must carry before anyone builds the agent. If the definition of done cannot be written down, the task is not ready for an agent.

Sample and rebuild. Run the five tests from the first week, on a small sample, and record the results. A pilot that produces a clean sampling record is easier to scale than one that produces only throughput numbers. Engineering agents raise the same question in a different setting: our AI developer productivity solution covers the review queue, and the AI coding agent review queue guide sets out the equivalent control.

What is the best way to evidence AI agent work in a bank in 2026?

The best way to evidence AI agent work in a bank in 2026 is whichever approach lets second line rebuild a sampled case from the record alone, with attribution, refusals and acceptance visible, and that survives a change of agent or framework. For some banks that is a new work-management layer; for others it is an existing case system extended carefully.

We would judge any option against five criteria:

1. Gateway-written records. The record of each call is produced outside the agent, not reported by it.
2. Append-only history. Corrections add a version; nothing overwrites.
3. Proof before done. A task cannot be closed without attached evidence, for agents and people alike.
4. Framework independence. The record outlives the agent framework, whether that is LangGraph, CrewAI, AutoGen or the OpenAI Agents SDK.
5. Readable reproduction. Any record can be produced as a plain English document for a reviewer.

Against those criteria, a bank should test general trackers such as Jira, Linear, Asana or Monday.com, and the run histories of agent frameworks, in the same way: sample a case and see whether the record shows what the agent did and why the result was accepted, not only that a ticket moved. Cognibl's proof gate and gateway-written trace are designed for the first three criteria, with the limits set out above.

There are cases where a different answer wins. A bank that already runs reconciliation and complaints in a mature case-management system with immutable logging may get further by extending that system to capture agent steps than by adding a new layer, particularly where its records are already mapped to the Handbook. A bank whose agent use is confined to engineering may find its existing pull-request review already gives it the acceptance record it needs. The point is the evidence, not the tool, and our voice AI auditability guide makes the same argument for call recordings.

Frequently asked questions

Does the EU AI Act logging rule apply to UK banks?

The EU AI Act logging rule matters to a UK bank only where the bank is a provider or deployer of a high-risk AI system within the Act's scope, which is a question for each group's legal counsel. For Annex III systems such as creditworthiness assessment, the tracker shows the obligation applying from 2 December 2027, with deployers keeping logs for at least six months.

Where the Act does not apply, the FCA Handbook rules described above are the record duties this guide covers. Article 12 of the Act separately requires high-risk systems to be designed so that they can record events automatically, which falls on the provider rather than the bank (Article 12).

Does Cognibl write to a bank's core systems today?

Cognibl's public site does not describe writes to a bank's core systems. It describes coding agents that open pull requests a person merges, and tools for agents that are read-only by default, with write access offered only for Google Workspace when an admin enables it. Any bank use would start with agents preparing work that people review and accept.

That boundary is useful in a regulated pilot, provided the bank keeps it. An agent limited to reading, drafting and attaching evidence produces records while people keep the decisions. If an admin enables Google Workspace writes, the connections page warns that they go straight through with nothing held for approval, so that switch belongs in the bank's change control.

Want to see this in practice? Visit Cognibl, explore the DATS methodology, book an AI placement diagnostic, or talk to the team.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.