You will have to supply the following information to scheme members via pensions dashboards.
- Administrative data. This includes the scheme name, the dates the member was in it, the name and contact details for the administrator and, if available, the employer’s name. You will also need to provide a member’s date of birth to enable dashboards to show the time to retirement (the date of birth itself will not be shown on dashboards).
- Signpost data. These are hyperlinks to websites where the member can see other useful information about the scheme, such as information on costs and charges, the scheme’s statement of investment principles and the scheme’s implementation statement.
- Value data. This provides details of how much pension the member has built up already and how much they may have when they retire (their ‘estimated retirement income’). Further detail on this is set out below.
- Contextual information. This helps members to make sense of the value data.
You can find the complete list of view data in the data standards.
When you should provide the data
Administrative and signpost data
You must return administrative and signpost data immediately after a view request is received.
For new members who request view data within the first three months of joining the scheme, you will need to provide the administrative data as soon as you can and no later than three months after the member joined the scheme.
Value data and contextual information
You must provide value data immediately if it is based on a statement provided to a member in the last 13 months, or a calculation made for the member in the last 12 months (for example if there was a previous request made on a dashboard). Where this is not the case, you will have three working days to return value data where all benefits provided to the member are defined contribution (DC) benefits, and 10 working days in all other cases, such as defined benefits (DB) and hybrid benefits, where the value is calculated by reference to both DB and DC elements.
For new members, you are required to provide the value data as soon as you can. This should be no later than when you first produce a statement of the members’ benefits for them, or 12 months from the end of the first full scheme year they have been in the scheme, whichever is soonest.
What value data and contextual data you should provide
The values (including estimated retirement income) that you need to supply will depend on the status of the member and the benefit type.
The table details what data you should provide. If you have a complex benefit structure you should speak with your administrators about what data you should provide.
| Benefit / member type | Accrued value (information regarding the pension or benefits built up to date by the member) | Projected value (information regarding the pension, benefits or other income the member may receive based on continued contributions, earnings or service) | ||
|---|---|---|---|---|
| Pot | Annual income | Pot | Annual income | |
| DC |
Yes | Yes (as of 1 October 2023 – it is optional* until then) | Optional* | Yes (unless the members fall into the exemptions to this) |
|
Active DB including public service (Public service schemes may present two blocks of data) |
Optional* | Yes | No | Yes |
|
Deferred DB including public service (Public service schemes may present two blocks of data) |
Optional* (Potential simplified calculation for the first two years of being connected) |
Yes |
No | No |
| Active cash balance | Yes | Yes (unless the sole purpose is to provide a lump sum on retirement) | Yes | Yes (unless the sole purpose is to provide a lump sum on retirement) |
| Deferred cash balance | Yes | Yes (unless the sole purpose is to provide a lump sum on retirement) | No | No |
| Active collective DC |
No | Yes | No | Yes |
| Deferred collective DC |
No | No | No | Yes |
| Hybrid benefit | Where the benefit is calculated by reference to both DB and DC elements, you can return one or more sets of values, which may be based on DB, DC, cash balance or collective DC methodology depending on which you consider best represents the members’ benefits. | |||
*Optional means that you can provide the data despite not being required to do so.
You will also need to provide certain ‘contextual’ information to help members make sense of the value information – for example:
- the date to which the value relates
- the date from when a benefit is payable
- whether more than one retirement date has been used to calculate the value
- whether there is a spouse’s or civil partner’s benefits attached to the pension
- whether the benefits would increase or decrease in payment
- why a value is not available
You can find further detail on contextual information in regulation 27 of the dashboards regulations and the MaPS data standards.
Preparing value data
You need to ensure that the quality of your data is sufficient to meet your dashboards duties. This includes ensuring that:
- administrative data you provide is accurate
- value data is calculated in line with the legal requirements and is sufficiently recent (see below for more information)
- data is digitised so it can be returned through the digital architecture
You should audit your data, put a plan in place to improve data and make any changes required to your systems and processes.
Whether they are DC or DB, the values you give should be from either:
- a benefit statement provided to the member in the last 13 months
- a calculation made for the member in the last 12 months
This applies whether or not a calculation has been done in response to an earlier view request.
You will need to consider how you ensure that data returned to members is recent. If you have performed a calculation or provided the member with a statement within the time periods as above, you should return value information immediately. If you don’t have up-to-date information available, you need to decide how you will provide this. You will only have three working days where all benefits provided to the member are DC, or 10 working days in any other case (including for hybrid benefits) to calculate a value on request. Therefore, it may be more efficient to put in place a process to revalue deferred pensions annually or automate the calculation of values in your administration system. Speak to your administrator and other advisers or suppliers to decide how you will deliver recent data, and where it might be possible to improve current systems.
There may be limited circumstances (for example, the pension provider is subject to a Pension Protection Fund (PPF) assessment period, or an action or decision is outstanding from the member) where you are unable to provide value data. In this case you will need to choose from the reasons provided in MaPS data standards and provide the member with a way of getting in touch.
DC values
DC projected values should be calculated in line with the Financial Reporting Council actuarial standards (known as AS TM1) for statutory money purchase illustrations. DC accrued annual income should also be calculated by reference to AS TM1, but leaving out the impact of future contributions and fund growth. The Department for Work and Pensions has developed guidance on how to calculate the annualised accrued value for DC schemes, including available methods. See annualised accrued value calculations for pensions dashboards. Values calculated by reference to AS TM1 will only be required once planned changes to these standards come into force, which is expected to be October 2023 (you will need to provide DC accrued pot value information from the outset).
You do not have to provide a projected value if the member is within two years of retirement or where the following apply:
- the accrued value (to money purchase benefits) was less than £5,000 when last calculated and provided to the member
- no contributions (including transfers and pension credits) have been made since
- the scheme has informed the member that further projections will not be given unless further contributions are made
You can still provide a projected value in these situations if you choose to.
DB values
You should calculate DB values in line with scheme rules, without taking into account possible increases in earnings.
However, for the first two years of being connected, you can provide a simplified calculation of deferred benefits revalued using an adjustment method you consider to be appropriate (eg using inflation figures). You can only do this if providing a value in line with scheme rules would be disproportionately expensive or take too long, and you are confident the alternative value provided would not be misleading. You must also confirm in the information you provide that you are using this basis for calculation, in line with the data standards. During these two years you should deliver the data and system improvements required to be able to provide a value in line with scheme rules.
If the member’s DB benefits have different tranches, you can choose to either provide one single value (showing a common retirement date) or separate values for each tranche (with their own retirement date). If you return separate values, you will need to provide a start and end date for each separate value.
Public service values
Public service schemes, excluding judiciary and local government schemes, will need to provide two sets of values which reflect the McCloud remediation process – one for each option they can select at retirement.
Public service schemes will only need to provide value data from 1 April 2025, or once a Remedial Service Statement has been issued (if applicable), whichever comes first.
Schemes in PPF assessment and schemes in wind-up
If your scheme, or a section of your scheme, goes into PPF assessment after you’ve connected to the digital architecture, you will need to remain connected. However, you are only required to provide administrative data and messaging confirming that the scheme, or section, is in PPF assessment using the ‘values unavailable’ codes in the data standards.
Schemes, or sections of schemes, in the process of winding up will need to connect to the digital architecture and provide administrative data, but do not have to provide value information to members (though they can do so voluntarily).