Vulnerability is not a flag

There is a moment familiar to all debt advisers. You're three screens into a case and, in the corner, you notice the marker 'Vulnerable: Y'. Nothing more. It was recorded by somebody, at some point, for a reason that presumably made sense at the time. You now have 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 and needs change. A person may be confident with one part of a journey and need support with 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 Financial Conduct Authority's (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 flag solved an important problem... Once

The traditional CRM marker exists for a good reason. If a customer explains a difficult circumstance to one colleague, they shouldn't have to repeat it on every 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's still accurate, what the customer actually asked the firm to do or who is permitted to see the details of the vulnerability. 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 may need communication in writing, the other a trusted third party to communicate on their behalf. 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 can't use and still being asked to repeat their circumstances and requirements. The existence of data is not evidence of an outcome.

Disclosure can't 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 backs that up: most people don't disclose. Financial Conduct Authority (FCA) research published in 2025 found only 42% of customers in vulnerable circumstances said they'd disclosed those circumstances to firms. A quarter said they felt uncomfortable explaining their situation to a financial services provider. The reasons won't surprise anyone who's listened to advice calls: embarrassment, fear of being treated differently, fear of a worse deal and doubt that the firm would do anything useful with the information. The same research found customers in vulnerable circumstances were more likely to report a negative experience 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 the customers already confident enough to navigate the organisation, while possibly missing the ones who need it most.

This isn't an argument for diagnosing customers using fragments of data. It's recognition that support needs surface in many places, and in debt advice, much of that evidence already sits 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. A change in income visible through Open Banking, where the customer has chosen to connect it. The FCA and Information Commissioner's Office's (ICO's) joint statement on vulnerability-related data, published in March 2026, makes the same practical point: indicators can appear across different channels and different stages of the journey. The technology challenge is to bring those signals together without turning them into a verdict the customer can't challenge.

AI should prompt attention, not make a diagnosis

This is where AI genuinely earns its place. One conversation on its own may show nothing. But look across five conversations, a live-chat exchange and a changed financial statement, and a pattern can emerge. The customer keeps repeating information. They're struggling with a step they used to manage. They describe the same change in circumstances several different ways. AI can hold more of that evidence in view than a person working one contact at a time. It can surface the language, behaviour and journey events worth a second look, trace each one back to its source, and ask an authorised colleague to check whether the current support still fits.

What it must never do is quietly label someone vulnerable and let that inference drive a real decision on its own. Models get things wrong. Language is ambiguous. Behaviour almost always has more than one explanation. A missed payment could mean financial difficulty. It could also mean a changed bank account, or a shifted payday. Repeated contact could mean confusion, poor service or a customer who just wants reassurance. So the output has to stay a prompt, not a verdict: here's the evidence, this may point to a changing support need, please take a look. The system shows it's working. It states its confidence clearly. And it lets the reviewer reject or correct what it found. That correction gets recorded, for calibration and future testing - not hidden as an inconvenience.

The FCA and ICO statement speaks directly to automated decision-making and profiling. This is exactly where data protection law bites hardest. If the processing is likely to create a high risk to people, a data protection impact assessment isn't optional. That thinking has to happen before deployment, not after the complaint. AI can widen what gets seen. It should never narrow a person down 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 on their behalf. 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 gives creditors and advisers a defined way to collect relevant evidence for a specific purpose, with the customer's consent, instead of letting a medical narrative pile up unstructured across free-text case notes.

This is where privacy and customer care come together. 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 people. 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 the information in a sensitive field changes in the journey, that's the moment to challenge why it's being collected at all.

Context has to survive the next contact

Identifying a support need is only useful if the whole operation responds to it consistently - and keeps responding as the customer moves through the organisation. A customer might move 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. Every one of those hand-offs is a chance for context to get lost, sent to the wrong place or simply ignored. A customer who's carefully explained their circumstances in a web form shouldn't have to explain them all over again on the follow-up call, just because two systems don't talk to each other.

Supporting vulnerability properly means designing for the whole journey. Frontline colleagues need clear prompts and the authority to adjust support themselves, without escalating every case. Digital journeys need a way for customers to describe needs that don't fit neatly into a drop-down list. Quality teams need visibility on whether the agreed support was actually 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 couldn't show how they effectively monitored or acted on outcomes for customers in vulnerable circumstances - and most couldn't demonstrate that those needs were built into product and service design in the first place. Adding another mandatory field to the CRM won't close that gap.

Measure the response, not the marker

The measures that actually matter describe what happened after a need was identified or suspected. Was the preferred channel used? Did the customer have to repeat themselves? Was the agreed adjustment applied at the next contact? Did the promised actions happen? Did repeat contact drop? Did the customer actually 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 firms commonly leaned on complaints, staff feedback and quality-assurance findings - and far fewer used direct feedback from customers in vulnerable circumstances, behavioural insight or take-up of additional support. It also warned that process measures, like whether a call followed the required steps, don't tell you what actually happened to the customer.

That's 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 those of non-vulnerable customers. It also has to show whether whatever action was taken to close the gap actually worked. If every measure is green because a mandatory field got filled in, the organisation is measuring data entry, not support.

One vulnerable customer journey, three different technology jobs

At Better Outcomz, we're solving this across the journey, not asking one product to do everything. InsolVatrack holds the structured case record: agreed needs, case information, financial circumstances, actions and history, all in a controlled workspace. Better Outcomes is the assurance layer - it works across conversations and connected journey evidence, so quality teams can see where vulnerability got missed or where support didn't follow through to the outcome. Partner Connect keeps the context, ownership and auditability intact when work moves between organisations. The right person sees the right evidence at the right time. Sensitive information stays controlled. Every AI finding remains open to challenge. Customers shouldn't pay a price for their journey being split across different systems.

The goal was never a perfect vulnerability score. No number can capture a person's circumstances well enough to replace judgement. The goal is an operation that notices when something changes, responds with care and can show whether the support actually worked.

My test for vulnerability technology: Take the vulnerability marker off every screen tomorrow. Could the organisation still say what the customer needed? What evidence informed that? What support was given and whether it worked? If not, the flag has replaced the understanding it was meant to represent. Vulnerability isn't a field. It isn't a model score to wave through. It's changing customer context. Technology's job is to help people notice, act and carry the right support through the whole journey - collecting only the information needed and never pretending an automated inference knows the customer better than they know themselves.