My concerns over DB data and dashboard
Paul McGlone says let's start with the basics, re-unite members with their DB schemes, and provide some very basic information
In 1999, I ran a project to get a large defined benefit (DB) pension scheme online, showing members their personal data, their accrued pension, retirement projections and transfer values. It took over my life for the whole of that year.
One problem was the lack of reliable data, resulting in about 20% of the membership not having access to the system at all. But for me, the bigger problem was the complexity of benefits: six different accrual rates, ability to switch between them at will, regular changes in part-time hours, multiple retirement ages, and protected historic benefits of all sorts.
Some 20 years later, the thought of doing this for all DB schemes in the UK through the pension dashboard fills me with dread.
Don't get me wrong, I support the dashboard. Reuniting members with pensions is crucial. Having a single point where they can see them is absolutely the right thing to do and it's great that the consultation document issued last year recognised that DB schemes will need longer to get their data ready.
But while data is an issue for individuals and schemes, for the dashboard as a whole, the problem is how to describe DB benefits and how far to go.
To bring this to life, let me share with you the complexities just in the small selection of DB schemes that I advise:
- Contracted-out defined contribution (DC) scheme with an underpin that members will get no less than a contracted-in DB benefit plus the SERPS benefit they have lost;
- Substantial proportion of members affected by annual allowance, with scheme pays debit every year acting as an offset to their pension;
- DB scheme with three underpins, so members are no worse off than if they had left service and re-joined in either 1991, 1995 or 2018 (and any combination);
- DB benefits but an entitlement to transfer DC benefits from a sister scheme at retirement to pay for tax-free cash;
- Four different retirement ages depending on date of joining company and scheme, and over 15 varieties of DB TV-in benefit, with different normal retirement ages, revaluation rates and fixed pensions, all recorded inconsistently in the admin system;
- Paired schemes 6A and 6B, with each being separate trust, but 6B benefit determined by reference to 6A benefit, so 6B benefit cannot be known until 6A benefit is settled;
- Individual accrual rates for every member, depending on interaction of their age at joining and waiting period before they joined the scheme, merging into a career average revalued earnings (CARE) scheme;
- Scheme with massive gaps in data caused by paper records being accidentally destroyed many years ago.
That's just eight schemes, each with their own complications. To create a standard data extract that deals with just those eight would be a nightmare. Scaling it up to over 5,000 schemes really doesn't bear thinking about.
Yet, I still hear suggestions that ‘all we need to do' is agree a common format for data and make it mandatory to provide it. That's easy to say and undeniably it's possible. But like mapping human DNA or mining bitcoins, ‘possible' can at the same time be hugely complex, time-consuming and expensive.
Personally, I'm not convinced that trying to bring all of the detail of DB benefits into the dashboard would be time well-spent, and certainly not in the short term. I'd love them to be there, and over time it may be possible to grow what is available. But if that's the initial target we are set, then it will fail and if we let members believe that full details of their DB benefits will all be online in any reasonable timescales, then it is only likely to lead to disappointment.
So let's start with the basics - re-uniting members with their schemes, and some very basic information. But let's leave the massive complexity of describing benefits in detail for another day.
Paul McGlone is president of the Society of Pension Professionals
More on Admin / Technology
UPDATED: DB trustees must equalise GMPs in past transfers
Defined benefit (DB) schemes that provide GMPs must revisit and, where necessary, top-up historic cash equivalent transfer values (CETVs) that have been calculated on an unequal basis, a landmark court judgment says today.
FCA must stop DB transfer history repeating
Regulators must act now to impose some "proper regulation" to stop another defined benefit (DB) transfer advice disaster, saysTim Sargisson.
DB funds as an economic lever could derail schemes from responsibilities
Opportunities for defined benefit (DB) schemes to pursue investment approaches that help repair the UK’s economy cannot stand in the way of improving member outcomes, Aegon says.
DB transfer activity rises as 60% show signs of possible scams
More members transferred out of defined benefit (DB) pension schemes in October after September's record lows while values were surprisingly stable, according to XPS Pensions Group's Transfer Watch.
Funding negotiations in uncertain times
Joanna Smith says trustees will need to accurately identify if covenant issues are short-term affordability concerns, or the start of more material deterioration.
