Recording vulnerability means writing down what a customer needs because of their circumstances, such as large print, more time on calls or one team for a late husband's accounts, on a lawful basis and in words any colleague can act on, so that the next letter, call, fee or collections contact meets the need without the customer having to explain again. The FCA treats the record as the hinge of fair treatment: if staff do not record and access the information, its guidance says, service and communications may not meet the customer's needs. Yet in 2025 it found banks whose systems held the needs and whose staff did not use them. A record is only right if it is lawful, current, in the customer's words, seen by the right people and used. Botminds' Vulnerable Customer Support records needs through a colleague, with the customer's words and basis attached, and then checks every contact against them.
The requirements here are the UK's: the FCA's guidance FG21/1, the Consumer Duty, and UK data protection law, which FG21/1's own appendix walks through. No US federal rule requires a bank to record a customer's vulnerability; a US bank that keeps such notes still answers to its own privacy obligations, and can borrow the tests below. Examples come from a fictional sample bank, Corvane Bank UK.
Five tests of a vulnerability record, and how to measure each
| Test | What a right record shows | How to measure it | Where it comes from |
|---|---|---|---|
| Lawful | The basis it was recorded on: the customer’s consent, with the passage, or another condition the bank can name | Share of records with a basis attached; share where the consent passage can be produced | UK GDPR Articles 6 and 9; FG21/1 Appendix 1 |
| In the customer’s words | What they said and what they need, with the driver it falls under; no diagnosis they did not give | File testing: does the note say how to help, in plain words? | FG21/1 paras 2.9, 3.17–3.18 |
| Current | A review date that fits the need: months for a bereavement, years for a permanent condition | Temporary needs past their review date and not yet reviewed | FG21/1 case study on periodic reviews |
| Seen by the right people | How to help, for every colleague; health details for specialists only | Who opened health details, and why; exports logged | FG21/1 para 4.61 and Appendix 1 |
| Used | Every letter, call, fee, sale and collections contact matched the need | Contacts checked against needs, misses found, misses put right | FCA retail banks review, April 2025 |
What does recording vulnerability involve?
Recording vulnerability involves four things: noticing a need, agreeing with the customer what to note, writing it so others can act on it, and making it reachable wherever the customer next deals with the bank. FG21/1 gives the classic failure in one sentence. If a consumer with a sight impairment asks for a document in large print and gets it, "but information about their need for large print communications is not recorded or accessed by staff in future, they may send the customer important communications they cannot read."
The word that matters in that sentence is "or". A need that was recorded and never accessed harms the customer exactly as much as one never recorded. The guidance says staff should know how to record information and also "how to access and use previously recorded relevant information to prompt meeting that consumer’s needs."
The sample shows the large-print case almost word for word. Mrs Hollis asked her branch for 16 pt print in March 2025, and the need was recorded, with her consent and a review date. In September 2026 her annual savings statement went out at 11 pt anyway, because the statement template had no large-print setting. The record was right; the system that printed the statement never read it.
What the FCA says about recording vulnerability
The FCA says firms should have systems that let staff record and later retrieve what a customer needs, so that "Consumers should not have to repeat information." FG21/1 offers simple examples, a "tell us once" style process for bereavement and a free-text box on the customer file. Its 2026 review of payments firms describes the stronger practice as firms that "Consistently record vulnerability using system flags in their customer management computer systems."
The supervisory findings sit on the other side. The FCA's April 2025 review of seven banks and building societies found that "While systems were in place to record customers’ needs, it was not always clear that staff were consistently using them." Some assurance reviews found staff failing to record needs at all. The 2026 payments review added that some firms "could not consistently evidence how vulnerability information was recorded and shared across the customer journey."
A free-text note is the weak point in both directions. It is easy to write and hard to use: a letters system cannot read it, a sales dialer cannot filter on it, and a compliance tester cannot count it. In the sample bank's outcomes report, 71% of customers who had to tell the bank a need again had first told a branch, whose free-text note the contact centre did not read. How a single register fixes that without a new CRM is the subject of our guide to the vulnerable customer register.
Do you need consent to record vulnerability?
Not always. Consent is one lawful basis, and FG21/1 says plainly that "the ICO is clear that firms need not rely on consent to process data: there are alternatives and use of consent will not always be appropriate". What the law does require is a lawful basis under Article 6 of the UK GDPR and, because most vulnerability information concerns health or can reveal it, an additional condition under Article 9.
FG21/1's appendix makes the second point sharper than many banks realise. Information about changes made for a customer because of their health may not name the health issue, but "would be likely to constitute Special Category Data as their health issue could be inferred." A note saying "speak slowly; check she has heard" is health data in practice.
Two conditions a bank can rely on for health information, side by side
Explicit consent (Article 9(2)(a)): The customer can understand and agree, and the bank asks on the call or in the branch.
Safeguarding economic well-being (DPA 2018, Sch 1, para 19): Consent cannot be given, cannot reasonably be obtained, or asking would prejudice the protection.
Explicit consent (Article 9(2)(a)): Any customer who agrees.
Safeguarding economic well-being (DPA 2018, Sch 1, para 19): An adult "less able to protect his or her economic well-being by reason of physical or mental injury, illness or disability".
Explicit consent (Article 9(2)(a)): Need not be written; oral consent is valid but harder to prove, so keep the passage.
Safeguarding economic well-being (DPA 2018, Sch 1, para 19): Must be necessary, and the bank needs an appropriate policy document.
Explicit consent (Article 9(2)(a)): A customer may withdraw it; the bank needs a way to act on that.
Safeguarding economic well-being (DPA 2018, Sch 1, para 19): The bank must be able to show the necessity, case by case.
Many banks choose consent for ordinary cases anyway, because it doubles as the customer-service moment: the customer hears what will be noted and why. The sample bank does: its colleague flow records a need only when the customer agrees, keeps the consent passage with the need, and leaves other bases to a specialist, who records the legal basis where consent cannot be given. That is the bank's policy choice, not a rule, and an auditor should read it that way.
The TEXAS model, step by step
TEXAS is a five-step routine for handling a disclosure that FG21/1 cites as an example of good practice. It was developed from work on mental health and debt collection and is now used across sectors. Its value is that it makes the recording step a conversation rather than a form.
TEXAS: what each letter asks of the colleague
- T: Thank the customer for telling you
Acknowledge before processing. The FCA’s 2025 bank review found staff who did not acknowledge customers who were noticeably distressed.
- E: Explain how the information will be used
Who will see it, what will change, and that the customer can ask to change or remove it.
- X: eXplicit consent, or cheXs
Depending on the basis, either seek explicit consent, or check whether the customer objects to the information being processed.
- A: Ask questions to understand the need
What would help, for how long, on which channels. Record the need, not a diagnosis.
- S: Signpost to support
A specialist team inside the bank, or an outside service with the right expertise, where appropriate.
In the sample bank the X step is a script, C-4: "Would it help if I made a note of this, so you don’t have to explain it again? You can ask us to remove it at any time." If the customer says no, nothing is recorded and the decline is kept with the call, so the next colleague knows the question was asked. An agent can prompt the question and draft the note; it cannot answer for the customer, which is why the Listening agent in the solution never records. The wider question of where AI belongs in this step is covered in our guide to AI and vulnerable customers.
How long should a vulnerability record stay on file?
As long as the need lasts, and no longer, which means every record needs a review date set by the kind of need. FG21/1 describes a firm that "conducts periodic reviews of the client’s information and circumstances to ensure its records are up to date", and data protection law's principles apply to any personal data kept past its purpose. A bereavement is not a permanent characteristic; deafness usually is.
Review periods by kind of need, in months, as one bank might set them
- Review3 mo
- Then ask the customer6 mo
- Then ask at a natural contact12 mo
- Then confirm at a natural contact24 mo
Who conducts the review matters as much as when. In the sample, a Review agent finds temporary needs due and asks the customer at the next natural contact, so the review is a question, not a silent deletion. It never closes a need: a colleague and a second person do. On the sample bank's register, 2,860 temporary needs fell due for review in the next 30 days, which is the size of a job nobody does by hand reliably.
Who can see vulnerability information?
Every colleague who serves the customer should see how to help; far fewer should see why. FG21/1 says firms should design systems around what customers would reasonably expect, for example that "where a consumer holds multiple products within a single brand they may expect staff within that brand to be aware of their needs." Within the firm, its appendix says sharing is possible where the purpose is compatible with the one the information was collected for.
The sample bank splits the record in two. Colleagues see a plain-words line, such as "Bereaved Sep 14; hearing aid; large print; phone and branch only". Health details stay with specialists, compliance and internal audit; a restricted referral shows only "Held by Specialist Support"; and an evidence pack for the FCA or internal audit replaces health details with the driver and how to help, and masks account numbers to the last four digits. The export itself is logged with who asked for it and why.
A support needs register in Vulnerable Customer Support: how to help in plain words, with basis and review
What goes wrong with vulnerability records
Records fail in three recurring ways: the information is given and nothing is done with it, it is recorded but stays in one corner of the bank, or it is recorded and then goes stale. FG21/1's own poor-practice case shows the first. A customer wrote to a debt management firm that they had cancer and had stopped work, enclosing a new income and expenditure form; a member of staff received the letter "but took no action", and payments were reduced only six months later at an annual review.
The second failure is the one the FCA's 2025 consumer research heard most clearly. A blind customer told the regulator's researchers that staff repeatedly asked her to read aloud a reference number; adjustments were eventually made each time, but, in the FCA's summary, she was frustrated that she "had to repeat their needs every time they contacted the firm." Her need existed somewhere. It did not travel.
The third is quieter. A temporary need with no review date stays on file after the circumstance has passed, which is poor data protection and poor service at once: a customer who has recovered from a crisis may not want to be handled as if they had not. A review date, and a person who asks, are what keep a record true.
Testing whether records are used
The test that matters is whether contacts matched the needs, not whether needs were captured. The FCA's 2025 report found call handlers at some firms who never looked in their own systems for what was recorded about a customer's circumstances (FCA good practice report, 2025; more of the same review in FCA vulnerable customers review 2025). Its 2026 outcomes-monitoring review described one firm whose tracker raised action when it saw "complaint levels, repeated root causes and missed vulnerability flags". A missed flag is countable, if the bank checks contacts against needs.
Checking contacts against needs finds misses a file sample would not
412,600
letters, calls, fees, sales and collections contacts checked against recorded needs in 30 days
61
contacts that did not respect a recorded need
54
put right, on average 3 h 40 min after the miss was found
A file test still has a place, because it judges what a count cannot: whether the note says how to help, whether the consent passage supports what was recorded, whether a specialist acted in time. The sample bank's compliance analyst tests 60 files a month, and 52 passed in October. The two methods answer different questions. A whole-population check tells the bank how often needs were ignored; a file test tells it whether the records deserve to be followed.
Follow-through checks: each miss with the passage that shows it, and a proposed fix
A file-test sheet for one vulnerability record
- Is there a basis, and can you produce it?
The consent passage from the call or branch, or the specialist’s note of the other condition relied on.
- Does the note say how to help, in plain words?
A colleague who has never met the customer should know what to do differently.
- Is there no diagnosis the customer did not give?
Record the customer’s words and the need, not a staff member’s guess at a condition.
- Is the review date right for the kind of need?
And if it has passed, was the customer asked?
- Did every contact since recording respect it?
Letters in the format asked for, no sales contact where refused, fees reviewed, collections held where agreed.
- Where a contact missed, was the cause fixed?
A reprint fixes one letter; a template change fixes the next thousand.
- Did the customer have to say it twice?
A second disclosure of the same need within 90 days is a sign the record did not travel.
Whether a CRM flag can carry these tests, or whether a bank needs a tool that also checks contacts, is weighed in our guide to choosing a vulnerable customer support tool. The full set of screens is on the Vulnerable Customer Support page.
Questions people ask
Is vulnerability data special category data?
Often, yes. Health information is special category data under the UK GDPR, and FG21/1's appendix notes that a note about changes made because of a customer's health is likely to be special category data even when the condition is not named, because it can be inferred. Life events or financial difficulty alone may not be, but are still personal data.
What is a vulnerability flag?
A marker on a customer's file that tells staff and systems the customer has a recorded need. The FCA's 2026 review of payments firms counted consistent use of system flags as good practice; its 2025 bank review found needs on customers' profiles that staff did not check. A flag is useful when it carries the need in plain words and the systems that contact the customer read it.
Can a customer ask to remove a vulnerability record?
Yes, and the process for doing so should be simple. In the sample bank, customers can see, change or remove any need, and the colleague's script says so when the need is first recorded. Where the bank relies on consent, a request to remove the need ends that basis for keeping it.
Should staff record distress?
Not as a need. Distress on one call is a reason to slow down, acknowledge and perhaps offer a callback; it is not a lasting characteristic. In the sample call the Listening agent hears possible distress at 0.81 confidence, and the screen notes it is not recorded as a need because it describes the customer's situation, not a diagnosis.
Who should review temporary needs?
Someone with a list of what is due and a reason to ask the customer. The sample bank's Review agent finds temporary needs due for review and asks at the next natural contact; only a colleague and a second person can close a need, and expired temporary needs are deleted 90 days after the review date.