Pensions Dashboards – could there be a sting in the tail for the DB pensions world?

One of the challenges for the Government in designing a pensions dashboard is meeting the needs of the public without imposing unnecessary burdens on pension schemes (and other pension providers).

To limit the cost burden on schemes, the Government has stipulated that (initially at least), schemes will only be expected to show: “at maximum, the information already available on annual statements, or on request”. [1]

At first glance, this would seem to be a reasonable and minimalist requirement of schemes. Pension schemes are already subject to so-called ‘disclosure regulations’ which set out the information which has to be supplied to members. If the new dashboards only display data that is already required, what could be simpler than that?

However, the crucial missing phrase which should have been added is “… and in a specified format” and a multi-million pound bill could sit behind those innocent-sounding words.

It is one thing to have to set up an infrastructure to supply a dashboard, on request, with data that is routinely prepared for annual statements. But there is data which is not routinely prepared – especially for deferred members – which will be required by dashboards, and even data which is currently supplied may need to be re-presented. Putting in place structures to prepare this data on demand for all members, active and deferred, could be a much bigger job and one that many schemes are not currently ready to undertake.

The key example of data in this category would be what the Pensions Dashboard Programme refers to as “expected retirement income” (ERI). In its working paper [2] on data definitions the Dashboard Programme says that its research has found that ERI is:

“the most important piece of information about each pension that many individuals would find useful” (para 62)

It goes on to say that because dashboards themselves will simply present the data they have been sent (rather than undertake their own projections or manipulate the data in other ways):

“This means that, for each pension found, pension providers and schemes must supply an estimated retirement income (ERI)” (para 63).

The definition given of ERI is:

“An estimate of the amount of money the individual might receive in retirement, in today’s money terms”.

The consultation document explains that for active members this will simply be “..the prospective annual retirement income that appeared on the individual’s latest annual statement (using current earnings)”. It might be assumed that this should not require any additional data processing or calculations by the scheme. But this would not be the right assumption.

At present, the information which schemes can provide on annual statements is subject to considerable discretion. To give one example, for active members, the trustees can choose whether to display pension based on service to date or based on continued service up to pension age. If the government decides that the dashboard should present the information in one way and the scheme routinely presents it in the other, considerable re-working could be required.

For deferred members, who account for more than four fifths of all DB members under pension age, the challenges could be even greater.

The document says that what is required is: “the annual pension at date of leaving, revalued to date”. Unless deferred members are routinely receiving this information, preparing revalued pension entitlement for deferred members will be an extra task, and one that for smaller schemes may not necessarily have automated.

Even for larger schemes, the process of re-presenting the data may be complex for ‘non standard’ cases. For example, how many schemes could easily re-present the pension rights of someone with a debit for divorce, a transfer in, a late retirement or a historical leaver whose service ended before statutory revaluation?

It is worth adding that the dashboard programme team recognise the complexity of DB rights and suggest that each ‘tranche’ of expected retirement income would be associated with a date at which the payment comes into force. However, this way of presenting data could be different to the way in which it is presented in annual statements, and this could further add to the cost of supplying data to the dashboard.

A further potential source of difference between schemes and the dashboard is the meaning of the “current value” of the expected retirement income. For example, if a member has GMP benefits which rise faster than inflation between now and retirement, should the ‘current value’ of the benefit take account of those guaranteed future real increases?

The key point is that different schemes may answer that question in different ways but the dashboard, which will present multiple pension entitlements side-by-side, can only answer the question in one way. If your scheme doesn’t already present the data in that way then you have a potentially expensive problem.

The July ‘call for input’ [3] on data definitions is seeking feedback on these proposals and the consultation is open until 31st August.

It would be hard to argue that all members should *not* be able to see their expected retirement income from past DB pensions on a dashboard. But it may be that the government is under-estimating the challenge for DB pension schemes in supplying data both in a standardised format and for some members where it is currently only available ‘on request’. I would encourage any scheme for whom this is likely to be a challenge to respond to the ‘call for input’ by the end of the month so that the dashboard programme has a realistic impression of what is involved. Trustees may also want to ask their administrators how much of a task this could be, and ensure they are prepared.

[1] See “Pensions Dashboards: Government response to the Consultation”, April 2019 and in particular Paragraph 157.

[2] See “Pensions Dashboards data definitions working paper”, August 2020.

[3] See: Pensions Dashboard programme.