Updated: Sep 22
We have covered at length the different types of vulnerabilities and the challenges in identifying them, but one question we frequently get asked is, how I record any identified vulnerabilities and what does good reporting look like?
To be honest, this is a tricky question to answer, as a clear view on what good reporting looks like is hard to find and the new consumer duty guidance has done little to ‘unmuddy’ the water.
There are obviously some vulnerabilities that are easier to record such as defined life events or health events, but others can become a lot trickier. Even health and live events can, in themselves, have very different impacts on your clients, dependent on their levels of resilience and capability. This then leads us onto how we record resilience and capability-based vulnerabilities, which in turn has its own set of challenges.
So where do you start?
A good place to start to make sense of this is to first revisit the challenges that exist in the identification of vulnerable circumstances — by addressing many of these challenges, ‘good’ recording of vulnerabilities should naturally follow. So, what are the fundamental challenges faced in identifying financial vulnerabilities?
Identification is highly subjective
Everyone has a different view on how their clients are impacted by a vulnerable circumstance, even if the same training has been received. There are multiple reasons for this ranging from differing levels of IQ, experience and even our own cognitive bias (we will get Tim to explore that in a later blog).
No consistent methodology
When working with clients to understand other factors around their views on planning matters, such as attitude to risk, a consistent methodology is usually used. However, this is often not the case when it comes to vulnerability. This leads to a range of subjective methods being used, even varying from one client to the next.
Inconsistently deployed identification
Good reporting needs consistency. Without it, an approach of when and who is assessed is going to lead to inconsistencies in identification. By only exploring with clients who you suspect may be showing signs of vulnerability is potentially going to leave a number being unidentified (see next point).
Cognitive based vulnerabilities are hard to spot and often well concealed
Tim often tells me that even professionals can find cognitive vulnerabilities hard to spot, as many people develop coping mechanisms and ways to hide certain mental health-based issues. This is also not something many would choose to share, regardless of how good their relationship is with their adviser.
Ultimately, all these factors lead to a lack of consistency in assessing vulnerability, which in turn, leads to a lack of consistency in recording and reporting. This also puts the burden of identification on advisers and client-facing staff, most of whom are not skilled or equipped to identify mental health-based triggers – and nor should they be.
How do we address this?
It goes without saying that a consistently deployed identification process and methodology is a key first step. This removes the inconsistencies and subjective approach many advisers use and gives us a base line to work to. Given most vulnerabilities are cognitive in nature (that is, based on mental health factors), it also makes sense that any approach taken has some mental health and clinical underpinnings.
However, we appreciate this is not always possible (unless our App is used, of course). So, in the spirit of supporting all those who read this blog, here are some key factors to consider when recording vulnerabilities:
Make sure you differentiate between a vulnerable circumstance and vulnerability
Good practice is to record all vulnerable circumstances and then whether this is having an impact on your client. For example, someone who is bereaved should be logged in all instances, but it is then important to understand what, if any, impact this is having on your client. Someone losing a distant uncle is very different to losing a lifelong partner.
Record each and every identified vulnerable circumstance
Vulnerabilities rarely exist one at a time; there are often groupings of vulnerabilities driven by one underlying factor. Therefore, you should try to identify all the vulnerabilities your clients might be experiencing and record each of these separately.
Vulnerabilities come and go
Understanding if your client has any vulnerable circumstances should not be a once and done exercise. The FCA make it very clear that vulnerable circumstances come and go, so your recording needs to take account of this. For users of our App, we recommend 4 touch points when it comes to understanding vulnerability:
1. New client onboarding
2. Annual review
3. Trigger based (this could be learning of a new health or life event, or a transactional event such as taking a further drawdown from an Equity release product)
4. The niggle – possibly, one of the most important. You know something is not right with your client but can't pinpoint what it is.
Record interventions and actions
With the regulators focus on outcomes, it is important to record what actions you have taken and any outcomes. Given my earlier point about recording each and every vulnerability, the same approach should be adopted here as how you support each vulnerability might differ and the timeframes involved are also likely to vary.
Log assessment against each and every client
It is very easy to only record where a vulnerability is spotted, however, this does not represent a systematic process, nor does it provide any protection against potential complaints where a vulnerability may have gone undetected (or indeed there wasn’t one, but you have no record to prove that). It is a lot safer to have a record against each client saying you have assessed for vulnerability, and none were detected.
So, in conclusion, a solid assessment process will negate many of the challenges associated with recording vulnerabilities and allow you to create a reliable record of vulnerabilities for your client base and, thereby, enable you to effectively meet any vulnerability reporting requirements.