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: 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, 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.