AI agents in financial services

Why this toolkit exists.

If you are reading this, you have already decided AI agents matter for your business. You probably do not need another deck telling you the technology is real, the productivity gains are large, or the competitive risk of inaction is rising.

What you need is help getting an agent into production inside a regulated financial services firm, without the project stalling in a Risk committee, dying in Procurement, or being quietly defunded after the third InfoSec review.

This toolkit is built for that. It assumes you have already done the easy part of building conviction. It is here to help with the hard part: navigating the seven internal stakeholders, twenty or so common objections, and three or four governance frameworks that sit between your conviction and a live deployment.

It is opinionated where we think a clear point of view is more useful than a balanced summary, and neutral where you need raw reference material. We have flagged which is which.

The seven stakeholders who decide whether your AI agent ships.

Most AI agent projects in regulated firms do not fail on technology. They fail because the project lead underestimates how many internal sign offs are required, and pitches each stakeholder with the wrong message.

Here are the seven you will need to win over, what they care about, and the one question to answer for them upfront.

Cares about enterprise risk exposure, model risk and third party risk. Will block on any deployment that creates a new material risk without a corresponding control. Answer upfront: what is the worst plausible outcome, how likely is it, and what controls reduce it to acceptable levels?

Cares about regulatory obligations (FCA, PRA, ICO, sector specific), the audit trail and evidenceability. Will block on anything that cannot be evidenced to a regulator. Answer upfront: what record will exist of every agent decision, and how is it retained?

Cares about data residency, access controls, supplier security posture and attack surface. Will block on data flowing to environments they have not approved. Answer upfront: where does customer and firm data go, how is it protected in transit and at rest, and what is your supplier's last SOC 2, ISO 27001 or penetration test result?

Cares about contractual liability, IP, data protection law and customer contract terms. Will block on terms that put the firm on the hook for the supplier's failures. Answer upfront: what does the contract say about liability, indemnities, IP ownership of outputs, and exit?

Cares about lawful basis, data minimisation, the ROPA and automated decision making under UK GDPR. Will block on undocumented processing or unlawful basis. Answer upfront: what personal data does the agent process, on what lawful basis, and is automated decision making in scope of Article 22?

Cares about total cost, supplier viability, contract terms and exit. Will block on anything that bypasses the procurement process or creates concentration risk. Answer upfront: what is the three year total cost of ownership, what is the exit plan, and is the supplier financially stable?

Cares about outcomes, return on investment, time to value and accountability. Will block on nothing, but if they are not engaged, nothing else matters. Answer upfront: what business metric will move, by how much, by when, and who is accountable if it does not?

Most teams pitch AI agents to all seven stakeholders the same way. That is the single biggest avoidable mistake we see. Build seven versions of your one pager, the same project seen through a different lens for each audience, before your first formal review.

FORTAY CONNECT

The objections handbook.

Ten objections you will hear inside any UK financial services firm, with the response we see leading teams give.

Distinguish generative agents, which can hallucinate, from retrieval and workflow agents, which retrieve from approved sources or follow deterministic logic. Most enterprise agent use cases are the latter. For genuinely generative components, controls include responses grounded in retrieval, confidence thresholds, a human in the loop on low confidence outputs, and an audit after the fact.

Three layers: contractual (no training on your data, written into the master services agreement), technical (private endpoints, no data egress to the foundation model provider, customer managed keys where available), and operational (data loss prevention scanning of inputs and outputs). Ask the supplier for their data flow diagram in writing.

The same way you explain any consequential automated process: documented purpose, documented controls, evidence of testing, evidence of monitoring, and evidence of human oversight where required. The FCA has been clear that it expects existing frameworks, SM&CR, Consumer Duty and operational resilience, to be applied to AI rather than replaced.

The Senior Manager whose business area owns the agent's function, in the same way they would be accountable for a human team doing the same job. Document it in the Statement of Responsibilities. The agent is a tool; the accountability is the senior manager's.

Apply the four outcomes, products and services, price and value, consumer understanding and consumer support, to the agent's interactions. If a human agent doing the same task would need to deliver these outcomes, the AI agent does too. Test for it explicitly.

Bias testing before deployment, ongoing monitoring of outcomes by protected characteristic, and clear escalation paths for affected customers. The Equality Act 2010 applies to automated decisions the same way it applies to human ones.

Ongoing monitoring against a baseline, scheduled reassessment, and change control on any model updates from the supplier. Treat it like any other production system that can degrade, because it is.

Three reasons most regulated firms land on enterprise platforms instead: data handling commitments (training, retention, residency), integration with internal systems and identity, and audit and admin controls. The model itself is rarely the differentiator.

Standard exit planning, but be specific. Get the supplier's commitment in writing on data return format, model artefact handover where applicable, and transition support. Apply the same scrutiny you would to any operationally critical supplier under SS2/21.

Define success metrics before deployment, instrument for them from day one, and review monthly. Common ones: containment rate for service agents, accuracy against a human baseline, customer outcome metrics, and escalation rate. If you cannot define what good looks like, you are not ready to deploy.

The operating model question.

This is where most AI agent programmes get stuck. The technology is solvable. The operating model is harder, because it requires the firm to answer four questions it has usually never had to answer at the same time.

Inside a business line, embedded in CX for example; inside a horizontal function, such as a centre of excellence; or as shared infrastructure, such as a platform team. Each model has trade offs. Embedded models move fastest but create fragmentation. Centralised models govern best but bottleneck delivery. Platform models scale but require maturity to build.

Product? Operations? Engineering? The answer determines the rhythm. Product gives you roadmap discipline, operations gives you outcome focus, engineering gives you technical rigour. Most firms end up with shared ownership; the firms that succeed have one accountable owner.

Existing model risk committees? A new AI governance body? A subcommittee of an existing risk forum? Entirely new bodies create work but signal seriousness. Reusing existing bodies is faster but risks AI being underweighted in their agenda.

For low risk use cases, periodic sampling. For higher risk, continuous monitoring with a human in the loop. The decision is not technical; it is a risk appetite decision, and it should be made by Risk and Compliance, not the project team.

Pick a model, document it, communicate it, and revisit it every six months. The worst outcome is a default operating model that nobody chose, usually the team that built the first agent owning everything by accident. That collapses under any kind of scale.

FORTAY CONNECT

A starter business case structure.

A business case for an AI agent in a regulated firm needs seven sections. We are not giving you the numbers; those are yours. We are giving you the scaffolding so you do not miss anything that gets queried in committee.

Quantify the current state in money or time. “Our team handles 40,000 enquiries a month, average handling time 7 minutes, fully loaded cost of £X per minute.” Vague problems get vague approvals.

What the agent does, what it does not do, and what is in scope for phase one. Be ruthless about phase one scope: most failed deployments tried to do too much.

Two or three measurable metrics, with a baseline and a target. Containment rate from X per cent to Y per cent. Average handling time from X to Y. Customer satisfaction held flat or improved. Avoid vanity metrics.

Three year total cost of ownership, broken into platform, integration, change management and ongoing operations. Most business cases undercost the last two by half.

A short risk register: the top five risks, with likelihood, impact and mitigation. Include the risks of not deploying.

How the deployment is governed, who signs off, who reviews ongoing performance, and how exceptions are handled.

What you are asking for, from whom, by when. If the committee does not know what decision they are being asked to make, they will not make one.

The regulatory reference shelf.

A starting point, not a substitute for your Compliance team. Each item below should be pulled, current version, by someone who can interpret it for your firm. Dates are the publication dates of the most relevant version we are aware of at time of writing.

FCA Discussion Paper DP5/22: Artificial Intelligence and Machine Learning

The FCA's foundational paper on AI in financial services, joint with the PRA and the Bank of England. Sets the direction of travel: existing frameworks, SM&CR, operational resilience and model risk, apply.

FCA and PRA Feedback Statement FS2/23

The follow up to DP5/22, summarising responses and the regulators' position. Worth reading in full.

FCA Consumer Duty (PS22/9) and ongoing guidance

Applies to all automated interactions with retail customers. The four outcomes, products and services, price and value, understanding and support, apply to AI agents the same as to human ones.

SM&CR: the Senior Managers and Certification Regime

The existing accountability framework. AI agents do not change who is accountable; they change what the accountable person is accountable for. Statements of Responsibilities should reflect material AI deployments.

SS2/21: outsourcing and third party risk management (PRA)

Relevant where the AI agent is materially provided by a third party. Most enterprise AI deployments will trigger this.

UK GDPR and the Data Protection Act 2018

Lawful basis, data minimisation, transparency and the record of processing activities. Article 22 on automated decision making is particularly relevant where the agent's output materially affects a customer.

ICO guidance on AI and data protection

Practical guidance on applying UK GDPR to AI systems, including expectations on explainability and fairness.

The EU AI Act

Directly relevant for firms operating in the EU, and indirectly relevant for UK firms whose suppliers operate there. A risk tiered framework with phased implementation through 2026 and 2027. Confirm the current implementation status with Legal.

DORA: the Digital Operational Resilience Act

EU regulation on operational resilience for financial services, including information and communications technology third party risk. Applies extraterritorially in some cases; confirm scope with Legal.

What good looks like: a maturity model.

Use this to work out where your firm is, and to set realistic expectations with your sponsors. Most firms are at stage two, occasionally stage three.

Conversations happening in pockets. Maybe a few workshops and a handful of proofs of concept in safe environments. No coordinated programme, no executive owner, no governance framework. Investment is opportunistic. The telltale signs: the term “AI strategy” being used aspirationally, no named accountable senior leader, and nothing in production.

One or two use cases moving toward production. A nominated owner, often a transformation lead or an innovation function. Risk and Compliance engaged but not yet comfortable. The first objections being worked through. The telltale signs: a named pilot, a steering group, and frequent relitigation of the same Risk questions.

The first use case in production, or close to it. Operating model decisions being made, often painfully. A governance framework drafted. A second wave of use cases beginning to queue behind the first. The telltale signs: an agent live with real customers or colleagues, a documented governance framework, and clear ownership.

Multiple use cases in production. Governance functioning. A platform, or a set of patterns, enabling reuse. Investment moving from exploration to scaling. The telltale signs: shared infrastructure, repeated patterns, and a declining marginal cost for each new use case.

AI agents are part of how the firm operates. Build or buy decisions are made on each use case rather than each programme. The conversation has shifted from “should we” to “where next”. The telltale signs: AI capability is part of operating reviews, new business cases default to considering an AI component, and the firm has talent depth rather than a single team.

Most of the value compounds at stage four, but most firms get stuck at stage two. The blocker is rarely technology. It is the operating model and governance work that bridges stage two to stage three. That is where this toolkit is designed to help.

FORTAY CONNECT

Where to go from here.

If this toolkit was useful, the most valuable next step is to stop reading about AI agents and start working with one.

The fastest way to find out what AI agents can actually do for your firm is to see one running on your problem.