Pensions Dashboards: What will trustees need to do?

What will Trustees need to do How quickly? The hard bit Incomplete data

What will Trustees need to do?

Trustees will need to make sure their schemes can respond to the Find Message in real-time, seeking to match the customer attributes in the message across their membership. This requires schemes to have digitised architecture, or to use an ISP that can host their data for Dashboards purposes. The Find Message will typically contain:

  • Name
  • DOB
  • NINO
  • Address

A yes or no message needs to be returned. Where some of the attributes match, but perhaps an address doesn’t, a partial find is returned. This will allow the customer to investigate further.

The scheme will then need to return an ERI. For defined contribution (DC) schemes this is currently under consultation, but it will be the current SMPI basis or something similar.

Defined benefit (DB) schemes will need to take the pension at Date of Leaving (DOL) and revalue, by tranche, to NRD. This is also under consultation to see if a “simplified” calculation can be applied. So far, the simplified basis doesn’t look very simple!

How quickly?

If a pre-calculated value is used, such as from an annual DC benefit statement, then in real-time the ERI figure can’t be more than 12 months old. ERIs must be refreshed at least annually.

For an ad hoc calculation, being made on receipt of the request, up to 10 days are allowed for DB calculations and 3 for DC. The ad hoc calculation needs to be returned to the customer’s Dashboard.

The hard bit

To get close to meeting requirements schemes will need to focus on two areas.

  1. Data quality - the first issue is ensuring you have data that is good enough to calculate from. This could be a stretch for many schemes.
  2. Calculating the ERI - to present an ERI the sensible approach will be to calculate and store the figure in advance. This means that when a figure is requested it can be returned in real-time. To run ad hoc calculations on all requests received would be impossible within the SLA.

This also assumes that the administration platform will be capable of easily calculating an accurate revalued pension for DB. Many legacy platforms and even some newer ones struggle to do this.

Incomplete data

Where a member record isn’t good enough to automatically run a calculation on Mantle, it will fail and be flagged to the administrator. The nature of Mantle means that it’s easy to see where a calculation has failed and view the missing or incomplete data within the service standard. Once fixed, the ERI is automatically made available to the Dashboard.

So, there are two options available regarding incomplete data.

  • Fix the missing data for all members in advance and store them for Dashboard use.

or

  • Wait to see if a member uses the Dashboard and matches a record held. Where a positive find message is returned against a member without an automated ERI, the administrator is notified. There is then a  10 day limit to fix the record and return an ERI.

Smart thinking

Using our smarter approach to Pensions Dashboards, once the member record has been fixed, Mantle makes the calculation and pushes the ERI to Altus (our ISP), which in turn pushes it to the customer’s dashboard.

We believe that this is a unique approach allowing for all records to be made Dashboards ready in bulk, or as required, when a customer enquires.