You will have to supply the following information to your 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).
- 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’). You should utilise the codes that are provided in MaPS data standards to provide contextual information which helps members make sense of the provided value data.
- Signpost data (referenced as ‘additional data’ in MaPS data standards). 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.
You can find the detailed requirements for 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, along with relevant contextual information, 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, along with the relevant contextual information, where all benefits provided to the member are defined contribution (DC) benefits. You will have 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, along with relevant contextual information, 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 information 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 | 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) |
If benefit is designed to provide a lump sum | Yes | No | Yes |
|
Deferred DB including public service (Public service schemes may present two blocks of data) |
If benefit is designed to provide a lump sum |
Yes (simplified option in certain circumstances) |
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. | |||
You also need to provide certain contextual information to help the members make sense of the value information. MaPS data standards have set out the standard format and codes for this information, which includes:
- 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
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 do not 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.
You do not have to provide a projected value if the member is within two years of retirement or where all 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 (for example, 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 that reflect the McCloud remediation process – one for each option they can select at retirement.
Schemes in PPF assessment/wind-up/buyout
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 the scheme, or section, is in PPF assessment using the appropriate 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). If your scheme has entered into a buyout process, but has not yet triggered wind-up, then you should still meet the requirements for providing value information.
Schemes with multiple sections or benefit types
If you have multiple sections with different administrators, you need to work with each of them to understand and agree who will be providing value information, and how they will provide it. As a trustee, you need to ensure that the information being provided to the digital architecture, across different sections and administrators, is consistent and in line with legal requirements.
If your scheme has members with benefits across different sections or benefit types, for example, a DB element and an AVC value, you are legally required to present this to the member using the same illustration date.
In many situations, schemes may not yet be using the same illustration date across all their sections or benefit types. In some complex situations, schemes may take a considerable time and effort to align the illustration date. If your scheme is in this situation, and likely to be in breach when your scheme connects to dashboards, you should consider our guidance and assess whether to report a breach of law to us.
It is important that the value information presented to members is recent, clear, accurate and understandable, and the accrued and projected value for the same benefits have the same illustration date.