A vulnerable customer register every system reads, with no new CRM

A vulnerable customer register, in banking, is a single record of the support needs customers have shared, such as large print, no sales calls, a bereavement or an attorney who acts for them, kept with the basis on which each was recorded and a date to review it, and read by every system that sends a letter, makes a call, charges a fee or starts a collections step. It is the practical form of what the FCA's guidance calls a "tell us once" process: the customer explains once and the whole bank responds. Most banks already store needs somewhere; the failure the FCA found in 2025 is that the stores are scattered and the systems that contact customers do not read them. Botminds' Vulnerable Customer Support keeps one register of needs alongside the bank's existing systems, applies each saved need to seven channels and checks every contact against it, so the CRM, the correspondence system and the collections platform stay where they are.

The expectations quoted here are the UK FCA's. No US federal rule requires a bank to keep a register of customer vulnerability; a US bank weighing one should start from its own privacy obligations, and can use the design below as a model. Examples come from a fictional sample bank, Corvane Bank UK.

What is a vulnerable customer register?

It is the bank's single source of truth on what each customer needs because of their circumstances, built to be read by machines as well as people. The word "register" is also used by energy and water suppliers for their own priority lists; in a bank the content is different, because the actions are different: a format for statements, a hold on collections, a block on sales, a review of fees, a named attorney.

FG21/1 sets the purpose without using the word. Firms should have systems that let staff record and access what will be needed to respond to customers' needs in future, because "Consumers should not have to repeat information." Its examples include "a “tell us once” style process where customer can notify a firm of a bereavement just once." A register is what makes "once" true across a bank with a dozen customer-facing systems.

The FCA's 2025 bank review saw the good version in practice. Some firms "had centralised these systems, such that staff from across different business areas and brands could view the customer’s needs, regardless of where they had disclosed them", which avoided the distress of repeating sensitive information. The review saw the bad version too.

Why notes in one system fail the next one

A note fails when the next system that acts on the customer cannot read it. FG21/1 gives the canonical case: a customer tells one part of the business about financial difficulty caused by illness, but "the system does not allow this to be shared with the collections department", so the collection process carries on regardless. Nothing about that failure is a training problem.

The FCA's 2025 findings describe the same pattern at scale. Its bank review heard that "fragmented customer relationship management (CRM) systems across business lines could make it more difficult to keep track of cases", and saw customers who had to repeat information or whose cases were delayed or dropped because they had been lost in the firm's systems. Its wider report found limits "often due to legacy systems or because there were multiple customer relationship management systems in use in different parts of a firm", with bereaved customers sending the same documents several times.

The sample bank measures the cost directly. In its third quarter, 3.1% of customers with a recorded need had to tell the bank a need again within 90 days, and 71% of those had first told a branch, whose free-text note the contact centre did not read. The register is the fix for that 71%: once a need is a row rather than a sentence, the contact centre, the letters system and the dialer all see it.

How do letters, collections and sales use the register?

Each channel reads the register for the one thing it must do differently. Letters check format and addressee before printing; the sales dialer suppresses customers who asked for no sales contact; the fee engine flags charges for review where a need says so; collections holds contact or routes it to a specialist. A good register stores the adaptation for each channel, not only the need, so no team has to interpret a diagnosis.

How Vulnerable Customer Support shows each channel adapted, and what the colleague approves

Do we need a new CRM for vulnerable customers?

Usually not. The FCA's findings point at systems that do not share, not at systems that are missing, and a new CRM rarely reaches the correspondence platform, the dialer, the fee engine and the collections system on day one. What is needed is a register those systems can read, through the integrations they already support, and a check on whether they did.

The FCA has also said, gently, where the obstacle usually lies. On attorneys' access to online banking, it found the limitation "often appeared to be due to the firm’s investment decisions". Its wider report described a firm that failed to get internal approval for engineering work to fix third-party account access, and so accepted a higher risk of customers being locked out. A register that sits beside existing systems lowers that bar: the engineering is a feed and a lookup, not a replacement.

Honesty about fit matters here. If a bank already runs one customer platform that every channel reads in real time, the register may simply be fields in that platform, and the remaining gap is checking whether the channels obeyed it. Where the channels run on separate systems, as in most banks with branches, contact centres and outsourced print, a register plus a contact check is the shorter path. The difference between a flag in a CRM and a tool that also checks and follows through is weighed in our guide to choosing a vulnerable customer support tool.

What goes in each row of the register

Each row should let a colleague act, a system filter, a tester verify and the customer recognise what was noted. That means plain words for people, structured fields for machines, and evidence for auditors, with health details kept apart.

The plain-words line is the field most registers lack and the one that does most work. A code such as "VULN-H2" means nothing to a temporary colleague on a Saturday shift; "speak slowly and check she has heard the key points" does. The structured fields serve the machines; the sentence serves the person on the phone.

Data protection risks of a vulnerability register

A register concentrates sensitive information, so its risks are concentration risks: too many people seeing too much, data kept too long, and information used for something the customer did not expect. FG21/1's appendix is the best short guide. It notes that information about changes made because of a customer's health is likely to be special category data even when the condition is never named, that firms need an Article 6 basis and an Article 9 condition, and that a data protection impact assessment may be needed.

Three design choices answer most of the risk. Show colleagues how to help and keep the why with specialists, as the sample bank does with a lock on health details. Set a review date on every temporary need and delete expired ones on a schedule; the sample deletes an expired temporary need 90 days after its review date. And keep the use within what the customer was told: FG21/1 observes that a customer with several products in one brand may expect staff in that brand to know their needs, but one dealing with different brands of the same group may not. The lawful-basis questions are covered in detail in our guide to recording vulnerability.

The register in Vulnerable Customer Support, with health details locked to specialists

Checking before, not after

A register earns its keep when a system checks it before the contact, and the next best thing is checking straight after. Letters can usually be checked before they print, because correspondence systems queue them; calls, fee postings and collections steps often can only be checked after the event, which is why the fix has to reach the cause.

The misses are where the register pays for itself. In the sample, one was a credit card upgrade call to a customer who had asked for no sales calls, because the dialer loaded the do-not-call list weekly; the proposed fix was to reload it every hour. Another was an £8.00 returned payment fee on a late husband's direct debit, proposed for refund and waiting for a specialist. The register made both misses detectable; the check made them visible; a person fixed the cause.

Integration in practice: six systems, one register

The register needs to read from, and be read by, the systems the contact centre and branches already run. In the sample bank that is six: the contact centre platform for call audio, chats and team diaries; the core banking record for accounts, standing orders and charges, written to only after a check; the correspondence system, for every letter before it prints; the collections system, for contacts and holds; the complaints system, for the outcomes comparison; and branch appointments, for interpreters and accessible rooms.

The FCA's October 2026 publication on AI adds one more question for any register fed by automated tools: whether customers "could switch channels without having to repeat information". That was the FCA describing good practice in AI-supported journeys; it is also a good acceptance test for a register. The product, its agents and its screens are on the Vulnerable Customer Support page.

Questions people ask

What is tell us once?

A process that lets a customer give information, typically a bereavement, once and have it reach everyone who needs it. FG21/1 cites a "tell us once" style process as a way to minimise how often a customer must tell a firm about their circumstances, and a trade association service that lets people notify several banks and building societies of a death at the same time.

How do you share vulnerability data across systems?

By keeping one record of needs with a lawful basis and letting each system read the adaptation it must apply, rather than copying free text between them. FG21/1's appendix notes that a firm can share data internally where the purpose is compatible with the one it was collected for, and that special category data needs an Article 9 condition.

Who maintains the vulnerability register?

Usually the frontline colleagues who record needs, the specialist teams who handle complex cases and close needs, and an administrator who keeps consent wording, review periods and channel rules. In the sample bank, closing a need takes a colleague and a second person, and any change to settings needs a written reason and the Consumer Duty manager's approval.

How do you avoid customers repeating themselves?

Record the need once in a place every channel reads, show colleagues how to help on the screen they already use, and measure repeat disclosures. The sample bank counts customers who tell it a need again within 90 days, 3.1% on its sample data against a design target of under 1%.

Is a vulnerable customer register the same as a CRM flag?

A flag is usually a marker on one system; a register is the full record of needs, with basis, review date and channel adaptations, read by every system. A flag can be part of a register; on its own it tells a colleague that something is there, not what to do.