Joining the vulnerabilities dots…

Customer vulnerabilities are a hot topic under Consumer Duty. The FCA wants better consumer outcomes for all customers, including those with a vulnerability.

Sharing information on customer vulnerabilities is one of the challenges to managing customer vulnerabilities and overcoming this would provide an important route towards better outcomes.

However, the sharing of vulnerability data is an area that needs to be treated with appropriate sensitivity and consideration for both customer privacy and the potential transient nature some types of vulnerability.  Yet, there are several ways to achieve improved visibility that have the potential to remove the onus from customers and support the wider industry in collaborating to achieve better customer outcomes.

Vulnerable customers, vulnerable processes

When we talk about customer vulnerabilities, it isn’t just the more obvious permanent vulnerabilities that are applicable to every interaction with the customer, but also transient vulnerabilities.

Transient vulnerabilities are temporary and may only apply to one interaction. They may not be applicable for the next interaction.  So, before we even get started on how best to support all customers, the baseline is constantly moving.

As an industry we know that identifying vulnerabilities and offering the relevant support is not straightforward – and this in turn has an impact on the customer in some form.

Firms tend to identify and capture support requirements manually. They use a marker or notes function in systems that can be easily missed the next time the policy is viewed. Worse, there’s an inconsistency across firms in the capture of information – perhaps born from fear of breaching GDPR and customer consent?

Different companies in different parts of the value chain identify and record vulnerabilities for their own purposes, without consideration for the wider customer journey. This creates blind spots. Each Company is effectively starting from scratch in determining additional support needs.

Is this right?  How can we better work together on this as an industry so that we can maintain, store and change this data?

How can the industry share data?

Across wealth and across industries we are currently working in silos. They are profoundly unhelpful.

Professionals in a firm might identify a vulnerability – recording and retaining that information only fir their own use and future interactions with that customer.

In future, when a firm identifies an additional support need for a customer, they could capture customer consent to share this with other firms.

For example, out of all parties in the value chain, advisers will spend the most time with the customer, getting to know them and making recommendations based on personal circumstances. KYC processes will capture vulnerabilities, but these may not be shared with the platform.

Provided the adviser has the customer consent to do so, why would this not be part of the process?

This would be a positive outcome for the customer – reducing repetition at the next interaction and minimising unnecessary difficulties with the interactions and service given by the next company.

It may not be appropriate to always share transient vulnerabilities. Yet, if the customer benefits, and is happy for the information to be shared, surely sharing helps to achieve the best outcomes.

Sharing data across the value chain can be done if the system capabilities support it.  As we know, application programming interfaces – APIs for short – are a massive enabler for this.

For those firms without such system capabilities, a consistent approach for recording and supporting vulnerabilities with best practice guidance could be a positive step, eradicating any uncertainty.

There needs to be a consideration for the relevance of the vulnerability identified, for example, an adviser may be aware of mobility issues when it comes to face to face interactions, but a platform with digital communication doesn’t need to account for this.  Coupled with different standards applied when identifying vulnerabilities, consistency in data capture is also a consideration that needs to be overcome.

A centralised register

One option to overcome this would be a centralised register that enables firms across the value chain to add and store support needs.  The relevance of the support required to the service being delivered can be discerned by the company, as a consideration of holistic customer needs and not just those relevant to the transaction being undertaken.

An example of where this works well is Utility companies.  There is a public register for those who need quicker support.  For example, an electricity provider will prioritise a customer with known medical conditions that rely on electricity where a power cut is reported.

The drawback with this system, however, is that if a customer wants to have their support needs recorded, the requirement is for the customer to log on to the register and add the details.

This is a good starting point but relies heavily on customers populating it.  Adapting it so that firms can also push and pull data from it, with connectivity options to suit different technology capabilities, could prove a real asset in supporting customers with vulnerabilities. It can also apply across financial services – not just wealth – thereby removing the need for customers to do this multiple times with multiple providers.

Moreover, a register broad enough to cover all financial industries, not a register-per-silo, would complement data sharing even further and see a collaborative approach to achieve the same goal.

We recognise that transient vulnerabilities may be more difficult to get right but tackling this one step at a time and focusing on what additional support customers may need rather than their vulnerability, could open the door to helping the more complex scenarios.

Changing the approach in this way alongside centralising customer needs has the potential to solve some of the GDPR challenges that could be experienced. For example, the fact that someone is blind isn’t actually important, what is important is that the customer needs braille / large print. If the register, focussed on these things then it would be much easier to apply across the industry.

This could be a material benefit to customers – and whilst a register would certainly need promotion, and investment, there are some existing materials we can build from such as the Vulnerability Recording Service (VRS) and the Experian Support Hub.  We urge the industry to start the conversation.