Vulnerable customers under Consumer Duty: FG21/1 explained at file level
FG21/1 asks firms to assess and respond to characteristics of vulnerability. The gap most files have is not the assessment — it is the documentation. A file that shows vulnerability was considered, and why, converts an invisible judgement into evidence.
The guides at a glance
| Guide | What it covers |
|---|---|
| FG21/1 checklist | The four things a file must show, at file level. |
| Drivers of vulnerability | Health, life events, resilience, capability — with file-level indicators. |
| Documenting vulnerability | The one-paragraph documentation wording that works. |
| File changes | What changes in a file when a client is flagged vulnerable. |
| Ongoing monitoring | Reassessment cadence, evidence trail, and board visibility. |
| Signs of vulnerability | The money-side indicators the FCA points to. |
| Consultant pre-scoring | Scoring vulnerability across client firms before it ships. |
The four drivers of vulnerability — health, life events, resilience, capability — are the starting point. What matters at file level is that each is checked, the outcome recorded, and any adjustments documented.
What the FCA says about vulnerable customers
The FCA's guidance for firms on the fair treatment of vulnerable customers — FG21/1 — sets out four drivers of vulnerability: health, life events, resilience, and capability. It is finalised guidance, so firms are expected to follow it. Under the Consumer Duty those expectations are reinforced: the duty's cross-cutting rules require a firm to act to deliver good outcomes for retail customers, and to pay particular attention to the needs of customers in vulnerable circumstances. The FCA's Consumer Duty pages set out the cross-cutting rules and the support firms are expected to provide.
The FCA has also looked at how firms treat vulnerable customers in practice. Its multi-firm review of vulnerable customers — held in the Consumer Duty publications library — found firms were more likely to identify vulnerability than to record the outcome and adapt the service. That finding is the whole theme of this page: the identification matters less than what the file shows the firm did next.
What vulnerable-customer care means at file level
At file level there are four things a reviewer looks for: the characteristics considered, the assessment recorded, the adjustments made, and the review points that follow. A file with all four answers the vulnerable-customer question without a single extra paragraph of jargon.
- Characteristics. Which of the four drivers were checked and what was found. The four drivers of vulnerability guide lists the signals under each driver, and signs of financial vulnerability covers the money-side signals in particular.
- Assessment. The conclusion recorded in the suitability report — not a label, but the reasoning. How to document vulnerability in a suitability report shows the wording.
- Adjustments. What changed because of the assessment: a simpler illustration, a slower timeline, extra checks, a different communication channel. The what changes in a file when a client is flagged vulnerable guide runs through the practical difference.
- Review points. Vulnerability is not a one-time flag. The ongoing vulnerability monitoring guide covers the logs, triggers, and reassessment a firm keeps.
The whole four-step pattern, as a working checklist, is in the FG21/1 file-level checklist. Consultants and compliance teams will also find the vulnerable customers for compliance consultants guide useful when reviewing another firm's files.
The trigger points matter as much as the initial assessment. A change of job, a bereavement, a complaint about debt, a pension access request early in retirement — each is a prompt to re-check the four drivers and record whether anything changed. Firms that rely only on the annual review miss the vulnerability that arrives between reviews, and the ongoing monitoring guide lists the triggers worth building into the process.
Worked example: the assessment that stays in the file
Before
“Client is 72 and recently widowed.” — the fact is on the file, the vulnerability consideration is not.
After
“Life-event driver identified: bereavement within the last six months. Resilience assessed: state pension plus £38,000 cash reserve; income needs covered for 24 months. Adjustments: cashflow modelled with 3% inflation assumption; recommendation deferred until funds received; documentation sent in larger print; review brought forward to six months.” — the same fact, now an assessment with a response and a review point.
Nothing in the second version is heroic. It is the first version with the judgement recorded — which is what the guidance and the duty actually ask for.
Common mistakes in vulnerability documentation
- Recording the fact, not the assessment. “Client is elderly” is a description. What the firm did differently because of it is the evidence.
- Only checking once, at onboarding. Circumstances change. A file that never re-checks the drivers at review points cannot show good outcomes over time.
- Treating vulnerability as a risk label. Flagging a client as vulnerable and taking no further action is worse than not flagging — it documents the risk without the response.
- Over-sharing personal data. Files need the characteristics and the response, not a clinical history. Records should be proportionate and consented.
- No link to the suitability reasoning. If vulnerability changes how a recommendation is made — cashflow modelling, a deferred purchase, a simpler product — the suitability report has to say so, not just the file note.
The vulnerable-customer file checklist
| File element | What to find |
|---|---|
| Drivers checked | Health, life events, resilience, capability — each considered |
| Assessment recorded | The conclusion and its reasoning in the suitability report |
| Adjustments made | What changed in the recommendation, timing, or communication |
| Review points set | A dated reassessment, or triggers that bring it forward |
| Data proportionate | Only what is necessary, with consent where required |
Related reads
- FG21/1 at file level: the vulnerability documentation checklist — the working version of this page.
- Documenting vulnerability in a suitability report — exact wording for the report section.
- The four drivers of vulnerability — the signals, driver by driver.
- Ongoing vulnerability monitoring — logs, triggers, and reassessment over time.
Frequently asked questions
Do we need to record every vulnerable client in the file?
The file needs to show vulnerability was considered and, where present, how the firm responded. That does not mean writing a medical history — it means recording the characteristics identified, the adjustments made, and the review points that follow. FG21/1, the FCA's finalised guidance on the fair treatment of vulnerable customers, is the source firms work from, alongside the Consumer Duty's cross-cutting rule on acting to deliver good outcomes for vulnerable customers.
What if a client does not want vulnerability recorded?
Handle the client's data with their consent and in line with GDPR, but the consideration itself still belongs in the file. A file that shows no record of vulnerability consideration is a gap the firm will have to explain; the response can be proportionate to what the client shares.
Is vulnerability a permanent label?
No. Vulnerability can be temporary or permanent, and it can change. The four drivers in FG21/1 — health, life events, resilience, and capability — can vary over time, which is why the firms' processes reassess at review points rather than labelling once.
How does Consumer Duty change what the FCA expects?
Vulnerable customers are a cross-cutting theme of the Duty: the FCA expects firms to act to deliver good outcomes for them with equal or better care. Under the duty, that expectation moves from good practice into the rules, and firms need the file evidence to show it. The FCA's Consumer Duty pages set out the cross-cutting rules and the FCA's multi-firm work in this area sits in the Consumer Duty publications library.
Your next step
Pull five client files and check the four elements: drivers checked, assessment recorded, adjustments made, review points set. Files that record the fact but not the response are the gap. Proven Duty flags vulnerability consideration against the FG21/1 drivers on every scored file, so the missing assessment shows up as a line-level flag rather than a surprise later. Start with a free trial or see pricing.