Consultation outcome

Government response: Draft Pensions Dashboards Regulations 2022

Updated 15 July 2022

Ministerial Foreword

I am pleased to be publishing the Government’s response to this important consultation on Pensions Dashboards. I would like to thank all the individuals and organisations who took the time to respond to the consultation, or to attend one of the webinars we hosted during the consultation period.

It is really promising to see so much positive engagement with our proposals, and I welcome the broad support that has been shown for making pensions dashboards a reality.

Of course, not every respondent agreed with every proposal, and we have received some helpful and constructive feedback on how the draft Regulations could be improved. We have carefully listened and considered that feedback. Alongside this we also identified further areas where we want to engage further, which is why we launched an additional consultation last month relating to new provisions on the disclosure of information between MaPS and TPR and the Dashboards Available Point.

The important point readers should take away from our consultation response is that the Government remains fully committed to making pensions dashboards happen at the earliest opportunity. The building and initial testing of the digital architecture by the Pensions Dashboards Programme is already well underway. Trustees or managers of pension schemes of all types and sizes should therefore focus their preparations on making sure their data is ready and they have plans in place for how they intend to connect to the digital architecture.

Pensions dashboard services will change the way people engage with and prepare for retirement forever. By enabling people to see all their pensions information in one place online, including on their State Pension, individuals will be able to make better informed decisions about their retirement, as well as find lost and forgotten pots.

And this is just the beginning. The first version of pensions dashboard services will be relatively simple, offering people the opportunity to find their pensions and then view information about the value of those pensions. As the use of dashboards becomes more commonplace, we will learn more about what people find useful and these insights will allow for us to enhance the dashboards experience further. I am therefore greatly encouraged that many respondents already have an eye on the future of dashboards, with faster response times and greater functionality of dashboards among the suggestions for improvements.

I look forward to continuing to work with all interested parties to make pensions dashboard services a success.

Guy Opperman MP Minister for Pensions and Financial Inclusion 

Introduction

1. The Government remains steadfast in its support for pensions dashboards. We know that individuals often struggle to understand their pensions, and many do not know how much they can expect to receive in retirement. With the success of Automatic Enrolment, millions more are saving for retirement and may have multiple pension pots, with no easy way of keeping track of these. Pensions dashboards will change that – making it easy for individuals to see their pensions information, including on the State Pension, in one place online on their laptop, smartphone, or any other device of their choice.

2. The consultation on the draft Pensions Dashboards Regulations 2022 was launched on 31 January 2022 and closed on 13 March 2022.

3. The draft Regulations set out the requirements to be met by pensions dashboard service providers and by trustees or managers of relevant occupational pension schemes in Great Britain. We expect the Department for Communities in Northern Ireland will make corresponding legislation to ensure parity across the United Kingdom. The Financial Conduct Authority (FCA) also consulted on proposed rules for personal and stakeholder pension providers from 11 February 2022 until 8 April 2022.

4. To support the launch of the consultation, the Department for Work and Pensions (DWP) held a series of webinar sessions during the consultation period with representatives from the Pensions Dashboards Programme (PDP), The Pensions Regulator (TPR), the FCA, and the Financial Reporting Council (FRC) in attendance to help answer questions about the proposals.

5. The sessions included an overview of the consultation as well as key aspects of the Department’s proposals. In total these webinars had around 1,500 attendees from pension schemes and the wider pensions industry, as well as representatives from consumer groups and others.

6. We received 100 responses to the consultation. These were from several leading trade bodies, representatives of occupational pension schemes, personal and stakeholder pension providers, public service pension schemes, administrators, software providers, legal and consultancy firms and a small number of consumer groups and others.

7. We have carefully considered the feedback received. The following chapters provide a summary of the responses received and an outline of the changes that have been made.  

Chapter 1: Overview of Pensions Dashboards

Introduction

1.1. We set out in chapter 1 of the consultation a broad introduction to pensions dashboards. This included an overview of how the technology behind dashboards will work, what was being done to protect consumers when they use dashboards, and the role of standards.

1.2. Question 1 of the consultation asked whether respondents had comments on any aspect of the Regulations or consultation, that had not been covered in the other consultation questions.

1.3. Where possible, we have sought to consider our response to comments under question 1 as part of a relevant chapter, which correspond to the original chapters in the consultation. We have, however, provided a broad summary of some of the key themes of the responses which came up under this question (and have not been considered elsewhere), and this is set out below.

1.4. As mentioned above, we also set out in chapter 1 the role of standards, which the Regulations would require compliance with. Question 2 of the consultation asked respondents to consider whether they agreed with our proposed approach to the oversight and approval of standards.

Summary of responses: Question 1

Question 1: Do you have any comments on any aspect of the Regulations or consultation, that is not covered in the following consultation questions?

Dashboards Available Point

1.5. Some respondents provided comments on the point at which pensions dashboard services (dashboards) will be made available to the public, which we have referred to as the “Dashboards Available Point”. They highlighted that once dashboard services become available to the public, this will have an operational impact, including on the staffing levels required to deal with additional queries related to dashboards.

1.6. Some respondents highlighted there are risks to making dashboards available to the public too soon. Respondents emphasised the importance of live testing to ensure most individuals using dashboards understand the limitations of dashboards, are not confused by what they see, and do not take inappropriate steps after viewing their pensions.

1.7. A leading consumer group Which? emphasised its view that the Government should publicly set out its expectations for when dashboards will be launched following testing, to provide a clear outlook on progress for dashboards and avoid unnecessary delays to delivery.

Liability

1.8. Several respondents flagged concerns around liability for industry in general, highlighting two areas in particular:

• schemes could be held liable for an individual mis-using or misinterpreting data that has been provided by them; and
• liability for failing to return a match and liability for reporting a match to the wrong individual.

1.9. There was concern expressed that individuals may act upon the values they see on dashboards but that these values are likely to be estimates and may be expressed in a simplified form to meet the requirements in the Regulations. The Pensions and Lifetime Savings Association (PLSA) outlined research by the European Insurance and Occupational Pensions Authority which recommended that all dashboards should include disclaimer wording explaining that the pension incomes shown are only estimates. The PLSA also recommended that a strong disclaimer is required to be shown on all dashboards and that this wording “extinguishes schemes’ liability from users making poor decisions based on View data”.

Cost of dashboards

1.10. Some respondents sought clarity on the cost of dashboards and asked questions about the future funding of the pensions dashboards digital architecture. There were questions about the full costs of setting up the digital architecture as well as the annual cost of maintaining this, including the cost of the identification service, and how this will be funded on an ongoing basis. This was linked to a request for clarity about the long-term plans for the governance of dashboards.

1.11. Others highlighted that the increased costs of meeting the requirements in the Regulations may be passed on to scheme members, as well as a risk that the requirements could impact on the funding level for defined benefit schemes, particularly small schemes.

Orphan Schemes

1.12. Some responses queried whether administrators would be required to provide a scheme’s data if it is an “orphan” scheme, i.e., in cases where they do not have the trustees’ agreement to connect to dashboards because there are no trustees, or the trustees are not contactable.

Additional functions of dashboards

1.13. Some respondents asked questions about the future direction of dashboards with queries about whether transactions would be permitted and how data can be presented on dashboards. The Association of British Insurers provided the results of its own research on the public’s desire for dashboards to provide more interactive formats, such as by providing “sliders” to allow individuals to model how changes, for example to their income, would affect their pensions. The consumer group Which? was also supportive of the idea that, in time, the Government should “allow for greater innovation in the presentation of dashboards to help drive consumer engagement”.

Government response: Question 1

Dashboards Available Point

1.14. We have noted comments about the need to provide certainty on when dashboards will be made available to the public so that schemes can prepare for an increase in operational activity. We have therefore proposed including a new provision in the Pensions Dashboards Regulations which covers the process for confirming and announcing the Dashboards Available Point and we are consulting on this issue separately^{[footnote 1]}. This consultation will be running until 19 July 2022.

Liability

1.15. As set out in our consultation paper, trustees or managers will be responsible for meeting the following requirements:

• receiving find data, undertaking matching (as independent data controllers, in compliance with data protection legislation (UK GDPR - General Data Protection Regulation, the Data Protection Act 2018) as well as dashboard duties) and registering Pension Identifiers (PeIs) for found pensions in accordance with MaPS standards; and
• checking authorisation of view requests and responding by generating (if not already generated) and returning the correct view data (as independent data controllers, in accordance with MaPS data standards).

1.16. Trustees or managers are not responsible for verifying the identity of users, or for the consent and authorisation service’s authorisation of view requests, or for any processing of view data carried out by dashboards (as independent data controllers).

1.17. The PDP will be consulting on design standards for pensions dashboard service providers which we understand will include requirements to display a clear explanation to individuals using those services, which point out the limitations of the service. This should help mitigate the risk that individuals misuse or misinterpret the data.

1.18. We acknowledge the concerns among trustees or managers around potentially being in breach of the regulations and/or data protection legislation where they fail to match effectively or return data to the wrong person. ‘Possible matches’ are designed to ease this tension as they allow trustees and managers to flag where they may have found a pension, but they are not fully confident it is the correct person. This will prompt individuals to get in touch and provide sufficient information to meet the scheme’s threshold for matching. These possible matches cannot be used to retrieve personal data, limiting trustees’ risk of exposure to data breaches. More information about possible matches is set out in Chapter 3. It is also important that trustees or managers are fulfilling their responsibilities to maintain the accuracy of their data to support effective matching.

1.19. The ICO has echoed our view that “it is vital schemes are doing what they can to improve the accuracy of the data which will be integral to the success of pensions dashboards. The accuracy principle under Article 5(1)(d) of the UK GDPR requires that organisations ensure data remains accurate and up to date”. They go on to explain how important it is that projections are based on accurate data inputs, recognising this may influence an individual’s behaviour. The ICO said “it is vital that steps are taken to rectify or remove any inaccurate data without delay”. For clarity, this does not mean that trustees or managers will be responsible for the calculation methodology used if this is determined by another organisation (for example, the calculation methodology in AS TM1 set by the FRC for money purchase schemes).

Cost of Dashboards

1.20. With respect to comments about the costs of adhering to the Regulations being passed on to savers, the Government sets a cap on the annual amount that can be charged to savers in default arrangements within defined contribution pension schemes used for auto-enrolment. This charge cap will continue to apply to relevant pension schemes.

1.21. Further detail on the costs to schemes of participating in pensions dashboards and the benefits to savers will be available in our Impact Assessment, which will be published when the Regulations are laid before Parliament.

Orphan schemes

1.22. The legal responsibility for compliance with the requirements in the Regulations sits with trustees or managers of relevant occupational pension schemes. The issue of orphan schemes is a wider issue, but we understand TPR will seek to engage with providers to understand the art of the possible in terms of making benefits in orphan schemes available to the dashboards.

Additional functions of dashboards

1.23. As we set out in our consultation, the digital architecture to which dashboards will connect, will not have transaction functionality. This means pension transfers and consolidation, for example, cannot be processed through the architecture.

1.24. We know there are potential benefits of providing more functionality and a more interactive experience and are grateful to respondents that have provided evidence to support this. However, we remain of the view it is important that initial dashboards provide only a relatively straightforward ‘find and view’ function which allows the consumer to search for their pensions and see some relatively high-level information about them. This is to help build trust in the service. We will continue to review this position and consider whether future iterations of dashboards will be able to provide a more interactive offering which is based on evidence collected from user research.

Summary of responses: Question 2

Question 2: Do you agree with the proposed approach to the oversight and approval of standards?

1.25. The vast majority of respondents agreed with the proposed approach to the oversight and approval of standards, with very few respondents expressing outright disagreement.

1.26. However, some respondents did highlight specific issues and concerns for our consideration. We have summarised some of the common points raised below:

• Meaningful consultation with industry is important, including providing industry with adequate time to respond to consultations. Some suggested the Regulations should include a requirement on MaPS to consult on changes to standards.
• When changes are made, industry must be given adequate notice and time to implement changes. Some suggested that standards should change no more than once a year and that a one-year notice period for changes should be specified in the Regulations.
• Some indicated that scrutiny of changes will be important, including a mechanism for holding MaPS to account. Several respondents recommended informal industry advisory groups to enable industry input prior to changes.
• The Regulations lacked a definition of “minor technical changes” and what changes could be implemented by MaPS without approval from the Secretary of State. Some respondents expressed concerns about how the impacts of changes to standards on parties would be assessed, highlighting those minor changes may still have significant impacts for some parties. Some indicated that “minor changes” should be clearly defined in the Regulations rather than left to the discretion of MaPS.

1.27. There were also some concerns raised by a smaller number of respondents that:

• the Regulations contain too much technical and operational detail, which would be more appropriately left to standards;
• there appeared to be two sets of technical standards, which could cause confusion; and
• MaPS must engage closely with TPR and FCA to ensure changes are not overly burdensome – and the Secretary of State approval should consider the views of the regulators.

Government response: Question 2

1.28. We are pleased to note that most respondents agreed with our overall proposed approach to the oversight and approval of standards. But we recognise that it is important to provide further assurance as to how the process for setting and approving standards will work and how it is likely to affect industry in practise.

1.29. As the draft Regulations provide, the Secretary of State for Work and Pensions will be required to approve the first set of standards and any subsequent standards, having been previously approved by the Secretary of State, that go beyond minor, technical amendments. We are engaging with the PDP on the first iteration of their standards, and these will be consulted on in due course. PDP will also be consulting on its approach to setting standards, which we understand will include setting out what they consider to be a minor technical change.

1.30. We agree it is important for industry, consumer groups, government, and the regulators to be able to provide input and feedback on changes to standards. PDP will be responsible for setting out specific governance processes relating to changes to standards. Given the Secretary of State’s role in approving significant changes to standards, the DWP will continue to work with PDP to ensure that the governance processes enable meaningful feedback to be gathered that supports the Secretary of State in deciding on whether to approve changes to standards. PDP is already working with industry stakeholders on some standards through a number of working groups, including a data working group, ecosystem technical working group, usability working group, and integration and test working group.

1.31. Further information about PDP’s approach to standards, including how often they expect to update standards and how much notice they would expect to provide to industry, can be found on the Pensions Dashboards Programme website.  

Chapter 2: Data

Introduction

2.1. The consultation document set out proposals on a range of data-related requirements on trustees or managers of occupational pension schemes. These relate to:

• Administrative data
• Signpost data
• Value data, including accrued and projected data requirements for:
  • Schemes offering money purchase benefits
  • Schemes offering non-money purchase benefits
  • Schemes offering cash balance benefits
  • Schemes offering collective money purchase benefits
  • Schemes offering hybrid benefits

2.2. We asked a number of questions on proposals relating to these areas. The main purpose being to ensure that dashboard requirements were deliverable and to understand the extent to which those requirements align with current approaches taken to the calculation of values for benefit statements. Of equal importance, we wanted to ensure that the suite of value and supporting information proposed met the needs of individuals using dashboards and had the potential to offer the best user experience.

2.3. The consultation also sought views on our proposed approach to State Pension information on dashboards, including the information that would be shown in respect of an individual’s State Pension, and the accompanying messaging.

2.4. In addition, the Financial Reporting Council (FRC) – the body tasked with setting out the approach to providing illustrations for money purchase schemes – has consulted on revisions to Actuarial Standards Technical Memorandum 1 (AS TM1), in part to reflect the requirements for dashboards. The consultation is now closed and the FRC are considering responses. The FRC AS TM1 Consultation Paper remains available for viewing.

Summary of responses: Question 3

Question 3: User testing shows that the inclusion of date of birth for display logic purposes could be useful for individuals using dashboards, so we are minded to include it. Does this cause any concerns?

2.5. The vast majority of respondents to this question supported the proposal. There were a small number of respondents that raised concerns in response to this proposal, which included the potential for fraud, scams or misuse, particularly if data export is to be permitted, and of schemes holding incorrect dates of births. There were some isolated concerns that date of birth was a weak data item, and that national insurance number was considered stronger, yet not mandated. Only very few respondents were against this proposal.

2.6. In summary, the majority of respondents who answered this question were content for date of birth to be used for display logic purposes, that is, not actually displaying an individual’s date of birth, but enabling dashboards to present the amount of time an individual has until they reach their retirement date. Some suggested that they would be more concerned if an individual’s actual date of birth was to be displayed on dashboards, but this is not the intention.

Government response: Question 3

2.7. Based on the consultation responses, we will include date of birth as a data item. Including date of birth will be used for display logic. This means that an individual’s date of birth won’t actually be displayed but will enable dashboards to not only present an individual’s retirement date (which is a data field already required separately), but also display how long until an individual would reach retirement. We have not proposed to mandate national insurance numbers, to ensure that the largest amount of people possible are able to make use of dashboards. However, we would strongly encourage any individual who does have a national insurance number to provide it, to support the matching process.

Summary of responses: Question 4

Question 4: Will it be feasible for trustees or managers to provide administrative data to new members making a request for information within three months of joining the new scheme?

2.8. There was general agreement amongst respondents with the principle of new members receiving administrative data within three months of joining the scheme, should they make a request for it. The majority of those that answered this question agreed that providing administrative data to new members within three months will be feasible. Some of these agreed, but did so with some concerns, which are detailed below. About a fifth of respondents were either against the proposal or were not sure if it would be feasible.

2.9. The main concerns amongst respondents were:

• Schemes will be reliant on employers sending information to them in a timely manner in order to fulfil this obligation. A small number of respondents suggested that it may be more appropriate to start the three-month window from the point at which the scheme has received complete data.
• Supplying administrative data within three months may be challenging for certain types of schemes, with data for Automatic Enrolment (AE) schemes likely to be limited.
• Providing administrative data within the specified timescale could be more of an issue where a National Insurance number has not been issued.

2.10. Generally, there was widespread agreement this can be done, but a number of respondents outlined that this should not raise an expectation for value data to be shared within the same timescales for new members. The draft Regulations on which we consulted were silent on the expectations for the provision of value data for new members. Below, we have outlined separate requirements for new members of schemes receiving value data.

Government response: Question 4

2.11. We were pleased to see widespread agreement throughout consultation responses on our proposals for administrative data to be provided to new members within three months of joining a scheme. We acknowledge the difficulties that some noted about receiving data from employers, and would encourage trustees and managers to work with employers to improve processes to facilitate data provision in a timely manner. As set out in our response to question 3, we will not mandate individuals to provide their national insurance number but would strongly encourage those who have one to provide it; and the partial match process described in chapter 3 should also provide the means for matches to be made where this is not immediately possible. We have set out below the amendments we will include in the Regulations for providing value data to new members, having taken into account consultation responses.

Value data for new members

2.12. Respondents to the consultation stated that a provision should be included relating to the return of value data, and stated that the provision of value data to new members should not be subject to the same timelines as administrative data. The reasons cited included increased complexity with providing value data and the need for individuals to be members for a minimum period before the data would be meaningful.

2.13. Therefore, we will include a provision to reflect our policy which requires that value data should be provided to new scheme members as soon as is practicable, but no later than the sooner of:

• the point at which the first statement has been produced for that member; or
• within 12 months of the end of the first full scheme year of which the member was a part of the scheme.

2.14. Our policy is that this provision will apply to all scheme types and is similar to the provision in The Occupational and Personal Pension Schemes (Disclosure of Information) Regulations 2013 (“Disclosure Regulations 2013”) for money purchase members.

2.15. If a member has been transferred from another scheme as a result of a transfer of liabilities, then they would be considered to be a new member.

Summary of responses: Question 5

Question 5: To what extent do schemes currently make use of the exemptions under Disclosure Regulations 2013, Regulation 17(6)(c), which exempt money purchase schemes from issuing projections if certain criteria are met? Do many choose instead to issue SMPIs (Statutory Money Purchase Illustrations) in these circumstances?

2.16. The majority of respondents either didn’t answer this question as it was not applicable to them or stated that they did not know to what extent the exemptions are used. There was no consistency amongst the respondents that provided a substantive answer to this question. Some said that they are aware that some schemes do utilise the exemption, but also know that others don’t, while others said they don’t use the exemption, though a few of these stated that they would support it being included regardless. A smaller number of respondents said they make full use of the exemption. In some isolated cases, respondents cited that possible increased demand caused by dashboards could mean that they start to utilise these exemptions.

2.17. The responses indicated that many schemes, particularly larger schemes with administrators and those with automated systems, do not identify members that the exemptions apply to, and instead provide SMPIs to every member, including those to which the exemptions would apply. In respect of the ones with automated systems, providing SMPIs regardless would appear to be an easier, more efficient approach than identifying members that would be exempt.

2.18. Other exemptions outlined in the Disclosure Regulations 2013 tended to be more widely-used than the exemption specified at regulation 17(6)(c) of the Disclosure Regulations. That which exempts members within two years of their retirement date from receiving projections appears to be most commonly used, although a significant number of respondents only choose not to provide exemptions to members within 12 months of their retirement date. In contrast, one response stated that the Pensions Dashboard Regulations should allow projections to be calculated beyond normal pension age (NPA), with increasing numbers of members continuing to save beyond their scheme’s normal retirement age.

2.19. A fairly common suggestion was for members to have a minimum pot value before providing projections. In regulation 17(6)(c) of the Disclosure Regulations 2013 this is pots less than £5,000, assuming that certain other criteria are also satisfied. In practice, some respondents reported that they do not issue projections for pots less than £2,000 in value, while others do not provide projections to members with less than £1,000 in pot value. Therefore, it appears schemes use their own definition of what the minimum pot value should be.

2.20. The responses also included a widely held view that the Pensions Dashboards Regulations should align as closely as possible with the Disclosure Regulations 2013, and other relevant existing legislation. This, among other things, would support consistency between dashboard and benefit statement values.

Government response: Question 5

2.21. The responses to this question confirm our assumptions at the time of consulting. For clarity, the exemptions that will be available are that money purchase schemes will not be required to provide projected information where all of the following criteria are satisfied:

• The value of the member’s accrued rights to money purchase benefits under the scheme was less than £5,000 on the last illustration date; and
• Since the previous illustration date, no contributions (including transfers of pension rights and pension credits) have been made to the scheme by, or on behalf of, the member in respect of the member’s money purchase benefits; and
• The trustees or managers of the scheme have previously given notice to the member that the information listed in Part 2 of the Schedule 6 to the 2013 Regulations will not be given to the member again unless further contributions have been made.

2.22. Although not specifically referenced in the question, under the Pensions Dashboard Regulations, trustees or managers of money purchase schemes will also not be required to provide projected information if the member is within 2 years of their retirement date. In any case where these exemptions apply, trustees or managers may choose to provide projected information voluntarily.

2.23. We also note the response relating to values being provided beyond the scheme’s normal retirement age, and have made changes to the requirements as set out in our response to question 13.

Summary of responses: Question 6

Question 6: Do schemes apply exemptions when providing information in respect of cash balance benefits, which they think should be transferred over to dashboard regulations?

2.24. We received few responses to this question, all of which either replied “no”, or that they do not rely on exemptions in respect of cash balance schemes.

Government response: Question 6

2.25. It is clear from responses that schemes do not apply exemptions when providing information in respect of cash balance benefits. Therefore, we do not propose including any specific exemptions in respect of cash balance benefits in the Pensions Dashboard Regulations.

Summary of responses: Question 7

Question 7: Do the Regulations reasonably allow for our policy intent for deferred non-money purchase schemes to be achieved, and does it reflect current practice?

2.26. Most responses stated that the majority of non-money purchase schemes do not provide annual benefit statements (nor currently have the capability to revalue benefits en masse) for deferred members and that current practice was only to provide this on request, but the extent of automation across schemes varies considerably. However, the notable exception to this seemed to be respondents representing public service pension schemes (PSPS) which indicated that they generally issue annual benefit statements to deferred members and agreed that the proposals represent current practice.

2.27. A significant number of respondents indicated that the system changes needed to enable information on deferred pensions to be provided in a timely manner will be costly and difficult for industry to achieve due to a lack of capacity amongst administrators.

2.28. One particular concern was that the publicity around the launch of pensions dashboards services could lead to an increase in requests for information from deferred members and this would make it difficult to meet the ten-day response time.

2.29. Suggestions included:

• If dashboards could provide calculations this would be easier for industry.
• Government could allow deferred values to not be revalued for a temporary period.
• ISPs may be able to support schemes that do not have the capability to carry out revaluations in-house.

2.30. Notwithstanding the challenges to industry, a large number of respondents agreed that the proposals to revalue values would represent an improvement in the information provided to deferred members and agreed with the reasoning behind the policy. One respondent also indicated that while this would require significant work up front, revaluation should then become routine.

2.31. However, some respondents indicated that they didn’t have much demand for this information, so questioned whether it is proportionate for schemes to undertake the costly work which would be required to meet the requirements.

2.32. In terms of methodology, respondents highlighted that there are some good reasons not to revalue deferred benefits to current date. These included that this could overstate the benefit in retirement (if there was a period of deflation), and highlight other inaccuracies such as that any early retirement deductions would not be taken into account. This would also mean that values would only be accurate if the individual did not take a lump sum.

2.33. One respondent to the consultation suggested a principle-based approach could be more appropriate. That is, that the Regulations should require a deferred pension to be revalued to the illustration date in a way that is broadly consistent with how the benefits would be calculated at normal pension age, with trustees given discretion over all the details. This would also allow them to pick up various complexities appropriately such as the impact of pension sharing orders, temporary pensions, state pension deductions.

2.34. One respondent indicated that some schemes would have little ability to recoup costs during the life of the scheme and to keep costs down, trustees may unduly rush calculations to the detriment of members and security.

2.35. With respect to the drafting of the methodology within the Regulations, other concerns included:

• It is unclear what value will be shown for deferred members older than normal retirement age.
• The Regulations may unintentionally exclude non-money purchase schemes which include a money purchase additional voluntary contribution (AVC) arrangement (or require the AVCs to be displayed separately).
• Illustrations could be up to two years old in specific circumstances.
• Clarifications needed on specific treatment expected for Guaranteed Minimum Pension (GMP).
• There would need to be messaging displayed to individuals using dashboards to explain that the values shown are estimates.

2.36. While not exclusively related to deferred members, as opposed to non-money purchase benefits more generally, some respondents also commented that consideration needed to be given to schemes with Protected Retirement Ages, benefits with tranches and individual who would get a step up between 60 and 65.

Government response: Question 7

2.37. From the mixed responses we had to this question, it is clear that there would not be a single approach that would completely satisfy all parties. We believe that including values for deferred non-money purchase benefits is an important element in enabling dashboards to provide a good user experience and to achieve the policy aims. Similarly, it is important that deferred members’ value data is revalued as we think this would provide the most meaningful information to individuals. There will be standardised messaging which will explain value data returns to individuals and contextual information data elements are provided to support an individual’s understanding of the information they receive.

2.38. In response to concerns some respondents to the consultation raised about costs that will be incurred by changing systems and challenges in providing a revalued accrued value for deferred members, we will offer schemes a simplified approach to calculating this value. This is explained in more detail in the Government response to questions 8 and 8a. Similarly, more clarity on providing AVC entitlements is within the Government response to questions 11 and 12, and policy on members over normal retirement date in the response to question 13.

Non-money purchase benefits with tranches, different retirement ages, step-ups

2.39. We will amend the Regulations to provide trustees or managers with flexibility when returning the values set out in Schedule 3, Part 1, paragraph 2 (non-money purchase benefits), so that they can take the approach that they feel would provide the best representation of the benefit, either:

• a combined value covering all the tranches of benefit, along with a single common retirement date; or
• a separate set of values for different combinations of tranches of benefits, along with a retirement date in relation to each.

2.40. Trustees and managers would also be required to provide a message explaining where a benefit referred to may cease or reduce from a certain age

2.41. The same principle would hold for deferred members, for whom schemes are now able to provide either a single combined accrued value with a single retirement date; or an accrued value for each tranche.

2.42. Where a scheme has returned values/sets of values for more than one tranche in a benefit, they are now required to return a start and end date in respect of each separate value data returned under the relevant provision in Schedule 3, Part 1. The remainder of the contextual information is common for all tranches so would only need to be returned once.

Summary of responses: Questions 8 and 8a

Question 8: Would provision of an alternative, simplified approach to calculate the deferred non-money purchase benefits as described make a material difference in terms of coverage, speed of delivery or cost of delivery of deferred values for any members for whom the standard calculation (pension revalued to current date in line with scheme rules) is not available?

2.43. Overall, there was a range of opposing views on this. Of those that responded to this question, just over half supported a simplified approach. Others did not oppose having a simplified approach, and stated that they wouldn’t use it. A smaller number were against including such an approach.

2.44. Of those that stated they would not use a simplified approach, the majority were public service pension scheme representatives. These schemes suggested that they would not need this functionality as they already carry out calculations based on scheme rules or have a single rate of revaluation.

2.45. There were clear concerns expressed from some about providing values which are (knowingly) inaccurate and would therefore seek assurances over liability.

2.46. Some respondents suggested that providing a simplified approach (even time-bound) could discourage and delay schemes from investing in improving their data/systems.

2.47. Of those that supported having a simplified approach – which included schemes that wouldn’t use it themselves but recognised that others would - were supportive on the basis of deliverability, ultimately that it would make it easier for some schemes to return a value.

2.48. Some of those who supported having a simplified approach suggested that it could be for a limited period (with some suggesting the end point should be set out in the Regulations, with others suggesting this should be subject to future consultation). Most who supported a simplified approach suggested allowing both methods of calculation; but many also said that the simplified version should only be provided where absolutely necessary; and that trustees would need to make the decision (and record it).

Question 8a: If a scheme were to use the alternative, simplified approach to calculate the deferred non-money purchase value, would the resulting values be accurate enough for the purpose of dashboards as a comparison with other pension values? Is the potential for this degree of inconsistency of approach reasonable? What are the potential risks to consumers or schemes in providing a value based on a simplified calculation?

2.49. As with question 8, there were a range of responses to this question.

2.50. Most public service pension scheme representatives suggested that a simplified methodology would cause problems with consistency and accuracy (compared with their response to Question 8 that many already follow a scheme rules approach).

2.51. A number of respondents suggested that it would be better to have the ‘right’ answer, at the expense of return times or overall requirements relating to timing.

2.52. There were significant numbers of respondents, however, who were supportive of employing a simplified approach, running in parallel, and perhaps as a second-order choice. Arguments included:

• all values are estimates anyway;
• simplified valuation tends to understate, so is therefore less risky.

2.53. Where a simplified approach was accepted, it was often on the basis of it being only in a limited set of circumstances and scheme rules wherever possible; being time limited so schemes should move towards scheme rules approaches; and with very clear caveats presented to individuals using dashboards and a specific data flag.

2.54. It was also noted that trustees should make clear (and documented) decisions with advice from actuaries about the use of the simplified approach for different groups.

2.55. Some suggested that a simplified approach could be improved by incorporating some scheme provisions - such as Retail Price Index (RPI), or non-revalued benefits.

2.56. There were also isolated suggestions that re-valuing with the latest Occupational Pensions (Revaluation) Orderon orders rather than uncapped inflation would be more accurate.

Government response: Questions 8 and 8a

2.57. The draft Regulations set out (in Schedule 3, Part 1, paragraph 2(1)(b)) the requirements for non-money purchase benefits for deferred members – calculated in accordance with scheme rules and valued to the illustration date.

2.58. Considering the responses, we will alter the Regulations to allow a simplified approach to be used when calculating deferred members’ non-money purchase benefits. A simplified calculation is an accrued value which is calculated to the illustration date by adjusting for inflation the value of the benefit at the date of leaving the scheme. However, we will restrict the use of a simplified method to a limited period, that is within two years after the scheme’s connection date, which we believe should allow schemes sufficient time to improve their data and their systems. We have also sought to ensure that the simplified option is only used in cases where it would not be possible to provide a full calculation without incurring disproportionate costs or outside of a reasonable timescale; and where trustees or managers are content that the alternative accrued value would not be misleading as to the value of the benefits. Additionally, a flag to indicate that the simplified calculation has been used, must be returned.

2.59. Trustees or managers should apply the method(s) of adjustment most appropriate for the benefit. This may include the relevant inflation figures or the appropriate percentages from the most recent update of the Occupational Pensions (Revaluation) Order (e.g. The Occupational Pensions (Revaluation) Order 2021).

Summary of responses: Question 9

Question 9: Do the Regulations as drafted fulfil our policy intent for cash balance benefits, and do the requirements reflect current practice in delivering values?

2.60. The majority of respondents to the consultation did not respond to this question.

2.61. Two thirds of those that responded agreed that the Regulations meet the policy intent and delivered broad consistency between illustrations for money purchase, non-money purchase and cash balance benefits on dashboards. No respondents stated that the Regulations did not fulfil our policy intent, though one third didn’t provide a direct answer to the question.

2.62. Several respondents indicated that the proposals are a shift from current practice because schemes that have cash balance arrangements currently do not issue annual benefit statements.

Government response: Question 9

2.63. Based on the responses we received, we are content that the Regulations fulfil our policy intent for cash balance schemes. We have noted the point raised in one of the responses that ‘definitions need to clarify that the Regulations require lump sum amounts and not actuarial values’, and we would like to confirm that this is indeed our policy intent: we have changed the terminology so that the requirements are presented as accrued and projected ‘fund values’, which are the value of an individual’s accrued rights.

Provision permitting cash balance schemes not to provide annualised values in certain circumstances

2.64. Respondents highlighted that some schemes provide cash balance benefits, which have the sole purpose to provide a lump sum. There is often no mechanism within the scheme, nor any expectation, to annuitise the cash balance amount. Hence, a requirement in the Regulations to provide annualised values for cash balance benefits would be problematic for the scheme trustees or managers (and confusing for the individual) where the entitlement has been set up with the specific intention of providing a lump sum.

2.65. Therefore, we will change the Regulations to indicate that if a cash balance benefit has been set up with the express intention of providing a lump sum to a member, and no annualised amount is due, then a scheme’s trustees or managers need not apply requirements set out in schedule 3 of the regulations to provide an annualised figure only. The lump sum values do need to be provided though, in all cases. This provision is not intended to enable trustees or managers to present the prediction of a choice that will be made at retirement, and we are aiming to prevent schemes making decisions on members behalf’s about lump sums; it is intended to be a specific reflection of the stated purpose of the scheme, and only used in those cases.

Summary of responses: Question 10

Question 10: Is displaying more than one value, to account for legacy and new schemes, in respect of members affected by the McCloud judgement and Deferred Choice Underpin (DCU) a feasible approach? Do consultees believe it is the correct approach in terms of user experience?

2.66. Of the answers we received to this question, respondents disagreed on the best approach. Some respondents indicated that displaying two values risks being too confusing and that individuals may think they are entitled to receive both values. However, others agreed that displaying two values was the correct approach in order to be accurate and many suggested that the values displayed on dashboards should mirror any requirements for benefit statements to ensure consistency. Others were of the view that it was too early to determine what values should be displayed because McCloud legislation was still being worked through.

2.67. It was noted that not all schemes are affected the same way and in particular, the local government pension scheme and Judiciary schemes do not have a deferred choice about which information needs to be reflected on dashboards.

2.68. Of those that commented, most agreed that whatever approach is taken, simplicity was a priority and it will be important that individuals are provided with clear contextual information or signposting so that they understand the values being displayed.

2.69. A number of respondents highlighted that it will not be feasible for Public Service Pension Schemes (PSPS) to provide two values as they would not have issued statements reflecting the McCloud remedy at this time.

Government response: Question 10

2.70. We have discussed our approach to this issue with colleagues in HM Treasury and the other responsible departments. From those discussions, we have concluded that requirements relating to the McCloud remedy and DCU values should in fact be presented more tightly; and that it is clear which types of scheme should be required to provide two sets of values.

2.71. We will amend the Regulations to reflect that the requirement for schemes to provide two sets of values only applies to members of certain public service pension schemes. These are those schemes who are in ‘Chapter 1’, defined in s.33(1) of the Public Service Pensions and Judicial Offices Act 2022, who have remediable service as defined in s.1 of that Act

2.72. In practice, this will exclude those members of Judiciary pension schemes (who are covered in chapter 2 of the Act); and local government members, as covered in chapter 3. For these members of chapter 2 and 3 schemes, there should be no requirement to produce two sets of values because these schemes do not have a deferred choice about which information needs to be reflected on dashboards.

2.73. We will also amend the regulations so that the approach reflects the operation of the McCloud remedy for ‘Chapter 1’ schemes. After the retrospective provisions of the Act, particularly s.2, come into force, all members will be treated as having accrued service in the legacy schemes for the period 1 April 2015 to 31 March 2022. Then, when they come to retire, they can make an election for new scheme benefits (under s.10 of the Public Service Pensions and Judicial Offices Act) if they want to.

Summary of responses: Questions 11 and 12

Question 11: We have proposed that hybrid schemes should return the value data elements as outlined for money purchase/non-money purchase schemes depending on the structure of the individual’s benefit within the scheme, within the relevant timescales. Are the regulations drafted in such a way as to deliver the policy intent stated, and is this deliverable?

2.74. Responses to this question can be categorised under the following headings:

2.75. Intent: Most respondents stated that the approach we have set out is straightforward and makes sense.

2.76. Several respondents agreed that it would be easier to provide money purchase and non-money purchase benefits separately, with a small number stating that this should be the only approach for hybrids.

2.77. Comparability/calculating projected element: Several respondents suggested that it is not appropriate to compare the money purchase projection (using AS TM1) with the non-money purchase projection. This may throw up anomalies and lead to situations where non-money purchase is returned for accrued, but money purchase is returned for projection, leading to confusion. It was suggested that trustees should be afforded flexibility to undertake a more meaningful comparison (which may also help to mitigate against the anomalies).

2.78. Return times: There was a fairly even split between those that believed return times would be achievable, and those that believed they would be challenging. Respondents on both sides raised that return times should be the same for the non-money purchase and money purchase elements of hybrid schemes (i.e., no 3 day and 10-day difference). Respondents commented that the user experience would be sub-optimal if not and may lead to individuals prompting continued requests which do not get viewed. The return time should be 10 days for both.

2.79. Additional Voluntary Contributions (AVCs): With regard to separately provided AVCs, the general view was that these should be provided separately to the main scheme benefit by the provider of the AVC because general practice is that the two amounts are considered separate. Additionally, some respondents suggested that separately provided AVCs with links to the main benefit may not be returned at the same time depending on if the benefit is money purchase or non-money purchase and may lead to confusion for the user (essentially their linked benefit could arrive in 3 days if money purchase, but their main benefit could be non-money purchase and take 10 days, or vice versa).

2.80. Over a third of those that responded sought clarity on requirements for AVCs.

Question 12: Our policy intention is that where a benefit is calculated with reference to both money purchase and non-money purchase values (as opposed to hybrid schemes with separate values), schemes should only provide a single value. The regulations do not currently make this explicit. Would a requirement that a scheme must supply only the data for the greater benefit of the two cover all scenarios with mixed benefits? Are there other hybrid scenarios which are not covered within these Regulations?

2.81. Of those that responded to this question, two-thirds were in favour of showing a figure and a third were against showing any figure at all.

2.82. Most responses pointed out the complexity in making the comparison and questioned how it should be undertaken. This led those who were in favour to be broken further down into:

• Those that believed it should be a combination but ultimately the scheme should be able to choose the best figure (including methodology to apply to calculate it) that best represents the benefit, which was the most well-supported approach;
• Those that believed the higher figure should be shown;
• and a single suggestion of both.

2.83. A number suggested the scheme should be able to provide some explanation to contextualise the number and weren’t in favour of frequent calculations.

2.84. For those not in favour, they questioned the value in undertaking this exercise given the application of the hybrid benefit won’t be known until normal retirement date, especially when a ‘partial’ red flag could be utilised. Respondents also pointed out the complexity in making the comparison between money purchase and non-money purchase calculations and questioned how it should be undertaken. Some suggested that a single figure would be misleading. Finally, there were suggestions that it may be better to give contextual information instead as they would need to be able to explain the figure in detail.

Government response: Questions 11 and 12

Additional Voluntary Contributions (AVCs)

2.85. As outlined in the question 11 summary above, a significant number of respondents outlined that more detail would be required on requirements for AVCs. We have responded to those specific questions below:

• Whether these are considered to be money purchase benefits for the purposes of these draft Regulations and whether this position differs for the private and public sectors?
  • The AVC should be provided as the type of benefit it is. In essence, if the AVC is non-money purchase, it should be treated as such.
• What AVC data will need to be returned to pensions dashboard services?
  • The same accrued and projected value data as required by the Regulations for other scheme types, depending on whether the AVC is money purchase or non-money purchase.
• Which parties would be responsible for making that data available?
  • MaPS data standards, which are subject to consultation, propose to allow for the scheme to decide if it allows the AVC provider to send the data separately, for which the return would be flagged with the ‘pension link’ data element, or for the trustee or manager to gather the data from the AVC provider to present alongside scheme benefits. In practice we expect the data will be made available to dashboards by whomever administers the AVC – this may be a commercial AVC provider. But, in those circumstances, trustees would still be legally accountable for ensuring that this happens and will need to work with their AVC provider accordingly.

Approach to hybrid benefits

2.86. While the Regulations did not include a provision for hybrid benefits, we asked specifically about an approach for providing values for these in the consultation. The approach that we consulted on in respect of hybrid benefits was, where one benefit is calculated with reference to both money purchase and non-money purchase formulas (e.g., one with an underpin of the other), only the greater value should be provided.

2.87. Responses to the consultation showed that the ‘higher of’ format is not the only structure of hybrid benefit, and that there are other structures, which are too numerous and too varied to be able to describe adequately within the Regulations. On account of this, we have decided on an approach which is designed to give trustees or managers greater flexibility when returning values in respect of hybrid benefits. This would still see trustees or managers follow the methodologies for the appropriate pension types described in Schedule 3 (trustees or managers cannot use a new calculation approach), but they will be able to exercise discretion on which methodology they should apply, based on what they consider to best represent the value of the member’s benefits under the scheme.

Hybrid scheme response times

2.88. We do not feel it is appropriate for hybrid schemes to get a blanket 10-day response time for providing value data. A third of all relevant members (over 1 million) of hybrid schemes only hold money purchase benefits within the scheme. We feel it is unacceptable for members such as these to wait 10 days to receive their value information, where they should be receiving it in 3 days.

2.89. To clarify, any benefit which is solely a MP benefit should be returned in 3 days; but any benefit which includes anything other than a money-purchase calculation should be returned in 10 days. If a benefit is a hybrid benefit, and includes anything other than a money purchase calculation, then it should get 10 days. In a hybrid scheme, each benefit within that scheme should be returned on its own merit (i.e., a money purchase benefit within a hybrid scheme would be returned within in 3 days; a non-money purchase benefit would be returned within 10; a hybrid benefit within a hybrid scheme would be returned as per the description above).

Summary of responses: Question 13

Question 13: Are the accrued values for different scheme and member types deliverable, and can they be produced in the time frames set out in the ‘Response times’ section? Are these values necessary for optimal user experience?

2.90. Just over two-thirds of respondents of the consultation answered this question. Responses can be categorised as follows:

2.91. Response times: Respondents raised concerns over the 3- and 10-day (we will refer to this as “3/10” for simplicity) response times. Around a quarter of respondents raised that if the data had already been generated and was available, they would be able to provide it within the timescales, but if data is not readily available, then 3/10 days would be challenging. In those instances where schemes are not able to provide value data immediately, there are usually a number of reasons (not automated, complex calculations, need third party input, etc.). In such cases, it was thought unlikely that they will be resolved, calculations re-calculated, systems updated, and value provided to dashboard within 3/10 days.

2.92. Conversely, about a quarter of responses stated that the 3/10-day response times are achievable, with some stating that these should be reviewed and reduced on an ongoing basis.

2.93. Several respondents were concerned about the operational impact of the return times, and increased requests for information caused by their members using dashboards, on day-to-day administration. It was suggested that day-to-day operations could need to be de-prioritised in order to meet 3/10 day return times, which may create a 2-tier system of dashboard requests versus other requests.

2.94. Annualised accrued value: A number of respondents had concerns on the requirement to provide an annualised accrued value, for a range of reasons:

• The value omits important contexts of AS TM1 and is purely hypothetical.
• Every money purchase scheme will be required to produce this value, unlike projections where there is £5k de-minimis exemption (Disclosure Regulations 2013, regulation 17(6)(c)). Therefore, it may be confusing to users to see very small annualised accrued income but no projection.
• For those members close to retirement, it omits AS TM1 elements that would be included in projections, but projections are exempt for <2yrs from retirement.

2.95. Some stated that the inclusion of this value was well-intentioned and would be deliverable in 2023 but recommend further user research/testing to ensure that users did not misunderstand the figure and it didn’t lead to confusion, as well as some of the reasons mentioned above in some cases.

2.96. However, there were a large number of respondents who expressed views that the complete suite of value data we proposed, including the annualised accrued value, was necessary for optimal user experience. A small number suggested that all of the value data proposals were necessary for a minimum viable product.

2.97. Normal Pension Age (NPA)/retirement date: Many respondents stated that the definition of normal pension age (NPA) doesn’t align with the AS TM1 and Disclosure Regulations 2013 definition of ‘retirement date’, and instead dashboard Regulations should refer to ‘retirement date’ (as in Disclosure Regulations 2013) rather than NPA. Respondents also stated that NPA was inconsistently interpreted amongst non-money purchase schemes, including as: the date on which a pension can first be taken, the date on which a pension can be taken without reduction, a date on which it can be taken without third party consent, or a date after which the pension will be increased for late payment.

Government response: Question 13

Annualised accrued value

2.98. Although we recognise it is a new requirement for schemes, we believe the annualised accrued value will help individuals to contextualise and better-understand the amount of pension they have accrued in a scheme by seeing it as an income as well as a single pot value. Because this value will be calculated using elements of AS TM1, it will not be required from money purchase schemes until the first statement has been given, or the calculation has first been performed, after 1 October 2023. This coincides with when it is planned that the Financial Reporting Council’s updated AS TM1 guidance will come into force.

2.99. We will alter the regulations to clarify the methodology for calculating this value by requiring that annualised accrued values should be calculated as if the individual has reached their retirement date on the illustration date. Assuming the member has reached their retirement date, this essentially means for money purchase schemes that the annuity only has to last a ‘normal’ retirement period of time, rather than lasting from the age that the member is when the calculation is made (for example, 30 years old). We have tested this approach with industry representatives and collectively agree that this would make the description more meaningful, although we accept that there are some outstanding concerns. Our view is that this is an important value to show, and that there are no clear, viable alternatives which improve upon the approach taken.

2.100. We will alter the regulations so that this wording applies to all benefit types required to provide an annualised accrued value, to improve clarity and consistency.

2.101. Our response on issues respondents raised with regard to response times can be found in the collective response to questions 17, 18 and 19 in chapter 3.

Changing ‘normal pension age’ to ‘retirement date’

2.102. In response to a significant number of respondents indicating that ‘normal pension age’ is problematic, we will change references of ‘normal pension age’ within the Dashboards Regulations to ‘retirement date’. Our policy is for the definition to follow that at regulation 19(5) of the Disclosure Regulations 2013. We believe that, as well as aligning more closely with Disclosure, ‘retirement date’ gives some flexibility across all scheme types, enabling them to select the most appropriate date – including where they currently (for statements) might use normal pension age. We also think this will be helpful where a dashboard user is above normal pension age because it allows a value to be returned based on a future end date. This explained further below.

Providing projections to members over ‘retirement date’ age

2.103. Respondents to the consultation suggested that there should be a provision that allows projections to be illustrated beyond an individual’s normal pension age. We believe that our shift from ‘normal pension age’ to ‘retirement date’ (as described above), solves this problem by giving trustees and/or members flexibility to select the most appropriate retirement date, based on when the member plans to retire.

Summary of responses: Question 14

Question 14: Do you believe our proposals for data to be provided and displayed on dashboards, particularly on value data, provide the appropriate level of coverage to meet the needs of individuals and achieve the aims of the Dashboards programme?

2.104. The majority of respondents supported and agreed with the range of values we proposed.

2.105. There were some questions raised on how the values that will be presented on dashboards tie in with simpler statements.

2.106. A small number of respondents suggested that including guaranteed lump sum values would be beneficial; and not including an option for schemes to factor in lump sums incurs the risk of overstating income in retirement as that is what most members opt for.

2.107. There was belief that communication of values will be crucial to ensure that people understand the information displayed on dashboards before they act, and are clear that the values are estimates, not promises.

2.108. There was a suggestion to include an exemption for schemes in the Pension Protection Fund (PPF) assessment on providing value data.

2.109. A number of respondents sought clarity on what the methodology should be for calculating value information for users beyond retirement age.

Government response: Question 14

2.110. We are pleased that the majority of respondents agreed with our proposals for value data and believed that they were necessary for a positive user experience.

2.111. Dashboards and simpler annual benefit statements are separate initiatives, though we have made efforts to ensure that the information to be displayed on dashboards aligns with that which is displayed on benefit statements.

2.112. With regard to messaging on dashboards to make clear to individuals that values are not promises, MaPS’ intention is to consult on design standards which will include provision that allows schemes to convey messages such as this.

PPF

2.113. We cover changes relating to PPF assessment in Chapter 5 of this response.

Summary of responses: Question 15

Question 15: Are there ways in which industry burden in terms of producing and returning value data could be reduced without significant detriment to the experience of individuals using dashboards?

2.114. A significant number of respondents found the proposed approach to be deliverable and that the burden on industry cannot be reduced without harm to user experience, though several noted that automation is the only way that schemes will be able to manage the requirements.

2.115. There were calls from a number of respondents to ‘keep it simple’ but few practical suggestions on what this could mean aside from suggestions for a simpler approach on deferred non-money purchase values. Contrastingly, there were counter-calls from some, suggesting that simplification would cause poor user experience and inconsistency.

2.116. There were some suggestions that allowing calculations on dashboards could reduce burden and improve user experience. For example, dashboards could provide projections based on accrued pot and pension age; individuals could then manipulate the data and review different scenarios using income ‘sliders’ or similar tools. There was a similar suggestion of a central aggregator that would essentially allow schemes to input figures for automatic calculation by a third party.

Government response: Question 15

2.117. As per the response to questions 8 and 8a, we will include a simpler approach for calculating deferred non-money purchase values, which is aimed at reducing burden for schemes for a period of time where they are working towards automation.

2.118. In terms of enabling calculations on dashboards, we believe that manipulation of pensions information should be constrained in the early delivery of dashboards to a limited set of circumstances. The circumstances will be determined through the standards set by MaPS and the FCA’s rules for QPDS – each subject to forthcoming consultation. Our view is that providing a reasonably consistent view of pensions data will engender trust in dashboards.  

Chapter 3: Find and view

Introduction

3.1. The draft Regulations we consulted on would place requirements on trustees or managers of occupational pension schemes in relation to the processes involved in enabling individuals to find and view pensions information on dashboards. We proposed that trustees or managers would be required to:

• connect to the digital architecture to receive find and view requests;
• receive find requests, undertake matching and register any found pensions so that individuals could be matched to their pension; and
• receive and respond to view requests to make information available to an individual via a pensions dashboard service of their choosing.

Summary of responses: Question 16

Question 16: Is 30 days an appropriate length of time for individuals to respond to their pension scheme with the necessary additional information to turn a possible match into a match made?

3.2. The consultation sought views on the issue of possible matches to understand whether 30 days was a sufficient period for individuals to provide schemes with the necessary additional information to turn a possible match into a match made. The majority of respondents agreed 30 days was reasonable, subject to some clarification. A small minority said we should be more ambitious, and an even smaller minority (only from non-money purchase schemes) suggested longer was needed.

3.3. Within the responses, there were some misunderstandings on this issue and many respondents wanted further clarity on the 30-day response time and its practical application.

3.4. There was confusion around whether schemes would have to respond with data immediately upon the resolution of a possible match. Respondents also requested clarification about whether response times (the approach of giving schemes 3 or 10 days to provide value data in certain circumstances as set out in the next question) would apply after the possible match had been resolved.

3.5. We have summarised some of the other main points raised by respondents below:

• Some respondents queried how partial matches are turned into full matches.
• There were concerns raised around whether there was potential for permanent possible matches and, if a possible match is subsequently deemed not a match, what would need to happen to ensure it did not show up again for the individual who has made the request.
• There were concerns that the Regulations were not clear enough around who is responsible for resolving possible matches.
• Respondents questioned what would happen if an individual accesses their dashboard multiple times whilst the 30-day possible match period is ongoing and what would happen to stop them getting multiple error messages.
• There were concerns that this requirement could place additional burden on schemes and their administrators.
• A Pensions Identifier (PeI) will be de-registered after 30 days, but if it remained unresolved, would it be re-issued with every dashboard request. Respondents queried whether this was a problem.
• It was recognised that user research would be important to shape this requirement and understand whether it is effective. Any delay in seeing information caused by a possible match would put users off from using pensions dashboard services. It was suggested that online forms should be encouraged to allow for information to be provided more quickly.

Government response: Question 16

Resolution of possible matches

3.6. The consultation responses make it clear that whilst on the face of it, 30 days is considered a reasonable amount of time, the process for dealing with possible matches needed further clarification.

3.7. We will seek to do that through changes to the Regulations. Where a scheme is not confident that they can identify a ‘match made’ (for example, because they are not confident that all matching criteria have been met), trustees or managers should return a possible match and we have sought to amend regulations to ensure that trustees or managers are clear on what they must do when returning a possible match.

3.8. We intend that in returning a possible match, trustees or managers must provide both a limited form of administrative data (the name of the pension scheme and information about the scheme’s administrator) and an error message in accordance with data standards published by MaPS. No personal data or further details about the pension that might be a match for the member would be returned.

3.9. Combined, these will allow individuals to understand that the scheme in question has identified a possible match and that in order to ascertain whether a full match can be made, the individual must act by contacting the scheme. The limited administrative data will provide the contact information to allow the individual to contact the scheme in question.

3.10. The Regulations will also be changed to specify that the scheme must delete the find request information if the individual for whom a possible match has been identified does not contact the scheme within 30 days. If an individual makes contact within 30 days, where a possible match cannot be resolved within a time reasonably allowed by the pension scheme (having regard to guidance on matching) the scheme must delete the find request information.

3.11. An issue remains in relation to the potential for permanent possible matches. In cases where a possible match is subsequently deemed not to be a match made, we want to ensure that the possible match in question does not show up again for the individual who has made a request. This issue will be explored further with industry after regulations have been laid.

3.12. If, following contact from an individual, a scheme concludes that the original possible match is a “match made”, trustees or managers must ensure that they notify their internal resource server (see Glossary) as well as MaPS and they must re-register the PeI from a possible match to a match that has been made. This must be done in accordance with technical standards, and we anticipate that standards will specify how the process differs for a “match made” and a “possible match”. We do not anticipate that standards will specify how schemes should interact with their ISP (if they are using one), it will be for trustees or managers to facilitate this.

3.13. The key difference for trustees or managers of schemes is that the data which they must return is different. For a possible match, they will only send limited administrative data and an error code in response to view requests. In the case where a possible match is subsequently identified to be a match that is made, trustees or managers must, on receipt of a view request, provide the full view data in line with the proposed response times within the regulations. Either immediately, or within 3 or 10 days, depending on the circumstances.

Summary of responses: Questions 17, 18 and 19

Question 17: Do you think that the response times proposed are ambitious enough?

3.14. The consultation set out our ambition that all schemes will move towards the automation and digital storage of data to facilitate immediate responses to view requests in almost all cases. We recognised however that there will be cases where, at present, this is not possible. We therefore proposed allowing schemes up to 3, or 10 days to provide value data in certain cases. Question 17 sought to understand whether this proposed approach was ambitious enough.

3.15. There were three types of responses to this question, those in agreement, those that argued the response times were too ambitious and those that felt they were not ambitious enough.

3.16. Those in agreement flagged that a clear plan was needed to highlight how we will make response times instantaneous over time, and that the shift to ‘immediate’ as the default should be as soon as possible. There were concerns that data provision to dashboards must not come at the expense of other scheme operations (such as setting benefits for members retiring). It was also recognised that the response times would be challenging for smaller providers and those with less automation and that whilst setting response times of 3 and 10 ten days is a worthwhile ambition, there will still be times where this is not possible.

3.17. Those who argued that the response times were too ambitious were mostly non-money purchase schemes (mainly PSPS) and some administrators. There was concern that the need to respond to dashboard requests quickly would lead to a two-tier membership system where dashboard users are prioritised over non-dashboard users.

3.18. In relation to non-money purchase schemes, a specific challenge raised was the need to amend contracts with third party administrators and the cost of this. Current contracts are suitable to meet disclosure regulation requirements, but not the proposed dashboard requirements. There is a risk that even if contracts were changed to adhere to the legislation, they would still fail to meet requirements.

3.19. Some identified that the necessary changes to software to meet the requirements will be difficult to achieve within the time available and that the level of financial investment required would be high. It was felt that user research should play a crucial role in shaping response times and until more is known about dashboard user volumes, response times should continue to reflect disclosure regulations.

3.20. Those that said the response times were not ambitious enough were mainly the larger master trust schemes. There was a strong feeling among this group that most of the industry can provide much faster response times than what was proposed and that should be the expectation for dashboards. Some identified that it may be a better approach to have real-time (or very quick responses) using application programming interface (API) technology as the norm, with exemptions for certain legacy schemes which will never be able to respond instantly. There was also concern that the current proposals are unlikely to fulfil the expectations of individual users who will lose interest in dashboards if the data are not provided instantly.

Question 18: What issues are likely to prevent schemes being able to return data in line with the proposed response times?

3.21. A range of issues were cited by respondents to this question on the challenges they were likely to face, which fell into a few broad categories.

3.22. The most common problems cited related to issues with data. This included poor data quality (poor or missing data), poor technological systems (including a lack of automated systems, such as legacy systems that cannot be easily upgraded or replaced and software issues) and poor data storage.

3.23. Another concern was that of scheme-specific complexities impacting the ability to meet the proposed response times. These almost exclusively related to issues that required some form of human intervention in the process that meant it would take longer than 3 or 10 days to resolve the issue. For example:

• There may be a need for complex calculations, including calculations relating to deferred members.
• Schemes may have specific historic issues to consider while some cases may include features such as protected ages, pension credit, step-up pension, bridging pensions or Barber Window (for more information on these, please see the glossary of terms).
• Some respondents highlighted that a lack of knowledge about the detail of benefits or uncertainty about things like benefits scheme rules would have an impact on member comprehension.

3.24. Some PSPS highlighted that their dependency on employers providing them with information on time was an issue.

3.25. Respondents raised a range of further issues of concern:

• The volume of cases where it has been cited that it is likely to be difficult to return data in line with the proposed response times is unknown at this stage. This led to concerns around a lack of actuarial and administrative resource because it is not known how much resource would be required.
• Given the reliance on third parties, smaller schemes were concerned their business would not be viewed by third party suppliers as if it were as valuable as that of a larger scheme.
• Concerns around the impact on response times of a pensions administration system or the architecture being down.

Question 19: We are particularly keen to hear of where there could be specific difficulties to providing this data for exceptional cases, how many cases this might include, and whether consultees have views on how exceptions could be made without damaging the experience of individuals using dashboards for most cases where values can be provided more readily. Are there any specific cases when providing the information asked for would be particularly difficult?

3.26. In response to this question, respondents outlined instances that may make it difficult for schemes to meet the proposed response times. Responses made it apparent that it is difficult to grasp the scale of the issue and that additional issues may emerge as pensions dashboard services develop. For example, estimates ranged from 5% up to 20% of cases where a specific challenge was likely to make it hard to return values in line with the proposed response times.

3.27. The only suggestion put forward around how to deal with the cases where exceptions should be considered was that there should be a working group introduced to identify exceptional cases and to understand the scale of the problem related to them. Respondents also made it clear that if exceptions were listed, care would need to be taken to ensure that these could be updated to reflect developments.

3.28. The most common issue raised by almost half of respondents was that of non-standard or complex benefits that will be tricky to make a calculation on within the proposed response times. According to these respondents, complex benefits could include:

• calculations involving top up schemes
• bridging pensions
• divorce cases
• complex underpins
• annual allowance charges
• legacy consolidations
• protected or hidden benefits
• schemes with multiple categories of members with complex benefit structures
• pension credit members
• Pension Sharing Order (PSO) cases
• hybrid benefits, or aggregation cases.

3.29. Other issues raised include:

• Schemes which have multiple retirement ages where it is often not possible to amalgamate two tranches of benefits.
• Cases where trustees need legal advice around scheme rules.
• Complications related to members over normal retirement age.
• In the case of firefighters, some members’ information is more difficult to calculate because they do not have a set pattern of service or salary and do not always receive an automated ABS (Annual Benefit Statement).
• Further difficulties were highlighted in the case of ‘Special members’ (Matthews ruling 2006). This led to legislation being introduced to ensure that retained firefighters employed between July 2000 and April 2006 had the right to be treated no less favourably than wholetime firefighters.
• Schemes with distinct types of AVCs.
• It was highlighted that there should be an exception where other action is already taking place (like a member transferring out and leaving the scheme or transferring in).
• Poor data quality was another issue flagged mainly by PSPS and master trusts.
• Many stated that it would be difficult to provide data because of issues with the employer failing to provide pensionable pay data for employees working zero-hour contracts, or employees who have another form of casual contract.
• For schemes where there is a change of administrator, it is likely that a new administrator would identify data issues that need addressing. This would impact on a scheme’s ability to respond on time.

3.30. Multiple issues were flagged only once; this does not reflect that they are less important, but does highlight that there are many issues to consider when thinking of cases that may require an exception:

• A member may have requested to opt out of their scheme, but this may not have been processed when they made a dashboard request.
• Schemes undertaking a bulk switch of investments.
• Operation of caps and collars on benefit increases.
• Untraced deferred members.
• People over State Pension age.
• A lack of automation to calculate values needed or the inability to automate certain data to be provided on time.
• Instances where investigations are ongoing with respect to criminal activity (fraud / investigations related to the Proceeds of Crime Act 2002).
• Where an insolvency event has occurred triggering Pension Protection Fund (PFF) assessment or scheme wind up.
• Schemes with different payment dates (such as schemes affected by McCloud).

3.31. These examples highlight a wide range of complex cases where it may be difficult to provide the required data within the specified response times. This could have an impact on the user experience and is an area that will need to be explored further through user testing.

Government response: Questions 17, 18 and 19

Response times

3.32. Having reflected on this range of views, we believe it is right to proceed with the proposed approach set out in the draft Regulations for consultation. We recognise that there are cases where response times will be difficult to adhere to. That is why we have highlighted examples of the exceptional cases section below where TPR may use their discretion when enforcing breaches. It means that in relation to response times:

• The time limit for the proposed response times begins for schemes from the point at which a scheme receives an individual’s information from the digital architecture. The exception to this is where initial possible matches are later turned into matches that are made. In these cases, the clock will start from the receipt of a view request. Once trustees or scheme managers have received a view request, they must adhere to the proposed response times (immediate, 3, or 10 days depending on the circumstances of each individual case).
• All schemes must provide administrative data immediately.
• Value data may be provided based on a value that has been generated for a benefit statement or generated for another purpose but using the same methodology, within the last 12 months. Where this value has been generated in this way, value data must be provided immediately.
• Where a value has not been generated or provided on a statement within the last 12 months, all pension schemes must return value data within 3 days, or 10 days in the case of non-money purchase benefits.
• Schemes which offer benefits where the benefit value is calculated with reference to both money purchase benefits and non-money purchase benefits will also have 10 days.
• Schemes which offer hybrid benefits that only contain a mixture of different money-purchase benefits, will have 3 days to respond.

3.33. With regards to values from statements, we know that many providers will want to rely on the values provided in annual statements. We recognise, however, that there may be some fluctuations in the delivery of annual statements, meaning that if a dashboard request is made just over 12 months after a statement was last provided to the individual, but just before the next statement has been provided, then a valid statement value would not be available.

3.34. We are therefore changing the requirement that values must be from a statement provided to the member within the last 12 months to a requirement that it must be from a statement provided to the member within the last 13 months. This is to provide some operatinoal flexibility, while maintaining the general policy requirement. Where statements are provided beyond the 13-month window, values must to be based on a new calculation, and the requirements for values based on calculations outside of statements remain at 12 months.

Exceptional cases

3.35. What did become clear from the consultation responses was that there may be cases where it is not possible to provide data in line with the proposed response times. Having reviewed the consultation responses in full, the list of examples where this may be the case is extensive. In addition, it may well be the case that as dashboards develop, challenges may increase or reduce as schemes find ways to meet the proposed response times.

3.36. Until dashboards are fully operational and tested at scale, we cannot fully understand the range and extent of the challenges that schemes will face in providing data.

3.37. We want pensions dashboard services to deliver the best user experience. The response times proposed will be immediate in most cases. Our longer-term ambition is to achieve responses times that are as short as possible for all values in all cases. We believe this is achievable and we expect industry to strive towards this goal. When dashboards are launched, we are committed to working with MaPS and the regulators to monitor response times and consider how best to work towards our longer-term ambition.

3.38. We will not be providing any exceptions from providing value data within the times set out in the Regulations. The compliance framework does allow TPR discretion in deciding whether to take enforcement action in respect of a breach of the Regulations and TPR will take individual circumstances into account. We understand TPR intend to consult on their compliance and enforcement policy shortly after DWP has laid the Regulations before Parliament.

Use of ‘immediately’ in Regulations

3.39. In the draft Regulations, we referred to actions as having to be carried out “immediately” in relation to the duties on trustees or managers to provide data to dashboards. For example:

• Matching – must be completed immediately.
• In the case of a match made, schemes must immediately create and register a PeI with their resource server and MaPS.
• In the case of a possible match, schemes must immediately provide a limited form of administrative data and an error message.
• All schemes should provide administrative data immediately.
• All schemes must immediately, after a view request is received, provide a website address to locations where signpost data can be accessed.
• With regards to value data, where a value has been generated for a statement within the past 12 months or is based on a calculation made within the last 12 months, this too must be returned immediately.

3.40. MaPS will provide further information around the timeframes for immediate responses within their standards (service standards – part of the code of connection). We expect that MaPS will be consulting on their suite of standards shortly after the publication of this document, but when referring to things needing to be done ‘immediately’, within the regulations, the intention is that action must be completed as quickly as it can be done. The expectation is to deliver responses within seconds. The PDP has proposed that find requests should realistically be responded to in under 1 second and view requests responded to in under 2 seconds.

3.41. We recognise that in relation to matching and the registration of a PeI, it is likely to take a little longer, particularly in cases where organisations have previously undertaken mergers, acquisitions or have legacy systems that require them to search in multiple places. In cases like this, unless schemes have not stored their information in one place prior to connecting to dashboards, the PDP estimates that matching and, therefore registration of the PeI, could take up to 60 seconds. We understand that as part of their consultation on standards (code of connection specifically) expected shortly after the publication of this document, MaPS will propose that schemes must register their PeI (which will involve matching) in under 60 seconds with a target of 15 seconds. We are content that this proposal would fit within the meaning of ‘immediate’. Trustees or managers of schemes will have the opportunity to comment on these proposals in response to MaPS’ consultation on standards which we understand will be published shortly after the publication of this consultation response.

Matching

3.42. Within our consultation, we made clear that trustees or managers of schemes will need to adhere both with their requirements to conduct matching and their duties under data protection legislation. These duties go hand in hand and should be considered equally. Schemes must always be considering whether there are improvements that can be made. If they are not happy with their data, we expect consideration will be given to how they can improve it to match more effectively whilst minimising the risk of data protection legislation breaches. We expect that schemes will regularly revisit their matching policy to ensure that a successful balance is struck between holding good data and delivering a positive user experience.

3.43. Through positive and proactive action by trustees or managers of schemes, we will avoid situations where the rate of successful matches made is low because schemes are concerned about breaching data protection legislation. It will also ensure that schemes are constantly developing their policies to minimise the risk of data protection legislation breaches. We are clear that both circumstances not only demonstrate a poor user experience, but in the case of data protection legislation breaches, could also bring into question the security of the dashboards ecosystem.

3.44. We have high expectations of the role that trustees, or managers will play in relation to their duty to match, but we recognise that it is not always straightforward and there will be cases that cannot simply be mitigated by positive, proactive action. This was evidenced by numerous responses which referred to the need for further clarity around how both the ICO and TPR would approach enforcement of matching on dashboards.

3.45. Within their consultation response, the ICO provided helpful clarity around how schemes can ensure they conduct matching in a way that is safe and secure. For the purposes of Article 35(4) UK GDPR, the matching, combining or comparing of data from multiple sources is one of the operations that automatically requires a Data Protection Impact Assessment (DPIA).

3.46. Schemes may already possess a DPIA covering their matching process and as such, it may be the case that these need to be updated to ensure that they consider the likely increase in the scale of data matching that will be conducted when connecting to the digital architecture and responding to find requests. DPIAs are iterative documents which need to be kept under review and updated following substantial change to the nature, scope, context or purpose of processing. Organisations should actively consider the benefits of producing or reviewing their DPIAs to demonstrate compliance. The publication of DPIAs can also help to engender public trust and confidence.

3.47. In their consultation response, the ICO also reiterated our concerns around data being inappropriately disclosed to the wrong person, particularly given the volume of data that will be processed through pensions dashboards. They recognised the need for great care to be taken to ensure that data is processed securely. To ensure that organisations process data securely, the ICO have advised that the considerations which schemes must consider are detailed in Article 32(1) of the UK GDPR. These include the cost of implementation and the significant risk to the rights and freedoms of the individual.

3.48. The level of security that is implemented should align to the level of risk and should be documented in the DPIA(s). The ICO has produced guidance on security of processing data which may also be of use when considering the security measures to implement.

3.49. Finally, the ICO outlined that for the purpose of matching, data providers must consider the data minimisation principle when setting their own matching criteria.^{[footnote 2]} This means that data providers should identify the minimum amount of personal data they need to fulfil their required purpose. This information should be held, but no more. The ICO emphasised that the data minimisation principle also “requires that the data being processed is ‘adequate’ meaning the controller must be satisfied that the find data they process is sufficient to fulfil the stated purpose (i.e., to accurately identify matches)”.

3.50. TPR will be regulating trustee and scheme manager compliance with their duties, including those on matching. TPR will be consulting on their proposed compliance and enforcement policy later in the year.

3.51. In June, TPR published its initial guidance on pensions dashboards. TPR expects trustees and scheme managers to consider the availability and accuracy of a scheme’s data when deciding on their matching criteria.

3.52. Trustees and scheme managers need to be confident in the accuracy of the data they are using for matching and put a plan in place to improve this data if required. While this work is underway, they should broaden their matching criteria to include more items. This should increase their confidence that they are matching to the right person, without increasing the risk that they fail to find someone when they should.

3.53. For example, if a scheme wishes to use DOB, NINO and surname for matching, but they have some concern around the quality of DOB, they could add postcode and first name to their matching criteria, while they deliver improvements to the DOB data. When these improvements are done, they can review their matching criteria back to DOB, NINO and surname.

3.54. Trustees and scheme managers should return a ‘possible match’ if they think there may be a match but are not confident they have definitely ‘made a match’. The dashboard user will be encouraged to contact the scheme and provide any further information required to provide trustees with confidence that they have found the right person.
 

Chapter 4: Connection

Introduction

4.1. The consultation document set out proposed requirements for trustees or managers of relevant occupational pension schemes in relation to the initial connection of their scheme to the digital architecture, as well as the ongoing requirements of remaining connected. The proposals included requirements to:

• complete connection during a specified window
• cooperate with MaPS to support connection
• maintain connection and adherence with standards set by MaPS
• have regard to guidance in relation to connection
• report specified information related to connection to MaPS

4.2. The consultation document also provided details about how schemes could apply for early connection and high-level details about what would be expected to be included in pre-connection steps to be set out in standards.

Summary of responses: Question 20

Question 20: Do the proposed connection requirements seem appropriate and reasonable? If not, what alternative approach would you suggest and why?

4.3. Most respondents agreed the connection requirement proposals were appropriate and reasonable, with some expressing general support while specifying some caveats. There were however some respondents that expressed concerns about the proposals. We have summarised some of the concerns raised below.

4.4. Several respondents indicated their need for clarity on the standards and guidance for connection.

4.5. A small number of respondents voiced concerns that a period of one month is too short a connection window and leaves little contingency for any technical issues to be corrected if problems are encountered. Related to this, one respondent indicated there was a risk of “bunching” connection dates at the beginning and end of each connection window as schemes either sought to allow themselves as much time as possible before they needed to connect or sought to connect as early as possible in case of technical issues which needed to be addressed before the staging deadline.

4.6. Some respondents highlighted a dependency on the ISP market developing and were concerned by a lack of information currently available about how these organisations will operate. Another point of contention was that it would not be feasible for scheme managers and trustees to decide on connection issues individually and that they will in practice be reliant on their administration and software providers.

4.7. A few respondents representing locally-administered public service pension schemes (PSPS) indicated that while the requirements were reasonable for centrally-administered schemes, the requirements were not appropriate for locally-administered schemes which have complex governance structures with expectations on scheme managers, and scheme advisory boards (which are unique to locally administered public service pensions schemes).

4.8. Other respondents highlighted that early connection via an already-connected endpoint should be streamlined and actively encouraged.

4.9. Some respondents flagged a concern about the notification requirements for any disconnection set out in draft regulation 20 which specified this would need to be completed “immediately”. The responses urged greater flexibility in the timescales because notification would require human intervention and it was therefore unreasonable to expect an immediate notification in the middle of the night or at weekends.

4.10. Some respondents voiced concerns about the rigidity of the connection requirements, urging greater flexibility to allow for reasonable grounds for non-compliance, for example IT upgrades, an administration provider change, ISP change, IT failures, benefit design changes, wind-ups, and other unplanned system downtime. There was some concern that as drafted any outage could be a breach of the requirements. One respondent suggested that TPR should set a threshold of 95% availability in guidance and its compliance and enforcement policy.

4.11. There were also some practical questions about how connection would work. Some respondents queried whether schemes with multiple administrators, particularly schemes with AVCs would be able to connect separately, or whether a single connection endpoint needed to be used.

Government response: Question 20

4.12. We were pleased to note that most respondents agreed that our proposals for connection were appropriate and reasonable. However, we acknowledge comments from some respondents that further detail is required around specific connection requirements to be set out in standards. As many of the requirements relating to connection are necessarily technical in nature (for example, the use of application programming interfaces), the draft Regulations are not overly prescriptive in content and provide a number of high-level requirements to ensure standards set by MaPS are followed. This is an intentional policy choice to ensure technical requirements do not quickly become outdated and can be adapted accordingly. We continue to believe this is the correct approach and it would be wrong for Regulations to be overly prescriptive in respect of technical requirements where there is not a policy need to do so.

4.13. To support the Government’s consultation, the PDP published a scoping document in January 2022 setting out what it expects to include in its “Code of Connection” which will incorporate the security, service, and operational standards and its connection guidance. The PDP expects to consult on the first full suite of standards shortly after the publication of this response document which will provide further specific details about expectations for connection and the opportunity to influence the development of these standards.

4.14. We agree with respondents that indicated that the process for obtaining consent to connect early should be as streamlined as possible. As we set out in our original consultation document, policy intention and design is to enable the mass connection of multiple schemes via the same single connected endpoint. Requests to connect early this way will be quicker and smoother.

4.15. With respect to comments about the responsibilities of scheme managers for locally-administered schemes, the connection requirements in the draft Regulations are consistent with other pensions legislation where the person responsible for implementing the requirements is the trustee or scheme manager. See for example, requirements in the Occupational and Personal Pension Schemes (Disclosure of Information) Regulations 2013. We therefore expect that schemes should be able to manage this.

4.16. We are aware that in practice trustees or managers may choose to utilise the services of a third party, such as an administrator, a software provider, or an ISP to fulfil their duties. Indeed, as set out in our original consultation document, we would encourage the use of single endpoints by multiple schemes as a technologically efficient way of enabling mass connection. We do not, however, consider it appropriate to make changes to the long-standing principle that trustees or scheme managers are responsible for compliance.

4.17. We are aware that some respondents were concerned about the length of connection windows in the draft Regulations, with some fearing that if a scheme faced technical problems when they tried to connect, there may not be sufficient time available to resolve the issue without breaching requirements. However, although we would expect schemes to finalise their connection during their connection window, this will not prevent work on connection starting before this point. PDP will provide a “sandbox” environment for testing to take place before a scheme’s connection window, which should provide sufficient opportunity for technical issues to be identified and resolved before formal connection takes place. We would also encourage schemes to apply to connect early, which (if agreed by MaPS) effectively expands the connection window because a scheme would not be considered to be late connecting from a compliance perspective until after its staging deadline.

4.18. We have noted the concern that the proposals could lead to schemes requesting connection dates in a manner which bunches them close together towards the beginning and end of connection windows. While we hope that schemes will be able to make a request to connect on a date of their choosing (within the staging window), MaPS will be responsible for managing this process and therefore the date of connection will be agreed with MaPS. As set out in the draft Regulations, we intend to include a requirement that trustees or managers would need to cooperate with MaPS. In view of this cooperation requirement, trustees or managers may be expected to connect on a date other than their first preference if too many schemes were seeking to connect around the same time.

4.19. With respect to queries about pensions schemes with multiple administrators (in particular, schemes with additional voluntary contributions), it will be technologically possible to connect this information via different endpoints. However, it will be important in situations like this that the information presented demonstrates that the information displayed relate to the same pension. Standards set by MaPS, which we understand will be consulted on shortly after the publication of this document, will confirm the technical details for how pension links will need to be provided to ensure the information individuals see on dashboards make sense.

4.20. We noted in one of the responses a comment that staging deadlines could go out of date based on when dashboards are made available to the public (what we have described as the “Dashboards Available Point”). We therefore wish to clarify that the date of the Dashboards Available Point would not have any impact on the requirement to connect to the dashboards digital architecture by the staging deadline. As explained in Chapter 1, we are seeking views on a new provision relating to the Dashboards Available Point in a separate consultation which closes on 19 July 2022^{[footnote 3]}.

4.21. We have taken account of comments from respondents to the consultation that the notification requirements for disconnection in the draft Regulations could be interpreted as being too onerous. We understand that a notification of disconnection may require manual intervention by a person rather than being something which could be automated and that administration services will usually operate only during office hours on normal business days. We will therefore amend the requirement which was set out in draft regulation 20 to notify MaPS of any disconnection “immediately” to “as soon as possible”.

4.22. Likewise, we have noted concerns that the connection requirements could be interpreted so as to rigidly prohibit any variation in connection, such as downtime which is scheduled and agreed with MaPS. This is not the policy intention; however that trustees or managers would be expected to make every endeavour to maintain their connection in line with standards set by MaPS. It will be for MaPS to determine in their standards what variations in connection are permissible, such as scheduled downtime.

4.23. We have noted a query from one respondent which asked why we have not adapted the Open Banking standards for pensions dashboards. While pensions dashboards will have some similarities with Open Banking, there are significant differences which require a different approach. This was an issue which was discussed in greater detail in the response to our earlier consultation, published in April 2019^{[footnote 4]}.  

Chapter 5: Staging

Introduction

5.1. The consultation sought views on our proposals for staging and other related issues. Staging describes our phased approach to requiring different cohorts of schemes to connect to the digital architecture and be ready to respond to find and view requests.

5.2. We set out our staging objectives and staging principles, which provided a framework for our approach. As explained in the consultation, we prioritised pace and deliverability in determining the staging profile. This is intended to deliver greater coverage on dashboards in a way that is achievable for schemes, while supporting delivery of dashboards to the public (the Dashboards Available Point) as soon as possible.

5.3. We are also committed to including State Pension data in the testing phases and making it available for users of dashboards from the initial Dashboards Available Point.

5.4. We received a broad range of responses to the consultation questions on staging, the main findings of which are summarised below.

Summary of responses: Questions 21, 23, 24, 25, 26 and 27

5.5. The questions here are grouped according to their relevance, beginning with questions 21, 23, 24, 25, 26 and 27 which focused on the staging timeline and sequencing.

Question 21: Do you agree that the proposed staging timelines strike the right balance between allowing schemes the time they need to prepare, and delivering a viable pensions dashboards service within a reasonable timeframe for the benefit of individuals?

5.6. Almost three quarters of respondents to the consultation answered this question. Of those, over a third agreed or mainly agreed that the staging proposals struck the right balance between delivering at pace and allowing schemes sufficient time to prepare. Conversely, around two thirds did not agree, however, around half of those were PSPS representatives.

5.7. No consumer groups answered specific questions on the staging timetable. However, Which? said in its response ‘in the face of considerable challenges being put forward by many parts of the pensions industry to the proposed staging timetable, there needs to be clear leadership from the Government to ensure that progress is maintained’.

5.8. The most common type of respondents to agree were administrators, software providers and ISP suppliers. Twice as many of these broadly agreed (12) as broadly disagreed (6). Most of the administrators and software providers agreed that the proposals were balanced. Those who tended to agree thought the timelines were tight but manageable. The ones who did not agree said given that the final requirements were not yet published, the timeline was very ambitious. They said that schemes required legislative certainty to complete their preparations and that administrators would need time to prepare their clients’ data to be compliant with the requirements.

5.9. Amongst the master trusts and personal pension providers, five broadly agreed, while four broadly disagreed. The ones that agreed with the timeline did so on the basis that there would be no significant changes to the scope of the Regulations and data requirements. One large provider of Self Invested Personal Pensions (SIPPs) felt that the overall timetable was too tight given that final regulations were only expected to be laid six months before the start of their connection window.

5.10. One specific concern raised by a Master Trust that also provided non-money purchase benefits was that, as a hybrid scheme, they faced the same challenges as other hybrid and non-money purchase providers so should not be included in the first cohort to connect.

5.11. Most trade bodies including the PLSA, ABI, Society of Pension Professionals (SPP), PASA and the Association of Professional Pension Trustees (APPT) seemed to broadly agree with the question although The Investing and Saving Alliance (TISA) mainly disagreed. TISA cited the impact that other regulatory changes within the broader pensions landscape would have on schemes’ ability to meet dashboard requirements, as well as seeking clarity on when the Dashboards Available Point would occur. The ABI, SPP and PLSA also said that clarity on the Dashboards Available Point would have a bearing on schemes’ ability to prepare. Some respondents questioned to what extent the regulations would be enforced before the Dashboards Available Point given the impact on user experience would be minimal. A common theme amongst the ABI, SPP and PLSA was that, although ambitious, the staging profile and timeline was a reasonable approach to connecting relevant members’ data to dashboards as quickly as possible. They pointed out that schemes would need to work to ensure that their data was ready by their given deadlines, although there would be a reliance on ISPs and third party administrators and further clarity on standards was required.

5.12. Some legal and actuarial representatives felt that the timeline did not provide schemes with adequate preparation time. The Association of Pension Lawyers (APL) said that large schemes are often very complex in terms of the benefits they provide and there could be “countless reasons” why it might be appropriate for their staging deadlines to be deferred. (We explore deferral below in Q29 and Q30). The Association of Consulting Actuaries (ACA) said that whilst they were supportive of the staging profile, certainty would need to be provided as soon as possible for schemes to start their planning for dashboards. They also expressed concerns that the timeline did not allow adequate time between the finalisation of guidance and standards, the Regulations coming into force and connection of the first schemes. They also pointed out that dashboards will be implemented at a time when pension administration teams would be focused on other projects, including GMP rectification and equalisation.

5.13. As noted, the most common type of respondents who disagreed with the question were PSPS representatives with almost all PSPS respondents disagreeing. Some respondents acknowledged that whilst they viewed their cohort’s deadline of 30 April 2024 as conceivably allowing them enough preparation time for dashboards alone, the timelines for dashboards and the legislative timelines to implement the McCloud remedy (see Annex C) will be happening at the same time, as set out in the Public Service Pensions and Judicial Offices Act 2022 (PSPJOA 2022)^{[footnote 5]}. They also pointed out that the staging deadline of April 2024 occurs before Annual Benefit Statements which reflect the McCloud remedy would have been issued to their members. Broadly, PSPS representatives were concerned that this timeline meant they would not have the capacity or resources to prepare for dashboards alongside implementing McCloud. Also, there was concern that the value data available in April 2024 would not reflect McCloud remedy information which could result in member confusion and risk credibility.

5.14. The Local Government Association (LGA) on behalf of the firefighter schemes strongly disagreed with the amount of time proposed. They felt their deadline would not give Fire and Rescue Authorities or their administrators sufficient time to implement McCloud.

5.15. Another view amongst some PSPS respondents was that although PSPS include some of the largest schemes (and in total account for nearly a fifth of all memberships in scope for dashboards), some locally administered schemes would fall into the medium category (sub-1000 memberships) and therefore warrant a later staging date.

5.16. The majority of PSPS respondents proposed an alternative staging deadline of April 2025, which is when most of them are expecting to have issued statements reflecting McCloud remedy information to their members. However, one administrator of a large PSPS suggested that providing admin data only from April 2024 was potentially viable. However, they had concerns about the benefits of such an approach and the impact it could have on service delivery. They also emphasised that suitable caveats would need to be made available to members to manage expectations. They said that value data could be provided by April 2025, contingent on progress made with McCloud remedy work. The LGA (on behalf of the firefighter schemes) suggested an extended staging window for PSPS. They said that this would allow schemes with the capability to connect earlier to do so, with more time allowed for those with greater challenges.

Question 23: Do you agree with the proposed sequencing as set out in the staging profile (Schedule 2 of the Regulations), prioritising Master Trusts, DC used for Automatic Enrolment and so on?

5.17. Just over two thirds of respondents answered this question. Of these, over three quarters agreed or mainly agreed with the proposed sequencing as set out in the staging profile. The most common types of respondents to broadly agree were administrators, ISPs, and software providers (a quarter of respondents) followed by master trusts and personal pension providers (around a fifth of respondents). The approach of prioritising the largest schemes to obtain greatest coverage was considered a logical one. While most master trust respondents agreed or mainly agreed with the proposed sequencing, some disagreed. One master trust argued that a better approach would be to focus on the quality of coverage, starting with smaller schemes that volunteer. They questioned the value of prioritising AE memberships as this could represent only a small proportion of total pension entitlements for many individuals.

5.18. Almost as many PSPS respondents broadly agreed as disagreed with the proposed sequencing. Most trade bodies broadly agreed in principle including the ABI, PASA, SPP, TISA and the APPT.

Question 24: (Cohort specific) If you represent a specific scheme or provider, would you be able to connect and meet your statutory duties by your connection deadline? If not, please provide evidence to demonstrate why this deadline is potentially unachievable and set out what would be achievable and by when.

5.19. Just under half of respondents answered this question. For most of those who did not respond, the question was not applicable. Some did not specify a response, explaining that a definitive answer was not possible until all the requirements including the Regulations were finalised or, as the PLSA suggested, because schemes would be dependent on their administrators or an ISP.

5.20. Amongst the respondents that did answer, just over half said they would not be able to achieve the proposed deadline for their cohort. However, more than three quarters of those represented PSPS. Among private pensions provider respondents, the majority broadly agreed that the deadlines for their cohort(s) were achievable. A few administrators did not agree, but most broadly agreed. Among those in the first cohort of schemes to connect, two indicated they would not be able to achieve their staging deadline, three did not specify while eight suggested they would be able to meet the requirements in time.

5.21. The LGA and the Local Government Pensions Committee (LGPC) in respect of the Local Government Pension Scheme (LGPS) said that the 30 April 2024 deadline was completely unachievable. They said the LGPS would not be able to connect and meet the requirements until April 2025. They also said they were awaiting clarity on how McCloud will need to be reflected on Annual Benefit Statements. They said that more time was needed to update software as the value data requirements for dashboards go further than the data they currently provide and that a significant amount of work will be required to comply with the McCloud legislation.

5.22. Of the five master trusts that answered this question, three said they would, in the main, be able to connect and meet their duties by their prescribed deadline and two suggested they would not be able to. A further two master trusts did not specify either way. All five personal pension providers that answered the question responded that they anticipated being able to meet their staging deadlines. One highlighted their dependency on seeing finalised standards and access to an ISP market that is still developing.

5.23. Only a small proportion (less than a quarter) of the total responses were from non-money-purchase schemes (excluding PSPS). Among those that responded, it was noted that the ability to connect and meet the requirements would be challenging and carried substantial risk and was dependent on the availability of final standards and regulations.

5.24. Among administrators and software providers, most were clear that the requirements to connect to dashboards were achievable. There was some confidence they would be able to support schemes with the connection process as well as ensuring that schemes’ data would be compliant. Some also pointed out that it was incumbent upon schemes to prepare to ensure their readiness to connect. An exception was a PSPS administrator who echoed concerns expressed by the LGA as set out above.

Question 25: Do you agree that the connection deadline for Collective Money Purchase schemes/Collective Defined Contribution schemes (CDCs) should be the end of April 2024?

5.25. Just under a quarter respondents answered this question. Over three quarters of these agreed with the proposed connection deadline of April 2024 for CDC schemes. Less than a fifth disagreed, suggesting that CDCs should stage either earlier or later than April 2024. Some who agreed with the deadline said that CDCs should be able to incorporate dashboard readiness into their setup and authorisation processes. It was suggested that the first benefit statements are due to be issued in the latter part of 2023, allowing CDCs ample time to be ready to connect in April 2024. One administrator who disagreed with the April 2024 deadline suggested that CDCs could be ready to connect on authorisation, so from the first day of operation, given value data would not be an immediate requirement for new joiners.

5.26. The Royal Mail Group (which will launch the UK’s first CDC scheme) felt that the staging deadline for CDCs was appropriate. They provided views on the importance of messaging on dashboards to explain the nature of the CDC benefit and the interplay between annual benefit illustrations and the dashboards values. These have been addressed in Chapter 2 (Data) and Chapter 7 (Qualifying Pensions Dashboard Services). Royal Mail also however highlighted that they would be providing a hybrid scheme for their members and sought further clarity on their staging deadline as a result.

Question 26: Do you agree with our proposition that in the case of hybrid schemes, the connection deadline should be based on whichever memberships falls in scope earliest in the staging profile and the entire scheme should connect at that point?

Question 27: Do you agree that the Regulations meet the policy intent for hybrid schemes as set out in Question 26?

5.27. Almost all respondents to this question agreed that both sections (or parts) of hybrid schemes (money purchase and non-money purchase) should connect at the same time. However, two thirds of those who answered the question disagreed that the staging deadline should be based on whichever of the two sections falls in scope earliest in the staging profile. Respondents who disagreed included trade bodies such as SPP, PLSA and PASA, who felt that the staging deadline should be based on whichever is the later date. The main reason provided was that value data challenges for hybrid schemes were the same as those of ‘pure’ non-money purchase schemes, if not greater. It was argued that, given that one of our priority staging objectives is to consider the deliverability concerns of industry, going with the earliest date would be counter intuitive. Respondents also pointed out that it was unlikely that the Dashboards Available Point would be triggered before hybrid schemes had connected so it would be immaterial to members if the connection deadline was based on whichever memberships fell in scope latest in the staging profile.

5.28. Overall, the responses to Question 27 were mixed – some agreed that the draft Regulations met the policy intent, but disagreed with the policy, or simply expressed their disagreement with the policy whilst some suggested detailed drafting amendments to the draft regulation 15 (hybrid schemes) including refinements to the policy.

Government response: Questions 21, 23, 24, 25, 26 and 27

5.29. We recognise that the staging timetable is ambitious and there will be challenges faced by industry in meeting the requirements to connect and deliver on the data requirements. We also acknowledge many schemes will have a level of dependency on third parties offering ISP solutions and them having the capacity to deliver for the different cohorts according to specific deadlines. We also agree with Which? that our focus should be on delivering dashboards for the public as soon as possible.

There is a great deal that schemes and administrators can be doing now to prepare their data and engage with their administrators and other suppliers on how they will meet their duties. TPR recently published guidance which provides a list of practical steps for trustees and scheme managers, including steps they should be taking now^{[footnote 6]}. The PDP published material to support our consultation, including information on their approach to standards and indications of what will be required of schemes^{[footnote 7]}. We expect the MaPS to consult on their suite of standards shortly after the publication of this document. We also encourage schemes and their administrators to familiarise themselves with the PDP’s ‘steps to connection’ material^{[footnote 8]} which is available on their data providers hub which is designed to provide further support to pension schemes and the wider industry.

Staging for initial cohorts

5.30. It is important we push forward on the delivery of dashboards and deliver on Government’s commitment to make dashboards available to the public within the shortest timeframe possible. Whilst we continue to urge trustees and managers to ramp up their preparations for dashboards, we recognise that final regulations, FCA rules and the MaPS standards are an important part of finalising this work ahead of staging deadlines. This is particularly acute for the first staging cohorts.

5.31. Given our latest assumptions on industry readiness and the timetable for the Regulations (on which FCA rules and the MaPS standards are dependent), we believe a modest change to the staging timetable for the first two cohorts could support schemes to meet their legislative duties without affecting the start of onboarding or the potential Dashboards Available Point (DAP).

5.32. We have decided to defer the deadlines for the first two staging cohorts by two months while expanding the connection window for the first cohort (to five months) so that connection may still begin from 1 April 2023. This change will not impact the level of coverage on pensions dashboards from September 2023 onwards. It affects master trusts with 20,000 or more relevant members (whose staging deadline will change from 30 June to 31 August 2023) and money purchase schemes used for automatic enrolment with 20,000 or more relevant members (whose staging deadline will change from 31 July to 30 September 2023). The 30 September 2023 deadline for money purchase schemes for automatic enrolment and master trust schemes with 10,000-19,999 relevant members has not changed

5.33. Within the staging profile as set out in the draft Regulations, there were existing staging breaks in August and December 2023 and May 2024. To accommodate this deferral without impacting the rest of the staging timetable, we have removed the August 2023 staging break.

Public Service Pension Schemes (PSPS)

5.34. In the consultation we proposed that all PSPS would be required to connect to the dashboards digital architecture by the end of April 2024. Through our engagement with other Government departments leading up to consultation, we were aware of concerns about the deliverability of this deadline, and we therefore signalled the need for further mitigating measures in our consultation. Respondents to the consultation very clearly reinforced the message that April 2024 was undeliverable due to implementation of the McCloud remedy and explained why April 2025 was more realistic.

5.35. To mitigate the impact of the McCloud remedy implementation, we have deferred the staging deadline for PSPS by five months from 30 April 2024 to 30 September 2024. It is still important that users of dashboards will be able to find their public service pensions at the earliest opportunity.

5.36. In addition, we have noted that most PSPS are expecting to have issued statements reflecting the McCloud remedy to their members by 1 April 2025. We recognise the concerns PSPS have around capacity to provide meaningful value data before this time and the need to carefully manage what information members are receiving in this period. We have therefore decided to ease the requirement on PSPS to provide value data (accrued and projected values), to 1 April 2025 at the latest, or earlier in cases where a Remediable Service Statement has been issued. Although we cannot guarantee that all PSPS members’ value data will reflect the McCloud remedy by this point, we anticipate that most will, and it is important to the user experience to minimise the length of time in which their value data may not feature on dashboards.

5.37. We intend to amend the Regulations to require all PSPS to:

• connect to the dashboards digital architecture by 30 September 2024 and meet the required standards (connection, security and technical);
• respond to find requests and complete matching;
• provide administrative and signpost data on request; and
• provide value data on request once a Remediable Service Statement (where applicable) has been issued to the member, or by 1 April 2025, whichever is the sooner date.

5.38. The value data elements required for PSPS are the same as for other non-money purchase schemes. This includes accrued and projected values for active members and accrued values for deferred members. The measures affecting PSPS will include other public sector bodies also affected by McCloud. The Regulations also allow for more than one value for the same entitlement to be displayed, to accommodate the Deferred Choice Underpin (DCU) introduced by the McCloud remedy. This is covered in further detail in Chapter 2.

5.39. Since the PSPJOA 2022 does not place a requirement on the LGPS to provide Remediable Service or Information Statements in respect of McCloud, we will update the Regulations on how the data requirements must be met. The LGPS must meet their value data requirements voluntarily or by 1 April 2025 at the latest. This would achieve consistency with the approach taken for other PSPS.

Staging deadlines for hybrid schemes

5.40. Respondents who gave a view on our proposals for the staging deadlines for hybrid schemes mostly agreed that these schemes should connect as one, but most disagreed that the staging deadline should be based on the earlier of the two sections’ equivalent cohort dates.

5.41. We explored the option of reversing the position, basing it on the later date. With this option several respondents identified a potential loophole where one section (or part) of a hybrid scheme could be so small that it could be placed very late in the staging profile (despite the other section being large) or take it outside the scope of the Regulations altogether, so a backstop date for staging was suggested. For hybrid schemes with one large section, we considered a backstop at the end of Wave 1 (i.e., 30 September 2024); and for those which had a medium-sized section, a backstop at the end of Wave 2 (i.e., 31 October 2025). However, this would have had a significant impact on the level of coverage achieved. It would also add further complexity to a provision that was already complicated.

5.42. We subsequently considered and settled upon a simplified approach where hybrid schemes would total the relevant members across both the money purchase sections and non-money purchase sections and treat the entire membership of the hybrid scheme as a non-money purchase scheme to determine the staging deadline. This simplified approach preserves our current assumptions in terms of coverage. We tested this simplified option with members of the Joint Industry Forum (which includes ABI, SPP, PLSA, PASA, PMI and APL representatives) and they were supportive of this approach. Although some hybrid schemes will have an earlier staging deadline than under the previous proposal, and some will have a later one, for most there will be no change. It also means that hybrid schemes would have a staging deadline no earlier than the end of November 2023, which we think is reasonable.

Collective money purchase schemes

5.43. We do not intend to change the staging requirements for collective money purchase schemes, also known as CDC schemes.

5.44. However, such as in the case of Royal Mail, where a scheme operates a CDC (money purchase) section and a non-money purchase section, it is important that, as with other hybrid schemes, all parts (or sections) connect to dashboards at the same time. We intend to make it clear in the regulations that where a CDC scheme is also a hybrid scheme, it will be required follow the staging deadlines for hybrid schemes.

Hybrid master trusts

5.45. There are a small number of schemes that fit within the categories of both master trusts and hybrid schemes. They have money purchase sections as well as potentially large non-money purchase sections. Within the draft Regulations, these schemes were categorised as master trusts with staging deadlines as early as June 2023. However, it was raised that these schemes face the same deliverability challenges as other non-money purchase schemes. We believe it is reasonable therefore to treat hybrid master trusts the same as other hybrid schemes and we intend to reflect this in the regulations. This would mean revised staging deadlines of 30 November 2023 at the earliest for these schemes, aligning them with those of other hybrid schemes of comparable size and helping to reduce the risk of non-compliance amongst the first cohort. The revised staging deadlines for these schemes would have minimal impact on the overall staging profile in terms of membership coverage.

Summary of responses: Questions 22, 28, 29, 30

5.46. In this section, we have grouped the remaining questions raised in Chapter 5 of the consultation, which sought views on scope, new schemes, schemes that change in size and the criteria for making deferral applications.

Classes of scheme and benefits out of scope of the Regulations

5.47. In the consultation we set out that pensioner members would not be within the scope of the Regulations which meant their information would not be viewable. We also set out that non-UK based schemes and schemes that were non-registrable by TPR (subject to exceptions) would be out of scope. The draft Regulations set this out in regulation 3 (Application).

Question 22: Apart from those listed in the table ‘classes of scheme out of scope of the Regulations’ are there other types of schemes or benefits that should be outside the scope of these Regulations? If you have answered ‘yes,’ please provide reasons to support your answer.

5.48. Of the 42 respondents who answered this question, just over half recommended other types of schemes or benefits that should be excluded, while just under half said there should not be further exclusions.

5.49. From those who recommended further exclusions, a range of schemes or benefits were put forward for consideration. Schemes in Pension Protection Fund (PPF) assessment and schemes winding up were most often suggested. The PPF itself suggested that consideration should be given to schemes that have entered PPF assessment when their connection date arises. Some respondents suggested that rather than excluding these from dashboards, a better approach might be to postpone their staging deadlines.

5.50. It was argued that it may be disproportionate to expect schemes in PPF assessment or in wind up to allocate resources to connect for what could be a short period. Some respondents also pointed out that value data relating to schemes in PPF assessment would be misleading. It was also suggested by some that an exclusion should only apply to schemes in wind up where the wind-up process had started before the dashboards legislation was made.

5.51. Other common suggestions were to exclude or clarify the position in relation to insurance buyouts, schemes based in crown dependencies, benefits of members not in UK whose benefits are expressed in a foreign currency and Equivalent Pension Benefit members. The rationale for these was generally around complexity and that the cost of including them would outweigh the benefit. Some suggested allowing schemes to use their discretion without the risk of fines or penalties.

5.52. Conversely, others argued against exclusions on the basis that dashboards should have as wide a coverage as possible, and their scope should not be further reduced. One respondent commented it would be better for users of dashboards to find they have an entitlement, even if schemes might have difficulty with providing value data in all cases. Others made the case for certain benefits or schemes to be included, including a suggestion that insurance buyouts should be included (even though these would not be classified as a pension scheme).

5.53. It was highlighted by some that PPF and Financial Assistance Scheme (FAS) entitlements should be viewable on dashboards. Clarity was also sought on apparent inconsistencies in the way remaining benefits after partial annuitisation or drawdown were to be handled alongside our position on unfunded pension lump sum (UFPLS) cases. Questions were also raised regarding non-money purchase schemes with Additional Voluntary Contributions (AVCs) and for users over state pension age. Our position on how we would treat AVCs is contained in Chapter 2.

Question 28: Do you agree with our proposals for new schemes and schemes that change in size?

5.54. Almost half (42) of respondents answered this question. The vast majority of these agreed or mostly agreed with the proposals for new schemes and schemes that change in size.

5.55. A few suggested that the requirement to connect within a six-month deadline may be too short for practical reasons such as the scheme could be in the middle of its annual statement exercise, and/or insufficient time for TPR to communicate with the scheme. These respondents suggested either a 12-month deadline or, alternatively, that the six-month deadline should only apply as an interim measure.

5.56. Some suggested that the proposal for schemes that change size may need further consideration. Two respondents suggested that medium schemes that later reduce to a smaller category should be able to stage alongside their smaller counterparts as they may lack the capability to connect.

Question 29: Do you agree with the proposed approach to allow for deferral of staging in limited circumstances?

Question 30: Are there any other circumstances in which trustees or managers should be permitted to apply to defer their connection date to ensure they have a reasonable chance to comply with the requirements in the Regulations?

5.57. As questions 29 and 30 are closely linked, we have summarised the responses together below.

5.58. Respondents mostly agreed that there should be a mechanism for granting deferrals, with just one exception. Respondents also largely agreed with the proposed approach to granting deferrals in the case of a change of administrator.

5.59. However, many indicated that the criteria for granting deferrals were too narrowly prescribed. This was the most common area of concern and disagreement highlighted, cited by 23 respondents.

5.60. Several respondents indicated that TPR, rather than the Secretary of State, would be a more appropriate decision-maker for considering deferral applications

5.61. Most respondents (55 in total) thought there should be additional circumstances in which trustees or managers may apply for a deferral of their staging deadline, while seven said there were not any.

5.62. The most common response (20 respondents) held the view that rather than specifying further particular circumstances, the Regulations should be more flexible and provide for a more general discretionary power to consider and grant deferrals on a case-by-case basis, subject to the provision of compelling evidence. 14 respondents specifically said that TPR, rather than the Secretary of State, should consider and grant deferrals where a deferral would be appropriate and in the interests of individuals with a pension entitlement in that scheme (deemed ‘reasonable grounds’).

5.63. Among specific circumstances cited, the most common were:

• PPF assessment
• scheme wind-up scenarios
• buy-ins and buy-outs
• the McCloud remedy as a PSPS-specific reason for deferral of staging
• mergers/transfer of liabilities
• sponsoring employer insolvency
• upgrading IT systems
• administrator or IT provider failure.

5.64. There were eight public service pension scheme respondents that held the view that conflicting scheme-specific pressures that made it administratively and practically unable to provide correct data should also be considered as grounds for deferral.

Government response: Questions 22, 28, 29, 30

Classes of scheme and benefits out of scope of the Regulations

5.65. As set out in the consultation, pensioner members, non-UK based schemes and schemes that are non-registrable by TPR (subject to exceptions) will remain out of scope of the Regulations. The Regulations will also only require schemes with 100 or more relevant members (medium and large schemes) to connect. Small and micro schemes may connect on a voluntary basis.

5.66. Clarity was sought in relation to UFPLS cases. UFPLS is derived from tax legislation and is a way of taking some of an individual’s benefits from a scheme, while leaving the remaining benefits uncrystallised. Therefore, members of schemes who take UFPLS payments are not considered pensioner members.

5.67. Having considered the consultation responses, we agree with the view that further reductions in the scope of the Regulations should be avoided as far as we can to ensure that the dashboard is as comprehensive as possible. We do, however, agree that some exceptions should be made for schemes in PPF assessment and for those in wind-up, but we do not agree they should be entirely excluded from the requirements.

5.68. We didn’t find there to be a compelling case to exclude other suggested scheme types or benefits. We recognise there may be challenges for schemes and administrators providing value data for members in certain circumstances. However, a complex array of exclusions would be difficult for users of dashboards to comprehend. This is something we will keep under review as user testing increases in scale.

5.69. We do, however, agree that some exceptions should be made for schemes in PPF assessment and for those in wind-up, but we do not agree they should be entirely excluded from the requirements.

PPF assessment

5.70. Requiring schemes that enter PPF assessment and face insolvency issues to spend additional funds to connect to dashboards may be disproportionate considering that these schemes may be connected for only a limited period before potentially winding up. The PPF has also advised us that most schemes undergoing assessment usually have fundamental data integrity issues.

5.71. For schemes in PPF assessment, the draft Regulations will therefore be amended as follows:

i. Entire schemes already in PPF assessment before their staging deadline will be exempt from the requirement to connect. Where one or more sections in a scheme is not in assessment, the entire scheme would still be expected to connect.

ii. Schemes that are exempted from the requirement to connect (as in point (i), which subsequently come out of assessment but do not enter the PPF will be required to connect by the later of either:

a. 6 months from the end of the assessment period; or

b. the staging deadline for the scheme as per its type, size, and the reference date.

(The PPF have concluded that schemes which exit PPF assessment will do so having had any data integrity issues identified and should leave their assessment in a much better position to connect to dashboards.)

iii. Where a scheme, or section of a scheme, enters PPF assessment after they have already connected to dashboards, the scheme will be required to maintain its connection. However, it would not be appropriate to require these schemes (or the sections of schemes as applicable) to present value information on dashboards given the uncertainty on the future values of pension entitlements for schemes in PPF assessment. Therefore, a scheme in this category will be required to provide administrative data only alongside messaging (in accordance with standards set by MaPS) confirming that the scheme is in PPF assessment. We acknowledge that there is an unavoidable downside that individuals could see an incomplete picture of their pension entitlements for an indefinite period while these schemes wind up.

iv. Connected schemes (or sections of schemes) that subsequently exit PPF assessment but do not enter the PPF will be required to meet the full data requirements in the Regulations as soon as practicable or by no later than 3 months after the exit date.

Schemes in wind up

5.72. Schemes in wind up will still be required to connect according to their staging deadline. Winding up can be a drawn-out process which many schemes take years to complete. In addition, most schemes that are currently in wind-up have fewer than 100 relevant members so would not be within the scope of these Regulations.

5.73. However, we agree that connected schemes (or sections of schemes) that enter the wind-up process should only provide value data (plus corresponding contextual and signpost information) if they consider it appropriate to do so. In those cases, they should also provide a message explaining that the scheme is winding up.

New schemes and schemes which change in size

5.74. In relation to new schemes and schemes that change in size, most respondents agreed with our proposals, and we do not intend to change the policy as set out in the consultation. A scheme’s staging deadline will be set according to the number of relevant members it has at the reference date, the scheme year end in 2020/21.

5.75. If a scheme did not exist at the reference date or had fewer than 100 relevant members, but then comes into existence or subsequently meets the size threshold within two years of the reference date (i.e., scheme year end between 1 April 2021 and 31 March 2023 inclusive), then it will be required to connect. It’s staging deadline will be the later of either:

• six months from the end of the scheme year in which it came into being or met the size threshold (100 or more relevant members); or
• the staging deadline for the equivalent scheme of that size and type had it existed on the reference date.

Example 1 – new scheme in scheme year end 2022/23

Scheme year end 2020/21 - scheme did not exist

Scheme year end 2022/23 - new money purchase for AE scheme with 1,000 members

Staging deadline = 29 February 2024 (cohort 1(g))

5.76. If a scheme did not exist at the reference date or had fewer than 100 relevant members, but then comes into existence or subsequently meets the size criteria in the scheme year(s) post 1 April 2023, the staging deadline will be 6 months after the end of the scheme year in which it came into existence or met the size threshold.

Example 2 – new scheme in scheme year end 2023/24

Scheme year end 2020/21 - scheme did not exist

Scheme year end 2023/24 - new money purchase for AE scheme with 1000 members

Staging deadline = 30 September 2024 (6 months from 31 March 2024)

5.77. A scheme’s staging deadline will remain fixed even if it subsequently changes in type or in its size unless it falls out of scope (such as all its members become pensioner members).

Example 3 – scheme that changes in size

Scheme year end 2020/21 - money purchase for AE scheme with 5,000 members

Staging deadline = 30 October 2023 (cohort 1(d))

Scheme year end 2021/22 - same scheme reduces to 1,000 members

Staging deadline remains 30 October 2023 (cohort 1(d))

Applications to defer staging deadline

5.78. We do not intend to expand the criteria for allowing applications to defer a scheme’s staging deadline. As set out in the consultation, applications must be submitted no more than 12 months from when the regulations come into force and cannot be made more than once. It is important that applications are submitted well in advance of a scheme’s staging deadline to ensure it can be considered in time. We will add to the regulations that applications must be submitted at least 2 months before the relevant staging deadline. Applications must satisfy the conditions as set out in the regulations, including that, before the regulations come into force, trustees or managers had in good faith embarked on a programme to transfer their data to a new administrator or had entered a contract to retender administration of the scheme, and the timing of this conflicts with the staging deadline. There must be evidence to demonstrate that complying with the staging deadline would be disproportionately burdensome or would put the personal data of members at risk. It should also be made clear what steps are being put in place to achieve connection at the earliest opportunity.

5.79. As we have set out above, we received a wide range of suggestions for expanding the deferral mechanism set out in the draft Regulations. The most common suggestion amongst respondents in relation to deferrals was a principles-based approach whereby any reasonable grounds may be given for applying for a deferral to the staging deadline, including issues which may have been unforeseen.

5.80. However, we do not believe it would be appropriate or necessary to amend the Regulations in this way, for the following reasons:

• Such a provision would provide the Secretary of State with sweeping powers to change staging deadlines. Although we think it is reasonable for the Secretary of State to consider applications for deferral in limited circumstances, it would not be appropriate for the Secretary of State, or another body, to have the power to fundamentally change a staging timetable which had been agreed by Parliament.
• We have a clear plan to make dashboards available to the public at the earliest possible opportunity and we expect every effort to be made by trustees or managers to comply with the requirements to help make this a reality. Although we recognise that unforeseen circumstances may reasonably prevent compliance, we think such a broad deferral mechanism would send the wrong message that compliance is not essential.
• TPR already has discretion to not take enforcement action if a scheme is unable to comply due to circumstances outside their control so this is a further reason a broad deferral mechanism would not be appropriate.

5.81. We have also carefully considered suggestions from respondents that TPR should oversee applications for deferral, rather than the Secretary of State. Whilst TPR has broad discretion on whether to take enforcement action or not, we do not agree that it is appropriate for TPR to be able to vary the legislative requirements.

5.82. As we set out in the consultation, we think it is reasonable to provide a deferral mechanism to ensure all schemes have a reasonable chance of being able to comply with their staging deadline and the purpose of this is to provide for limited flexibility for issues which are already known.

5.83. We have accepted that undergoing a PPF assessment would meet these criteria, but as we have set out above, rather than requiring these schemes to undergo an application process, we have made alternative provision for these schemes.

5.84. Some respondents indicated that schemes in the process of winding up or planning to carry out a buy-out should be considered for inclusion in the deferral mechanism (or exempted from connection requirements entirely). This was on the basis that if a scheme is in the process of winding up or transferring assets to another entity, it may not represent good value to members for the scheme to invest in new technology to connect to dashboards for a short period of time.

5.85. The current deferral mechanism allows for a 12-month delay before the requirements would apply. Both the processes of winding up or carrying out a buy-out can be lengthy and 12 months is unlikely to adequately meet the circumstances of all schemes in the process of winding up or planning a buy-out. This could result in these schemes still being in breach of requirements if they did not then complete connection later. We have however included an exclusion from the requirement to provide value data for schemes winding up, as set out above.

5.86. In respect of plans a scheme may have to upgrade their IT systems, we recognise that some schemes seeking to modernise the service they provide may have already invested considerable amounts of money in developing IT upgrades. These upgrades may not be ready in time for their staging deadline, meaning they would need to reinvest in updating their old systems and meet dashboards requirements. However, we do not think that extending the criteria for deferral on these grounds would be appropriate. We anticipate that most schemes will need to carry out upgrades to their IT systems to enable them to connect to dashboards. Therefore, the Secretary of State could be inundated with applications. TPR will however maintain discretion not to take enforcement action if it considered appropriate.

5.87. Some respondents to the consultation highlighted that in the event of a bulk transfer of liabilities, if a scheme that was receiving a transfer had already connected to dashboards, then it would need sufficient lead in time to prepare the “new” data for a dashboard connection. However, we have considered this issue and do not think it would be necessary to include any specific lead in time. Individuals with a pension being transferred would be considered to be new members of the scheme following the transfer and there are already mitigations in place to allow additional time to respond to requests for find and view information from new members, which we believe should be sufficient.

5.88. In circumstances where a scheme is undertaking a buy in with an insurance provider, trustees or managers would maintain a liability to pay any pension benefits in the usual way, so we do not consider this a sufficient reason why they should be able to defer their staging deadline.

5.89. Some other issues were raised by respondents to the consultation which we do not consider would be appropriate to provide a deferral mechanism for, including the scheme being unable to obtain the resource to connect for reasons outside of its control (such as lack of availability of an ISP market), an administrator or IT provider failure, administrator insolvency, and data breaches. We do not think that these events should be catered for by way of an exemption or an application for a deferral because each of them are likely to be issues which are not necessarily foreseeable. It would be more appropriate for TPR to exercise its discretion (if it considered this appropriate) in these circumstances.

Chapter 6: Compliance and Enforcement

Introduction

6.1. The consultation document set out our proposals in relation to the compliance and enforcement provisions set out in Part 4 of the draft Regulations. These provisions included measures to enable TPR to take enforcement action in relation to the requirements placed on trustees or managers of relevant occupational pension schemes by Part 3 of the draft Regulations.

6.2. In summary, the draft Regulations included provisions for:

• Compliance notices
• Third party compliance notices
• Penalty notices
• A mechanism for the review and appeal of penalties

6.3. The consultation document also set out our policy position that TPR should, at their discretion, be able to issue penalties for each individual contravention of a requirement of the Regulations.

Summary of responses: Question 31

Question 31: Do you agree that the proposed compliance measures for dashboards are appropriate and proportionate?

6.4. Of the respondents who answered this question, the majority indicated they agreed, or mainly agreed, that the proposals were proportionate and appropriate, with some commenting they were consistent with other areas of regulation. Many commented that it was important to have a framework which acts as a deterrent to non-compliance and felt that the proposals worked in principle.

6.5. However, of these responses, most also caveated that they either wanted further detail on how the compliance regime will work in practice or stressed the need for a pragmatic approach to enforcement.

6.6. Respondents were generally supportive of TPR having discretion to issue penalties, but many stressed that TPR should take an educational and supportive role at first before it resorts to penalties.

6.7. Many respondents welcomed the provision of third-party compliance notices, for circumstances which are outside the direct control of trustees or managers. However, some respondents asked for clarity about who could be issued with a third-party compliance notice. Many of the respondents raised a specific concern about the potential for incorrect data provided by employers leading to non-compliance or asked that the Regulations make clear that employers could be subject to third party compliance notices if they were the cause of a contravention.

6.8. A few respondents asked for clarification as to whether a party that offered services for both TPR-regulated schemes and FCA-regulated scheme could be fined by both regulators for the same breach.

6.9. A small number of respondents indicated that they did not agree that the compliance provisions were appropriate and proportionate. The main objections focused on the proportionality of fines, the need for a period of test and learn, and highlighted that the trustees’ and managers’ duty to act in the best interest of the members may come into conflict with some of the timescales.

6.10. Many respondents expressed concern with the “per request” aspect of the policy proposals. Many felt that the risk of an uncapped penalty system was not proportionate to the compliance framework as a deterrent and highlighted it could lead to very large fines, particularly for large schemes. Some respondents felt that a strict enforcement policy could have an impact to members who would bear the cost of ensuring compliance. In some cases, respondents asked for reassurance to be included in the Regulations by way of a further cap on penalties issues for a single or related event.

6.11. Two respondents explicitly called for a grace period to be included in the Regulations before penalties would be issued to allow for teething issues to be solved in a live environment. Other respondents indicated that as pensions dashboards are a new initiative, they would expect TPR’s compliance and enforcement policy to allow for a bedding-in period and that TPR should take a pragmatic view on enforcement.

Government response: Question 31

6.12. We are pleased to note most respondents were generally supportive of our proposals.

6.13. The Government recognises that pensions dashboards are a new endeavour and that there will a period of learning for industry. That is reflected in our proposals by ensuring TPR has full discretion to determine when it is appropriate to take enforcement action.

6.14. It is also understandable that respondents would be keen to understand more about how the compliance regime will work in practice. To facilitate this, TPR will be consulting on its compliance and enforcement policy once the draft Regulations have been laid before Parliament. This will provide further information about how TPR expects to approach regulating compliance with dashboard duties and will provide an opportunity to influence the development of this policy. We do not think it would be appropriate for the Regulations to specify greater detail about TPR’s approach to enforcement.

6.15. In reference to concerns about the possibility of large fines being issued and suggestions of a cap on the total amount that could be issued in penalties for a single event, it is already the case that TPR is required by the Regulator’s Code to take a proportionate, consistent, and targeted approach to enforcement. In the event of multiple compliance breaches, the draft Regulations allow TPR to issue multiple penalty notices within the same document. Where this was the case, we would expect TPR to consider its approach in the round to ensure it was appropriate and proportionate in the circumstances. We therefore consider it unnecessary to place an arbitrary limit on penalties for a single event that has led to multiple compliance breaches.

6.16. Likewise, in respect to concerns about the proportionality of fines being issued for what might be a technological failure, we would expect TPR to pragmatically consider both the causes of a compliance breach and the impact it has had when determining the level of any penalty. We think TPR has the tools and expertise needed to meet these expectations.

6.17. We have noted the suggestion from some respondents that there should be a delay or grace period before TPR undertakes enforcement activity (particularly prior to the Dashboards Available Point), in recognition that dashboards are an entirely new undertaking. However, while we recognise some of the requirements will be challenging, we do not agree it would be appropriate to specify a grace period for enforcement action in the Regulations. If there was no possibility of enforcement action being taken during the early stages, this could encourage non-compliance and undermine the purpose of the Regulations to ensure that dashboards are made available to the public as soon as possible. Setting a grace period in the Regulations would also prevent TPR from being able to take immediate action where it considered that there had been wilful non-compliance, which we consider to be essential.

6.18. We expect compliance with all the requirements, including responding to find and view requests, prior to the Dashboards Available Point because this is an essential part of enabling user testing at scale, which will help inform when the Dashboards Available Point can be achieved.

6.19. With respect to the requests for clarity about who could be issued with a third-party compliance notice, the draft Regulations do not prohibit TPR from issuing these to any person, so long as TPR is of the opinion that the non-compliance by trustees or managers was “wholly or partly, a result of an act or omission by another person”. This could include an employer if TPR believed they had caused a breach. However, it will be for TPR to determine what course of action it should take in any given situation.

6.20. We note that some respondents queried whether a single organisation could receive penalties from both the FCA and TPR for a single event. TPR will be regulating the compliance by trustees or managers of relevant occupational pension schemes with dashboard duties in the Regulations. The FCA’s rules will apply to pension providers in respect of occupational schemes which are personal or stakeholder pension schemes. While some organisations are involved in the management of both trust-based and contract-based schemes and could therefore be overseen by both the FCA and TPR, the rules and regulations apply to different elements of their businesses. So, a single event is unlikely to be a breach of both FCA rules and DWP regulations. This approach is consistent with other pensions legislation, and we do not consider this is likely to be problematic.

6.21. In conclusion, having considered all the consultation responses, we are satisfied that the compliance provisions in the draft Regulations are appropriate and proportionate, and we do not plan to make any changes to the compliance provisions which were set out in the indicative draft Regulations.  

Chapter 7: Qualifying Pensions Dashboard Services (QPDS)

Introduction

7.1. The consultation set out the proposed prescribed requirements which pensions dashboard services and providers must meet for a pensions dashboard service to become a Qualifying Pensions Dashboard Service (QPDS). These requirements include:

• Data Protection
• Connection and Functionality
• Displaying of the view data
• Reporting and monitoring of the dashboard
• FCA Authorisation and the new regulated activity

7.2. We asked a total of 10 questions about the draft requirements for QPDS, as well as the suggested approach to consumer protection, data manipulation and data export. Below are the summaries of the responses received.

Summary of responses: Questions 32 and 35

Question 32: Do you agree that our proposals for the operation of QPDS ensure adequate consumer protection? Are there any risks created by our approach that we have not considered?

Question 35: Do the proposals set out here provide the right balance between protecting consumers and enabling dashboards to deliver the best user experience? Are there ways in which consumers might be afforded more protection without negatively impacting the user experience?

7.3. Most individuals who responded to question 32, agreed that the level of consumer protection offered by the Regulations was acceptable; just a handful of those who responded did not think that the consumer protection measures set out were adequate.

7.4. Respondents raised a few concerns, suggesting that:

• Firms attempting to manipulate or benefit from the consumer, by using certain advertising or marketing techniques on the dashboard, could have a detrimental effect on individuals.
• Scammers could use the service to acquire individuals’ National Insurance Numbers (NINO) for fraudulent purposes.
• Allowing Power of Attorney (POA) would be an added benefit where individuals cannot use the Identity (ID) service to verify themselves.
• There is an inherent tension between making QPDS sufficiently appealing for potential providers to enter the market and ensuring adequate consumer protection.
• Features of a QPDS which might not be available through the MaPS dashboard and the creation of delegated access may introduce risks, and these will need to be managed.
• Scammers could create bogus or cloned dashboards services to obtain an individual’s personal information, and then use it for fraudulent purposes.
• It is unclear how consumers will know whether they are accessing a legitimate pensions dashboard service, so it is important that a register of approved QPDS providers is maintained by the FCA, made accessible to the public and its location publicised.

7.5. Of the 60 respondents to question 35, around a half agreed that the proposals strike the right balance between protecting consumers and delivering the best user experience. There were however others who disagreed and cautioned that it was impossible to say at this stage as the proposals are not yet complete. For example, these respondents said they could not reach a view until there is more clarity on data privacy questions, MaPS publishes standards and the FCA publishes its proposed regulatory framework for QPDSs. Several respondents also stressed the need to review proposals following live consumer testing.

Government response: Questions 32 and 35

7.6. The success of dashboards relies on a positive and secure user experience, so, we are keen to ensure that there is an appropriate level of control and oversight, as well as provide scope for innovation. The Regulations, with standards published by MaPS and the FCA’s rules for providers of dashboards, work to ensure a robust consumer protection regime. Each plays a different role in ensuring that consumer protection is at the heart of pensions dashboards.

7.7. The Regulations will set out several requirements that pension dashboard providers must meet and continue to meet to be a QPDS. A QPDS would be required to conform to MaPS’ standards, which would set out the technical, security and operational details relating to how a dashboard service should connect to the digital architecture and operate. The design standards are likely to address issues such as the manner of which dashboard information is presented to individuals, so the information is consistent, accurate and clear and not misleading alongside using and accessing the dashboard service. These regulations remain unchanged from what we consulted on.

7.8. We do intend however, to make a small clarification to the drafting of the reporting requirements in regulations 11 and 27 to ensure that the policy intent is reflected correctly and that reporting requirements are not assumed only to relate to aggregated or survey data, and that more granular information could be required for audit purposes. MaPS will consult on reporting standards in due course.

7.9. An application for FCA authorisation will not be considered until the applicant is considered able to comply with the requirements set out in the Regulations. For as long as they are authorised, they are expected to continue meeting the threshold conditions and FCA principles for business. If a dashboard provider fails to meet these requirements, the FCA can take a range of actions, including varying or cancelling providers’ authorisation under the Financial Services and Markets Act 2000 (FSMA). The authorisation process ensures that all FCA regulated firms meet common sets of minimum standards (Threshold Conditions). There are already rules and regulations in place for FCA authorised firms for advertising and marketing. The FCA may also choose to include rules on advertising in their rules for QPDS which they are due to consult on later this year.

7.10. We also expect that the FCA will consult on rules for QPDS that obtain the regulatory permission for the new regulated activity (when it is introduced by the Government).

7.11. Consumer protection is central to the success of Dashboards, and it is supported by the suite of prescribed requirements in Regulations, standards published by MaPS, and FCA authorisation and regulation of QPDS operators. As per the Minister’s commitment in Parliament, our policy intent is that any party wishing to operate a qualifying pensions dashboard service must obtain and maintain FCA authorisation and permission to undertake a new regulated activity. It is intended that this new regulated activity will be introduced through an amendment to the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 (RAO).

7.12. Given that it is a criminal offence for any party to undertake (or purport to undertake) a regulated activity without FCA authorisation, we believe that it is unnecessary to duplicate in these regulations the requirement to be authorised, which is set out in the amended RAO. We will therefore remove regulation 7(4) of the Regulations we consulted on in January. We are content that this has no real impact on the way in which the policy will operate for those providing dashboard services, but it removes the duplication of powers and the potential for drafting conflicts for the amended RAO.

Summary of responses: Questions 33 and 34

Question 33: We are proposing that dashboards may not manipulate the view data in any way beyond the relatively restrictive bounds set out in Regulations and Standards, as a means of engendering trust in Dashboards. Do you agree that this is a reasonable approach?

Question 34: Do you agree that not constraining the content placed around dashboards is the right approach for dashboard providers and users?

7.13. Most respondents to question 33 agreed that a relatively restrictive approach to the presentation of information on dashboards is necessary, but that the approach should be monitored and adapted as QPDS develop so that user experience can be optimised, and/or additional functions can be added to the central digital architecture. Some respondents indicated that they felt some levels of controlled manipulation would be beneficial for users of dashboards. Examples included allowing individuals to see their annual amounts to be shown as weekly or monthly breakdowns as opposed to annually.

7.14. Concerns were raised by a few respondents that reducing the dashboard to a very minimal set of information might encourage individuals to export their data to an environment which is much harder to control. They suggested DWP should therefore reconsider whether consumer protection might be better served by being less restrictive about what can be done on the highly regulated dashboard itself, rather than allowing people to export data into a much less controlled environment. Respondents also recommended that DWP and the FCA should consider the behavioural consequences of whatever is decided and test the risk to consumers, and change rules as needed.

7.15. There were mixed responses to question 34. Most respondents said that content displayed around dashboards should not be constrained as it could allow users to be given a fuller picture of their pensions.

7.16. Of the respondents that agreed, the most common suggestions were:

• Content surrounding support, guidance, advisory or engagement tools should not be constrained as this could help users fully understand their data and engage them more in their pensions.
• Signposts and messaging should not be limited, as this could ensure that users are made aware of potential risks associated with exporting data or leaving the regulated area of the dashboard.

7.17. A small number of respondents disagreed, stating that there appeared to be a tension between reducing the risks of scammers and aggressive marketing and allowing for useful information around the dashboard, which could help inform users of their pensions information with greater clarity and precision. There were concerns that a lack of control on the content placed around dashboards will dilute the protection that the proposed restrictions on dashboard output will provide. For example, the possibility of fraudsters being able to place adverts for free pension reviews alongside the prescribed dashboard output ought to be removed. Respondents recommended that the government consider making the absence of advertisements on the dashboard screen a prerequisite for providing a pensions dashboard.

7.18. Overall, there was consensus that caution needs to be taken around the advertising and marketing tools that a QPDS could present around the dashboards. Respondents felt that if adverts and pop-ups were permitted on dashboards, they would need to be carefully regulated to ensure individuals are not mis-sold to or scammed.

Government response for question 33 and 34

7.19. We believe that manipulation of pensions information should be constrained in the early delivery of dashboards to a limited set of circumstances. The circumstances will be determined through the standards set by MaPS and the FCA’s rules for QPDS – each subject to forthcoming consultation.

7.20. The decision regarding what may be displayed around dashboards is largely a matter for FCA rules and MaPS standards. We will work closely with the FCA and MaPS to determine in what circumstances limited manipulation of the view information will be permissible. We are not seeking to make any changes to the proposed regulations on manipulation of data.

7.21. We acknowledge that some respondents were concerned about advertising and marketing to dashboard users and how these could have detrimental effects on consumers if not regulated or monitored effectively. Feedback from this consultation is being shared with the FCA for consideration as it develops its regulatory framework for QPDS providers.

Summary of responses: Questions 36, 37 and 38

Question 36: Does the introduction of a 3rd party audit sound workable for potential dashboard providers? We are particularly keen to receive views on:

* The deliverability of such an approach.
* The availability of relevant organizations to deliver such an audit.
* The degree of assurance that individuals can take from this third-party audit approach.
* Who should be this third-party trusted professional to carry out the assessment on dashboards compliance with design and reporting standards.

Question 37: In what ways might prospective dashboard providers expect a third-party auditor to assume any liabilities?

Question 38: What would dashboard providers expect the cost of procuring such a service to be?

7.22. Many did not respond to question 36. There were, however, some similar themes among the responses received. While most respondents thought that the proposed approach is logical, a few expressed worries that the process would be too onerous for dashboard providers, thereby discouraging them from entering the market.

7.23. Others expressed concern that the cost of obtaining a third-party audit for dashboard providers will deter smaller companies wanting to become QPDS from entering the market.

7.24. A few disagreed with the approach and recommended a range of alternative options, including the use of public self-certification, which is an approach that the OpenID foundation has used in a few markets and the respondents consider this has worked well.

7.25. Several respondents recommended that a third-party audit should either not be required or be required but carried out (or paid for) by the FCA. Several respondents suggested that the third-party audit approach should be trialled in the second phase of testing to investigate how this would work in practice. It was also proposed that DWP could use a combined approach of both internal and external audits. This would reduce costs on firms but also ensure that compliance with certain elements, namely MaPS standards, are held to the correct standards.

7.26. Some of the third-party auditors suggested by respondents were: Kantara; Money helper; Pension Administration Standards Association; the Pensions Ombudsman; the Pensions Regulator; and the Financial Conduct Authority. If resourcing at the FCA might be an issue to support auditing, a respondent recommended the Institute of Chartered Accountants in England and Wales might be able to support as they also provided a framework for Master Trust Assurance, or Skilled Persons in line with the FCA’s s166 rules. “Information Commissioner’s Office” and other organisations and individuals that conduct ISO 27001 accreditations and audits were also mentioned as other examples by respondents that could help facilitate a third-party audit.

7.27. Those who responded to question 37 said that if an auditor is engaged by the dashboard provider, then any failing should be a dashboard provider issue and subject to audit. The auditor would be expected to assume liabilities if they fail to identify issues or omit to carry out a proper audit leading to future sanction or disconnection. Of those who responded to question 38, most indicated that they were unable to make an estimate of the likely cost of procuring a third-party auditing service because the extent of the audit was unknown. Values given by the handful of respondents who provided them covered a very large range, indicating that it was difficult to provide a number without further understanding of the scope of the audit. Few specific estimates were provided.

7.28. A few respondents requested clarity about who would pay for this third-party audit. Some respondents did not provide an estimate for the cost of procuring a third-party audit, but indicated that the cost of could be substantial, particularly if few organisations were to offer this service.

Government response: Questions 36, 37 and 38

7.29. We feel that the engagement of a third-party audit is a reasonable and necessary approach, which is a significant addition to our consumer protection armoury. We note some respondents suggested that the FCA should undertake this role, but as the standards are set by MaPS, rather than the FCA, we believe that having the involvement of a third-party auditor ensures that there is a regular and direct scrutiny which provides useful additional consumer protection, separate from and in addition to the FCA’s regulatory framework for FCA authorised QPDS operators.

7.30. We appreciate concerns that the introduction of a third-party audit will add to the costs of running a qualifying pensions dashboard service. However, we do not agree that the third-party audit is an unnecessary step. Drafting changes set out below provide additional clarity, and we intend to provide further information in the coming months about the role of the auditor, which should help inform and refine the likely cost estimates.

7.31. We believe that a regular third-party audit will improve consumer protection. The third-party professional would be required to undertake an audit of the dashboard provider to ensure compliance with the standards set by MaPS (with which the regulations require adherence) are being met. This additional provision seeks to ensure that there is a regular and detailed assessment of the ways in which dashboard providers are operating, providing another layer of protection forconsumers.

7.32. Those who provided responses to question 37 indicated that a clear understanding of liabilities should be in place. Our view is that liabilities should be set out clearly in a contractual agreement between the QPDS firm and their chosen auditor.

7.33. We intend to make some minor drafting amendments to regulation 13, which do not have an impact on the policy intent. Instead of referring to a ‘third-party auditor’ we intend to replace this with ‘independent person’. We believe that reference to a third-party auditor might suggest an accountancy role, which is not the function that we have set out. We want to ensure that the role involves a broader skill set which will provide assurance of compliance with standards.

7.34. We also intend to alter the language for regulation 13(3)(b) to a person ‘who it is reasonable for the provider to conclude is suitably qualified or experienced to carry out the tasks referred to in paragraph (1)’, to ensure that the definition does not exclude potentially suitable parties; and to make clear that the onus on the provider to ensure suitability.

7.35. These are clarifications rather than changes to the overarching policy intent. The responses highlighted a variety of examples of potential auditors, and more detail on the type of person that can provide this audit will be provided in due course.

7.36. We will clarify the language so that the function of the audit is better-defined. The purpose of the audit is to deliver an assessment of whether or not the dashboard is compliant with the rules in Part 2 of the Regulations relating to standards. Where the dashboard is not compliant, the audit should provide an assessment of the adequacy of any measures put in place to comply. Finally, we want to make a clarification to the period that providers must submit the outcome of the audit report to MaPS. Regulation 13 will state that the audit report must be submitted to MaPS within 20 working days of the date of the initial audit report, or 20 working days from the date, which is one year from the initial audit, as appropriate.

Summary of responses: Questions 39 and 40

Question 39: What are your views on the potential for dashboards to enable data to be exported from dashboards to other areas of the dashboard providers’ systems, to other organizations and to other individuals?

Question 40: If data exports were prohibited, would prospective dashboard providers still be keen to enter the market to provide dashboards?

7.37. Several respondents were opposed to permitting data export; a few were strongly in favour; and many agreed that data export could have some benefit, but only if it were subject to conditions that ensure appropriate consumer protection. The responses evidenced different interpretations of ‘data export’. Data exports could entail the movement of data to another area of the dashboard provider’s website, to a third party away from the dashboard provider altogether or to the individual themselves. While some answered the question on the assumption that data export was to the dashboard provider only, for modelling (or other forms of limited manipulation), others read data export more widely - potentially to anyone to whom the consumer gives consent. This latter interpretation was prevalent among the respondents most opposed to or concerned about data export.

7.38. Those who were opposed to data export expressed concerns that data export could increase the potential for scams, mis-selling, data misuse and decisions that may not be in the consumer’s best interests. Some of these risks are heightened as the view data alone is insufficient to support important decision-making. A small number argued that there should be no need for data export if dashboard providers included interactive features such as modellers and tools.

7.39. A few respondents thought enabling data export for initial dashboards would be inappropriate but recognised that it may be appropriate to consider once dashboards are better established and user behaviours have been tested.

7.40. Many respondents said they would support data export, subject to certain conditions. These conditions included:

• strong security;
• clarity on lines of responsibility and liability;
• clear explanation of the risks;
• prominent warnings and caveats;
• active consumer choice with informed, explicit consent; and
• provision of privacy notices.

7.41. Less than half of respondents offered a substantive response to the question of whether data export is necessary for commercial dashboards. Of these, over half felt that a prohibition on export would significantly reduce interest in entering the market. A small number felt that dashboard providers would enter the market without data export potential, with a handful indicating it is their intent to become QPDS operators, regardless of whether data export is permitted.

7.42. A few respondents suggested that if data export was the primary motivator for entering the market, it might indicate that the associated business model may not operate in consumers’ interests. One respondent argued that if data export is necessary for commercial viability, it calls into question the public interest case for commercial dashboards.

Government response: Questions 39 and 40

7.43. We recognise that there are arguments for and against data export. We want dashboards to be innovative and develop in functionality over time, and we are also keen to ensure that the protections for consumers are not reduced as a result.

7.44. We acknowledge the concerns that arise from data export, that individuals could become more vulnerable to fraud because of this mobility, collection, and access to information.

7.45. We are not seeking to prohibit data export in the Regulations and believe it is for the FCA to determine the risks and place their conclusion regarding data export into their rules for QPDS. We have shared the responses to these consultation questions with the FCA for consideration as it develops its regulatory framework for QPDS firms.

Summary of responses: Question 41

Question 41: Do you have any comments on the impact of our proposals on protected groups and/or views on how any negative effects may be mitigated?

7.46. A few common themes emerged from the responses. In relation to dashboard access, a few respondents flagged the importance of considering Power of Attorney (POA) or court order as a means of improving outcomes for those who have a right to access their pensions information but may not be able to do so themselves.

7.47. Some respondents believed that MaPS should consider a paper-based alternative that provides the same information as a dashboard would or utilising MaPS guiders. A few also flagged that there is a need to safely ensure that accessing a pensions dashboard is not too daunting with too many disclaimers and complicated messaging.

7.48. A couple of respondents felt that delegated access should be available to a wider population than proposed. A trade body respondent suggested that if the Government were to introduce a new activity of ‘enhanced personal guidance’ and this were to become subject to FCA regulation, such guiders should be considered for delegated access.

Government response: Question 41

7.49. Throughout the policy development for pensions dashboards, we have considered the equalities impact. The equality impacts will also be considered in more detail as part of the regulatory impact assessment discussion, which will be published alongside the Regulations when they are laid in Parliament.

7.50. Pensions dashboards do not remove the methods that individuals can currently use to obtain information on their pensions, but aim to offer an alternative, quick and effective way of obtaining this information digitally. Therefore, if a user has no access to use a digital service, they are still able to access the same service as they had previously without the need for using a pensions dashboard service. It is a tool or service for individuals to use if they wish which builds on other existing methods for accessing information (such as annual benefit statements or statements on request). We therefore do not consider pensions dashboards to be discriminatory.

7.51. We recognise that it is important that dashboards are created with accessibility needs in mind to minimise the potential for exclusion, or detriment. All efforts should be made to make dashboards as universally accessible as possible, hence the PDP is continuing to grow its evidence base via its various channels, including their Usability Working Group (UWG), which has been established to gather key insights on user needs to help to set its requirements

7.52. We acknowledge that respondents recommended that access to dashboards by protected groups with power of attorney or court order should be allowed from the start. We have not included power of attorney for dashboards as the current digital architecture does not facilitate this. The entire ecosystem is designed around an individual using the dashboard themselves and the user having control of their own data and control over who has access to this data. As dashboards and the digital architecture develops, MaPS can keep further possible delegation options under review for developments in the future. We understand this may be disappointing for some users, but we will continue to review this as dashboards develop.  

Annex A: List of organisations that responded to the consultation

The following organisations responded to the consultation (this list does not include individuals who responded in a personal capacity):

Abaka Holdings Limited

Aegon UK

AJ Bell

Altus

Aon

Arc Pensions Law LLP

Armed Forces Pension Scheme (AFPS)

Association of British Insurers (ABI)

Association of Consulting Actuaries Limited

Association of Pension Lawyers

Association of Professional Pension Trustees

Aviva Staff Pension Trustee LTD, RAC Pension Trustees LTD, and Friends Provident Pension Scheme Trustees LTD (joint response)

Aviva

Avon Pension Fund

B&CE

BPTS

British Airways Pensions

Capita Pension Solutions Limited

Clara Pensions

Confederation of British Industry (CBI)

Dorset County Pension Fund

Legal advisers to Electricity Pensions Trustee Limited

Equiniti Paymaster

Essex Pension Fund

Eversheds Sutherland

Fidelity International

Financial Services Consumer Panel

Fire Officers’ Association

First Actuarial

Hampshire and Isle of Wight Fire and Rescue Authority

Hampshire Pension Services

Herbert Smith Freehills LLP

Heywood Pension Technologies

HS Administrative Services Ltd

HUB Financial Solutions

Hymans Robertson LLP

Independent Transition Management (ITM)

Information Commissioner’s Office (ICO)

Isio

Joint Police Pension Board

Kent Fire and Rescue Service

Lane Clark & Peacock LLP

Legal & General

Local Government Association (LGA)

Local Government Pension Scheme (LGPS)

Local Pensions Partnership Administration Limited

London Borough of Hillingdon

LV

Mantle Services and Dalriada (joint response)

Mercer Limited

Moneybox

Moneyhub Financial Technology Ltd

National Police Chief’s Council (NPCC) on behalf of the Police Pension Scheme

Natwest Group Retirement Savings Plan

NEST

NHS Business Services Authority as administrators of the NHS Pension Scheme

NHS Pensions Board

North Yorkshire Fire and Rescue

North Yorkshire Police

Northern Ireland Local Government Superannuation Committee (NILGOSC) NOW: Pensions

Pension Protection Fund (PPF)

Pensions Administration Standards Authority (PASA)

Pensions Management Institute

Pensions Policy Institute

PensionSync Ltd

Phoenix Group

Pinsent Masons LLP

Railways Pension Trustee Company Limited (RPTCL) and Railpen Limited (Railpen)

Royal Mail

Sacker & Partners LLP

Scottish Public Pensions Agency (SPPA)

Scottish Widows / Lloyds Banking Group

Shropshire County Pension Fund

Smart Pension

South Wales Fire and Rescue Service

Squire Patton Boggs (UK) LLP

Superannuation Arrangements of the University of London (SAUL) Surrey Pension Fund

T L Dallas Independent Financial Services Ltd

Tesco PLC Pension Scheme and Tesco PLC

The Firefighters’ Pensions Scheme Advisory Boards for England and Wales

The Investing and Saving Alliance (TISA)

The Pensions and Lifetime Savings Association (PLSA)

The Pensions Ombudsman

The Royal London Mutual Insurance Society Limited

The Society of Pension Professionals

Tyne and Wear Fire and Rescue Service

UK Power Networks

Universities Superannuation Scheme

West Midlands Pension Fund

West Sussex County Council

West Sussex Fire Authority

West Yorkshire Pension Fund

Which?

Willis Towers Watson

XPS Administration

Zurich  

Annex B: Glossary

Key terms used in this consultation

Term	Definition
Application Programming Interface (API)	An Application Programming Interface, generally referred to as an “API,” provides a way for applications to “talk” to one another. In the context of pensions dashboards, APIs allow thousands of databases holding pensions information for millions of individuals to be accessed in one place, without integrating those databases into a central system. APIs are therefore essential to the functioning and security of pensions dashboards because they allow a dashboard service to display pensions information without ever holding the information itself. As part of the technical requirements of connecting to pensions dashboards, pension schemes will need to develop (or secure access to) a Find API and a View API.
AS TM1	Actuarial Standard Technical Memorandum 1 (AS TM1) is a guidance document produced by the Financial Reporting Council (FRC). The document specifies the actuarial assumptions and methods to be used in the calculation of Statutory Money Purchase Illustrations of money purchase pensions. Actuarial assumptions are an estimate of uncertain variables, such as the rate of future inflation.
Barber Window	Barber Window - an announcement sent to members in 1991 that both men and women would have a retirement age of 65 for service after 1 December 1991. It was agreed that for service before 17 May 1990 (the date the Barber judgment was handed down), the retirement age for male members was 65 and for female members was 60. In relation to service during the period from 17 May 1990 to the date a scheme’s rules are amended, the Court of Appeal had to consider the principle of European law that the scheme must “level up” benefits for the disadvantaged sex. This period is known as the “Barber window”.
Bridging pensions	A supplementary pension paid by an occupational pension scheme to a member who retires and starts drawing a scheme pension before reaching state pension age.
Caching	Caching refers to the temporary storage of the view data and state pension data for the purposes of an individual viewing their pensions data.
Dashboard ecosystem	Multiple parties, technical services and governance will be involved in and connected to what we are referring to as an ecosystem. This is made up of: the supporting digital architecture, which allows dashboards to work; the dashboards themselves that individuals interact with; pension providers’ find and view interfaces; and the governance register, which monitors the whole ecosystem’s operations.
Decumulation	The process of converting pension savings into retirement income (i.e., annuities or drawdown).
Deferred Choice Underpin	The Deferred Choice Underpin (DCU) seeks to address the discrimination brought about by transitional protection policies following the introduction of new schemes across Public Service Pension Schemes in 2015. At the point at which pension benefits are paid, individuals will be able to choose to receive legacy pension scheme benefits or pension scheme benefits equivalent to those available under the reformed pension scheme for service between 2015 and 2022 (known as ‘the remedy period’).
Delegated Access	The process by which individuals using dashboards will be able to allow another person to view their pensions information on a dashboard. To ensure the safety of people’s information, only MaPS guidance specialists, regulated financial advisers with the correct permissions and others considered by MaPS to be appropriate will be permitted to view pensions information this way and only with the consent of the relevant individual (which can be withdrawn at any time).
Digital Acknowledgement (ACK)	When the Pension Finder Service issues a find request to pension schemes, pension schemes will return a digital acknowledgement, known as an ‘ACK.’ This is to acknowledge that they have received the find request.
Digital Architecture	The digital architecture is the central elements that make dashboards work. It includes the ecosystem components that PDP is responsible for delivering: the pensions finder service, consent and authorisation service, identity service and a governance register.
Endpoint	This is a widely used concept in the IT industry to describe the location where an API connects with another system. Essentially, an endpoint is one end of a digital communications channel which is used to request and receive information. For the purposes of pensions dashboards, an endpoint will connect pension schemes to the digital architecture and is the digital location that requests to find and view pensions information will be sent. The same endpoint would be used to send pensions information back to the person requesting it.
FCA	The Financial Conduct Authority (FCA) is the regulator for around 51,000 financial services firms and financial markets in the UK. The FCA will authorise and regulate firms which plan to offer a pensions dashboard service. The FCA will also make corresponding rules for personal and stakeholder pension schemes to provide information to pensions dashboards.
Find data	Find data is the data that trustees, or managers of schemes will receive to conduct matching and is comprised of verified identity attributes and non-verified identity attributes.
Find interface	The find interface is the mechanism via which pension schemes will receive requests to find pensions from individuals using a dashboard. Standards set by MaPS will determine the technical criteria for find interfaces. See definition of “API” for more information.
Hybrid benefit	Defined in the Regulations as per s.84D(2) of the Pension Schemes Act 1993. A hybrid benefit is a benefit that is provided as part of a hybrid scheme.
Hybrid scheme	Defined in the Regulations as per s.307(4) of the Pensions Act 2004. A hybrid scheme is a scheme which can provide to its members both money purchase and non-money purchase benefits.
Intermediaries	Third party administrators, software providers and ISPs (Integrated Service Providers) that pensions schemes may use to fulfil any of their legislative duties.
Integrated Service Provider (ISP)	This is a new concept for pensions dashboards. An integrated service provider (ISP) is a type of intermediary which will allow multiple pension schemes to connect to the digital architecture using the same endpoint. For the purposes of dashboards, ISPs will allow pension schemes to connect to the digital architecture without them having to build their own find and view interfaces.
Internal resource server	A computer server which hosts protected information, and which handles authorised requests for access to that information.
Lost Pots	When individuals are unlikely to claim the lost asset in the future, for instance communication about the pension pot has not been able to be made (i.e., written communication has been ‘returned to sender’ or communication via phone/email has not been received).
MaPS	The Money and Pensions Service (MaPS) is an arm’s-length body sponsored by the Department for Work and Pensions, established at the beginning of 2019. MaPS is responsible for developing (via the Pensions Dashboards Programme) the digital architecture which will facilitate dashboards, as well its own dashboard service, referred to as the “MaPS Dashboard” in this consultation.
MaPS Dashboard	A government-backed pensions dashboard to be created and run by MaPS.
Matching	The process by which pension schemes use the Find data they are sent by an individual using a dashboard service to determine whether a pension is held for that person.
Memberships	Memberships refers to the total number of the pension scheme’s members, including active, deferred and pensioner members.
Money purchase schemes	Often referred to as “defined contribution” schemes, this is a pension pot where any money paid in by an individual or their employer is put into investments (such as shares). The value of the pension pot can go up or down depending on how the investments perform. They are referred to as “money purchase” schemes because the money invested can be used to purchase an annuity which would then provide an income in retirement.
Non-money purchase schemes	Often referred to as “defined benefit” schemes, this is usually a workplace pension based on an individual’s salary and how long they have worked for their employer. The value of the pension depends on the individual’s pension scheme rules and their salary, not on investment performance.
Non-verified identity attributes	Additional personal information such as the individual’s National Insurance number, previous names and addresses, email address and mobile phone number which individuals can elect to provide for schemes to use to conduct matching.
PDP	MaPS established the Pensions Dashboards Programme (PDP) to design and implement the digital infrastructure that will make pensions dashboards work.
Pension Credit	Extra money for pensioners to increase weekly income to a minimum amount.
Pension freedoms	The Pension Freedoms legislation enabled consumers to flexibly access their DC pension pots from the age of 55 and use the funds for a wider range of options including cash withdrawal, retirement income products, or a combination of the two.
Pension Identifier (PeI)	A PeI is a digital token which would be produced by a pension scheme in response to a find request to identify it has found a pension which matches (or possibly matches) the find data.
Personal or stakeholder pension scheme	These are schemes where a contract is in place between the pension provider and the individual.
Protected ages	Available for members who before 6 April 2006 had a right to take their pension savings at an earlier age than the current rules allow.
Qualifying Pensions Dashboard Service (QPDS)	A service which connects to the digital architecture to enable requests and display pensions information to an individual. A pensions dashboard service can only obtain and maintain its ‘qualifying’ status by meeting all of the proposed requirements set out in Part 2 of the Regulations.
Registrable scheme	An occupational pension scheme that is registrable with The Pensions Regulator by virtue of the Pensions Act 2004.
Relevant member	A member of a relevant occupational scheme that falls within the scope of the Regulations (i.e., not a pensioner member).
Relevant occupational pension scheme	A pension scheme provided through an employer that falls within the scope of the Regulations.
Resource Server	A resource server is located with the pension provider. Essentially, the resource server can be likened to a vault in the bank. An individual’s pension is the safety deposit box inside that vault and in order to access it, the individual must prove their credentials.
Staging deadline	The latest date by which a scheme must be connected to the digital architecture.
Staging profile	The order in which all pension schemes within the scope of the Regulations will be required to establish a working connection with the digital architecture.
Statutory Money Purchase Illustrations (SMPI)	An annual illustration of the contributions made for the benefit of, and the potential benefits due to, a member of a personal pension scheme. It is prepared in accordance with the Occupational and Personal Pension Schemes (Disclosure of Information) Regulations 2013 (“Disclosure Regulations 2013”) and AS TM1.
Step-up pension	For people retiring before Guaranteed Minimum Pension Age (GMP) the pensions received is tested against the minimum pension payable. If the amount being paid is lower than the minimum pension, the shortfall is paid as a “step-up” pension.
TPR	The Pensions Regulator (TPR) is the UK regulator of workplace pension schemes. TPR will be responsible for ensuring compliance with the proposed Regulations by trustees or managers of relevant occupational pension schemes.
User Managed Access (UMA)	The UMA interface would authenticate encrypted tokens to make sure an individual requesting access to pensions information has appropriate consent to access the information. Individuals using a pensions dashboard would have the option to delegate access to a regulated financial adviser, or a MaPS guidance officer. This would be controlled by the individual themselves via the Consent and Authorisation Service.
Verified identity attributes	Information such as first name, surname, current address, and date of birth that will be passed to all schemes by the Identity service and which schemes can use to conduct matching.
View data	The collective term to describe administrative data (details of the pension scheme, administrator, and employer details where known; additional signposting information) and value data that will consist of both accrued and projected values, specific to benefit type.
View interface	The view interface is where pension schemes will receive view requests from individuals using dashboards, check their authorisation at the consent and authorisation service, and if authorised return view data to dashboards. See definition of “API” for more information.

 

Annex C: The McCloud Remedy

1. The Public Service Pensions and Judicial Offices Act legislation facilitates implementation of the McCloud remedy, which will ensure that discrimination, which arose as a result of the way reformed schemes were implemented, is removed. The period in relation to which this discrimination arose began on 1 April 2015 for most schemes (for LGPS in England and Wales, it was from 1 April 2014, and for Civil Service by-analogy schemes 1 April 2016) and ends on 31 March 2022 and is known as the ‘remedy period’.

2. The primary legislation sets out that from 1 April 2022, all Public Service Pension Scheme members will accrue in the reformed schemes.

3. It also stipulates that retrospective changes must be introduced by 1 October 2023 but will allow schemes to implement the retrospective remedy through regulations ahead of this date.

4. The remedy brings about a Deferred Choice Underpin (DCU) for relevant members, which means that members will make their decision between scheme benefits shortly before benefits are paid from the scheme i.e., at retirement. In the meantime, members will be deemed to have accrued benefits in their legacy schemes, rather than reformed schemes, for the remedy period, until they make that choice. A choice of benefits for service during the remedy period will be offered to eligible pensioner members and in respect of eligible deceased members as soon as practicably possible following implementation of the retrospective remedy.

5. Considerable work will be required in the short term by PSPS to return affected members’ service in the reformed schemes to their legacy schemes for the remedy period, as well as resolving cases of members who have retired or died since April 2015.

6. Before schemes and administrators can implement new processes and IT system changes to deliver the DCU, the necessary secondary legislation needs to be passed. It is expected that implementation of the remedy will continue to place demands on schemes beyond October 2023 and will continue for decades as many members in scope of the remedy will continue working for some time before making their choice.

7. Detailed scheme level work is being undertaken by affected government departments and HMT to make the required changes in secondary legislation. The detail of any necessary amendments required to scheme regulations, in order to implement the remedy, will be subject to further consultations on a scheme-by-scheme basis.

1. See Pensions dashboards: further consultation - GOV.UK (www.gov.uk) ↩

2. See the ICO’s full consultation response ↩

3. See Pensions Dashboard: further consultation ↩

4. See pages 38-39 of ‘Pensions Dashboards: Government response to the consultation’ ↩

5. See Public Service Pensions and Judicial Offices Act 2022 ↩

6. See Pensions dashboards guidance on the Pensions Regulator website ↩

7. See Information on consultation standardson The Pensions Dashboard Programme website ↩

8. See the data providers: steps to connection on The Pensions Dashboard Programme website ↩