AI Agents in Financial Compliance: Automate the Work, Keep the Accountability

Compliance operations are unusually well suited to automation and unusually unforgiving of it. The work is high-volume, rule-bound and evidence-heavy, which is exactly what machines handle well. It is also work where being wrong is not a productivity problem but a regulatory one, and where the answer to “why was this alert closed?” has to survive examination months later.

The distinction that matters is not whether to use AI agents in compliance. It is which decisions an agent may take on its own authority, and what remains attached to a named person.

Adoption is already ahead of the governance conversation

The Bank of England and FCA: Artificial intelligence in UK financial services 2024 survey found that 75% of responding firms were already using AI, with a further 10% planning to within three years — up from 58% and 14% in 2022. Two findings from that survey deserve more attention than they usually get.

The first is that 55% of reported use cases involve some degree of autonomous decision-making, while only 2% are described as fully autonomous. Most real deployments therefore sit in the large middle ground where a machine decides something and a human is nominally in the loop. That middle ground is where accountability is most often assumed rather than designed.

The second is that around a third of use cases are third-party implementations, roughly double the 2022 proportion. Firms are increasingly accountable for behaviour they did not build and cannot fully inspect. The Bank of England: Financial Stability in Focus — artificial intelligence in the financial system examines the systemic dimension of that concentration, including the possibility of correlated behaviour when many firms rely on a small number of underlying models.

Bounded authority is the design decision

An agent in compliance should be defined by what it may do, not by what it can do. In practice that means separating three tiers and holding the boundaries in the architecture rather than the prompt.

• Retrieve: gather transactions, customer records, screening hits, prior cases and policy text relevant to an alert, and present them together. Consequence of error is wasted analyst time.
• Draft: propose a classification, assemble a rationale and prepare a case narrative citing the evidence used. Consequence of error is a misleading recommendation that a reviewer may accept.
• Dispose: close, escalate, file or notify. Consequence of error is regulatory.

A defensible first release places retrieval and drafting inside the agent and keeps disposal outside it. The economics still work: in most alert-handling operations the majority of effort is assembling context, not making the final judgement. Automating assembly while preserving judgement captures most of the benefit and almost none of the accountability risk.

Where auto-disposal is genuinely warranted — typically high-volume, low-risk categories with a stable historical base rate — it should be introduced per category, with a documented rationale, a sampling regime and an explicit reversal path. “The model is accurate enough overall” is not a category-level argument.

Model change is the control most often missing

A compliance process built on a fixed rule set changes when someone changes the rule, and that change is visible, dated and attributable. A process built on a model changes when the model changes — which may be a retraining cycle, a provider update, a prompt revision or a shift in the underlying data distribution. Firms routinely have mature change control for the first and almost none for the second.

The practical requirement is a regression set: a fixed, versioned collection of cases with known correct dispositions, including the awkward ones — edge categories, historical false positives, cases that were escalated and later confirmed, and cases where the correct answer was to do nothing. Every material change to the model, prompts, retrieval logic or data sources is re-run against it before release, and the results are recorded.

Drift monitoring belongs alongside it. Alert volumes, category distributions, override rates and escalation rates should be tracked over time, because a model degrading gradually rarely announces itself. A sudden fall in escalations is as much a warning as a sudden rise.

Evidence has to be reconstructable, not merely logged

A compliance decision must be explicable long after the fact, often to someone hostile to the conclusion. That requires more than an audit log of actions. It requires the ability to reconstruct the decision: which records were retrieved and which were not, which policy version applied at the time, what the model was shown, what it proposed, what the reviewer saw on screen, and what they changed.

Two failure modes are common. In the first, the system logs the outcome but not the retrieved context, so a later reviewer cannot tell whether a relevant record was missed or simply absent. In the second, the model is updated and prior decisions become unreproducible, because the version that made them no longer exists. Both are avoidable at design time and expensive to retrofit.

Retention deserves the same discipline. Reconstruction requires keeping enough; data minimisation requires keeping no more than necessary. The Information Commissioner’s Office: guidance on AI and data protection is the reference point for holding both requirements at once where personal data is involved.

Make the review real

Human oversight fails quietly. A reviewer approving eighty machine-drafted dispositions an hour is not exercising judgement, whatever the process document says. Oversight is real only when the reviewer has the authority to disagree, the information needed to disagree, and the time the disagreement takes.

Design for that directly. Show the reviewer the evidence rather than the conclusion. Surface the cases where the model was least confident rather than distributing attention evenly. Track override rates as a health metric — a rate near zero usually means the review has become ceremonial, not that the model is excellent. Give reviewers a route to flag a systematic problem rather than only correcting one case at a time.

The Bank of England: FS2/23 Artificial Intelligence and Machine Learning feedback statement is useful here, particularly on how existing regulatory frameworks already reach AI-driven processes without requiring a separate AI rulebook. Accountability under senior-management regimes does not move because a model is involved.

Third-party risk is now most of the risk

If a third of use cases are vendor-supplied, vendor management is a first-order control rather than a procurement formality. The practical questions are unglamorous: what changes when the provider updates the underlying model, how much notice you receive, whether you can reproduce a decision made under the previous version, what your exit position looks like, and whether your monitoring would detect a degradation the provider had not announced.

The Financial Conduct Authority: AI in financial services sets out a technology-neutral, outcomes-focused supervisory position. The practical implication is that a firm cannot transfer responsibility for a customer outcome to a supplier, however sophisticated the supplier.

For firms operating in the EU, the European Commission: AI Act adds obligations that vary by role — provider or deployer — and by classification. Determine your role in each deployment early, because it drives most of what follows.

What this cannot do

An agent cannot repair an incoherent control environment. If the policy is ambiguous, if two systems hold conflicting customer records, or if analysts have been quietly applying an undocumented rule for years, automation will encode the confusion and apply it faster. Nor can an agent supply the judgement that regulation actually asks for — whether a pattern is suspicious in context is not a classification problem with a stable ground truth.

Stop when the evidence needed for reconstruction is not being captured, when no one can name the accountable person for an automated disposition, when the review has become a formality, or when the underlying policy would not survive being written down clearly. Fixing those first makes the automation both safer and more valuable. Deploying over them converts a manual problem into an auditable one.

Further reading: Bank of England and FCA: AI in UK financial services 2024; Bank of England: FS2/23 AI and Machine Learning; Financial Conduct Authority: AI in financial services; NIST: AI Risk Management Framework.

See how embedded leadership builds an AI operating model in a regulated function.