Vulnerability is not a flag

The flag solved an important problem - once

There is a moment familiar to anyone who has worked in debt advice. An adviser is three screens into a case and, in the corner, a marker reads “Vulnerable: Y”. Nothing more. It was recorded by somebody, at some point, for a reason that presumably made sense at the time. The adviser now has to decide what, if anything, it should change about the next ten minutes.

A vulnerability marker can be genuinely useful. It can prompt a colleague to slow down, switch channel or take account of circumstances the customer would rather not repeat. The problem begins when the marker becomes the organisation’s entire understanding of the person. Vulnerability is not a permanent status captured once and carried forever. Circumstances change and needs change with them. A person may be confident in one part of a journey and need support in another. They may disclose something directly, hint at it across several conversations or choose never to explain it at all.

Regulated firms have spent years asking whether the flag exists. The better question, and the one the FCA’s outcome-focused work keeps returning to, is whether the customer received the support the flag was meant to trigger. That is a data problem, a workflow problem and, increasingly, an AI design problem. More importantly, it is a customer-outcome problem.

The traditional CRM marker exists for a good reason. A customer explains a difficult circumstance to one colleague and should not have to repeat it every time they call. Recording an agreed support need creates continuity, reduces distress and helps the next colleague respond well. Frontline frameworks such as the Money Advice Trust’s TEXAS protocol taught advisers to handle disclosures with care. The CRM field is where too many of those careful conversations went to be flattened.

A single field has obvious limits. It rarely shows when the information was recorded, whether it is still accurate, what the customer actually asked the firm to do or who is permitted to see the detail underneath. One broad label also compresses very different needs into the same operational response. Two customers may both have a health-related characteristic of vulnerability. One needs communication in writing. The other needs a trusted third party involved, sometimes a formally authorised representative. A generic flag tells the adviser to be careful. It does not tell them what good support looks like for this person.

There is a subtler risk too. Once the flag exists, people assume the vulnerability control has worked. The field is populated, the report shows green and the organisation moves on. Meanwhile, the customer is still being transferred repeatedly, still receiving communication they cannot use and still being asked to explain the same circumstances again. The existence of data is not evidence of an outcome.

Disclosure cannot be the only detection method

Firms should make it easy and safe for customers to explain what they need. But disclosure is hard, personal and often incomplete. The evidence says most people do not disclose. FCA research published in 2025 found that only 42% of customers in vulnerable circumstances said they had disclosed those circumstances to firms. A quarter said they felt uncomfortable explaining their situation to a financial services provider. The reasons will surprise nobody who has listened to advice calls: embarrassment, fear of being treated differently, fear of receiving a worse deal and doubt that the firm would do anything useful with the information. The same research found that customers in vulnerable circumstances were more likely to report a negative experience with a financial services firm than other customers: 44% compared with 33%.

A process that only starts when a customer uses the right words will miss many of the people it exists for. It will work best for those already confident enough to navigate the organisation.

This is not an argument for diagnosing customers from fragments of data. It is a recognition that support needs surface in many places, and in debt advice much of that evidence is already inside the operation. It might be repeated failed payments after years of clean conduct, an income and expenditure review that no longer adds up, a customer who stops answering calls but replies to a text within minutes, or a change in income visible through Open Banking where the customer has chosen to connect it. The FCA and ICO’s joint statement on vulnerability-related data, updated in July 2026, makes the same practical point: indicators can appear across different channels and at different stages of the journey. The technology challenge is to bring those signals together without turning them into a verdict the customer cannot challenge.

AI should prompt attention, not make a diagnosis

This is where AI genuinely earns its place. One conversation may contain no clear disclosure. Across five conversations, a live-chat exchange and a changed financial statement, a pattern may become visible. The customer is repeating information, struggling with a step they previously managed or describing a change in circumstances in several different ways. AI can review that evidence across more interactions than a person working one contact at a time. It can surface the language, behaviour and journey events that warrant attention, link each finding to its source and ask an authorised colleague to review whether the current support remains right.

What it must not do is silently label somebody as vulnerable and allow that inference to drive a significant decision. A model can be wrong. Language is ambiguous, and behaviour usually has more than one possible explanation. A missed plan payment may indicate financial difficulty. It might also mean a changed bank account or a shifted payday. Repeated contact may reflect confusion, poor service or a customer who simply prefers reassurance. The output should therefore be a prompt for trained human judgement: here is the evidence; this may indicate a changing support need; please review it. The system should show its working, communicate an understood level of confidence and let the reviewer reject or correct the finding. That correction should be recorded for calibration and future testing, not treated as an inconvenience to be hidden.

The FCA and ICO statement addresses automated decision-making and profiling directly. This is where data protection law matters most. If proposed processing is likely to create a high risk to people, a data protection impact assessment is required. That thinking belongs before deployment, not after the complaint. AI can widen visibility. It should never narrow a person to a prediction.

Record the need, not the life story

Better use of data does not mean collecting every detail a customer is willing to share. In most cases, the operational need matters more than the underlying diagnosis. The organisation may need to know that the customer prefers written communication, needs extra time, requires information in a particular format or has authorised somebody to act with them. Often it does not need a detailed account of the health condition or life event behind the request.

Debt advice has a long-standing model for this discipline in the Debt and Mental Health Evidence Form. It is a defined way for creditors and advisers to collect relevant evidence for a particular purpose, with the customer’s consent, rather than allowing a medical narrative to accumulate in free-text case notes. This is where privacy and customer care support each other.

The FCA and ICO’s 2026 statement confirms that data protection law does not prevent firms using or sharing personal information where it is appropriate and necessary to support consumers. It also restates the conditions: a lawful basis, a clear purpose, accurate and proportionate information, appropriate security and transparency with the customer. Special-category data, including health information, requires additional protection. The practical design questions are short. Why are we recording this? What action will it change? Who needs access? When will it be reviewed? What have we told the customer? When should it be deleted? If nobody can explain what a sensitive field changes in the journey, the organisation should challenge why it is collecting it.

Context has to survive the next contact

Identifying a support need is only useful if the operation responds consistently and keeps responding as the customer moves. A customer may go from an online journey to a phone call, from an adviser to a case manager, or from one organisation to a partner handling the next stage. Each hand-off is an opportunity for context to be lost, overshared or ignored. The customer who carefully explained their circumstances in a web form should not have to explain them again on the follow-up call because two systems do not speak to each other.

Vulnerability has to be designed across the whole journey rather than delegated to one team. Frontline colleagues need clear prompts and the authority to adjust support without escalating every case. Digital journeys need ways for customers to express needs that do not fit a drop-down list. Quality teams need to see whether the agreed support was delivered. Product and technology teams need to understand how their design choices land on customers with different needs.

The FCA’s 2025 multi-firm review found that most firms could not show how they effectively monitored and acted on outcomes for customers in vulnerable circumstances. Most also could not demonstrate that those needs were embedded in product and service design. That gap will not be closed by adding another mandatory field to the CRM.

Measure the response, not the marker

The meaningful measures describe what happened after a need was known or suspected. Was the preferred channel used? Did the customer have to repeat information? Was the agreed adjustment applied at the next contact? Were promised actions completed? Did repeat contact reduce? Did the customer understand the option in front of them? Were abandonment, complaint or failure rates different for customers with additional needs?

FCA work on outcomes monitoring found that firms commonly leaned on complaints, staff feedback and quality-assurance findings. Far fewer used direct feedback from customers in vulnerable circumstances, behavioural insight or take-up of additional support. It also warned that process measures, such as whether a call followed the required steps, do not necessarily show the customer’s outcome.

That is the difference between a vulnerability dashboard and vulnerability assurance. A dashboard counts what the system holds. Assurance tests whether the organisation recognised a need, responded appropriately and achieved an outcome comparable with other customers’ outcomes. It should also show whether the action taken to close any gap actually worked. If every measure is green because a mandatory field was completed, the organisation is measuring data entry, not support.

One customer context, three different technology jobs

At WellTech-UK, we are approaching this across the journey rather than asking one product to do everything. InsolVatrack provides the structured case record: agreed needs, case information, financial circumstances, actions and history in a controlled workspace. ScoreCoach provides the assurance layer across conversations and connected journey evidence, helping quality teams see where vulnerability was missed or where support did not carry through to the outcome. Partner Connect preserves relevant context, ownership and auditability when work passes between organisations.

The right person should see relevant evidence at the right time. Sensitive information should remain controlled, and every AI finding should be open to review. Customers should not suffer because the organisation’s systems divide their journey into pieces. I do not believe the goal is a perfect vulnerability score. No number can represent a person’s circumstances well enough to replace judgement. The goal is an operation that notices change, responds with care and can demonstrate whether its support worked.

My test for vulnerability technology: If the vulnerability marker disappeared from every screen tomorrow, could the organisation still explain what the customer needed, what evidence informed that understanding, what support was provided and whether it improved the outcome? If not, the flag has become a substitute for understanding.

Vulnerability is not a field to complete or a model score to accept. It is changing customer context. Technology should help people notice it, act on it and carry the right support through the whole journey, without collecting more than is needed and without pretending an automated inference knows the customer better than they know themselves.