Agents in banking and insurance, answered in full.

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. It opened with 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.

They can do the document and evidence layer, where the elapsed time sits, and they should not take the decision. An agent reads incorporation documents, structure charts and identity evidence into structured fields with provenance per field, resolves entities across registries, assembles the file and says what is missing. It must not 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 defends to its supervisor. The design question is not accuracy but what the exception path costs, so route by confidence and consequence. Tenhaw built that pipeline shape on a live London specialty insurance engagement, a two-week proof of concept now being productionised in month three.

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, since 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 split the same way. 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 spanning the file, and it must not settle anything. Reading the notification and evidence into structured fields, checking completeness against the policy, routing by complexity and consequence, drafting the chronology and keeping customer communication current are coordination work. Deciding coverage, setting or moving a reserve, declining a claim and authorising a payment are not. Cycle time is made of waiting rather than handling, so map the waits first. Vulnerability is a route to a person defined by circumstance, not a confidence threshold. Any extracted field reaching a reserve is data the actuarial function is accountable for, which makes provenance an engineering output. That intake and provenance layer is what our specialty insurance proof of concept builds.

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. An agent must not 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 took a blank repository to a working proof of concept in two weeks, PDFs in and business intelligence out on Azure. It covered ground the business had circled for roughly a year, and we 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.

Not on its own. Conduct sits with the FCA and prudential soundness with the PRA, so a dual-regulated firm answers to both, and the same agent gets different questions from each. The FCA asks about customer outcomes and Consumer Duty, the PRA about model risk under SS1/23 and, for insurers, governance and data quality under Solvency II. Neither has written a separate AI rulebook and neither intends to. What answers both is one artefact set rather than two frameworks: a decision inventory, a risk classification agreed with your second line before anything is built, and an evidence trail that falls out of running the system. Our AI Readiness Audit produces that set in four weeks for £44,000 fixed.

It moves the first decision out of engineering and into the contract. A London specialty insurance AI build usually sits under a binding authority that already sets what may be written, within what limits and on whose paper, with the managing agent accountable for what is written under it, and none of it was drafted with a machine in mind. So the autonomy boundary is drawn inside what the binder permits, and the record of why a risk was routed, flagged or deprioritised is held in the workflow rather than in logs with thirty-day retention, because a coverholder audit asks how a risk came to be accepted. Where the binder does not contemplate machine involvement, that conversation comes first.