Agentic transformation in Financial Services

By mapping accountability for each agent decision onto a named individual with matching authority, defining explicit human-in-the-loop points for consequential or irreversible decisions, and extending model risk governance to cover systems that compose models at runtime. Under SM&CR the accountability cannot rest with the system, so the operating model has to resolve it to people before deployment.

Yes, if your firm is in scope of the Duty. It attaches to outcomes, not to mechanisms, so it makes no distinction between a decision made by a person, a rules engine or an agent. The four outcomes still have to be delivered and evidenced, products and services, price and value, consumer understanding and consumer support, alongside the cross-cutting obligations to act in good faith, avoid foreseeable harm and support customers in pursuing their financial objectives. The design consequences are concrete: the outcome measure has to be emitted by the system as it runs rather than reconstructed later, and vulnerability handling has to be an explicit route to a human, because a confidence score describes the model's certainty and not the customer's circumstances. Tenhaw has not delivered an agentic system into a customer-facing journey in an FCA-regulated firm.

The FCA has not published an AI rulebook and has said it does not intend to, so what it expects is what it already expects. A named senior manager accountable under SM&CR. Governance and controls proportionate to the risk. Evidence that the Consumer Duty outcomes are being delivered and monitored, including for customers with characteristics of vulnerability. And the ability to explain a decision to the customer who received it and to a supervisor afterwards. The practical test is whether you can answer who was accountable, what testing was done, what the system actually decided and where the record is, from artefacts the programme produced anyway rather than from an archaeology exercise months later.

SS1/23 took effect on 17 May 2024 for UK banks, building societies and PRA-designated investment firms with internal model permissions, and it uses a deliberately broad definition of a model: a quantitative method turning input into output for use in a decision. A language model inside a decision path meets that definition without needing a special case. An agentic workflow is usually several models plus prompts, retrieval corpora and tool permissions, all of which change behaviour, so the practical work is treating those as versioned artefacts with named owners, entering the system on the model inventory, agreeing its risk classification with the second line before you build, and designing so independent validation is possible: reproducible evaluation sets, recorded provenance, and change control that fires on a prompt change rather than only on a model upgrade. Insurers are outside the formal scope and raise it anyway, because the PRA treats the principles as good practice more widely.

Yes, where the supplier provides ICT services supporting a financial function of an entity in scope, and DORA has applied since 17 January 2025. That brings the AI vendor, and usually the model providers underneath it, into ICT third-party risk management: an entry on the register of information, contract terms covering audit and access rights, conditions on subcontracting, and a documented exit strategy, with a direct oversight regime for designated critical providers on top. UK-only firms are not in scope of DORA itself, and meet similar questions through the operational resilience regime and the critical third parties regime. The question that actually changes an architecture is exit: if the provider is unavailable, changes its terms, or a supervisor tells you to move, what breaks. Programmes built tightly around one provider's proprietary features have answered that by accident, and badly.

It does not name AI, and it binds it anyway, through governance and through data. The system of governance requires the four key functions to be effective, the ORSA has to reflect the firm's real risk profile, and data used for technical provisions must be accurate, complete and appropriate, with the actuarial function accountable for saying so. If an agent enriches submission data and that enrichment reaches pricing or reserving, someone has to be able to trace every field back to its source, which makes provenance an engineering requirement rather than a documentation exercise. Internal model firms add a model change policy and validation. And using a supplier for a critical or important operational function is outsourcing, with the notification and contractual duties that follow. Tenhaw holds no actuarial capability: our specialty insurance work is a proof of concept feeding business intelligence, not a rated pricing model.

Both. Our named financial services work is banking, at HSBC. Our current agentic engagement is with a London specialty insurance business, confidential at the client's request: a month-one audit, then a two-week proof of concept turning PDFs into business intelligence on Azure, covering ground the business had circled for roughly a year, with month three standing up a team to productionise it. Insurance differs from banking in ways that matter to the design. Underwriting, claims and reserving carry different data and different regulatory weight, Solvency II and the actuarial function govern where SS1/23 would in a bank, and delegated authority through brokers, MGAs and Lloyd's coverholders means a binding authority draws the boundary of a decision before any agent does. Ask on the call which of the banking work transfers to your regime and which does not.

With high-volume workflows where decisions are observable and cheaply reversible, and where the audit trail is naturally part of the output: control testing, internal knowledge retrieval, and case and call summarisation. Customer-facing decisioning should come later, once the governance evidence base exists.

Yes, at HSBC, as pilot and proof of concept rather than production. Tenhaw's founder led the proof of concept for an AI Voice Insights platform, applying natural language processing, sentiment analysis and entity recognition to enterprise voice data, projected to remove 1.5M+ hours of manual administration annually. That figure was a projection from a proof of concept, not a measured result from a production rollout. Separately, the operating-model work across HSBC's Global Payment Solutions division was designed, piloted and validated, with global rollout scheduled for 2026. Both are written up in full on the case studies page.

It requires a named senior manager to be accountable for the outcomes of the function, including those produced by agents. In practice this means the operating model must specify which decisions agents may take autonomously, which require human approval, and who holds accountability at each point, documented before deployment rather than reconstructed after an incident.

They can do the document and evidence layer, which is where the elapsed time sits, and they should not take the decision. What an agent handles well is reading incorporation documents, structure charts and identity evidence into structured fields with provenance recorded per field, resolving entities across registries and third-party sources, assembling the file, and saying what is missing. What it must not do is set the risk rating, clear a politically exposed person or close an alert, because customer due diligence under the Money Laundering Regulations 2017 is a decision the firm has to defend to its supervisor, and enhanced due diligence exists precisely for the cases where the machine-legible answer is least reliable. The design question is not accuracy, it is what the exception path costs: route by confidence and by consequence, score confidence from where each value came from rather than from the model's own certainty, and the accuracy target falls out of it. Tenhaw has built this pipeline shape on a live insurance engagement as a proof of concept, and has never taken one into production.

In alert triage and narrative assembly, which is the part everyone under-resources, and not in the disposition itself. An agent can pull the customer history, the prior alerts, the counterparty context and the relevant documents into one place, draft the investigation narrative with every claim linked to its source, and order the queue by consequence rather than by arrival time. That is analyst minutes per alert on a volume where minutes are the entire budget. What an agent must not do is close an alert, suppress one, or decide not to file, and it must never be allowed to tune the alert threshold: a system optimised to reduce alert volume has learned exactly the wrong objective and will be extremely good at it. For a bank, SS1/23 already reaches the monitoring models, so an agent in the disposition path joins the model inventory. Fraud disputes follow the same split: an agent assembles the evidence pack and drafts the communication, and a person declines the payment, because a false positive there is a customer locked out of their money, which is a Consumer Duty question before it is an accuracy question.

It can run intake, triage and the document work that spans the file, and it must not settle anything. Reading the notification and the evidence into structured fields, checking completeness against what the policy actually requires, routing by complexity and consequence, drafting the chronology and keeping the customer communication current are all document and coordination work. Deciding coverage, setting or moving a reserve, declining a claim and authorising a payment are not. Three things decide whether it works. Cycle time is made of waiting rather than of handling, so assisting each step leaves the end-to-end number almost unchanged and you have to map the waits first. Vulnerability has to be an explicit route to a person defined by circumstance, not a confidence threshold, because a confidence score describes the model's certainty and not the customer's situation. And reserving feeds technical provisions, so any field an agent extracted that reaches a reserve is now data the actuarial function is accountable for, which makes provenance an engineering output, not a documentation exercise. Tenhaw has not delivered an agentic system into claims handling.

Not the decision, and this is the workflow where the law is most direct about it. Section 80 of the Data (Use and Access) Act 2025 replaced Article 22 of the UK GDPR with Articles 22A to 22D, which turn on whether there is meaningful human involvement in a significant decision about a person, and a credit refusal is the textbook example of one. Consumer Duty adds price and value and consumer understanding on top, and a decision you cannot give the customer a reason for is not one you can defend. Where agents do earn their place is everything around the decision: assembling the application file, reading bank statements and accounts into structured data with provenance, drafting the credit paper and surfacing the inconsistencies a human would want to ask about. In commercial lending that file assembly is most of the elapsed time and almost none of the judgement. For a bank, an agent in that path also meets SS1/23, because a quantitative method turning input into output for use in a decision is a model under its definition whether or not anyone called it one.

Agents belong in investigation support and root cause, not in the outcome. An agent can assemble the full relationship history into a chronology, retrieve the terms in force on the relevant date, not the current version, draft the response for a person to own, and cluster complaints across the book so the same root cause is not rediscovered five times by five handlers. That clustering is the output most worth showing your second line early, because it is evidence of outcome monitoring, not a productivity claim. What an agent must not do is decide the outcome or send a final response unreviewed: a complaint is a customer disputing the firm's judgement, and having the machine decide it is marking your own homework at the moment it matters most. The FCA's complaints rules in DISP govern the handling and the Financial Ombudsman Service sits behind it, and the Duty expects the outcome, and not only the handling time, to be monitored and evidenced, which means the outcome measure has to be emitted by the system as it runs rather than reconstructed from logs a quarter later.

By turning the submission into structured, traceable data before an underwriter opens it, and by ordering the queue by appetite fit rather than by arrival. It is the one workflow on this page where our evidence is a build: on a live engagement in the London specialty insurance market we produced a working proof of concept in two weeks, PDFs in and business intelligence out on Azure, from a blank repository, over ground the business had circled for roughly a year, pair-programmed throughout with the client's own engineer. The pipeline extracts each document to a readable markdown form first so it is inspectable and re-runnable when the field list changes, then narrows to the fields that matter, normalises, enriches against third-party APIs and adds semantic grouping. Confidence comes from the provenance of each value combined with model certainty and an independent cross-check, not from the model's self-reported score, which is what makes routing explainable to the underwriter. What it does not do is decline a risk, set a price or bind, and extracted data should not reach a rating model without an explicit quality attestation, because the moment enrichment becomes an input to pricing the actuarial function inherits it. Where authority is delegated, the binding authority draws the boundary of a decision before any agent does, and that conversation with the managing agent belongs before the build. This is a proof of concept feeding business intelligence, not a production deployment.