Spotting vulnerable customers

• Calls, chats and emails are read for possible signs of vulnerability across the four FCA drivers: health, life events, resilience and capability. Each flag shows the customer's own words, so the colleague can see why.
• A trained colleague, not the AI, talks to the customer, asks what would help, and records the need only if the customer agrees.
• Agreed needs, such as 'prefers email', 'needs more time' or 'a named contact', follow the customer to every channel, so they don't have to explain again.
• Account activity that suggests financial difficulty or possible financial abuse is flagged to the specialist team, which decides what to do.
• Unconfirmed flags expire. A possible sign is never kept as a label on someone's file just because a model saw it.
• Outcomes are monitored by customer group: complaints, arrears outcomes, repeat contacts and how long support took, so the firm can show the Consumer Duty is working for vulnerable customers.

• FCAFG21/1: guidance on the fair treatment of vulnerable customers
  →

  The FCA's 2025 review kept FG21/1 unchanged under the Consumer Duty. The design follows it: understand the drivers of vulnerability, give staff the skills to respond, and record needs so they can be met consistently. The AI supports colleagues; it doesn't replace the conversation.

• FCAConsumer Duty (PRIN 2A) and outcomes monitoring
  →

  Firms must show that customers with characteristics of vulnerability get outcomes as good as other customers. The FCA's July 2026 outcomes monitoring review noted firms using risk indicators and AI to help spot vulnerability, and also limited evidence on how outcomes differ by group. Monitoring by group is built in from the pilot, and feeds the annual board report.

• FCA and ICOJoint statement on vulnerability-related data (27 March 2026)
  →

  Data protection doesn't stop firms supporting vulnerable customers, but they need a clear Article 6 basis and, for health data, an Article 9 condition: explicit consent, or a substantial public interest condition such as safeguarding individuals at risk or their economic well-being. The DPO chooses the conditions per purpose, and the design records which one applies to each need.

• ICOUK GDPR special category data and the Data Protection Act 2018
  →

  A model inferring a health condition is processing health data. So the AI flags possible signs for a person to explore, unconfirmed flags expire, and only needs the customer agrees to are recorded. A DPIA before the pilot, UK processing, short retention for transcripts, and contracts that stop providers training on your data.

• ICOEmotion analysis
  →

  The ICO has warned that emotion analysis technology is immature and risks bias and discrimination. This design reads what customers say, not how they sound. Voice stress, emotion and sentiment scoring stay switched off.

• ICOAutomated decisions (UK GDPR, as amended by the Data (Use and Access) Act 2025)
  →

  Because health data is involved, the strict limit on solely automated significant decisions applies. Nothing here makes one: no treatment, fee, limit, collections or product decision is ever made by the AI.

• EHRCEquality Act 2010
  →

  Many recorded needs are reasonable adjustments for disabled customers. They must be acted on reliably across every channel. The models are also tested so that accent, age or writing style don't change who gets flagged.

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

• A specialist support team that owns every referral, with enough people for the volume the pilot shows, before the AI is switched on.
• Clear wording for colleagues: how to ask about a possible need, how to ask for consent, and how to take no for an answer.
• Lived-experience and charity input on the wording and the support options, during discovery, not after launch.
• A weekly review of a sample of flags, including the ones colleagues rejected, and a monthly fairness check across age, accent and channel.
• A vulnerability outcomes forum with the authority to change products and processes when the data shows a gap.
• A named owner for every prompt, model and support policy, with change control, and the DPO signing off any new data source.

1. 3–4 weeks

   Discovery

   Map how needs are spotted and recorded today, measure the baseline, agree the lawful conditions with the DPO, and test the wording with customers and colleagues.

2. Gate · must be true to passBaseline agreed, DPIA started, conditions for processing chosen, specialist team capacity confirmed.

3. 6–8 weeks

   Pilot

   One contact centre team, in shadow mode: flags go to the specialist team for review only, and are compared with what colleagues spotted.

4. Gate · must be true to passConfirmed-flag rate within agreed limits, no group over- or under-flagged, wording signed off, DPO and compliance sign-off.

5. 4–6 weeks

   Production

   Flags go live to that team's colleagues, with monitoring, support and a rollback plan.

6. Gate · must be true to passMonitoring, outcomes reporting, training and rollback plan in place.

7. Ongoing

   Scale

   Add channels and teams one at a time, then account activity signals and collections.

8. Gate · must be true to passEach new channel or signal passes the same pilot gate, including the fairness check.

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

1. 1

   Goes wrong

   Flags become labels. A model's guess sits on a customer's file for years.

   How the design avoids it

   Flags expire unless a colleague confirms a need with the customer. Only needs are recorded, with consent and a review date.

2. 2

   Goes wrong

   It feels like surveillance. Customers find out the bank 'knew' before they told it.

   How the design avoids it

   Read what customers say, not how they sound. No inference of health from spending. Clear wording on what is recorded and why.

3. 3

   Goes wrong

   The specialist team is swamped, so referrals sit in a queue.

   How the design avoids it

   Size the team from the pilot's numbers before go-live, and tune flags with the team, not for them.

4. 4

   Goes wrong

   Spotting improves but outcomes don't.

   How the design avoids it

   Monitor outcomes by group from the start, and give the outcomes forum the authority to change products and processes.

5. 5

   Goes wrong

   The model flags some accents or age groups far more than others.

   How the design avoids it

   Fairness checks across age, accent and channel at the pilot gate and every month after.

1. Q1 2027
   Final FCA rules on the scope and proportionality of the Consumer Duty (CP26/23, consultation closed 18 September 2026).

   Watch for any change to how outcomes are evidenced, and keep outcomes reporting flexible enough to follow it.

2. 2026–2027
   The ICO's code of practice on AI and automated decision-making, required by regulations in force since May 2026.

   Keep the flag log, the human decisions and the reasons in a form you could show the ICO as well as the FCA.

3. Late 2026–2028
   The Cyber Security and Resilience Bill, bringing medium and large managed service providers into regulation.

   Expect your contact centre, CRM and AI suppliers to face new duties, and update supplier assurance and contracts to match.

4. 2028
   The NCSC's post-quantum cryptography milestone: a full migration plan by 2028.

   Needs records hold sensitive data for a long time. Record which encryption the platform uses and keep it easy to change.