1. Introduction

1.1. Sequencing and policy objectives

We asked how well our recommendations met the policy objectives and staging principles (Question 30). Two-thirds of respondents responded to this question. Of those who responded, half indicated explicit agreement that the recommendations met the objectives, while a small number of respondents indicated a ‘find-first’ dashboard that prioritised reconnection and omitted values to begin with might better achieve the objectives, and the remainder did not explicitly agree or disagree.

A small number of respondents highlighted estimated retirement income (ERI) projections as an issue that could impact policy objectives and staging principles, with some views that if ERI projections continue to be inconsistent, this may undermine consumer understanding and the objective of more informed user choices. 

Others raised concerns about the staging sequencing, with the suggestion to prioritise DB schemes to benefit those closer to retirement, and questioning why all providers of personal and stakeholder pensions would need to stage before any DB schemes. Some respondents highlighted issues around pensions coverage, feeling that the objectives encouraged/allowed for partial coverage, with others raising concerns that dashboards won’t show pensions in payment and/or decumulation options.

While not explicitly in response to our recommendations, some respondents indicated that consumer testing will be an important part of how we execute dashboards. Some highlighted the need for additional tools, system messaging and an education and awareness campaign to promote the benefits of dashboards.

1.2. Timeline

The call for input responses were not definitive on the deliverability of the recommendations: many respondents indicated that they needed greater clarity, particularly around data and the digital architecture’s technical requirements, before they could give accurate estimates about when providers would be ready to connect. 

Many pension providers were unable to estimate the lead time they need to connect to the dashboard infrastructure until they had further clarification of the data and technical requirements. Of those that did provide an estimate lead time, around three-quarters suggested that 12 months or more (up to 24 months) would be required. Most respondents agreed that the lead-in time starts when certainty is available, for example when regulations/rules and full technical specification are in place. Over two-thirds said that lead times started from when either government laid or Parliament approved the final regulations.

While the proposed sequencing generally met with broad agreement, there were some concerns around the timeline for delivery. Some respondents felt it was too ambitious; on the other hand, others suggested staging should be faster. Some feared that DWP’s consolidation agenda and competing regulatory demands on industry plus integrated service provider (ISP) preparedness and availability could disrupt the recommendations.

2. Feedback on proposed sequencing

2.1. Recommended scope for staging within the first wave

More than 60% of respondents who gave a response to this question (over 80% responded) explicitly agreed with the recommendation to prioritise staging all occupational schemes with 1,000+ members and FCA-regulated providers within the first two years (Question 11), with just five respondents explicitly disagreeing, and the remainder neither explicitly agreeing nor disagreeing.

A recurring theme among those who agreed was the need for clarity on the scheme size bandings. Many respondents also expressed a view that when defining scheme size for the purpose of staging, should be defined by active and deferred members only, with pensions in payment not counted, given that they are out of scope for dashboards.

A number of respondents highlighted that communications to dashboard users must clearly explain that they will not see all pension schemes represented on the dashboards, and that users may have other pension entitlements that are not shown.  

Those that disagreed with the scope for the first staging wave cited concerns that it does not prioritise consumers approaching retirement, who may have lost touch with their pensions and who they thought would therefore gain the most from dashboards. Respondents who were in agreement with the recommendation, similarly expressed this view.

Many respondents suggested the need for some flexibility for providers of personal and stakeholder pensions with more complex legacy systems and products. Some flagged that older products (eg Retirement Annuity Contracts and s32 Buyouts) tend to be administered on older platforms, which will take additional effort to deliver within cohort one of the first wave, and should therefore be given flexibility to stage later in the first wave. 

Some respondents also suggested using a higher membership threshold to determine large schemes, to prioritise the very largest first; adjusting or adding new cohorts; and using a staging window rather than a specific date to allow providers flexibility to manage their connection.

2.1.1. Cohort one – Master trusts and FCA-regulated personal pension providers

All respondents who provided a response broadly agreed with our recommendation that master trusts and FCA regulated pension providers go first (Questions 12 and 14, to which just under 60% and 75% respectively gave a response). Respondents said that master trusts are the main beneficiaries of auto-enrolment and scheme consolidation; they are authorised by TPR; and, these are the fastest-growing pension sector, with large memberships. 

Respondents suggested that TPR’s regulatory authorisation process may mean that master trusts’ data is easiest to make available to dashboards, as it has been subject to extensive data reconciliation and rectification. They reported that master trusts are likely to have the largest number of small pension pots and up-to-date administration systems, so they are therefore digitally enabled to share data.

Many respondents caveated their agreement with the recommended first cohort. Some noted a need for recognition of employer data quality issues (due to auto-enrolment of members, bulk transfer of existing schemes, and other issues). Others highlighted that some master trusts could be at a competitive disadvantage going first if, when dashboards go live, a proportion of workplace and retail DC pensions were visible on dashboards, while a proportion were yet to be available. Others suggested that connecting older pensions may have more value for dashboard users. For example, people closer to their retirement age are more likely to have DB pensions and less likely to have many pensions in master trusts. 

Just over half of all respondents provided a response on the issue of non-commercial master trusts staging slightly later (Question 13). Just over half of those who responded to this issue agreed that non-commercial master trusts should stage as part of the next cohort, and also agreed with using membership (20,000 members) as a proxy in the absence of a legal definition. Some agreeing respondents suggested non-commercial master trusts are more likely to have more historic records. 

Two-fifths of those who provided a response did not agree with our recommendation. Some felt that it may be unnecessary to differentiate between commercial and non-commercial master trusts, and expressed the view that all master trusts must meet the same high standards for authorisation, so should be similarly ready to connect to the dashboard ecosystem. Others highlighted the need for more clarity on the definition of a non-commercial master trust. 

The remainder neither agreed nor disagreed but some highlighted as a point for consideration that DWP must consider regulations around scheme wind-up. 

Half of all respondents provided a response to the recommendation that providers of personal/stakeholder pensions go first (Question 14), with most agreeing, albeit with caveats (see below), some neither agreeing or disagreeing, and none explicitly disagreeing. Respondents highlighted the following issues for consideration:

• closed-book schemes and legacy books may need special consideration (due to data being stored on older systems, possible data quality issues and manual intervention to generate pension values)
• more complex and/or older products may need greater flexibility (some suggested these products align more with the third staging wave than the first)
• a question around why the smallest FCA-regulated providers would stage ahead of very large occupational schemes
• staging windows would provide more flexibility
• provider dependency on availability of ISPs
• providers’ need for guidance regarding connecting to the infrastructure, ahead of staging deadlines

On the specific challenges for FCA-regulated providers of personal and stakeholder pensions in getting all or part of their business dashboard-ready (Question 15), respondents highlighted both provision of estimated retirement income (ERI) and the uncertainty over what data will be required to return ERI; legacy systems (and non-digitised data); and readiness of the programme’s digital architecture. 

A small number of respondents suggested that difficulties returning ERI and the effect of the uncertainty over data requirements on providers’ ability to prepare, and/or readiness of the digital architecture would present a challenge to readiness in wave one, with others believing it was deliverable in the timescales discussed. A number of respondents identified legacy systems that will be difficult to connect, and products for which returning ERI will be very complicated as challenges.

2.1.2. Cohort two – DC schemes used for Automatic Enrolment with 1000+ members, largest to smallest

The level of agreement with our recommendations for Cohort two was slightly lower (Q16), but responses still indicated broad support. Just under half of all respondents provided a response; most agreed with the proposition, with four respondents explicitly disagreeing.

A small number of respondents who agreed with our recommendations, caveated their agreement by suggesting that schemes used for automatic enrolment with 1000+ members tend to be younger and likely to benefit from increased engagement, which should result in fewer newly identified lost pots. They also agreed that these schemes are well run and generally have good data. However, some suggested that there needs to be flexibility for schemes to onboard their entire register (if preferred).

Those that disagreed with our recommendation questioned why, if use for automatic enrolment is the primary determinant, this cohort would be limited to DC pensions only. Others highlighted that privately-operated DC schemes are much less prepared than commercial arrangements; and some suggested DC schemes used for AE should be in the first cohort alongside master trusts, differentiated only by size.

2.1.2.1. Mixed benefits in cohort two

Over a third of all respondents provided a specific view about our rationale for requiring mixed benefit schemes, with DC sections used for AE, to be part of the second cohort (Question 18). More explicitly agreed (over 45%) than disagreed (under 30%).  Those who agreed cited the potential to confuse consumers, if dashboards presented DC benefits only.  However, they also cited concerns around ERI for DB benefits and felt that DB elements would face similar challenges to the rest of the DB cohort. Among respondents that disagreed, there were views that generally members already see the varying elements of their benefits separately and the recommendation does not take account of the complexities of how benefits are administered.

2.1.3. Cohort three – all remaining large occupational schemes

Just over half of all respondents responded to our recommendation that the largest DB schemes should stage from Autumn 2023 and all DB schemes with 1,000+ members should stage within the first wave (Question 19). Most agreed, with caveats; half of those that agreed were either DB schemes or public service schemes.

Some respondents that agreed suggested that smaller schemes may need longer to resolve data and automation issues. They also suggested the need for clarity around whether or not to include members who are pensioners and highlighted resources in the administrator market as a key dependency. Some questioned again whether the member threshold of 1000+ was appropriate, suggesting this should be 5000+ members.

Those who disagreed (including DB schemes, PS schemes, administrators and professional bodies), indicated that they thought the recommendation was too ambitious and not deliverable. Some suggested that find-first was the only deliverable option here. Others highlighted DB challenges with the provision of ERI, as well as large DB schemes not having the same economies of scale as large DC schemes, and smaller DB schemes in the large category (1,000+ members) may struggle to find the resources to cleanse their data and provide accrued/ERI values.

2.1.3.1. Challenges for DB schemes

Over half of all respondents provided a specific view on the challenges for DB schemes in connecting to dashboards (Question 20). A third of those suggested that view data, especially ERI, was going to be a challenge for DB schemes, citing the complexity of benefits, non-digitised data and manual calculations required, as well as guaranteed minimum pension (GMP) equalisation. A smaller group of respondents highlighted issues with matching and data quality (particularly for legacy DB benefits); resource strain if there is a high volume of queries sparked by dashboard use; and finding and displaying linked additional voluntary contribution (AVC) data for DB schemes.

2.1.3.2. When the largest DB schemes can stage

Two-thirds of respondents answered this question. Respondents suggested a range of timescales to the question about the earliest time in 2023 that the largest DB schemes (over 50,000 members) could reasonably be expected to comply (Question 21). Many respondents highlighted the need for clarity on data requirements here, and several respondents did not provide a specific view on timing. The most common estimates ranged from six to nine months from the beginning of staging. Some suggested that six months was possible, but only on the basis of a find-first approach without pension values. A small number of software provider respondents suggested they would have the functionality in place to enable DB clients to stage in 2023 or even earlier.

2.1.3.3. When public service pension schemes can stage

More than half of all respondents provided a response to our recommendation that all public service pension schemes should stage as early as possible within the first wave (Question 22). Two-thirds of those who responded agreed. However, a few indicated this was based on find-first, with flexibility for providing ERI. Nearly all of the responses from/representing public service pension schemes either explicitly disagreed, or neither agreed nor disagreed. Only some software providers, with public service pension scheme clients agreed; and only on the condition that the McCloud remedy implementation was taken into account, when determining staging deadlines.

Agreeing respondents said that due to large numbers of members and entitlements, and the levels of people that have had employment in the public service, it will maximise coverage and fulfil savers’ expectations to see all of their pensions on the first dashboards. Other pension scheme providers raised the challenges around the McCloud remedy, highlighting the level of uncertainty and identifying that it may be difficult for public service schemes to deliver ERI in the first stage. However, others disagreed and believed that the McCloud remedy should not affect dashboards.

Those who disagreed with public service schemes staging as early as possible within the first wave, highlighted that implementing the McCloud remedy is the strongest priority over the next three years and it will take significant resources to implement the required changes. The McCloud remedy would make it hard for public service schemes to provide accurate ERI values until a much later date: the first time that the two sets of data will be provided in Annual Benefit Statements will be in 2024.

Respondents also highlighted that public service schemes will have to consider procurement regulations in their approach to selecting a potential supplier for dashboard onboarding. This could be their current supplier, or an independent ISP (although detail of the ISP marketplace is not yet known). This could end up being a considerable effort. Other challenges for public service schemes included data underpinning ERI, resource implications, other proposed regulatory changes, and industry transformation projects.

We asked about the specific challenges presented by the McCloud Judgement for public service schemes, and what they thought the earliest date that they could reasonably connect to dashboards (Question 23). The combination of the additional workload caused by the McCloud judgement, along with the complex dual benefit accrual it creates for the remedy period, and the uncertainty as to what information will be required under disclosure (with regulations and guidance not expected until 2022), were cited as the most common challenges. 

In terms of a possible earliest connection date, respondents suggested providing a window to connect, with a final end date closer to the end of the two-year period from April 2023. Others suggested public service schemes should start staging in the last quarter of the first wave / first quarter of the second wave. If there was flexibility on ERI and accrued values, or the initial scope was focused on finding members and benefits, some respondents said that some schemes could be ready in early 2023.

2.1.3.4. Remaining large DC schemes staged within wave one (up to two years from April 23)

Around a third of all respondents provided a response to our recommendation (Question 24) that all remaining DC schemes with 1,000+ memberships should stage by the end of the first wave (within two years of April 2023), with nearly all agreeing albeit with caveats. A small group caveated their agreement by suggesting the data requirement was find-first. Others said that schemes in wind-up should be excluded, and pensioner members should not be included in the definition of scheme size. A small number of respondents disagreed, with some suggestions that up to two years was too long.

2.2. Wave two: medium schemes

2.2.1. Medium schemes’ ability to participate

About a sixth of respondents provided additional views or evidence on the ability of medium schemes to participate in pensions dashboards (Question 25). Some indicated that many of these schemes will be wound-up and consolidated into larger pension schemes in the next few years, and suggested staging windows might be helpful to medium size schemes. Others highlighted technological readiness challenges, returning ERI data, as well as competing priorities and limited resources as challenges.

2.2.2. Impact on savers of deferring medium schemes

Around a quarter of respondents provided views on the potential impact on savers of deferring medium schemes until the bulk of large schemes have staged (Question 26). Respondents highlighted the potential reconnection value to savers in staging medium DB schemes, suggesting these schemes could potentially contain more lost pensions. Respondents indicated many of these schemes are closed to future accrual and have limited interaction with members. Staging later could mean that it takes longer to reconnect savers with these pensions. However, no evidence was provided on the number of lost pensions in medium schemes.

Other respondents cited the impact on the user experience by suggesting that if the dashboard available point (DAP) occurs before the staging of medium schemes is complete and/or find-only information is offered, the older DB deferred population could disengage with pensions dashboards. There were views that the size of a scheme is not relevant to the individual, so consumers will expect to see all their entitlements on dashboards, regardless of the nature of the scheme.

Some respondents also highlighted the importance of communicating the staging principles to users at the outset, to set reasonable expectations around what is/is not displayed.

2.3. Wave three: small and micro schemes

Over half of all respondents responded to our recommendation that small and micro schemes should form a third wave, after large and medium schemes (Question 27). We also asked when a reasonable timeframe for staging would be and why. Just under two-thirds agreed with deferring small and micro schemes to a third wave. Just one respondent disagreed, suggesting small and micro schemes should be the first to stage, and around a third neither agreed nor disagreed.

Many of those who agreed with the proposition cited the margin between cost and benefit (in comparison to the large and medium schemes), and less automation and lower digitisation of records. Therefore, wave three would provide small and micro schemes with more time to prepare their systems.

Some respondents highlighted a risk to the user experience. Delaying the staging of these schemes for a prolonged period could impact engagement with the dashboard service, as savers will want the certainty of knowing that they will be able to view all their pensions information in one place. 

Other respondents suggested that most of these schemes are expected to wind up and consolidate into larger pension schemes in the next few years. Some respondents suggested that most administration systems used by small and micro schemes may have already connected by wave three, so staging of these schemes could be straightforward. This cohort is likely to be reliant on solutions being provided by the data providers and ISPs. 

Where respondents indicated a timeframe for staging small and micro schemes (only around one in ten did so), suggestions varied considerably, ranging from within 12 months of the end of Wave two to up to five years after initial staging.

2.3.1. Impact of deferring small and micro schemes on savers

A few respondents provided views about the potential impact on savers of delaying small and micro schemes until after 2025 (Question 28). Respondents again highlighted the importance of communicating to users at the outset, to set reasonable expectations around what pensions may or may not be shown, to mitigate the risk of decisions by users based on insufficient information. Respondents did not provide any evidence to suggest that delaying small and micro schemes until after 2025 would affect savers.

3. Other issues

3.1. Obstacles to staging

Around half of all respondents provided views on practical obstacles to our recommended sequencing and timing for staging (Question 29). However, a large proportion did not answer this question directly, with nearly a third of those who responded stating that there remains a lot of uncertainty about requirements, with some respondents specifically linking this to uncertainty around what the requirements will be for ERI or referring to difficulties in providing a calculation for ERI. Another frequent response was the limited timeframe and available resources. 

Some respondents raised concerns over the increased costs associated with increased contact from members using dashboards, while others highlighted data migration and IT obstacles, as well as issues relating to third parties. There has been a consistent theme throughout all responses in relation to the availability of ISP solutions, as well as concerns about cost and service quality of ISP solutions.

3.2. Providers’ appetite for early staging and identified barriers

The response split equally between those expressing an interest in staging early and those thinking the PDP should do more to enable early staging. Of those expressing an interest, the majority were software providers or third-party administrators. Those who were keen to stage early said they wanted to do so to resolve any issues before the legal deadline.  

In response to being asked what more PDP could do to encourage early on-boarding, providers said that PDP needs to clarify how resource-intensive it is and what the technical requirements for early staging are. They also said that PDP needs to further clarify the benefits of early staging and communicate these with trustees and employers, to show the need for early action. There was also concern raised at the lack of clarity around connecting early from a data protection perspective.

A number of respondents raised concerns around the availability of ISP solutions, and some suggested that the ISP market wouldn’t be able to cope with the demand and highlighted the need for further guidance around their use.

3.3. Partial information

There was broad support for launching dashboards when a critical mass of pensions is findable and viewable via dashboards. There was a general consensus that consumers would want dashboards to display all the information at the same time, and consumers would be unlikely to accept partial dashboards. Respondents also highlighted the importance of consumers understanding what data is not being shown/currently unavailable and why. There was also consensus, however, that showing partial information is preferable to showing no information at all.

3.4. Impacts of the recommended approach on consumers 

3.4.1. Locations of lost pots and the impact of our staging recommendations

Around half of all respondents provided a response on where lost pensions are most likely to be located and the impact, therefore, of our staging recommendations on reconnecting savers with lost pensions (Question 31). Most suggested that lost pensions would be most prevalent in the over-50s and those with older pension entitlements. Another common response was the ongoing issue of under-engagement and failure to update contact details like correspondence addresses.  

3.4.2. Equalities impacts of staging and impacts on under-pensioned groups

A sixth of respondents provided a response when we asked about the equalities impacts of staging and impacts on under-pensioned groups (Question 32). Most provided responses around lost pots, indicating women may be more likely to be affected by lost pots, due to changes in their surname.

3.4.3. Limiting the scope of dashboards only to pensions not in payment

Some respondents raised concerns about limiting the scope of dashboards only to pensions not in payment as dashboards will not provide an accurate picture of customers’ pension savings.

3.5. Remaining uncertainties, on which industry needs clarity

Respondents highlighted a number of uncertainties, on which industry needs clarity, including:

• data – specifically what view data (especially ERI) will have to be returned 
• data protection and liability
• connection requirements
• response times
• identity verification and assurance process
• matching protocols
• ISP market dependency
• McCloud for public service schemes
• competing priorities – GMP equalisation, simpler annual benefits, small pots, transformation programmes

3.6. Estimated retirement income and find versus find and view

A number of respondents highlighted concerns around estimated retirement income (ERI), including around industry’s ability to provide ERI figures (particularly DB schemes), but also the likelihood of consumer confusion when presented with incomparable projections. 

While this call for input did not ask specifically about find-first, versus find and view dashboards, a number of responses volunteered opinions on the question of what data they should be required to return to members at dashboards. 

Several respondents – including responses on behalf of large membership bodies representing pension administration providers and DC and DB schemes – recommended a find-first approach, arguing there would be value for consumers (particularly those approaching retirement) in being reconnected with any lost pensions, and this would allow time for standardisation of how ERI amounts are calculated before values are displayed on dashboards. These respondents expressed a view that consumers would still value a find dashboards service. Some suggested that PDP’s user testing should include an assessment of find-only dashboards for a time, as well as find and view dashboards to test this concept. 

Other respondents volunteered views that ERI should be available on dashboards from day one, citing consumer need and the importance of including values for credibility and consumer engagement.

3.7. Time to provide view data

Around a third of respondents provided further detail about how long it would take to be able to provide all the required view data (Question 5). Most suggested that pension values will take longer to provide than administrative information, and some indicated a find-first dashboard would be achievable in a shorter timescale. A significant number of responses said that they need clarity on ERI requirements before they can specify a timescale for providing view data. Some noted that if ERI standardisation required system changes, this would extend the time they would need to connect. 

Of respondents that specified a timescale for connecting and being able to meet the obligations to provide administrative and view data, it ranged from anywhere between six to 48 months. However, the majority of timescales were 12-24 months. The scheme that suggested 48 months did say that this would be with automation built in, and this would be for all of its schemes. 

Around two-thirds of respondents provided further detail about whether response time would be material to onboarding and whether longer times for returning ERI or accrued values were needed (Question 6).  Most indicated that response times would not be material to staging. Most respondents suggested that accrued values were easier than ERI, and most of the concern was around ERI.

4. Next steps

4.1. Staging policy development

PDP has shared the responses to the call for input with DWP, FCA & TPR to inform staging policy development. PDP has analysed the responses in full, while this summary provides an overview of the key themes. 

The staging proposition will be set out in the DWP’s consultation on draft regulations for occupational pension schemes, expected at the end of 2021, and in the FCA’s consultation on draft rules for providers of personal and stakeholder pensions, which will follow.

4.2. Addressing uncertainties

We recognise the need for further certainty and reassurance to drive action. We are committed to publishing the necessary information as soon as it is available, to provide industry with sufficient warning to prepare their systems.  

PDP will continue to share learnings from our activity over the coming months, including updates from our initial (alpha) development. These updates will provide further insight into the onboarding process for data providers and potential dashboard providers. PDP will also provide updates from our consumer testing / user research.

Industry will also require clear standards for implementation and we will publish the following over the coming months:

• technical standards for data providers (winter 2021/22) 
• operational standards for data providers (winter 2021/22) 

FCA and TPR will also play a vital role in addressing uncertainty and driving action amongst their regulated communities, via face to face engagement and direct communications.

4.3. PDP research on ERI

In light of the concerns expressed in the call for input responses around ERI, and to build the evidence base to aid the DWP’s/FCA’s decision-making, we are undertaking further research and user testing in relation to what data should be displayed to users. 

Within our ongoing research, we are investigating the appeal of and users’ views on potential dashboard display content, including the types of data that could be required by pension schemes and providers to return to dashboards, and users’ tolerance of partial information about their pensions. 

In addition, we are carrying out some early prototype testing with users, which will help us understand how our users will react to different displays of information. This is not full prototype testing but will give us useful insights and inform future end to end journey prototype usability testing. The prototype testing breaks down as follows:

• the first prototype will display only administrative information about the pension and the pension provider, no pension figures will be shown
• the second will display the same information as the first prototype but will also include the accrued (current) figures for each pension 
• the third prototype will display the same information as the second prototype and will also include the estimated (projected income) figures for each pension
• a fourth prototype will display the same information as the third version, but will use an alternative design

The testing will take place in early October 2021, with analysis of the findings taking place by November 2021.