Vulnerability,

GDPR, and
disclosure
A practical guide for creditors and advisers

TECHNICAL GUIDE 3: RECORDING, USING, ENCOURAGING

Page 1
Contents page

TECHNICAL GUIDE 3
1. What is this guide about?

2. What do we think firms should do?

PART A: RECORDING DISCLOSURES

3. What should we record?

4. How should we record this?

5. What flags should we use?

6. What support codes should we use?

7. What account notes should we use?

8. What about secondary analysis?

9. How long should we keep data?

10. Who can we share data with? V

PART B: USING VULNERABILITY DATA

11. Using data to support individuals

12. Using aggregate data for monitoring

13. Using data to achieve good outcomes

PART C: ENCOURAGING DISCLOSURE

14. What is a disclosure environment? This series of guides was written by

15. How do we build one?
PART D: SUMMARY
16. What should we do next?
Chris FitchA, Rob BellB, and Colin TrendC.
The development of the series was
supported by Experian, Financial Wellness
Group, NatWest, PayPlan, Shoosmiths,
and Vision Blue.
The series represents best practice guidance,
but does not constitute legal advice.
A
Money Advice Trust
B
RB Compliance
C
Plymouth Focus Advice Centre

November 2020

2
THE GUIDES
The Money Advice Trust and Money
Advice Liaison Group exist to improve
the lives of people in debt.
To do this, they offer leadership and
guidance on key issues.
We are therefore pleased to support this
new series of guides for organisations on
vulnerability, disclosure, and GDPR.
Written to bring together two groups -
data protection teams, and staff working
on vulnerability policy – each guide deals
with a different practical issue.
“The Money Advice Liaison Group
and Money Advice Trust are delighted to
share this series of guides.
We hope they bring together the right
blend of expertise and vision for the
practical benefit of all consumers.”
Paul Smee, MALG Chair
Joanna Elson, Chief Executive,
Money Advice Trust

Technical TG1 is about the fundamentals – it explains

what vulnerability means in practice (rather
Guide 1 than just the definition), and why disclosures
of vulnerability are key moments (for
fairness, trust, and transparency).

TG2 walks firms through the choice of which

lawful processing basis to use with
Technical
vulnerability disclosures. This brings together
Guide 2 a legal understanding of GDPR, alongside
insight into the practical needs of vulnerable
customers.

This guide: TG3 focuses on how to record data (flags,

Technical Guide 3 support codes, account notes, and
Recording data secondary indicators), how to use data to
support customers, and how to encourage
Using data
further vulnerability disclosures.
Encouraging disclosure

Our Overview Guide provides a bird’s-eye

overview of selected content and actions
Overview
from all three Technical Guides. This gives a
Guide summary view, with the full detail being
3 found in each Technical Guide.
1. What is this guide about?

In our previous guides In this guide

In Guide 1 we outlined four ‘golden In this guide, we move-on from decisions
principles’ that all firms can follow: about processing base, to three practical
choices that flow from these:
 remember the reality of vulnerability
for the customer (our data come  what data to record on vulnerability
from real people with real problems) (and how to record it using flags,
support codes, and account notes)
 remember the staff who deliver your
policies (make their job simpler not  how to use the data on vulnerability
harder, as this will be more effective) (to best support customers, monitor
trends, and achieve outcomes)
 understand the full detail of each
processing base and choice (and  how to encourage further disclosures
don’t just jump on a ‘solution’) (as customer self-disclosure needs to
complement staff identification).
 record the absolute minimum of the
most relevant data (this requires a
crystal-clear purpose for processing).
In Guide 2 we then explored the choices
firms have to make when processing data
from customer and carer disclosures:
 describing the key lawful bases for
processing data from disclosures
(under both Article 6 and 9)
 emphasising that each base always
has its own strengths and limitations
(there is no ‘magic bullet’ or solution)
 showing how tools such as TEXAS
might be practically improved (to
handle difficult disclosure situations).
FIGURE 1
Our purpose for processing
In both guides, we have been clear: firms
need an approach that works on a ‘data’,
‘vulnerability’, and ‘operational’ level.
We call this the ‘three lens’ approach
(Figure 1).
To achieve it, firms need to bring their
data protection staff, vulnerability policy
staff, and operational experts together.
One ‘side’ cannot decide the approach –
instead, a careful balance of practical
realism, vulnerability sensitivity, and
GDPR compliance needs to be struck.
4
2. What do we think firms should do?

What should we do? What else should we do?

Only a firm can really decide its own This guide is not just about data
direction, as every situation, customer, collection and recording, but is also
and business challenge will be different. about the practical use of these data.
However, in this guide we recommend: We therefore also recommend that:
 when deciding ‘how’ to collect data  when considering how best to
every firm should adopt the mantra: support individual customers:
we aim to collect (and record) a firm brings together the key data
the absolute minimum of the most collected, plus any further evidence,
relevant data for action. to decide on the most practical action.
 when creating systems to record data  when using aggregate data to inform
every firm should use a trinity of: management decisions, firms should:
- multiple vulnerability flags - first, get the basic indicators right
- support need codes (volume, type, support, cause)
- account notes for context - second, get data on key features
 when establishing how long to keep (e.g. use of gambling blockers)
data, every firm should have their - third, collect DPA compliance data
own ‘retention rule of thumb’ that: (e.g. consent refusal/withdrawal)
we do not keep personal data for
- fourth, review the examples of
longer than [needed], and review key
data use described by the FCA to
data every 6-12 months to ensure it is
monitor arrangements for treating
accurate, relevant, and still of use.
customers fairly (page 27).1
 when considering how to share data
 outcome measures are clearly stated
disclosed by vulnerable customers:
as the FCA wants firms to show that:
- conduct a Data Protection Impact
Assessment for external sharing “[vulnerable consumers should]
experience outcomes that are as good
- do not overlook internal sharing of
as those of other consumers”1
data, as this is equally critical.
Finally, this guide recommends that firms
do not passively respond to vulnerability
disclosure, but actively encourage this:
 by creating disclosure environments
that make it simple for customers to
tell firms about a support need, and
send reassuring messages, signals
and explanations to customers about
what will happen to their information
if they did disclose to a firm.
1. FCA (2020). Guidance Consultation and feedback statement. Guidance for
firms on the fair treatment of vulnerable customers. GC20/3.

5
PART A: RECORDING DISCLOSURES

3. What should we record?

4. How should we record this?
5. What flags should we use?
6. What support codes should we use?
7. What account notes should we use?
8. What about secondary analysis?
9. How long should we keep data?
10. Who can we share the data with?

6
3. What should we record?
What should we record?
Understandably, the FCA does not offer
a definitive ‘shopping list’ of the things
firms should record about vulnerability.
Instead, firms should reflect on the data
they need in order to provide a customer
with a reasonable level of support.
This might include:
 what a customer is vulnerable to:
- things that make it harder to fairly
choose, purchase, access, use, talk
with, complain about, pay for, or
benefit from a product or service
- things not related to a product or
service in the ways described
above, but where a firm can either
(a) still take internal action to help,
or (b) signpost, refer, or partner
with an external specialist agency
- where a customer is potentially
vulnerable (at higher future risk),
and actually vulnerable (where
harm is being experienced now).
 any customer views on what support
could help this situation including:
- adjustments to process
- changes to contact methods
- actions involving external third-
parties
- actions involving internal
departments.

 any contextual information – such as
the cause of the vulnerability – that
could help provide this support
 any other information to help take
action to prevent, minimise, or avoid
the harm a customer is vulnerable to.
2. ICO. https://tinyurl.com/yynjobl5
7
That sounds like a lot of data…
The GDPR does not address vulnerability.
But it does say personal data should be:
“adequate, relevant and limited to what
is necessary in relation to the purposes
for which they are processed”.2
Firms need to reflect on each part of this.
i. Adequate information
Adequacy is all about having the right
amount and quality of data to support
customers in vulnerable situations.
It means asking what must be recorded
when a disclosure happens to capture:
 any immediate customer support
needs that are acted on (e.g. removal
from dialer, communication changes,
or adjustments to service provision)
 any support needs that may develop
over time, and need to be followed-
up on (e.g. a Stage 1 cancer diagnosis
without any current need for support
might, in time, progress to a Stage 2
diagnosis where support is needed)
 any contextual information to meet
these support needs sensitively (e.g.
a customer calls: five broad ‘support
need’ flags are on her account – such
as ‘talk slowly’– but no record/note
exists on the severity of these needs,
whether they are episodic or long-
term, or any actions we might take
that could cause or trigger further
harm).
Taking such steps will help firms ensure
customers do not have to repeatedly
re-disclose a vulnerable situation.
This can prevent situations where a
customer contacts a firm, assumes the
firm knows about a previously disclosed
vulnerability, but discovers they have to
re-disclose all of this again.
FIGURE 2
Customers often disclose
vulnerable situations in detail,
and in ways which can
challenge our ability to respond.
Adequate
Relevant
Limited
Firms respond by ensuring
they record the absolute
minimum of the most relevant
data needed to provide
meaningful care and support.
8
Adequate
 This is about having the right amount
and quality of data to help customers.
 It is about ensuring a good picture is
painted of the customer’s situation.
 It is about important details not being
left out, or questions left hanging.
 It is about having enough information
to decide what actions to take next.
Relevant
 This is about having the information
needed to inform practical action.
 It is about answering the key question
‘vulnerable to what?’
 It is about establishing what difficulties
or harm a customer is experiencing,
and what our firm can do about this.
 It is about recording information that is
essential, rather than ‘might be useful’.
Limited
 This is about having the absolute
minimum of the most relevant data.
 It is about balance - having the data
firms need to help a customer, but not
collecting data that is never used.
 Data protection teams should ask
vulnerability specialists what data and
insights they need to do their job.
 Firms that only collect ‘support need’
data are likely to miss key insights, and
may cause further customer harm.
ii. Relevant information
Relevancy is about collecting information
that will directly inform a firm’s actions –
rather than just being ‘of interest’.
In relation to disclosures of vulnerability,
this is about recording information that:
 will help improve the ways in which a
firm interacts with a customer
 will improve a customer’s ability to
access (and use) a product, service,
or process
 is about any difficulties, detriment, or
harm a customer is experiencing that
affect their relationship with the firm
 answers the question “vulnerable to
what?”, and records what customers
feel will prevent detriment from this.
Critically, all of this insight is recorded to
help prevent customer harm.
iii. Limiting data collection
Limiting and minimising the amount of
data held about a vulnerable customer’s
situation is an important safeguard.
However, it can go too far – causing
harm for customers and firms.
Most often, this happens where firms
introduce ‘blanket’ data policies only
allowing support needs to be recorded.
While done to minimise the amount of
special category data collected, this can
– as illustrated in Guides 1 and 2 – make
it more difficult to help customers.
Further, even where support needs are
recorded, these may still inadvertently
infer an underlying health issue, making
them special category data after all.
For these reasons, we must remember
one of our main purposes for
processing: to help our customers,
rather than collecting data that half-
explains how we do this.
9
How do we act on our principles?
It is one thing to have a set of principles,
but another to consistently act on them.
We would make four observations.
First, ensure one of our primary
purposes for processing is understood by
all staff: to help our vulnerable
customers.
While compliance with the GDPR is key,
firms have a choice in how they do this.
They must therefore adopt an approach
that delivers compliance, and provides
the data staff need to help customers.
Second, provide staff with the tools to
extract and record the most relevant
information.
There are several candidate tools to
assist with this. These are briefly
described in Guides 1 and 2.
Third, ensure staff are trained in turning
conversations into data.
This can be challenging for staff, but it is
important they are able to accurately
summarise a customer’s vulnerable
situation, support needs, and what the
customer is practically vulnerable to.
Fourth, careful planning and investment
should be made into vulnerability flag
and data systems – these can provide a
useful resource for both limiting and
organising the information firms hold
about vulnerable customers.
4. How should we record this?
Every firm is different
Every firm is different when it comes to
their information and data systems.
Many firms will have ‘legacy systems’
where a patch-work of different
databases exists across a firm (often not
linked, nor using the same protocols).
Other firms may be mid-way through an
IT renewal project, where only small
changes can be made to an already
agreed blue-print for data recording.
Meanwhile, some firms will be in the
early stages of creating their systems,
and just working out what vulnerability
flags, notes, or indicators are needed.
One common factor
However, whatever stage a firm is at,
one thing is clear: an effective system
for recording vulnerability data is rarely
introduced overnight or ‘first time’.
Instead, firms will need to work within
existing constraints (IT, budgets, time),
and be prepared to work – in steps –
towards a new information system.
Listen, test, learn, repeat
In developing a new system for recording
vulnerability data, it is vital that firms:
 listen to frontline staff on:
- what vulnerability data they need
‘at their fingertips’ to help customers
- what problems they have with the
way vulnerability data is recorded
and shared on/across systems.
 test and learn:
- pilot/test any improvements to data
recording (before any wider roll-out)
 repeat this process (where possible)
so that staff have the opportunity to
comment on the pilot process.
10
Building blocks
When recording data on vulnerability,
firms should consider their use of:
 flags for staff - once set, these signal
to staff that a customer has been
identified as vulnerable to harm.3
Firms will typically use multiple flags.
One flag will signal the presence of a
‘vulnerability’, whilst others will alert
staff to key customer characteristics.
Problems can occur with flags where
they are not visible across all systems,
or staff do not understand the flags.
 support categories – some firms have
systems that allow staff to categorise
the support given to customers.
These involve staff choosing support
codes off a drop-down list, which are
then visible on the customer account.
Such a system can, however, only be
used if a firm has mapped what help
it will give to different vulnerabilities.
 account notes – these allow staff to
write a brief contextual note about a
customer’s situation and needs.
In doing this, staff should always aim
to record the absolute minimum of
the most relevant data. Problems,
however, can occur where staff are
unsure what ‘relevant’ data is –
recording too much, or too little.
 secondary analysis – the above data
are not only used in helping individual
customers, but in also giving a view
across the entire customer base of
the level and type of vulnerability,
trends over time, and key outcomes.
This allows a firm to better ‘know’ its
vulnerable customers, and grasp how
they are being supported and helped.
3. Firms should be aware that any flags that are set will be seen if a customer
makes a Subject Access Request (unless an exemption applies). Therefore
they need to be able to justify why certain flags were applied against a
customer’s record in the event of any challenge from a customer.
 FIGURE 3

The purpose of a flag is to send a clear and immediately visible signal to staff.
They are not meant to provide a detailed description. Instead they simply alert a
FLAGS staff member to an issue they need to take into account.

Examples: Vulnerable customer – YES Disclosed a disability - NO

Refer to specialist team – NO Sensitive care needed - YES

The purpose of a support category is to describe the help a customer needs.

They are like a flag, but are usually formed of short pre-written sentences.
SUPPORT
When staff provide support to a vulnerable customer, they can choose one or
CATEGORIES
more categories to describe this help. This is then visible to other staff who deal
with this customer, and also provides useful monitoring information.

Examples: Alternative format – YES Third party access - YES

Decision-making limitation – NO Opt out of lending - YES

The purpose of an account note is to give the detail/context that flags cannot.
ACCOUNT
Staff need to record the absolute minimum of the most relevant information
NOTES about vulnerability. However, they are often unsure what this means in practice.

Example: “The customer has been diagnosed with Ataxia – they have said
this can affect their speech. They say it can mean they sound
drunk. However, they can speak if given the time to do this.”

SECONDARY The purpose of secondary analysis is to get an aggregate picture of vulnerability.

ANALYSIS It gives firms a ‘bird’s-eye’ view across the entire customer-base of the number
of vulnerable customers, the types of vulnerability reported, and the actions
being taken to support these customers.
Firms will pool together data from flags and support codes to build this picture.
However, they may also get staff to collect other data to aide this monitoring.

Examples: Cause of vulnerability – LIFE EVENT Length – FLUCTUATING

Customer referred to debt advice – YES Query resolved - YES

11
5. What flags should we use?
What should our flag system do?
The purpose of a flag system is to:
 visually alert a staff member
 inform them that a customer has
been identified as vulnerable to harm
 remind the staff member to actively
take any vulnerabilities into account
 direct them to consult support codes
and account notes for vital context
 allow staff to add, update, or remove
flags to reflect a customer’s situation
 contribute to a data-set that monitors
vulnerability across all customers.
Dashboard
To do this, firms need to have a series of
flags that act like the dashboard of a car.
These should be limited in their number,
clearly visible at all times, and succinctly
inform staff about vital information.
Looking back
However, we would never drive a car by
only looking at our speedometer, rather
than in our mirrors, or the road ahead.
Therefore we need a flag system that
reminds staff to look back at support
codes and account notes (as these will
provide key contextual information).
Road ahead
And we need a forward-looking system.
This should inform conversations with
customers about their current situation,
and allow staff control over flag setting
to reflect any ‘new bumps’ in the road.
It should allow potential vulnerability to
also be flagged (so that firms can ‘watch’
for any emerging problems over time).
12
What flags should we use?
There are a potentially large number of
flags available to firms (Figure 4).
In making this decision, firms should
consider the following factors:
 flags signal a problem, they do not
describe it in detail – firms should
not have too many flags for staff to
interpret, remember, or look out for.
Keeping it simple is key.
 however, a single vulnerability flag is
too simple – customers often have
multiple problems, a range of needs,
and with different levels of severity.
Some of this – like customers at high-
risk of harm, or with communication
problems - need immediate flagging.
One vulnerability flag cannot do this.
 others may be involved – customers
may be supported by a firm’s internal
specialist team, or an external third-
party (e.g. family or debt adviser).
Being alerted to this from the outset
can be beneficial to staff.
 ‘unfinished business’ – sometimes,
due to emotional upset or practical
difficulties, staff will not be able to
complete all the actions needed with
a vulnerable customer. Flagging this
can allow conversations to be broken
into smaller, more manageable parts.
 time and date stamps are key – flags
need to be accurate, up-to-date, and
reviewed for accuracy. Therefore
knowing when a flag was set/is due
for review is important.
 ‘feedback loops’ help – frontline staff
are in the best position to feedback
on how well a flag system is working,
and what flags need to be changed,
added, or removed.
FIGURE 4 MOST BASIC ADDITIONAL FLAGS MOST
FLAG (STAFF ‘TICK ALL’ DETAILED
THAT APPLY) INFORMATION

EXAMPLES

LIFE EVENT
Is there a HEALTH CONDITION DETAIL ON SEPARATE
vulnerability YES FINANCIAL DIFFICULTY VULNERABILITIES IN
issue? FINANCIAL SKILLS ACCOUNT NOTES AND
LONG-TERM | SHORT-TERM SUPPORT CODES
FLUCTUATING
POTENTIAL VULNERABILITY

Is there an SPOKEN COMMUNICATION DETAIL ON THE SUPPORT

accessibility WRITTEN COMMUNICATION NEEDED TO ENABLE
YES MORE TIME NEEDED ACCESS IN SUPPORT
issue?
DECISION-MAKING CODES
CANNOT USE IVR
ENGLISH LANGUAGE ISSUE

ACCOUNT NOTES AND

Is there a GREATER SENSITIVITY SUPPORT CODES PROVIDE
risk or greater YES REFER NOW TO MORE DETAIL (THESE MAY
care issue? SPECIALIST SUPPORT TEAM BE LOCKED TO SOME
STAFF IF SITUATION IS
CHECK ACCOUNT NOTES VERY SENSITIVE)

Is there a AUDIO CORRESPONDENCE FIRMS CAN USE A

customer support BRITISH SIGN LANGUAGE RANGE OF SUPPORT
need? YES ALTERNATIVE FORMAT CODES TO BETTER
NUMERACY SUPPORT CATEGORISE AND
CHIP & SIGNATURE QUANTIFY NEED

Is a INTERNAL SPECIALIST TEAM ACCOUNT NOTES

third-party MANDATED 3RD PARTY PROVIDE THE DETAIL OF
YES POWER OF ATTORNEY THESE ARRANGEMENTS
involved?
CARER DISCLOSURE
FRAUD RISK

Are there any CONTINUE INTERRUPTED ACCOUNT NOTES

unresolved DISCLOSURE DESCRIBE THE DETAIL OF
YES WHAT ACTIONS NEED TO
actions? CHECK-IN ON CUSTOMER
BE TAKEN AND WHY
REQUEST MEDICAL
13 EVIDENCE
6. What support codes should we use?
What should our codes do?
The purpose of support codes is to:
 clearly and quickly communicate to
staff what help a customer may need
 present this information using codes
or short pre-written sentences
 allow staff to add, update, or remove
codes to reflect a customer’s situation
 direct staff to consult account notes if
greater detail is needed (particularly
where need is complex or long-term)
 use these fixed codes and categories
to quantify the help and support
given across the customer base
 take an approach that requires firms
to think systematically about the
categories of support they can offer.
Why codes and categories?
Firms will often record customer support
needs within the account notes section.
This is understandable – particularly if a
customer’s support needs are complex,
detailed, and require explanation.
However, one disadvantage of account
notes is that this information can easily
be overlooked when multiple pages of
notes and past entries exist.
Using codes that visually alert staff to the
support that vulnerable customers need,
can help to overcome this basic problem.
Equally, it also forces firms to develop
their support strategy – as in order to
create such codes, firms need to know
what help they will (and won’t) provide.
Doing this requires resources – however,
its pay-off lies in the alerts staff are given
on the help individual customers need,
and the aggregate data produced on
support needs across the customer base.
14
What codes should we use?
There are a large number of potential
support codes firms could use (Figure 5).
In deciding this, the issues that apply to
flags need consideration (see page 12),
plus the following:
 support codes need to be visible and
understandable – there is no point in
firms devising support codes, if they
are not immediately visible to staff.
Equally, visible codes are little use if
they are too complex to understand
without a reference book.
 support codes can indirectly infer
specialist category data – where a
code describes a form of support for
a particular health condition – such
as a hearing impairment - then this
represents special category data (and
must be processed accordingly).
In short, if a support code infers an
underlying health condition (or other
special category data), it has to be
treated as special category data.
 account notes are still needed –
support codes exist to alert staff to
customer need. However, account
notes should be used alongside to
provide more detail (e.g. if needs are
multiple, complex, or long-term).
 time, dates, and feedback loops
stamps are key – like flags, codes
need to be accurate and up-to-date.
Therefore knowing when a code was
set/is due for review is important.
Staff should also be able to feedback
on how well the support code system
is working, and what codes need to
be changed, added, or removed.
 customers will usually know best
about the support they need – if in
doubt, staff should always ask.
Potential support codes: an A to W
Audio CD correspondence
Requires audio correspondence/interaction.
Authentication/ID issue
Customer struggles with authentication.
Bereavement/grief
Has had a recent death of someone close.
Blocker
Customer has turned on spending block.
Braille correspondence
Communication in an alternative format.
British Sign Language interpreter
BSL required.
Cannot sign/signature may vary
Customer signature may vary when they
sign a document (illness/writing difficulties).
Check before disclosure (joint product)
Customer does not want their details
disclosed to another party on that account.
Chip & Signature/No Chip & Pin
Does not use Chip & Pin.
Communication needs
Ask customer what these are/follow advice.
Court Protection/Public Guardian
This is registered on customer account.
Customer contact (repeat/frequent calls)
Customer contacts us repeatedly.
Digital issues
Customer might struggle with digital skills.
Decision-making limitation support
This customer may struggle to make certain
decisions without our support and help.
Developing situation (watch)
A potential vulnerability has been disclosed
that could emerge and develop over time.
Difficulty with speech
Customer has difficulties in talking/speaking
(but not in understanding what we say).
15
FIGURE 5
Easy Read correspondence
Customer has correspondence needs.
English language support
This customer may need English language
support (due to written/verbal problems).
Failed ID & Verification
Different verification route is needed.
Fraud risk
Under investigation/care of fraud team.
Hearing/induction Loop
Customer requires hearing loop.
Large print correspondence
Large print required.
Life event support
Disruptive life event (death, birth etc.).
Literacy issues
This customer might struggle with literacy.
May prefer non-written support/talk.
Longer appointment time needed
More time required due to vulnerability.
No contact via telephone
Cannot use/does not want phone contact.
Numeracy issues
Customer might struggle with numeracy.
PoA/Representative Access
Power of attorney is present.
Text Relay
Uses text relay service to communicate.
Third party
Customer account has third-party mandate.
Unable to use Interactive Voice Response
Cannot use IVR if contacting by phone.
Written confirmation required
Requires written confirmation (e.g. due to
mental capacity, memory issues, etc.).
What about ‘disclosure outcomes’?
When a customer discloses a vulnerable
situation, firms will want to help.
And support codes will help to categorise
the vast majority of these responses.
However, firms may take other actions
which although still helping a customer,
may be more about following process.
These might include, for example, staff
signposting to an external service that
offers specialist gambling support.
It could involve recording that contact
was made with the emergency services
due to concern about the customer.
Or it could simply be that a transactional
problem was successfully resolved.
Future contact and monitoring
Recording such actions using a support
code can help during future contact with
that customer (allowing staff to see what
signposting or processes were followed).
It can also help – as seen in the section
on aggregate monitoring – to describe
this across the whole customer base.
This may be particular useful – as noted
by the FCA - when comparing the
treatment and outcomes of vulnerable
and non-vulnerable/other customers.
Clearly, account notes can provide such
information. However, the visual alert
given to staff, or the aggregate picture
built-up by using these codes across the
customer base, can be invaluable.
16
Which outcomes could we record?
Again, firms will need to consider their
own specific processes and needs, but
the following disclosure outcomes are
often recorded:
 external referral to debt advice agency
– this signposting support code allows
staff and firms to understand who has
been referred to a debt advice partner
 external referral to health organisation
– similar to the above, this signposting
support code tracks referrals to either
specific named health organisations,
or more general signposting
 escalated as a complaint – this allows
insight into which vulnerable customers
have been escalated to complaints due
to a report of poor service or practice
 emergency service contact – this gives
insight into customers who have caused
serious enough concern for a firm to
have contacted an emergency service
 escalate to another team – firms may
want to track referrals between teams,
so that they can establish how quickly a
customer issue is resolved
 query resolved – this allows firms to
track how many queries from
vulnerable customers are resolved
 ongoing/ unclear/unresolved – this
allows firms to track how many queries
are ongoing/ unclear/unresolved
 other – an ‘other’ category is important,
as it allows staff to report actions not
covered by current codes, but where (if
there is a good reason) such codes could
be created in the future.
7. What account notes should we use?
What should our account notes do?
The purpose of account notes is to:
 give the additional detail and context
that cannot be conveyed in a flag,
support code, or outcome measure
 allow staff to read previous notes,
and add new account notes to reflect
a customer’s current situation
 provide a data-source that – in the
absence of support codes or outcome
measures - can be ‘word scrubbed’.
Pinned not lost (where possible)
One of the key problems staff can have
with account notes is that they can be
‘lost’ or overlooked when multiple pages
of notes and past entries exist.
Consequently, some firms allow staff to
‘pin’ the most current and relevant notes
to the top of the first page of notes.
Where such an option isn’t available in a
firm’s system, alternatives should be
sought (such as repeat posting of older
notes – to ensure they appear first).
‘Word scrubbed’ (where needed)
Sometimes firms will be unable to use
vulnerability flags, support codes, or
outcome measures.
In such situations, firms may choose to
batch process or ‘word search’ their
account notes for specific key-words
related to vulnerability.
These can provide an approximate
indicator of how many accounts may
involve some form of vulnerability.
Such a measure can be used in lieu of
flags or support codes, or may be used to
establish a ‘missed case’ where such a
flag or code should have been applied.
17
What notes should we use?
As account notes reflect an individual
customer’s specific circumstances, it is
not possible to offer generic examples.
However, in developing staff ability to
write flag notes, firms need to consider:
 minimum / maximum ‘rule’ – staff
should aim to record the absolute
minimum of the most relevant data
possible in an account note. In
practice, this will mean thinking
about what information will be
needed to both inform meaningful
action, and also help the next
member of staff (who won’t have
had contact with the customer) to
provide the support needed.
 vulnerable to what? – account notes
provide an opportunity for staff to
record exactly ‘what’ a customer is
vulnerable to, and what actions
might be taken to avoid this.
 facts not feelings – notes should
normally only contain facts (what was
said or done by a customer) rather
than impressions or feelings that a
staff member has. If impressions
have to be recorded, these should be
clearly marked as such. At all times,
staff should never guess or ‘diagnose’
what is causing a customer to act in a
certain way.
 account notes can infer special
category data – as noted earlier,
where an account note mentions a
form of support for a particular
health condition – such as a hearing
impairment – then this represents
special category data (and must be
processed accordingly).
8. What about secondary analysis?
What should our analysis do?
The aim of secondary analysis is to:
 give an aggregate overview of the
vulnerable customer base, and its
characteristics and trends over time.
 allow firms to better ‘know’ their
vulnerable customers, and compare
their experience and outcomes with
other/non-vulnerable customers.
 allow firms to use these data to
inform the design and operation of
journeys, processes, products, and
services that better meet the needs
of customers in vulnerable situations.
How might secondary analysis work?
When a vulnerable customer contacts a
firm, or discloses their situation:
 a firm’s first instinct must be to use
any flags, support codes, or notes to
best help that individual customer
(as discussed earlier in this section)
 as a second task, a firm might then
‘pool together’ data from such flags
and codes to describe vulnerability
across their entire customer base
 and as part of this, a firm might then
require staff to routinely record
other data about each vulnerable
customer to add further detail to that
picture of the wider customer base.
The secondary analysis element will
then come into how a firm uses this pool
of data to inform and guide its strategy
on working with vulnerable customers.
18
What indicators could we use?
Again, there are numerous secondary
indicators that firms could use (Figure 6).
In deciding upon this, firms should take
into account the issues noted for flags
and support codes (pages 12 and 14).
They should also consider whether a real
need exists to record a secondary
indicator about vulnerability.
Routinely recording such data may
require extra staff time, and firms need
to build this into operational planning.
Anonymised data
Where a valid legal basis for processing
exists, firms will be able to record data
directly on a customer’s account.
Taken together with information from
other accounts, these aggregate data can
then be used to monitor and evaluate
the fair treatment of customers.
However, if an appropriate legal base for
processing personal or special category
data does not exist (such as where
consent has been refused), then firms
may wish to consider recording the
information as anonymised data.
This requires a firm to strip away any
identifiable information, and create a
new record which is no longer linked to
the original customer account, and
where the re-identification of individuals
cannot take place.
In doing this, firms can ensure that data
that might be useful for aggregate
monitoring purposes are not lost
(while being mindful that this can
introduce issues of ‘double counting’
into aggregate data, if a customer agrees
at a later point for their linked account
data to be used for these purposes).
Other indicators: A to V FIGURE 6
Addiction Length (permanent, temporary)
Age (75+) Length (short, medium, long)
Age-related issue Life event (change circumstances)
Authentication/ID issue Literacy issues
Branch assistance required Lost job
Breakdown Medical issues
Cancer Mental health problem
Care leaver Non-standard requirements
Caring responsibilities Numeracy issues
Confirmed deceased Other
Consent could not be obtained Payment issue
Consent not given/refused Physical health issue
Consent withdrawn Referred from fraud
Counter transaction required Refugee
Critical illness Rejected medical write-off
Customer contact (repeat/frequent calls) Relationship breakdown
Customer is a carer Repossession
Decision-making limitation support Risk (high)
Disability Suspected deceased
Domestic abuse Suspected or confirmed as missing
Elderly Suspected vulnerability
Financial or economic abuse Terminal illness
Financial capability Third parties (involved)
Financial difficulty Third party help to manage their account
Financial resilience Third party support (POA/EPOA/OCP)
Financial understanding Unconfirmed/unverified/
Gambling addiction Unverified observation from 3rd party
Housing problem Vital interests
Language barriers
Learning disability

19
9. How long should we keep data?
How long is long enough?
The ICO has a simple message when it
comes to data storage:
“[firms] must not keep personal data
for longer than [they] need it”.4
However, neither the ICO nor the GDPR
state how long this period should be.
So what should firms consider when
developing their retention policy on data
from vulnerability disclosures?
i. Start the clock
The first step firms can take is to ensure
that time/date stamps are placed on key
data items.
This may sound obvious – however, it is
not uncommon for firms to date stamp
their account notes, but not apply similar
stamps to flags or support codes.
Without such information, it can be very
difficult for firms to establish exactly how
long vulnerability data have been held.
ii. Devise a ‘retention rule of thumb’
Firms will already know that vulnerable
situations can change over time.
Some customers will directly keep a firm
updated on their situation, and staff will
make changes to the relevant data.
However, some customers will not offer
such updates, and a firm must therefore
set a time-limit after which these ‘quiet’
accounts are reviewed, and a decision
made on whether the vulnerability data
is updated, or deleted from a system.
Again while some individual cases will
need different treatment (see opposite),
some firms review such cases every 6-12
months, contacting customers where it is
necessary to update their information
(and deleting data where it is not).
20
iii. Recognise there are exceptions
As noted earlier, customers will inform
firms about vulnerabilities where they
expect an imminent change might occur.
This may involve a potential vulnerability
(such as an early stage medical diagnosis
that may become more serious in time).
In such situations, firms might monitor
these customer accounts more regularly,
to check both the stored data is correct,
and no additional support needs exist.
iv. Recognise complexity
As always, firms will want to recognise
that customers may disclose more than
one type of vulnerability to harm.
In these situations, it may be necessary
to set multiple ‘time to review’ flags.
This can be important if a firm uses an
automated process or tool-set (such as
robotic processing) to batch-process
customer account data.
v. Allow customers more control
The simplest way to keep vulnerability
data updated, is to give customers the
option to do this themselves.
Some firms, for example, are planning
‘spaces’ in their account dash-boards
where customers will be able to request
a support need, let a firm know they
are disabled, or share other relevant
vulnerability information.
Importantly, this will give customers the
option – in limited ways – to update,
change, or delete this information.
vi. Purpose for processing
Finally, firms should always consider
their purpose for processing the data,
alongside any wider legal or regulatory
requirements on data storage.
4. ICO (2020) https://tinyurl.com/yxe23x3z
10. Who can we share data with?
What data should we share?
Sometimes firms will want to share data
about customers in a vulnerable situation
with a third-party organisation.
In this section, we review what a firm
(acting as a data controller) should think
about prior to sharing vulnerability data
(with another data controller).
Throughout, we encourage firms to think
about their purpose for processing, and
to challenge themselves to consider how
sharing vulnerability data fits into this.
Consequently, our starting point is not
‘what’ data to share, or ‘how’ to share it,
but whether data need sharing at all
(the ‘necessity test’ covered in Guide 1).
Key reading: ICO Code of Practice
It is important to note the ICO is due to
publish an updated statutory Code of
Practice on data-sharing.
Already consulted on, the current draft
Code of Practice is on the ICO website.5
As every firm should read this document,
our guide does not duplicate its content,
but instead considers its most key points.
5. ICO. https://tinyurl.com/yxdr4d69
6. The ICO provides detailed guidance on undertaking a DIPA.
This can be found at: https://tinyurl.com/y45tgy59
7. Firms do not need to conduct a DPIA for every piece of
information they wish to share, as this would be time and resource
intensive. Instead a DPIA only needs to be conducted where a firm
identifies that data sharing is necessary, where sharing should be fair
and lawful (lawful basis and providing privacy information), where
only the minimum amount of information necessary for the purpose
is shared, and they document their decisions for sharing the
information.
What do firms need to remember?
From the outset, firms need to know:
 the GDPR does not stop data sharing,
or create additional barriers
 there are often clear benefits in data
sharing (when correctly planned)
 consent is only one basis on which
data can be shared (although it may
be the simplest and clearest)
 data can always be shared in a true
customer emergency situation
 but whatever approach is taken,
firms always need to assess whether
data really need to be shared.
To assess whether disclosed vulnerability
data need to be shared (and if so, how to
do this), every firm should:
 conduct a thorough Data Protection
Impact Assessment (DPIA) where it is
necessary to do so6-7
 have a data sharing agreement in
place with the external organisation
(if data-sharing is a regular event)
 ensure these comply with the key
GDPR and DPA principles and rights
(including fairness and transparency)
 have a lawful basis for processing
personal and special category data
 be aware of any additional steps
needed to process law enforcement
data, or data regarding children.
In this section, we will not re-describe
the principles and rights of the GDPR and
DPA (these are dealt with in Guide 1).
Similarly, the lawful bases for processing
will not be covered (see Guide 2).
Instead, we will focus on what a DPIA
should cover, and what thinking firms
need to do for vulnerable customers.
21
Should we share data?
Before deciding to sharing data, firms
should ask themselves the following
practical questions about data sharing.
These questions fall into five groups.
Group one: aims and definitions
 what is the aim of sharing the data?
Firms need to be absolutely clear
what the specific purpose of data-
sharing is, and be able to justify this.
 what information needs sharing?
Firms must be able to explain exactly
what data they need to share, rather
than offer broad/vague descriptions.
Firms should only share the absolute
minimum of the most relevant data.
Group two: risks
 what risks does sharing pose?
Firms need to outline the risks that
sharing customer data might pose.
This could include customer exposure
to harm (physical, emotional, social
or economic), customers being likely
to object to processing, or customer
trust in a firm being undermined.
Measures must be put in place to
mitigate these risks.
 is it possible not to share data?
Firms must be able to show that they
couldn’t achieve their purpose for
processing without sharing the data.
If this is not possible without sharing,
they must explain why anonymised
data could not be shared instead.
 is it ‘right’ to share data? Firms will
need to consider both the benefits
and risks of sharing customer data
(both for the customer, the firm, and
wider society). Data sharing should
be proportionate to the objective for
processing.
22
Group three: legal basis
 are we allowed to share the data?
Firms will need to check if there is a
statutory bar or other restrictions on
data sharing.
 do we have a basis on which to
share the data? Firms will need to
establish what processing basis they
will use to share both personal and
special category data that has been
disclosed to them.
Group four: practical mechanisms
 who requires access to the data?
A firm’s policy should make it clear in
who – in the external organisation –
will have access to customer data. As
always, data should be shared on a
‘need to know’ basis. This means
only relevant staff in a firm and the
external organisation should have
access to the data.
 when should we share the data?
Firms will need to describe in what
circumstances disclosed vulnerability
data will (and will not) be shared.
It is important for firms to make it
clear whether data sharing will be a
routine activity, or a ‘one off’.
 how should we share the data?
The mechanism and process for
sharing should be described in a
firm’s data and vulnerability policies.
This should include appropriate
security provisions.
Group five: evaluation and refreshing
 how can we routinely check our
objectives have been achieved?
Firms will need to demonstrate
whether the actions taken have
achieved the purpose for processing.
They will also need to explain how
they will repeat the DPIA to ensure it
is current and up-to-date.
Considering vulnerability  emergency situations – firms should
To ensure a firm considers vulnerability identify scenarios where vulnerable
when thinking about data sharing, firms customer data might need to be
should pay particular attention to: shared in an emergency situation.
 the lawful bases for processing – This is not only about identifying
in Guide 2, we explained how firms which situations might arise, but also
could use a ‘vulnerability lens’ to being clear on what data would best
both choose a suitable processing be shared when these occur.
base, and also ensure that it was
used in a way that recognised any Summary
additional needs that vulnerable In this section, we have considered the
customers often have. factors a firm should take into account
prior to sharing vulnerability data with an
 the GDPR and DPA principles and external organisation.
rights – it is critical that firms always
remember that ‘data processing’ is a In doing this, firms should be aware of
term that covers all aspects of data the risks of data sharing – and always try
collection, use, storage, and sharing to prevent or minimise these.
(see Guide 1). Consequently, firms However, firms should not let any of this
need to think carefully about how the totally overshadow the benefits either,
principles and rights of the GDPR and as not sharing data in itself can also be
DPA are complied with in relation to harmful.
sharing vulnerability data.
As with the ICO says itself, firms should
 remembering that they are sharing weigh-up both these risks and benefits,
real data, from real people, living and take into account firm and customer
with real problems – therefore these interest.
individuals will be concerned with
And this can only be done through
these difficulties and problems,
careful planning and discussion which
rather than reading or searching out
involves the perspectives of the Data
a firm’s data protection policies.
Protection Team and Vulnerability
Firms therefore must put themselves
Specialists being considered.
in the shoes of their most vulnerable
customers and ask: would I expect
my data to be shared in this way?
Am I getting a clear explanation of
how my data will be shared? And
would I say I am being treated fairly?
 establishing how individual rights
will be upheld (where relevant)?
Customers have the same rights
(including those to access, being
informed, erasure, and objection) as
with any other part of processing.
Firms need to ensure these are
addressed, and also upheld in any
data sharing arrangement.
23
PART B: USING VULNERABILITY DATA

11. Using data to support individuals

12. Using aggregate data for monitoring
13. Using data to achieve good outcomes

24
11.Using data to support individuals
What is critical to remember?
Our purpose for processing vulnerability
data is ultimately to help our customers.
Therefore no matter how well-designed
or DPA compliant our processing may be,
how we practically use this data is key.
In this section, we briefly consider how
firms can turn customer data into action,
and aggregate insight into intervention.
And we also point to other resources
that firms can use to achieve this.
What should we do?
Firstly, supporting a vulnerable customer
requires a firm to establish exactly what
difficulty a customer is vulnerable to?
As explained in Guide 1, this can include:
 acting on specific problems that directly
make it harder for a customer to fairly
choose, purchase, access, use, talk
with, complain about, pay for, or
benefit from a product or service
e.g. customers who may not be able
to communicate their needs or access
additional explanation or information
 acting on problems where a customer
has a support need that goes beyond
what a firm can offer, and where
signposting, referral, or partnership with
an external specialist agency is needed
e.g. customers who have physical or
mental health problems that require
specialist health care interventions
 acting on problems not directly related
to a product or service, but where these
require a firm to adjust their practice
e.g. customers disclosing suicidal
thoughts or behaviours not related to
a product, but where a firm needs to
tailor future interaction and contact.
25
Secondly, to achieve this, staff need to bring
together all the information they have on a
customer’s vulnerable situation, alongside
any key financial activity data including:
 information from customer discussions:
 often captured using tools such as
TEXAS or similar protocols
 stored in vulnerability flags, support
need codes, and account notes
 additional evidence provided by a
customer (e.g. Debt and Mental Health
Evidence Form, or similar written letters)
 evidence provided by an authorised
third-party (e.g. debt adviser/customer
with power of attorney), or a third party
without authorisation (e.g. temporarily
captured using the CARERS tool)
 financial activity information such as
income and expenditure data.
Thirdly, staff and firms need to use these
data to decide on their practical response:
a. what standard actions are open to us?
(i.e. those we’d take for any customer)
b. will these standard actions help address
the problems a customer has disclosed?
(i.e. how might these help ‘as is’?)
c. what adjustments to standard practice,
or entirely new actions, would help?
(i.e. what changes need to happen?)
d. if making an adjustment, what needs to
happen during the current customer
contact, directly after, and in the future?
Lastly, firms then need to take action for
that individual customer (and in doing this,
record any relevant information about this,
so that any adjustments or actions are not
forgotten or overlooked).
 FIGURE 7

What is the customer What information can

vulnerable to? we bring together?

What standard
options are What are the ‘Business as Usual’ actions that we can take
open to us? with any customer (not just those who are vulnerable),
Will these help and which might address the difficulties a customer is facing.
the customer?

What
adjustments  Take more time  Minimise the amount of
 Use simpler language paperwork to complete
could we  Offer reassurance about
 Find a better time of
make? day to make contact how a customer’s
or  Allow contact through information will be used
an alternative channel  Work with a 3rd party
What new  Use the BRUCE tool to  Signpost to specialist
actions could support decision making external services
we take?

What action
is needed:
- now?
- in the future?

Take action Record relevant

information

26
12.Using aggregate data for monitoring
What is critical to remember?
The FCA has clear expectations about
using data to both understand customer
needs, and monitor activity over time:
“Firms should understand the nature
and scale of drivers of vulnerability… in
their target market and customer base.”
“Firms should understand the impact
of vulnerabilities on... consumers.”
“Firms should implement… processes to
evaluate…where the needs of
vulnerable consumers are not met, so
they can make improvements”.1
To do this, firms can use aggregate data
– key indicators pooled together from
multiple customer cases – to provide the
management information required.
What aggregate data do we need?
KYVC (know your vulnerable customers)
Firms need to have basic data indicators
in place to describe their (known)
vulnerable customer base.
This includes the:
 number of vulnerable customers
 what the customer is vulnerable to
 causes of vulnerability (FCA drivers)
 main types of support need.
Here the causes of vulnerability include
the four ‘drivers’ identified by the FCA
(health conditions, life events, financial
resilience, and financial capability), as
well as other causes that a firm wishes to
capture (e.g. mistakes made by a firm,
or wider economic or social conditions).
Critically, firms need to have indicators
that describe support need, and whether
these needs have been successfully met.
27
Specific products or features
Some firms will have developed products
or features that are specifically designed
with vulnerability in mind.
These may include, for example features
in a banking app that allow customers to
self-disclose a vulnerable situation.
Or they may involve a ‘gambling blocker’
mechanism on a current account that can
be activated by a customer to prevent
expenditure on gambling activities.
Whatever the additional feature, firms
will want to establish basic metrics
around their use, as well as their impact.
Data protection indicators
It can be useful – as Guide 2 notes – if
firms know how many customers have:
 refused consent
 withdrawn explicit consent
 been unable to give explicit consent.
Firms will also want to record when they
have been unable to obtain such consent
(e.g. customer was not contactable) and
another processing base was used.
Taking these steps will both meet the
GDPR accountability principle, and allow
firms to establish just how prevalent
consent refusal and withdrawal is.
Other indicators
Firms may also wish to use other data
indicators to monitor their treatment of
vulnerable consumers for the ten
examples set out by the FCA (Figure 8).
Outcome data
In addition to describing the key actions
taken with a vulnerable customer, firms
will want to also record their outcomes
(what difference the actions made), and
we address this issue in the next section.

“Firms should
produce, and
regularly review,
management
information,
A. QUALITY
appropriate to ASSURANCE
the nature of its
business, regarding
the outcomes for
Establishing quality
vulnerable
assurance processes that
consumers.” identify areas that require
improvement.
D. STAFF E. COMPLAINT
FEEDBACK CHANNELS
Allowing staff to feedback Ensuring it is easy for
anonymously when they vulnerable consumers to
think processes for make complaints, and
vulnerable consumers through multiple
could be improved. channels.
H. FEEDBACK
Use feedback that may
not be directly sent to the
firm, including online
reviews and social media
complaints.
28
B. CUSTOMER
EXPERIENCE
Testing experiences of
vulnerable customers
through processes such
as mystery shopping,
auditing, focus groups
and deep dives.
F. EVALUATE
IMPACT AND
OUTCOMES
Using information on
firm’s treatment of
vulnerable customers and
the customer’s
experience to help inform
understanding of
effectiveness of policies,
processes, training and
controls in place.
I. DEEP
DIVES
Select particular products,
processes or types of
vulnerability for ‘deep
dives’ to help better
understand where to
focus its services or make
improvements.
FIGURE 8
C. REVIEWING
POLICY
Reviewing whether
processes and policies are
effective in the fair
treatment of vulnerable
customers.
G. PRODUCE
MANAGMENT
INDICATORS
Provide Senior
Management or the
Board with reports on
progress and provide
challenge where
appropriate.
J. USE
MANAGEMENT
INFORMATION
Producing MI that
captures outcomes for
vulnerable customers,
and making sure it is
discussed regularly at an
appropriate level, and
escalated and acted on
where necessary.
13.Using data to achieve good outcomes
What is critical to remember?
When it comes to vulnerability, the FCA
is clear on what firms need to achieve:
“[vulnerable consumers should]
experience outcomes that are as good
as those of other consumers” 1
Consequently, firms need to consider
what outcome measures are of the most
use in making such comparisons.
What is an ‘outcome’?
In simple terms, an outcome is either a:
 change (something happened)
 no change (nothing happened)
 that flows from a specific firm action,
policy or intervention.
Customer outcomes
Outcome measurement focuses on
whether a change took place (or not).
This might involve a customer turning on
a ‘gambling block’ on their banking app,
or never using this function at any point.
It could feature a customer keeping to a
repayment plan following a conversation
with their creditor, or failing to do this.
Or it may involve a customer registering
a complaint about the introduction of a
new design for account statements.
What is key here is that a firm considers:
 whether a specific action – such as
introducing a new process – results in
defined change at the customer level
 whether customers in vulnerable
situations are negatively affected or
disadvantaged by this (compared to
customers who are not vulnerable).
To do this, firms need to be clear on how
they define their outcome measures,
and also what they expect to happen.
29
What outcomes should we use?
It is beyond this guide’s scope to list all
the outcome measures firms may use.
Instead, a firm’s outcome choices should
hinge on the products and services they
offer, and the processes they operate.
In doing this, firms will need to consider
the changes they want to see (or might
expect to see) in customer activity.
Firms may also want to build some of
their measures around the six consumer
outcomes the FCA places at the heart of
treating customers fairly:1
a. consumers can be confident they are
dealing with firms where the fair
treatment of customers is central
b. products and services… are designed
to meet the needs of identified…
groups and are targeted accordingly
c. consumers are provided with clear
information and...kept...informed
before, during and after..point of sale.
d. where consumers receive advice…this
…is suitable and takes account of
their circumstances
e. products perform as...consumers
expect, and…the…service is of an
acceptable [and expected] standard
f. consumers do not face unreasonable
post-sale barriers…to change product,
switch provider, submit a claim or
make a complaint.
These provide a starting point for data
collection, and comparison between
customers, rather than a last word.
Similarly, where data are collected, firms
may wish to consider any differences in
outcomes that exist between different
groups of vulnerable consumers.
PART C: ENCOURAGING DISCLOSURES

14. What is a disclosure environment?

15. How do we build one?

30
14. What is a disclosure environment?
What is critical to remember?
When developing a vulnerability strategy,
firms can often find themselves thrust into
immediate discussions about identification.
This often starts with how staff can ‘spot’
signs of vulnerability, shifts into the ethics of
using transaction data, before ending with
the challenge of self-serve online platforms.
However, while identification is a key pillar
of any strategy, it is never the only pillar.
Instead, firms should consider the ‘lines of
defence’ that lie before identification, and
how these can help vulnerable customers
(Figure 9).
In this section, we explain how disclosure
environments can provide such a ‘line’.
. messages, information, and signals about
“a disclosure environment involves a
firm actively designing its processes,
practices, and communications to
encourage and help consumers tell the
firm about any relevant situation
making them vulnerable to harm, and
where the consumer is shown not only
why they can trust the firm with this
information, but also the specific
benefits such a disclosure could bring”
31
What is a disclosure environment?
Disclosure environments are based on three
simple and linked premises:
 it is often easier for a customer to tell a
firm about their vulnerability, than it is
for staff or a process to identify this
 customers will be more likely to make
such disclosures when firms give clear
signals, explanations, and reassurance
about how their data will be used
 to give these clear signals, firms need to
understand the barriers that currently
deter their customers from disclosing.
Consequently, disclosure environments are
about more than providing a one-way ‘pipe’
into a firm for consumers to share detail.
Instead, they also involve a firm sending
the process and benefits of disclosure.
To illustrate what this practically looks like,
this section presents three different
models of disclosure environments.
It then describes some of the key factors
firms interested in developing their own
disclosure environment should consider.
The section then concludes with thoughts
on the overall strengths and limitations of a
disclosure environment approach.
 FIGURE 9

Accessibility – firms must ensure this involves a firm engaging in

A vulnerable customers can equally proactive and inclusive design so
access their products/services. customers don’t need to ask for help.

DE Disclosure Environments – firms this involves customers taking the step

must make it easy for customers to disclose, and firms sending
to disclose their support needs. reassuring signals about disclosure.
Identification – firms must work
I
across all their channels and data this involves a firm working across its
to identify vulnerable customers. audio, physical, and digital channels to
identify, engage, understand, and
E Engagement – firms must ensure
support customers.
staff can move from identification
to ‘cold’ starting often quite
sensitive conversations.
DM Disclosure management – firms
need to handle disclosures with
practical and compliant tools.
Understanding – firms need to
U
listen and establish the relevant
information to help a customer.
Support – identification and
S understanding that does not lead
to the reasonable provision of
support is a hollow process.
Recording – firms need to record
R
the absolute minimum of the
most relevant data for action, in a
clear, transparent, and fair way.

Internal support – where needed,

IS
a firm should signpost to internal
specialist support.
External support – where needed,
ES a firm should signpost to external Firms cannot do this alone – there will
services providing specialist help be limits to their expertise and
and support that a firm cannot. responsibilities, and they need to work
with external agencies when these
Monitoring – firms should limits are met.
M monitor a vulnerable customer’s
situation, respond to changing Vulnerable situations change over time
need, and keep data up-to-date. – firms therefore need to watch and
monitor a customer’s situation
32
15. How do we build one?
Where do we start?
Before starting to build a disclosure
environment, firms need to understand the
reasons for consumer non-disclosure.
Understanding these is key in a firm taking
steps to address any barriers to disclosure
within their own processes and systems.
Understanding the barriers
Firms can start by:
 reflecting on what they already know
about their customer base, journeys,
information, and contact channels.
This involves reviewing whether any
aspect of these may deter or prevent a
customer from disclosing a vulnerability.
In particular, firms should think about
the signals being sent to customers
about how to disclosure, the benefits
of doing this, and to reassure them
about any perceived risks.
 drawing on research on what is already
known about vulnerable customers
and disclosure.
In 2016, for example, the Money and
Mental Health Policy Institute ran an
online survey with 5,413 people with
experience of mental health problems.8
Participants were asked if they had
disclosed their mental health problem
to any company that they owed money
to (including organisations within, and
outside of, financial services).
The study found that out of nearly
4,000 participants answering this
question, eight-out-of-ten reported that
they had not disclosed this information
to a creditor (78%; 3027/3901).
8. Money and Mental Health Policy Institute (2016). In Control.
33
Critically, when asked why they had not
disclosed, participants reported:
 they weren’t aware it would make a
difference (60%)
 disliked telling people about their
health problems (55%)
 felt they would not be treated
sensitively/sympathetically (52%)
 were concerned how the
information would be used (40%)
 were worried that disclosure would
affect future access to credit (35%)
 thought they wouldn’t be believed
(31%)
 thought they’d be treated unfairly
(30%)
 were concerned that any debts
would be repaid from benefits (7%) .
Critically, each of these represents a
potential barrier to disclosure.
However, firms who understand this
may be able to address, prevent, and
ultimately over-turn these barriers.
To do this, firms will need to directly
address the concerns customers have
about disclosure, and counteract these.
By offering clear explanation and
reassurance about how exactly the
information they have shared will be
practically used, these perceptions may
be overcome.
 learning from the actions taken by
other firms to encourage disclosure.
Figures 10, 11, 12, and 13 (following
pages) describe four different models
that the financial services sector are
adopting or developing to encourage
disclosure and facilitate support.
FIGURE 10
Launched in September 2018, the ‘share with us’ initiative
aims to give the over 4.6 million customers of Monzo
bank a simple, direct, and always available mechanism to
disclose “any situation – temporary or permanent – that
affects the way you manage your finance”.
Offering its banking services via a mobile phone app, this
mechanism allows customers to provide a free-text
description of their situation to Monzo at any time of day.
This goes directly for review and potential response to
Monzo’s Vulnerable Customer Team (who can direct the
customer to guidance or resources to help with their
situation, or where a more detailed conversation can
begin via chat or an accompanying telephone service).
While one aim of the ‘share with us’ initiative is clearly to
make it simpler for customers to disclose a vulnerable
situation to Monzo, considerable thought has been given
in the initiative to the way the new function has been
presented and introduced to customers.
This is reflected in the language used within the banking
application which aims to normalise and de-stigmatise
disclosure.
The feature is located within the help function of the
Monzo app, and customers are also guided to it if they are
reading a relevant help article (see Monzo’s ‘helping us
understand your needs’ - https://monzo.com/help/your-
needs).
Monzo has gradually introduced the service and tested its
operation and with time, plans to evaluate whether this
‘share with us’ mechanism could be introduced as part of
the onboarding/application process for new customers, or
through other more prominent sections in its app.
Much of this will clearly depend on the capacity of the
Monzo Vulnerability Team to deal with the volume of
incoming disclosures. The team speaks to around 100
customers a day, and disclosures through ‘share with us’
make up around 16% of this.
The top three disclosure types that come through ‘share
with us’ for Monzo relate to financial difficulties, mental
health and gambling addiction, though there has been an
increase in its use to disclose financial and domestic
abuse, since it’s a safe form of communication to the
team that leaves no trace in the app.
34
How do we get buy-in? There are no specific data that relate to
While often recognised as a ‘good idea in this issue and disclosure environments.
principle’, firms can be discouraged from However, research has been conducted
building their own disclosure environments with front-line debt collection staff
by underlying management reservations. about consumers using vulnerability as
Recognising these from the outset is an excuse or ‘card’ to gain advantage.9
therefore key as it then allows firms to take This found that in 2016, 5% of staff felt
a ‘test and learn’ approach where concerns ‘many customers’ claiming to have a
about, for example, capacity to handle an mental health problem were disclosing
increase in the volume of disclosures can be this as an excuse to avoid repaying debt,
quantified to establish their actual (rather compared in 2010 to 14% of staff (in the
than feared) impact on operational activity. same set of financial service firms).
Among the most common reservations that While this tapered perception over time
firms may encounter include: may reflect shifts in societal perceptions
 concerns about a spike in the volume of on mental health, it is also likely that the
disclosures (including disclosures not now well established programme of
relevant to a firm’s core business, or work on vulnerability and encouraging
their ability to support a consumer). disclosure within the financial service
sector has also reassured staff about
While understandable, firms can consumers ‘gaming’ the system.
counter such concerns by gradually
introducing mechanisms for disclosure  fears about consumer expectations,
into their operation, or testing these and staff ability to meet these – firms
mechanisms with a subset of consumers often have fears that introducing a
(rather than the whole consumer base). disclosure environment will raise the
expectations that consumers will have
This approach is reflected in the work of the support that can be given.
that Monzo took in placing their ‘share
with us’ feature within the help function However, as seen in the Barclaycard
of their banking app. This allowed the example in Figure 11, clear messaging
feature to be evaluated and further about both what help can be given by a
resources developed to support firm, and what support can be provided
customers who disclosed (including by external partners, can help to
filtering-out irrelevant disclosures), counter-act this.
before deciding whether to move this  the need for perfect solutions to be in-
into the central onboarding/new place, rather than a ‘test and learn’
customer application stage. approach – firms can be dissuaded from
 worries about consumers using such introducing a disclosure environment
mechanisms to ‘game’ the system – approach by the view that they need to
fears that consumers who are not in a introduce a perfectly and fully designed
vulnerable situation will make use of environment from the outset.
disclosure mechanisms to gain an However, adopting a more gradual ‘test
advantage of some form are a concern and learn’ approach is likely to be more
among some firms. beneficial, in terms of understanding

9. Fitch C, Evans J, Trend C (2017). Vulnerability: a guide for debt collection.

www.moneyadvicetrust.org.uk/vulnerability 35
FIGURE 11

Launched in 2017, the Barclaycard ‘Money Worries Hub’

focuses on the signals that the organisation gives to
customers who are in a vulnerable situation due to
financial difficulty and other factors.
Critically, the Hub aims to reassure customers that taking
steps to disclose their vulnerable situation, and seek help
as early as possible, would result in concrete benefits.
Barclaycard recognised that a gap existed in its current
suite of resources, and what was needed was a resource
that wasn’t just about ‘reading information about the
importance of making contact’ but which made customers
aware of how people like them had been helped.
Consequently, Barclaycard worked with its customers and
external partners to develop the ‘Money Worries Hub’
which highlighted common situations that customers
might experience ranging from job loss and relationship
breakdowns to bereavements and medical conditions.
Each of these vulnerable situations – such as Carl’s
experience of unemployment - is presented in a ‘story’
format outlining the difficulties that customers might
face, but importantly walking through each of the actions
Barclaycard will take when a disclosure is made to them.
Importantly, each of these also recognises the fears and
concerns that customers have about sharing information
like this with Barclaycard, with an emphasis being placed
on addressing these fears and explaining the benefits of
what will happen if a customer makes a disclosure.
Throughout the Hub, this format is key to encourage
customers to disclose and share their circumstances and
difficulties, and making them aware that Barclaycard has
helped people in similar circumstances before.
In doing this, Barclaycard are doing more than simply
providing a number of ways in which to make contact
with them, but instead have actively worked to create an
environment in which customers feel secure and
reassured that disclosure will have positive benefits
(rather than punitive consequences).

36
 ‘what works’ for a firm’s consumers, and
managing demand and capacity to meet
disclosed need.
 does our firm have a strong sense of
the different internal support options
that can be offered to consumers who
do disclose?
Clearly, this not only applies to specific
disclosure environment approaches, but
also more generally to any disclosure of
vulnerability that is made by consumers
to a firm.
This is dealt with in more detail on page
14 (‘Support codes’) which refers to
wider guidance on support, and also
covers anticipating and meeting
consumer support needs.
 what signals and messages about the
process and benefits of disclosure can
we send to our consumers (and how
will we achieve this)?
As noted earlier, the messages that are sent
to consumers about the process and
benefits of disclosure are key.
However, these signals can be given via a
range of channels and can begin before the
consumer even gets in contact – written
reassurances on websites, leaflets and
posters, for example, can be used to remind
consumer at an early stage that all
situations are up for discussion.
Furthermore, small reminders and ‘nudges’
from staff in routine correspondence or
conversation with consumers can also
reinforce this (e.g. “is there anything else
that you’d like to tell us about your
situation”, or “are there any health or other
issues we should know about, as we will
treat these confidentially and they will help
us to provide you with a better service?”).
37
Summary
The introduction of a disclosure
environment approach is premised on the
simple rationale that it is easier for a
consumer to tell a firm about a vulnerable
situation, than it is for a staff member or
process to identify this.
As we have also seen, such environments
can only work where they recognise that
consumers will only share such information
if firms understand the known barriers to
disclosure, and offer clear reassurances
about the risks that consumers perceive
from talking about their vulnerable
situation.
Where implemented, firms have reported
that consumers will voluntarily disclose
information about their situation that was
not previously known.
Furthermore, sending clear signals to
consumers about the process and benefits
of disclosing different situations is vital.
While disclosure environments cannot
represent the whole of a vulnerability
strategy (particularly given that some
consumers will be unaware of their
vulnerability to harm – as is the case with
consumers with undiagnosed mental health
problems ), an accompanying proactive
identification strategy is also vital.
However, the development of disclosure
environments (on a ‘test and learn’ basis)
provides an opportunity for firms to add
another tool to their battery, make a clear
public statement that they recognise the
realities of their lives that many of their
consumers are living (and are willing to
listen, and take these into account where
the option exist), and most importantly to
reach consumers in vulnerable situations
who may have previously been unknown to
the firm.
FIGURE 12

Firms often overlook the opportunities for self-disclosure

afforded by the onboarding process.
Not during an application
It would be optimistic to expect a potential customer to
disclose either a vulnerable situation or support need
during an actual live application for a product or service.
This is because a customer is probably not going to want
to share any information they perceive might be used as a
basis to decline their application.
Welcome onboard!
However, once a firm has decided to accept a potential
customer’s application, an important opportunity arises.
Here, it is possible to give a customer the opportunity to
share any relevant support need or important information
about their situation.
This can include a free-text box for a customer to
complete, or a selection of fixed-choice support needs.
Knowledge from the outset
Critically, taking this step can help firms to understand
their vulnerable customers’ needs from the outset – and
this will help enormously in service design and delivery.

Welcome to Your Card!

Patrick is there anything you’d like to share?
Your new card and account are now approved.
But we’d like to give you some extra help (if you want it).
Is there anything that affects the way you manage your
money, or how you might use your new card?
This could be something that makes managing money
difficult, makes it harder to communicate with us, or
where you might need someone else to help you.
A lot of our customers tell us about these things, and we
always try to help them, so please do share with us.
SHARE WITH US HERE:

38
FIGURE 13

The WelcoMe customer service assistant was launched in

2018.

WelcoMe puts the customer in control of the information

they disclose to the venue staff relating to their disability
and any access and communication requirements.

Allowing this disclosure helps to create both foundational

relationships and personalised and empathetic customer
service interactions.

WelcoMe uses a visitor’s mobile phones location services

to provide the venue they are visiting with personalised
accessibility information. This includes an image of the
consumer, and information on the condition the visitor
would like the service team to have awareness of.

It also offers the venue top tips on interaction, prior to

the arrival of the customer. The user can add additional
specific information for their visit on that day along with
any additional information required (i.e. the need for a
ramp, an interpreter, a hearing loop etc. It can also be
utilised to provide information on the latest COVID
procedures and service provision).

WelcoMe is provided as a cloud based solution for venues

and the user information is retained within the user
profile and only shared with venues when the user has
planned a trip to a specific branch.

This enables the user to be in full control of when and

with whom they share their support needs.

Once a visit has been completed the user information is

retained by the user for future visits and the venue access
to the users data is removed until the next visit.

In this way, WelcoMe is also used as an internal staff

training tool by providing staff with direct access to
information covering a wide range of disabilities and
conditions. This information is contained within the CMS
and is provided by relevant charities.

Currently the app is installed across the UK in venues that

include NatWest, Edinburgh Airport, Deloitte and Diageo
the platform is gaining traction and seeing more users and
venues start to use the platform.

39
PART D: SUMMARY

16. What should we do next?

40
16. What should we do next?
In this guide
In Guide 3, we have considered the
choices faced in recording vulnerability
data, using vulnerability data, and
encouraging vulnerability disclosures.
Data processing
We have described why firms need to
work to collect the absolute minimum of
the most relevant data for action.
We have explained why firms should use
a trinity of multiple vulnerability flags,
support need codes, and contextual
account notes to record data.
And we have explored why firms need a
‘retention rule of thumb’ (so any data on
vulnerability remains accurate, relevant,
and still of practical use when needed),
and the role of Data Protection Impact
Assessments when sharing data (both
externally and internally).
Data use
Importantly, Guide 3 has also looked
more broadly and considered how firms
can best use data to help individual
customers, and also ensure they really
Know Your Vulnerable Customers.
Data generation
Finally, Guide 3 has also looked to the
future and underlined the importance of
firms actively encouraging disclosures of
vulnerability to them.
This involves disclosure environments
being developed that make it simple for
customers to tell firms about a support
need, and send reassuring messages,
signals and explanations to customers
about what will happen to their
information if they did disclose to a firm.
41
Where next?
There are currently three guides in this
series on GDPR and vulnerability.
While firms should work to apply the
content of these guides to their own
challenges, others should look to fill the
gaps in what has not been covered.
This includes the need for guidance on
processing criminal offences data, for
using transaction data to identify both
financial and non-financial vulnerability,
and also ensuring that data protection
processes comply with the Equality Act.
This guidance should come from
partnerships between firms and charities
working with vulnerable people, as they
will know the challenges posed in both
commercial and personal terms.
What is critical to remember?
Our final message is a simple one.
Firms should always remember that the
data we want to process always comes
from real people with real problems.
Consequently, these customers will be
more focused on solving these problems,
rather than invested in reading our
privacy notices or leaflets (no matter
how carefully worded).
These customers will often also be less
aware of the rights and principles of the
GDPR than ourselves, and may also need
additional help to follow our processes.
For this reason, we have to ensure our
GDPR policies have an understanding of
vulnerability running right through them.
And such an understanding can only
come from Data Protection Teams and
vulnerability policy specialists working
together, rather than – as is the case in
many firms – in separation.
 This is a joint publication from the Money Advice Liaison Group and the Money Advice Trust.

© November 2020

The moral right of the authors has been asserted. All rights reserved. Without limiting the rights under
copyright reserved above, no part of this publication may be reproduced, stored or introduced in a retrieval
system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording or
42
otherwise), without the prior written permission of both the copyright owner and the publisher of this report.