FCA vulnerable customers: how AI agents detect and escalate

A customer mentions a bereavement halfway through a conversation about a missed payment. Someone has to notice, change what happens next, and get that person to a specialist, all before the conversation moves on.

The FCA vulnerable customers framework asks firms to do exactly that, and most support operations are not built for it. They sample transcripts afterwards. With 26.4 million UK adults showing one or more characteristics of vulnerability in the FCA's May 2024 Financial Lives survey, a QA team reviewing a small share of conversations will meet very few of those people in time to change an outcome.

This guide covers what the regulator requires, how an AI agent detects vulnerability during a live conversation, why calibration causes more trouble than detection, and what evidence stands up in a Consumer Duty review.

What the FCA vulnerable customers guidance requires

The FCA's guidance on the fair treatment of vulnerable customers, FG21/1, defines a vulnerable customer as someone who, because of their personal circumstances, is especially susceptible to harm when a firm is not acting with appropriate care. It groups the causes into four drivers.

Consumer Duty raised what follows from spotting one of these. Vulnerability runs across all four Consumer Duty outcomes, and the consumer support outcome most directly: firms have to deliver good outcomes for customers in vulnerable circumstances, and have to be able to show they did. A flag sitting in a CRM field is not an outcome.

That distinction matters more than it sounds. Most firms can tell you their vulnerability policy. Far fewer can show, for a given month, how many customers disclosed a vulnerability driver, what treatment each of them received, and how quickly. The obligation is to act on the signal and evidence the action, which means the detection has to happen while the conversation is still running.

How an AI agent detects vulnerability during a live conversation

Guardrails in AI customer operations split into two kinds, and the difference decides what they can catch. Output-side checks, sometimes called agent guardrails, inspect the reply an agent has drafted and correct it before the customer sees it. That stops the agent giving financial advice or confirming an investigation it should not mention.

Vulnerability detection works on the other side. It is an input check: a classifier reads what the customer has just said, on every turn, before the agent decides what to do next. Gradient Labs runs it alongside related input checks for complaints, financial difficulty, and immediate risk of harm, because in real conversations those signals arrive together. Someone describing an eviction is often also making a complaint.

Three things to note:

• The agent classifies a signal, it does not diagnose a person. It recognises that a disclosure matching a vulnerability driver has been made, and changes what happens next. Whether that customer is vulnerable is a judgement for the specialist who picks the case up.
  
  

• Timing is the whole value. A disclosure on turn two is acted on at turn two, not found in a sample three weeks later when the customer has already had a poor outcome.
  
  

• It runs regardless of what the conversation was about. A customer who opens by asking for a statement and discloses a bereavement two messages later gets the same treatment as one who leads with it.
  
  

Firms that already built their own vulnerability classifier can keep it. Gradient Labs supports running a customer's own checks alongside ours, or in place of them, which matters when a model risk team has already validated an in-house approach.

Detection is the easy part, calibration is where firms get hurt

Detecting a bereavement disclosure is not technically hard. Tuning the threshold so the agent catches real disclosures without flagging every mention of money worry is hard, and it is where most of the operational damage happens.

One failure mode is over-sensitivity, which can show up in three escalating ways.

It blocks the support the customer needed. The vulnerability checks fire so readily that it hands off before the agent's financial difficulty procedure can run. Customers describing hardship get routed to a queue instead of being walked through the income and expenditure questions that would have got them a payment plan. The guardrail intended to protect them delays the help.

It damages the economics of the deployment. A card issuer adds financial support traffic to an agent that had been running well. Handoffs spike, and the resolution rate falls to roughly what a basic chatbot achieves, until the routing logic is retuned. The guardrail was doing what it was told, but what it was told was wrong for that traffic.

It gets switched off. A consumer lender deactivates vulnerability detection entirely after it flags ordinary financial hardship conversations. A firm that turns the check off has less coverage than before it automated anything, and that is a genuine regulatory risk rather than an inconvenience.

None of this argues against detection. It argues that the default setting is rarely the right setting, and that any vendor who tells you their vulnerability model works out of the box has not run one at volume.

Calibration is specific to a firm's book and its traffic mix. SteadyPay, an FCA-authorised embedded lending provider, is a worked public example. Their outbound collections agent needed to discuss financial difficulty, which is precisely the topic the standard guardrail restricts in inbound support, because only licensed professionals can give financial advice. Rather than accept the default, SteadyPay and Gradient Labs taught the agent the exception and its boundaries through a short period of internal guidance and testing before any customer took a call. Their team describes the precision of those guardrails as a requirement for empathy as much as for compliance, because customers with outstanding balances are often under real pressure.

What happens after the flag fires

A flag is a routing decision, not an outcome. Most AI vendors stop at the detection and leave the treatment to whoever picks up the escalation.

When Gradient Labs' vulnerability check triggers, the default is an immediate hand-off to a human. The agent stops working the original request and passes the case on with the full conversation, the reasoning behind the classification, and everything already established, so the specialist does not make a distressed customer repeat themselves.

Hand-off is not the only option. A triggered check can instead run a specific procedure, which is the right design when your policy says a particular disclosure gets a particular treatment rather than a general escalation. Recording a complaint properly is the common example: the overriding issue, not the underlying request, becomes what the agent works on.

Treatment should also differ by what was disclosed. A bereavement and a second missed payment both belong in hardship assessment and forbearance, and they should not receive the same forbearance terms. Gradient Labs' Lending Agent classifies the type of vulnerability disclosed and applies the forbearance policy the lender has set for that type, rather than defaulting every case to the same treatment. That is the difference between a process that satisfies an auditor and one that actually helps.

Proving your FCA vulnerable customers process to a regulator

A Consumer Duty review asks for evidence, not intention. Three things make a vulnerability process defensible.

• Performance data per check, over time. Gradient Labs reports each guardrail's behaviour over a rolling 90 days: how often it ran, how often it handed off, and its precision, catch rate, and accuracy. That turns "we detect vulnerability" into a number a compliance team can take to a committee.
  
  

• A reasoning trail behind every decision. Each classification carries the reasoning that produced it, alongside the data the agent referenced and the actions it took. Reviewers can see why a conversation was escalated, not just that it was.
  
  

• A feedback loop that changes behaviour. Operators who disagree with a classification record that disagreement, and it feeds the tuning. This is how calibration actually improves, and it is also the evidence that your firm is monitoring the control rather than trusting it.
  
  

We have seen these guardrail numbers reported to banks' model risk oversight committees, which is a reasonable bar to hold any vendor to.

Five questions worth asking any vendor before you let their agent near a vulnerable customer:

• What is the precision and catch rate of your vulnerability detection on traffic like ours, and will you show it before we sign?
  
  

• What happens to the conversation when it fires, and can we change that per policy?
  
  

• How do we see why a specific conversation was escalated?
  
  

• Can we run our own vulnerability checks alongside yours?
  
  

• How many of your live deployments have this enabled, and has any customer asked you to turn it off?
  
  

If you are assessing vendors more broadly, our guide to AI platforms for banking compliance covers certifications, regulatory coverage, and production evidence across the market.

To see vulnerability detection, escalation, and the audit trail running on your own conversation types, request a demo.