Vulnerable-Customer Detection in Product Journeys: The Data and Model Governance

The FCA expects you to detect and support vulnerable customers. The moment you build a system that infers who is vulnerable, you have built a profiling engine that can discriminate, and you now own the governance of it.

Consumer Duty has applied to open products and services since 31 July 2023, and to closed products since 31 July 2024. Its expectation on vulnerability is not new in spirit — the FCA’s finalised guidance FG21/1 predates the Duty — but the Duty sharpens it. Firms are now expected to actively identify customers in vulnerable circumstances, adapt how they treat them, and evidence that the outcomes those customers receive are as good as everyone else’s. In a digital product journey, “actively identify” quietly becomes “instrument the journey and run a model over the signals.” That is where the governance problem starts, and most firms have not noticed they created one.

What you are actually being asked to detect

FG21/1 frames vulnerability around four drivers: health, life events, resilience and capability. None of them is a database field you already hold. A recently bereaved customer, someone managing a serious illness, a person under acute financial strain, a customer who struggles with numeracy or digital interfaces — these are states, often temporary, that a customer will rarely declare and that no CRM records natively. So detection happens by inference: from behaviour in the journey, from what the customer types, from how they navigate, from the products they hold.

The honest way to describe this is that you are inferring a sensitive personal state from indirect signals. That framing matters, because it tells you which two bodies of law you have walked into at the same time as Consumer Duty: data protection and equality. Health information is special category data under the UK GDPR. An inferred hardship state, once recorded against a person and used to make decisions about them, is personal data with real consequences. And a model that changes how a customer is treated can, if it leans on the wrong signals, produce indirect discrimination against people sharing a protected characteristic under the Equality Act 2010. Detecting vulnerability to help people and profiling them in a way that harms a protected group are, technically, the same operation pointed in different directions.

Signals to capture — and the ones to refuse

The instinct of an analytics team told to “detect vulnerability” is to throw every available feature at the problem and let the model sort it out. That is exactly the instinct to govern out. The useful signals are behavioural and proximate to the customer’s actual difficulty: repeated abandonment at a payment step, disclosed life events in free-text or chat, requests for repeat information, unusually long dwell times on terms, missed payments trending in one direction, direct statements of difficulty. These are things the customer is, in effect, telling you.

The signals to refuse are the proxies. Postcode, ethnicity-correlated name features, age used as a blunt instrument, product-holding patterns that track deprivation — these predict membership of a protected group at least as well as they predict genuine need. A model that learns “customers from this postcode need extra scrutiny” has learned to discriminate, and it will pass its own accuracy test while doing so, because in the training data the proxy and the target are correlated. The discipline is to decide, before training, which features are admissible on outcome grounds, not on predictive power. That decision belongs in a documented feature policy, treated with the same seriousness as a data contract on the pipeline that feeds it, not left to whoever is tuning the model.

Governing the model that infers vulnerability

Once a model is deciding, even as a flag, that a customer is vulnerable, it is a governed model and needs the artefacts of one. Not because a framework says so, but because a supervisor or a complaint will eventually ask you to justify a specific decision about a specific person. You want to be able to answer:

• What signals produced this flag, and can we reconstruct them for a customer who complains months later?
• What happens when the model fires — does a human decide the treatment, or does the system act alone?
• Have we tested outcomes by protected characteristic, so we can show the model is not systematically flagging — or missing — one group?
• What is the false-positive cost, given that a wrong flag records a sensitive inference about someone who never asked for it?

The human-oversight point is not decorative. Where a flag drives a decision with a significant effect on the customer, UK GDPR Article 22 constrains purely automated decision-making, and a design that lets a model deny, downgrade or reroute a customer with no human in the loop is both a data-protection exposure and, usually, worse for the outcome. The safer pattern is that the model surfaces a possibility to a trained person who decides the treatment. The model triages; the human treats.

The evidence a supervisor will actually ask for

Consumer Duty is an outcomes-and-evidence regime, and vulnerability sits inside that. As I have argued about the Duty being a data problem before it is a policy one, the board-level test is whether your management information distinguishes outcomes for vulnerable customers from the rest of the book and shows they are no worse. That requires the flag to exist, to be reliable, and to be joined to outcome data — complaint rates, cancellation, arrears, product suitability — which is a lineage problem as much as a modelling one. A vulnerability programme with no clean line from signal to flag to outcome cannot produce the MI the Duty expects, however good the model looks in isolation. This is where a data governance framework earns its place: it is what lets you evidence the inference rather than merely assert it.

There is also a records question people skip. A vulnerability flag is a retained inference about a person’s health or circumstances. It needs a lawful basis, a retention limit, a route for the customer to see and challenge it, and a purpose boundary that stops the flag leaking into pricing, marketing or credit decisions it was never justified for. A flag created to help a bereaved customer through a journey, and later quietly used to decline them a product, is the exact failure mode both regimes exist to prevent.

The line to hold

The trap is to treat vulnerability detection as a data-science win — higher recall, more customers flagged, box ticked. Recall is not the objective. The objective is better outcomes for people in difficult circumstances, produced by a system that can prove it does not discriminate against them and does not profile them behind their backs. Build for that, and detection is a genuine control. Build for the flag count, and you have engineered a fairness liability with an FCA obligation stapled to the front of it.