The point is that very few schemes have data that’s as good as it could be. Getting data in shape is too often seen as an expense rather than a benefit. I’ve never experienced any real push back on the need for fit-for-purpose data, until it comes to paying for it!
How good is good?
There’s also the question of how good does your data quality need to be? There’s a spectrum where, at one end, a scheme can limp along running lots of manual processes. This creates unnecessary expense and results in a slow service to members and no opportunity to go online. Getting a decent data cut to the actuary can also be a bit of a battle.
At the other end of the spectrum is squeaky clean data, which is good enough to transact with a buyout provider. At that point, data often gets to the top of the agenda. With an overheated buyout market, insurers can be picky and a scheme with holes in the data will be lucky to find any interest.
In between those two there’s a middle spectrum, where your data quality needs will very much depend on what you want to do with it.
It’s surprising how many schemes operate on a hand-to-mouth basis, where poor data is often the root cause. So, what does poor data look like? Well, aside from the obvious, such as gaps and missing information, it’s important to consider how the data is held, and where.
A paper record can be accurate, but it fails the test on accessibility. Many schemes hold the bulk of their data on their pensions administration platform, but may also have paper records or data sitting on spreadsheets. Whilst this approach may work now, it’s limiting and will soon run foul of the Pensions Dashboards Programme requirements. More of that later.
The art of the possible
Another reason that data doesn’t routinely get addressed is that many trustees are unaware of what you can do with fully ‘digitised’, clean data. For example, it’s entirely possible to automate 100% of benefit calculations on a modern defined benefit (DB) administration platform. If you can feed the calculation engine with clean data, that becomes a game changer.
As an example, let’s look at member self-serve. This has the potential to be transformational on two fronts. Firstly, members get the convenience of a modern financial services product. Whilst we know that online won’t be for everyone, it’s the direction of travel for almost every product and service now (apart from haircuts!).
The second tangible benefit is the cost saving. Allowing members to view their own benefits, update personal details and generally look after themselves, takes out substantial cost.
In the DB space in particular, I believe that trustees aren’t aware of what’s possible with good data and a good administration system. Defined contribution (DC) is a much simpler beast and is underpinned by more contemporary systems, but it’s still far from perfect.
The Dashboard driver
The Dashboard has been rumbling along in the background for so long that most people have discounted it. Think again. Now that it’s been included in the Pension Schemes Act 2021 and has a rollout timetable, there will be a legal requirement to improve data. Voluntary onboarding starts next year and staged onboarding in 2023.
Not rocket science
The Dashboard is an ambitious project, not because it’s rocket science, but because of the inability of many schemes to meet its requirements.
In essence, all it is seeking to do initially is allow someone to search across all UK schemes to find out where their pensions sit and to view basic information. To do that, a scheme will need to accept a message from a centralised identity service and determine if the data items match with any of their scheme records. The finder data items are basic, such as name, date of birth, address and National Insurance number.
There are two main problems. Firstly, missing or incorrect records. We talked about that already. Secondly, finder data that isn’t ‘digitised’. Losing the jargon, the data needs to be accessible in such a way that when the request is sent from the finder service, the administration system is capable of receiving it and interrogating all the member records.
The real killer for many DB schemes will be to return an estimated retirement income to a dashboard. It’s a lot simpler for DC, but some schemes may still struggle. For DB, the scheme will have to calculate and return an Estimated Retirement Income at normal retirement age.
So, back to where we started. Why can’t we have data good enough to automate benefit calculations and an administration platform capable of serving them up? It’s not rocket science, but it will be a giant leap for some schemes. Best get started now.
This article was featured in Pensions Aspects magazine May 2021 edition.
Last update: 14 May 2021
Salary: £50000 - £55000 pa
Location: London, Liverpool, Glasgow, Edinburgh, West Sussex, Exeter, Manchester
Salary: £65000 - £80000 pa
Salary: £26000 - £30000 pa
Location: County Durham