Consultation outcome

Pensions dashboards: consultation on the draft Pensions Dashboards Regulations 2022

Updated 15 July 2022

This was published under the 2019 to 2022 Johnson Conservative government

Applies to England, Scotland and Wales

Ministerial foreword

With record numbers of people saving for retirement, it is more important than ever that people understand their pensions and prepare for financial security in later life.

We know many people lack confidence when making decisions about their finances – and it can be difficult to understand and keep track of multiple pensions. Pensions dashboards will revolutionise the way people interact with their pensions. They will make accessing pensions information easier by allowing people to see what they have in their various pensions at the touch of their smartphone, laptop, or computer.

It is, of course, important to get the design of the service right to ensure it is accurate, secure and focused on the individual. That is why we took the time to undertake a comprehensive feasibility study and consulted on this before introducing primary legislation. This current consultation on draft Regulations provides a further opportunity for both industry and individuals to continue to influence that process.

We acknowledge that our proposals are ambitious and that making a success of pensions dashboards is a significant task for both Government and industry. But dashboards are an essential part of our plans to modernise the pensions industry and make it fit for the 21st century digital age. Dashboards will open huge opportunities to reunite individuals with lost pots and transform the way people think about and plan for their retirement.

The draft Regulations, that we have published with this consultation, would ensure the connection of pension schemes is managed in a way that we believe is feasible. By prioritising the connection of the largest pension schemes first, we can ensure that dashboards serve the greatest number of people as soon as possible. We have also been mindful that initially some schemes may need time to turnaround certain information on the value of pensions for the purposes of dashboards, nevertheless, it is our intention that this will all become instantaneous in the future.

Government is playing its part in ensuring dashboards provide a comprehensive view of what a person may receive in retirement, as information on State Pensions will be included on dashboards from day one. People will be able to access a dashboard service that is publicly owned, provided by the Money and Pensions Service, which will form part of a comprehensive retirement planning hub. We want dashboards to be accessed by as many people as possible and, to that end, we will allow other organisations who meet prescribed requirements to develop and host their own dashboards.

The consumer is at the heart of every one of our proposals to ensure that data is managed in a way that is secure and is presented in a way that is useful and easy to understand. We have also ensured our proposals include a robust set of tools for regulators to ensure individuals remain protected and to target instances of non-compliance with penalties if required.

We are confident that these proposals will be widely supported by individuals that have pension savings, by the pensions industry, and by people across the political spectrum. They deliver on our commitment to facilitate the introduction of pensions dashboards and have the potential to transform retirement planning forever.

Guy Opperman MP
Minister for Pensions and Financial Inclusion

About this consultation

Purpose of the consultation

The purpose of this consultation, pursuant to section 317(1) of the Pensions Act 2004, is to seek views on the draft Pensions Dashboards Regulations, which make provision for requirements to be met by pension dashboard services or the providers of these services, and by trustees or managers of relevant occupational pension schemes (meaning occupational pension schemes which are not stakeholder pension schemes) in Great Britain (England, Scotland and Wales).

• Issued: 31 January 2022
• Respond by: 13 March 2022
• Territorial Extent: This consultation applies to England, Wales and Scotland. It is envisaged that Northern Ireland will make corresponding legislation

Who is this consultation aimed at?

We welcome views from any interested parties. We are particularly keen to hear from:

• individuals with a UK pension
• pensions and lifetime savings industries
• finance and consumer representative groups with an interest in pensions capability, financial capability, data protection and security
• trustees or managers of occupational pension schemes
• pensions administrators
• pensions administration software providers
• firms interested in offering Integrated Service Provider (ISP) services
• Financial Technology (Fintech) companies
• organisations interested in setting up pensions dashboards

How to respond to this consultation

Please provide your consultation responses, using the form on our consultation webpage, and email to: [email protected]

When responding please indicate whether you are responding as an individual or representing the views of an organisation.

Government response

We will publish the Government response to this consultation on the GOV.UK website. The report will summarise the responses and set out the Government’s proposed next steps, taking account of the responses.

Consultation principles

This consultation is being conducted in line with the Cabinet Office consultation principles.

Confidentiality and data protection

The information you send us may need to be passed to colleagues within the Department for Work and Pensions and may be published in a summary of responses received and referred to in the published consultation report. We also anticipate that we may share information with our key working partners: the Financial Conduct Authority (FCA), The Pensions Regulator (TPR), and the Money and Pensions Service (MaPS) through the Pensions Dashboards Programme (PDP). All information contained in your response, including personal information, may be subject to publication or disclosure if requested under the Freedom of Information Act 2000.

By providing personal information for the purposes of the public consultation exercise, it is understood that you consent to its disclosure and publication. If this is not the case, you should limit any personal information provided, or remove it completely. If you want the information in your response to the consultation to be kept confidential, you should explain why as part of your response, although we cannot guarantee to do this.

Executive Summary

Purpose and scope of the Regulations

1. This consultation is about introducing pensions dashboards, an electronic communications service intended to be used by individuals to access information about pensions. Pensions dashboards will put individuals in control of planning for their retirement by bringing together their pensions information from multiple sources, including information on their State Pension, which can then be accessed at a time of their choosing.

2. The proposals in this consultation have been informed by extensive engagement with our stakeholder community. Its purpose is to seek views on a range of policy questions relating to the creation of pensions dashboards. An indicative draft of the Regulations that would give effect to the policy (“the Regulations”) are included to show how we envisage the policy would be turned into law. In summary, the Regulations set requirements to be met for a pensions dashboards service to be a “qualifying pensions dashboard service,” and requirements to be met by the trustees or managers of relevant occupational pension schemes, along with provisions to ensure their compliance with the requirements. Such requirements are set out in these Regulations to ensure that proper standards are met for delivering information on dashboards and for handling people’s pensions information.

3. Responses to the consultation will help to inform the drafting of the Regulations, and the supporting standards and guidance which are referred to in the Regulations. This consultation contains questions on specific issues where we would like detailed feedback, but we also invite comments on any aspect of the regulations not covered by the consultation questions.

4. Further to Part 1 of the Regulations (see draft regulation 3), the Regulations would apply to all registrable UK-based occupational pension schemes with active and/or deferred members, including public service pension schemes. The staging profile (as set out in Schedule 2 to the Regulations and outlined in chapter 5: Staging) is a plan requiring the progressive connection of pension schemes to the digital architecture (see annex D) and annex B)), prioritising schemes by their size and taking into account deliverability factors. Schemes will be able to connect earlier than their staging deadline should they choose to (subject to permission from MaPS).

5. The Regulations set out:

a. Requirements to be met by pensions dashboards services in order to be “qualifying pensions dashboards services” (Part 2 of the Regulations).

b. Requirements on trustees or managers of relevant occupational pension schemes in relation to cooperating with and connecting to the Money and Pensions Service (MaPS) (which we have referred to in the consultation as the digital architecture), and the data they must provide to individuals via MaPS (Part 3 of the Regulations).

c. Provisions for TPR to take enforcement action in relation to pension schemes that do not comply (Part 4 of the Regulations).

Structure of the consultation

6. The Regulations are in the form of a statutory instrument, which is a form of secondary legislation and is structured accordingly. We have sought to make this consultation document as accessible to readers as possible, by presenting information to the reader and taking the reader through the key issues in a logical way, so that both the high-level design and policy intent of dashboards is clear, and the detail is presented within this context. We have taken this approach so that the reader is well equipped to understand the proposals and provide considered responses to the questions asked.

7. The table below sets out the structure of this consultation, and the relevant Parts within the statutory instrument:

Consultation Document	Statutory Instrument
Chapter 1: Overview of Dashboards	Part 1, General: Oversight of standards
Chapter 2: Data	Part 3, Chapter 2: Requirements relating to the provision of information Schedule 3: Value Data
Chapter 3: How will pensions dashboards operate? Find and View	Part 3, Chapter 1: Requirements relating to cooperation and connection
Chapter 4: Connection: What will occupational pension schemes be required to do?	Part 3, Chapter 1: Requirements relating to cooperation and connection
Chapter 5: Staging – the sequencing of scheme connection	Part 1, General: Application Part 3, Chapter 1: Requirements relating to cooperation and connection Schedule 2: Staging profile
Chapter 6: Compliance and enforcement	Part 4: Compliance and enforcement
Chapter 7: Qualifying pensions dashboard services	Part 2: Requirements relating to qualifying pensions dashboard services

Chapters

8. The chapters within this consultation set out our detailed proposals for how pensions dashboards will work, and how the Regulations would provide for the proposals in legislation. The chapters are split into specific sections: data; find and view; connection; staging; compliance and enforcement; and qualifying pensions dashboard services. However, the chapters are inter-related, and the document would best be read as a whole. Summaries of the content of each chapter are below.

Chapter 1: Overview of Pension Dashboards

9. This chapter provides an overview of pensions dashboards. This important contextual information is to support consultees’ understanding of the Regulations and consultation. It covers:

a. The background.

b. How the dashboards will work, including what dashboards are, the process, and consumer protection.

c. Requirements, including what is required of schemes, dashboard providers, and the standards.

Chapter 2: Data

10. This chapter explores the interactions between the data which schemes will receive to match individuals to their pensions, and the different types of data that schemes will then have to provide to individuals via the individual’s chosen dashboard. This includes ‘find data’ (personal data provided by individuals) and ‘view data’ (returned to dashboards by schemes, including administrative data, signpost data, and value data, as defined in the Regulations).

11. It sets out proposals for the value data required from different types of relevant occupational pension schemes, including money purchase, non-money purchase, collective money purchase and hybrid schemes, with proposals for both accrued and projected values, and proposals on where exemptions apply. There are also specific requirements proposed for State Pension information.

Chapter 3: How will pensions dashboards operate? Find and View

12. This chapter looks at the proposed requirements on trustees or managers of pensions schemes in relation to “find requests” and “view requests.”

13. It outlines how schemes must be ready to receive find requests from the digital architecture, complete matching to identify whether information held in the find request matches with an individual’s pension and return a pension identifier. It also sets out how intermediaries could be used to fulfil a scheme’s duties to return an individual’s data.

14. Chapter 3 further outlines details of ‘view data’ including how, and how quickly we expect schemes to return this information to individuals, and how long we expect schemes to have to return administrative data and value data. It also sets out how management information would need to be reported to regulators and MaPS, so they can monitor compliance and ensure that dashboards are delivering a good service.

Chapter 4: Connection: What will occupational pension schemes be required to do?

15. This chapter includes our proposals on what trustees or managers of occupational pension schemes must do to prepare to connect to the digital architecture, and some of the ongoing responsibilities associated with being connected to it.

16. It proposes a deadline for schemes to connect to the digital architecture, which includes being able to respond to find and view requests. Schemes would have a duty to cooperate with requests from MaPS relating to connection, and would have to report certain information to MaPS, which will be set out in published standards. Schemes would have to comply with those standards, and any future updates to them.

17. Chapter 4 also sets out that schemes can connect before their deadline, at the discretion of MaPS and TPR. At that point, they would be required to conform with all requirements. It also sets out that small and micro-occupational pensions schemes can also connect should they wish to.

Chapter 5: Staging – the sequencing of scheme connection

18. This chapter provides information on the rationale that underpins the staging proposals and how analysis was used to determine the proposed order in which schemes will be required to participate in the provision of pensions dashboards.

19. It sets out the rationale for requiring schemes to connect to the digital architecture in a staged manner, including that the staging profile should prioritise schemes by the number of members they have, to maximise the level of member coverage in the shortest possible timeframe. It details the three staging cohorts: large schemes (April 2023 – September 2024), then medium schemes (October 2024 – October 2025), followed by small and micro schemes (expected from 2026, but not covered by the Regulations).

20. The chapter also sets out that State Pension information would be available from day one. It details how scheme size should be calculated and the types of schemes that would be out of scope of the Regulations. It includes proposals for hybrid schemes, collective money purchase schemes, new schemes and schemes that change size. It also proposes staging breaks and some limited flexibility around the staging deadline in specific circumstances.

Chapter 6: Compliance and enforcement

21. This chapter provides detail on the consequences for pension scheme trustees or managers that do not comply with the requirements in Part 3 of the Regulations. It sets out how the Regulations would provide TPR with powers to issue compliance notices, third-party compliance notices, penalty notices, and that financial penalties for individual dashboard-related breaches can be up to £5,000 if the person is an individual and £50,000 in other cases. All enforcement action relating to non-compliance with Part 3 of the Regulations would be at the discretion of TPR.

22. This chapter also explains that the Regulations have been developed to be consistent with existing data protection requirements set out in law, including the UK GDPR. Therefore, it would remain the responsibility of the Information Commissioner’s Office to investigate any breaches of data protection law and take the action it considers appropriate, in the usual way. The Regulations would not make any changes to this existing role.

Chapter 7: Qualifying pensions dashboards services (QPDS)

23. This chapter sets out the proposed requirements that pensions dashboard service providers would have to comply with to be a QPDS.

24. It proposes that they would need to connect to the specified digital architecture, conform to MaPS standards (or TPR standards with respect to reporting standards) and be FCA-authorised. Chapter 7 also sets out how dashboard providers will be monitored on their compliance with the Regulations and sets out the requirements on QPDS in relation to reporting and monitoring.

25. This chapter also discusses proposals on allowing data to be exported from dashboards, the approach to delegated access, and additional functionality on dashboards.

Timing of the legislation

26. We are seeking views through this consultation to inform the further development of the Regulations before they are laid before Parliament. Our aim is to lay the Regulations when parliamentary time allows.

27. There are also plans for other dashboard-related consultations led by different organisations, including the Financial Conduct Authority (FCA), The Pensions Regulator (TPR), Financial Reporting Council (FRC) and Pensions Dashboards Programme (PDP). Further details are at annex B.

Chapter 1: Overview of Pensions Dashboards

What is the purpose of the Pensions Dashboards?

1. With the shifting pensions landscape, low levels of understanding of pensions and increased responsibility on individuals, there is a need for a new way to help people keep track and re-connect with their pensions information in one place. Pensions dashboards will bring together an individual’s pensions information from across their pensions, including their State Pension. This will help improve awareness and understanding among individuals, reconnect them with any lost pension pots and transform how they think and plan for their retirement. By enabling easier access to pensions information, we envisage that pensions dashboards will change how people perceive some of the challenges that historically prevented them from pursuing advice and guidance. Building on the benefits of automatic enrolment, and by prioritising these schemes as part of our approach to staging (see chapter 5), dashboards can particularly help those who have historically been less likely to save for their pensions, including women, ethnic minority groups and disabled people, who are more likely to have these savings.^{[footnote 1]} In this way we expect dashboards can have a positive influence from an equalities impact perspective.

2. Separate to these Regulations, as required under the Pension Schemes Act 2021, MaPS will develop and host its own pensions dashboard, situated within a newly developed retirement planning hub on the Money Helper website.^{[footnote 2]} Other organisations will also be able to develop and host their own dashboards, creating scope for innovation and engagement amongst a broad range of people. These Regulations set out requirements to be met in relation to these dashboards, which will be known as Qualifying Pensions Dashboard Services if they meet all the requirements.

3. Pensions dashboards will tech-charge the pensions industry and bring it into the 21st century. The emergence of qualifying pensions dashboards will bring opportunities to reach individuals where they already interact with digital services and provide opportunities to engage people who prefer to use tools from organisations that they already have a trusted relationship with, such as their employer or bank. We expect that this will encourage people to take greater ownership of their pensions, whilst paving the way for future innovations across pensions and beyond.

4. We expect that pensions dashboards will provide an opportunity for engaged individuals to consider taking action to consolidate their deferred small pots. Dashboards can help to drive individual engagement and could support people in making better informed decisions about their retirement. This includes in relation to Pension Freedoms, where individuals have greater choice in what to do with their pension savings, and the fact that there is a growing proportion of people in money purchase schemes, who have more responsibility to plan and make decisions around their retirement.

5. Dashboards would offer the potential for future innovations as they develop and become more sophisticated, which could better support people in planning their retirement, and managing their pensions more effectively. We may in future seek to include modelling tools as well as explore the potential to facilitate member-initiated transfers or consolidation, subject to any necessary consumer protections and legislative requirements. However, as we set out in the Government’s previous consultation on dashboards^{[footnote 3]}, a phased approach is important, especially given the scale and complexity of this project. During this first phase of dashboards these functions will not be in operation and are out of scope of these Regulations. Any recommendation to Government to make future changes such as these would need to be informed by ongoing user testing.

How will dashboards work?

What are dashboards?

6. Pensions dashboards will be online platforms for individuals to access information about their pensions in one place. Pensions Dashboards will bring together information from multiple sources and will include information on their State Pension and accrued and projected values of their pensions.

7. Seeing this information all together, in one place, will allow individuals to better understand their pensions and may support their planning for retirement.

How dashboard interactions will work for people - what will the process be?

8. The diagram below outlines how, by accessing a dashboard of their choosing (whether this is a qualifying pensions dashboard service, or the MaPS dashboard), an individual will be able to make a request to find and subsequently view their pensions information.

9. An individual will start their journey by submitting a request to find their pensions information. To keep individuals’ data safe, an identity service will confirm the individual is who they say they are. Furthermore, via the consent and authorisation service, the individual must also provide consent for their information to be used to perform the search on their pensions and authorisation for schemes to send the pensions information to the dashboard of an individual’s choosing for them to view. At any point, an individual can withdraw their consent.

10. At this stage, the pension finder service takes over. The pension finder service does not hold any pensions data. It acts as a switchboard sending the individuals find request to all pension schemes.

11. For each match found, a pension scheme will register a Pensions Identifier (PeI) with the consent and authorisation service. This does not include pensions data but acknowledges that there is a match. Once this has been confirmed, an individual can request to view their information and the individual’s dashboard will pull the data directly from the pension scheme for the individual to see (or someone to whom an individual has delegated access – see chapter 7 for further information).

12. Overseeing this process is a governance register. The governance register will work to ensure that the dashboard ecosystem (see glossary) is kept safe and that the required security and performance standards are met.

13. For further detail on the various components of the pensions dashboard digital architecture, please see annex B. There is also further detail on the various interactions that take place between an individual and components of the digital architecture when processing both find and view requests within the UK data protection legislation section of chapter 3.

How dashboard interactions will work for individuals – consumer protection

14. Consumer protection can be defined as action to minimise consumer detriment, including both prevention of harm, and access to redress for individuals if things do go wrong. We expect that the potential risks of scams, mis-selling or individuals making poor decisions about some, or all, of their pensions will be mitigated to some extent by our consumer protection measures which include MaPS standards and any relevant FCA rules which are in development. Ensuring these measures are in place will aim to instil trust and confidence in the pensions dashboards initiative.

15. For many people, a pension is one of the most significant financial investments that they will make throughout their life, so it is essential that pensions dashboards are safe and secure. For that reason, consumer protection is central to our pensions dashboards plans.

16. Consumer protection was of particular interest to Members of both houses during the passage of the Pensions Schemes Act 2021. While very supportive of pensions dashboards generally, in the House of Lords in particular, there was concern with the idea that transactions might one day be allowed to take place on dashboards. Also, many parliamentarians felt that there should be just one non-commercial dashboard (as opposed to multiple commercial dashboards) to reduce the risk of scams, miss-selling, or potential for confusion. There was also a lot of interest in data security via dashboards and the application of data protection legislation.

17. As set out in the response to the Government’s consultation, published in April 2019, there are three overarching design principles which underpin our approach to pensions dashboards with an aim to maximise consumer protection:

a. Put the consumer at the heart of the process by giving people access to clear information online.

b. Ensure consumers’ data is secure, accurate and simple to understand, minimising the risks to the consumer and the potential for confusion.

c. Ensure that the consumer is always in control over who has access to their data.

18. The key principle of our consumer protection proposal is that people using dashboards will have full control of who has access to their data. This includes:

a. Access to the data should be available only to the individual unless specific consent for delegated access is given (regulation 7(5)(b)).

b. Qualifying dashboard operators should not be allowed to access the data for any purpose unless they have the specific consent of the individual. Although caching (in other words, temporary storage of) the data on behalf of the individual (who must still give their consent) needs to happen for display purposes, the individual should be the only entity who can see their data on dashboards.

c. As provided for in regulation 7(5)(c), the individual has the right to withdraw their consent at any time. The dashboard provider should tell them how to do this, it should make it easy, and it should act on requests as soon as possible.

19. Several design principles were also included that may be reviewed in future, subject to advancements in technology and the development of dashboards. This included that the storing of pension data beyond caching at dashboards would not be allowed; and that there would be no aggregation of an individual’s information in any part of the ecosystem other than by the pension scheme or an Integrated Service Provider operating on their behalf and in respect of the benefits built up in that scheme.

20. Individuals will be provided with privacy information about the collection and use of their personal data. They will also be asked to provide consent for the dashboard providers to process their personal data in order to search for their pensions.

21. The proposals in this consultation document uphold the rights and freedoms enshrined in data protection legislation. They also mitigate the risk of consumers being confused or misled into making detrimental decisions.

Proposals

22. Our proposals to place specific duties on the trustees or managers of schemes and on Qualifying Pensions Dashboards Services (QPDSs) are intended to mitigate much of the risk identified above.

23. Chapter 2 outlines the ambitious data requirements that we propose placing on trustees or managers of pension schemes and will make clear how our approach puts the interests of users first, helping them to get the most from dashboards through the provision of information designed to meet their needs. Regulation 22(5)(a) would place a requirement on trustees or managers to check with MaPS that the individual to whom the find request relates has given consent to their view data being provided to their dashboard. This prevents an individual’s pensions information being sent to the wrong person. Furthermore, we have proposed a requirement that no information about State Pensions, other than that provided by DWP, should be presented on dashboards. The Government believes that this is important to ensure that any information that users view about State Pension is accurate, complete, and relevant.

24. In chapter 7, we are proposing specific requirements on dashboard providers for them to become a QPDS. Ensuring that QPDSs only use the specified digital architecture means that an individual is within all of the protections that the ecosystem offers. Protections including adhering to all MaPS standards, having permission under Part 4A of the Financial Services and Markets Act 2000 (referred to as obtaining FCA authorisation throughout this document), and ensuring that QPDS providers are undertaking their requirements in reporting and monitoring are all paramount in seeking to ensure that individuals using QPDS are protected as much as possible.

25. QPDSs must adhere to all design standards set out by MaPS. The design standards will cover matters such as the way the view information is presented to the individual on the dashboard. Design standards will be developed through user centred testing and user centred design, which will include standards to ensure accessibility for dashboard users. How QPDSs display the view data will be controlled by MaPS’ design standards. This is to ensure that values are presented consistently, accurately, and clearly, and that information is not misleading. We have therefore proposed mandating that the view data would need to be displayed in accordance with the design standards which will be published by MaPS. This also means that the values should not be manipulated for presentation beyond the relatively restrictive bounds set out in regulations (where design standards will detail the circumstances where data may be added up, displayed graphically or displayed in alternatives to annual amounts). Standards will include information around the messaging which would need to accompany the return values and the way the return values must be presented. Our aspiration is that restricting the way in which view data can be presented and manipulated on dashboards will help to build trust and confidence in the information shown.

26. In restricting the ways in which QPDSs can use and present view data, care needs to be taken not to inhibit other aspects of user experience, such as the enabling of innovation by QPDSs, and the ability of individuals to make other use of the data provided on their dashboards. Although this is not a part of the accompanying Regulations, we have set out in this consultation ways in which a balanced approach might be taken, so that pensions dashboards themselves retain a relatively consistent approach to the use of data. However, QPDSs are not prevented from offering people the ability to export their data away from the dashboard, either to another page within the QPDS provider’s system, or beyond. Chapter 7 provides further detail on this.

27. In addition, any entity that wishes to provide a qualifying pensions dashboard must obtain FCA authorisation to do so. Authorisation is an important mechanism through which the FCA can prevent the occurrence of harm to individuals, barriers to effective competition, and damage to market integrity.

28. 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 which include requirements to comply with various MaPS standards. It is proposed that confirmation of this ability to comply will be provided to the FCA by MaPS, informed for certain standards by assurance from a third-party auditor.

29. The authorisation process ensures that all FCA regulated firms meet common sets of minimum standards (Threshold Conditions). They must meet these requirements before the FCA will authorise them and are expected to continue meeting the threshold conditions, as well as the FCA principles for business, and relevant Handbook rules (including any the FCA may set specifically for dashboard providers) for as long as they are authorised. If they fail to do so, the FCA can take a range of actions, including varying or cancelling providers’ FSMA authorisation.

30. It is vital that people accessing their pensions information through a pensions dashboard can have trust in the safety and security of the service and their data. That is why MaPS, through the PDP, will facilitate the delivery of a secure digital ecosystem, enveloped in a robust framework of DWP and regulator-led regulation. In addition, people using dashboards will be fully in control of who has access to their data.

31. The whole process of accessing information on dashboards rests on the consent of the individual using dashboards. The nature of an individual’s consent must be clear, explicit, understood, and informed. It cannot merely be perceived as a tick box condition of usage. The PDP will articulate this more clearly in their UK GDPR publication due to be published in the summer of 2022.

32. We passionately believe that pensions dashboards will have wider, positive effects on consumer protection by increasing engagement and building understanding. It is our view that dashboards will help to protect people from potential poor choices and non-engagement associated with a lack of awareness. Pensions dashboards will offer individuals a better experience of engaging with their pensions, in a single place online which, in turn, is intended to help them to make better informed choices.

What is required of pension schemes and dashboard providers?

Compliance with legislation and standards

33. As we will outline throughout this consultation, these Regulations set out the requirements to be met by both pension schemes and dashboard providers. The Regulations would provide that for pension schemes, they must:

a. Connect to the digital architecture. Further information on the digital architecture is set out in annex B.

b. Complete matching to identify whether information held in the find request matches with an individual’s pension and return a pension identifier.

c. Return view data to individuals. Chapter 2 outlines further details.

d. Comply with standards to meet their legislative duties.

34. We propose that for providers of Qualifying Pensions Dashboard Services (QPDSs), the regulations will require them to:

a. Connect to the specified digital architecture.

b. Be FCA-authorised.

c. Comply with standards to meet their legislative duties.

35. Further details are set out at chapter 7: Qualifying Pension Dashboard Services.

36. As made clear above, a clear duty for both pension schemes and dashboard providers is to comply with standards. Given this, it is important to understand what the standards are, the role that they will play, and the mechanisms for their oversight and approval which is set out in the section below.

The role of standards

37. Throughout this consultation, we will set out the requirements in the Regulations that we propose placing on trustees or managers of occupational pension schemes and QPDSs. In some parts of the Regulations, we propose requiring compliance with standards, which will be set initially by MaPS (and in limited cases, TPR).

a. Regulation 4 outlines our proposed approach to the oversight of standards.

b. Part 2 – Prescribed requirements for qualifying pensions dashboard services sets out where QPDSs must adhere to standards to fulfil their dashboard duties.

c. Part 3 – Requirements relating to trustees or managers of relevant occupational pension schemes, Chapter 2 Requirements relating to the provision of pensions information outlines where trustees or managers of schemes must adhere to standards in relation to the provision of pensions information.

38. Standards provide further detail on how schemes and QPDSs must comply with their legislative duties. Because of their importance in the operation of pensions dashboards, compliance with them will be mandatory. Standards provide a greater level of technical or operational detail that would not be appropriate to set out in Regulations. It is also likely that standards will need to develop more regularly and rapidly than changes to Regulations could allow for.

39. Given the potential for regular iteration, it is not considered to be an appropriate use of parliamentary time for Parliament to be considering regular changes to standards, particularly when this could impact on the effective operation of dashboards. For that reason, we have proposed (as set out in annex A: background in this document and in regulation 4) an approval process that requires Secretary of State approval of standards.

40. We propose that MaPS (and in one limited case set out below, TPR) should set standards covering the legislative requirements. We expect there will be a range of standards covering:

a. Data – data standards will outline the data elements and the formatting requirements that trustees or managers must follow when returning data, including contextual data to accompany value data, to members via dashboards.

b. Technical – covering matters such as how the pensions dashboards service must connect to MaPS and pension providers, including:

i. The connectivity mechanisms to be used (i.e. APIs).
ii. The protocols for authorising the sharing of information between pensions dashboards services, the trustees or managers of occupational pensions schemes, the Secretary of State, and MaPS.
iii. How schemes will be required to generate and register PeIs.

c. Design – design standards will cover elements of how the State Pension and view data should be presented on the dashboard, messaging, signposts and guidance.

d. Reporting – reporting standards will cover the specific details of what information we expect schemes and QPDSs to keep and report to MaPS and regulators in relation to monitoring compliance and performance. In limited circumstances, these reporting standards may be set by TPR as well as or instead of by MaPS.

41. A code of connection will address how to connect to the digital architecture and will incorporate the following standards:

a. Security – covering matters such as the connection points and minimum information assurance the provider must provide to MaPS for connection purposes.

b. Service – providers must follow service standards which will cover things like interoperability, software conformance, maintenance, and outage handling.

c. Operational – providers must follow operational standards which will cover things like, the process for raising issues, escalation processes, on-boarding processes, and remediation routes for failures.

42. Each chapter will outline in more detail where and why we propose referring to standards. It is important to first set out how we anticipate ensuring the effective oversight and monitoring of the standards.

Oversight and approval of standards

43. It is crucial that we have an effective mechanism for the oversight and approval of standards. Below, we set out how we propose the Regulations would ensure that standards are effectively scrutinised and agreed, in order to ensure they are effective.

	Oversight and approval of standards
Standards referred to	In the Regulations we have referred to each of the standards that would be set by MaPS or TPR. There are several types of standards that have been referred to in the Regulations: connection and security, technical, service, reporting, design, Pensions Identifiers (PeIs), and data standards. These standards would apply to the trustees or managers of occupational schemes or to QPDSs, as indicated: - connection, technical, security, operational and reporting standards would apply to both schemes and QPDSs - design standards are for dashboard providers only - technical and data standards are for trustees or managers of schemes only to consider
Compliance with standards and the effect of non-compliance	In relation to the code of connection and technical standards, compliance is essential because failing to comply with these poses a risk to the digital security of the dashboard ecosystem. MaPS, through the digital architecture, will be able to detect non-compliance with the connection, technical, security and operational standards. Failure to adhere to any of these standards would lead to deregistration from the Governance Register and disconnection from the architecture. This would be automatic and is proportionate given the importance of protecting the safety of the dashboard ecosystem. TPR will also be able to take enforcement action if schemes fail to comply with any of the requirements in Part 3 of the regulations. QPDSs would not be able to operate unless they are compliant with these standards as well as meeting the other requirements that apply to pensions dashboards services or their providers. In relation to reporting, design, technical and data standards, the risk of non-compliance for both QPDSs and occupational pension schemes poses a threat to the credibility of the dashboard ecosystem rather than its security. Compliance is essential to ensure that dashboards are successful and failure to adhere to any of these standards by trustees or managers of occupational pension schemes would be a breach of regulation requirements that may result in a compliance or penalty notice being issued by TPR. For QPDSs, if MaPS notifies the FCA that a dashboard provider is no longer complying with these standards and therefore no longer meets the criteria of being a QPDS, the FCA can de-authorise the provider. Further detail about the FCA’s role is set out in chapter 7. As we set out, we are proposing an additional function whereby a third-party auditor is engaged by dashboard providers to assure MaPS of adherence to Design and Reporting standards, where relevant, at the outset and on an annual basis thereafter. It will also be capable of being wider than just for reporting and design where necessary.
Oversight and review of standards	To ensure that the setting of standards is appropriate, we think it is crucial that the Secretary of State has oversight powers. We propose that the Regulations would require the Secretary of State to approve the first set of standards and any subsequent amendments to standards which contains amendments that are more than minor technical changes.
Interplay between DWP legislation	The Pensions Act 2004 (as amended by the Pensions Scheme Act 2021) will provide powers to set requirements to comply with standards relating to pensions dashboards. The standards referred to in this consultation for the purpose of delivering pensions dashboards are referred to in Regulations that would be made under the Pensions Act 2004.

44. A provision at the end of Part 1 of the draft SI indicates that the Secretary of State must approve any standard referred to in the Regulations before it is published for the first time. Where subsequent changes are made that MaPS view as going beyond minor technical changes, they must also be approved by the Secretary of State. We anticipate that there are likely to be several situations where a change to standards will require re-approval by the Secretary of State because the change goes beyond something that is minor technical. Examples of these type of changes could be:

a. Substantial (i.e., incurring significant resource to implement) technological developments or changes in the way the schemes are required to connect and receive or return information. For example, an upgrade of the API standard to a newer technology stack, or the use of new security software.

b. A substantial change to business processes required to meet duties. For example, additional reporting or record keeping requirements that means schemes are required to provide significantly more information to MaPS or the regulators for the monitoring and detection of non-compliance.

45. We expect MaPS (or TPR with respect of reporting standards) to consult on the first set of standards before approval is sought from the Secretary of State. Where it is determined that Secretary of State approval is required for a change in standards because the proposed change goes beyond a minor technical amendment, it is expected that MaPS will consult on the change before the Secretary of State would approve the revised standard. Flexibility in MaPS’ consultation approach is important to avoid unnecessary burden. It is likely that more minor changes to standards, or changes that are significant but may only affect a few parties, would be preceded with a lighter-touch or more focused consultation.

46. As a matter of course, we expect that MaPS would engage closely with the regulators (FCA / TPR) in agreeing changes to the standards and the deadlines by which the parties to whom they apply would be expected to comply with these changes. The PDP will publish information on standards shortly.

Consultation questions

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

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

Chapter 2: Data

1. This chapter refers to Chapter 2 of Part 3 of the Regulations, along with Schedule 3. It explains the policy rationale and proposed requirements (as contained in the Regulations) for the proposed data elements that would be central to the operation of dashboards. This includes find data – to be used for matching savers to their pensions– and view data, which trustees or managers of schemes return to dashboards.

2. The following table describes in broad terms the key elements within this consultation chapter, and the proposed requirements made in the Regulations.

Chapter sub section	Summary of policy aims / proposed legislative requirements
Find data	Find data consists of personal data provided by individuals to the central dashboards architecture and sent by the Pension Finder Service to schemes, that enables schemes to search their records for a match. Some find data elements would be verified by the Identity Service, and some will be self-asserted by the individual using the dashboard. Trustees or managers would not be compelled to hold particular data for matching purposes, and schemes may use different data elements to search for a match.
View data	View data is pensions data that is returned to the dashboard by pension schemes once the individual’s identity has been verified and a ‘view’ request has been made (by the individual or by the party to whom they have delegated access at the Consent and Authorisation Service). View data is the collective term to describe administrative data, additional signpost data, and value data.
Administrative data	Administrative data is broken down into three categories: - information about the pension scheme - information about the scheme’s administrator - information about the employment that gave rise to the pension All schemes would need to provide administrative data, with the exception of certain employment details, which schemes would need to provide if they hold it. Trustees or managers would be required to be able to provide administrative data to a new member who seeks view data within 3 months of joining the scheme no later than three months after the member joined the scheme. Administrative data should be returned to individuals by trustees or managers immediately after a request is received.
Signpost data	Trustees or managers would need to provide a website address to individuals where they can access (where these apply): - information on member-borne costs and charges - the scheme’s statement of investment principles - the scheme implementation statement The Regulations propose that signpost data should be returned to individuals by trustees or managers immediately after a request is received.
Value data	Value data is the collective term used to describe accrued and projected pension values. The methodology to be used to calculate certain values in money purchase pensions is set out in Actuarial Standards Technical Memorandum 1 (AS TM1), which ensures parity with annual statements provided to most individuals with these pensions. The Financial Reporting Council (FRC) will be consulting on changes to AS TM1 which seek to improve the consistency of projections. The following value data should be returned to individuals by trustees or managers within the time scales regulation 25 proposes.
Value data for money purchase schemes
Accrued pension data	Schedule 3, Part 1 of the Regulations proposes that: For money-purchase benefits, trustees or managers, would be required to provide individuals with the value of the member’s accrued rights under the scheme, which may be a value generated for a benefit statement within the last 12 months or a calculation performed within the last 12 months. Trustees or managers would also need to provide individuals with the above value expressed as an annualised income based on the same illustration date. The calculation of this figure should follow the methodology set out in AS TM1, omitting elements which concern future contributions and fund growth. This value would only be required after the first statutory money purchase illustration (SMPI) is produced, after October 2023, as set out in the projections section below.
Projections (active members only)	Schedule 3, Part 1 of the Regulations proposes that: - for money purchase benefits, trustees or managers would be required to provide individuals with an illustration of what their pension might be worth in retirement, as an income, and as a projected pot value if it is held by the scheme. This would incorporate the current value along with any future contributions and anticipated investment returns. The Regulations would require trustees or managers to follow the relevant guidance in AS TM1. The FRC intend to consult on changes to AS TM1 in early 2022, with changes due to come into force for SMPIs from October 2023. The Regulations will only require money-purchase schemes to provide projections from the point at which an SMPI has been produced for the individual, after October 2023 - there are several exemptions, outlined in Schedule 3, Part 2 of the Regulations, that mean certain individuals with money purchase benefits would not receive a projected value on pensions dashboards. These exemptions largely reflect the existing exemptions set out in The Occupational and Personal Pension Schemes (Disclosure of Information) Regulations 2013 (‘Disclosure Regulations’) under regulation 17, paragraph 6. Individuals would still receive accrued pension information in these circumstances
Value data for non-money purchase schemes
Accrued pension data	For non-money purchase benefits, Schedule 3, Part 1 of the Regulations proposes that trustees or managers would be required to provide active scheme members with the amount of pension that would be payable if pensionable service were to have ended at the illustration date, presented as if the individual has reached normal pension age, calculated in line with scheme rules. The value provided must be from a statement provided within the last 12 months, or from a calculation performed in the last 12 months. For deferred members, we are proposing that trustees or managers of non-money-purchase schemes provide members with a value that has been revalued to the illustration date, presented as if the individual has reached normal pension age.
Projections	Schedule 3, Part 1 of the Regulations proposes that: - for non-money purchase benefits, trustees or managers would be required to provide active members with an illustration of their pension in retirement - calculations made by these schemes should be made following scheme rules, assuming that the member continues in pensionable service until normal pension age, and assuming no increase in the individual’s salary - the projected value would be required from non-money purchase schemes from the point at which they connect to the digital architecture
Other data requirements
Cash balance schemes	The proposals for cash balance schemes, as set out in Schedule 3, Part 1, are for members to be provided with an accrued pot, calculated in the same way as the accrued value for non-money purchase schemes, but presented as a pot, and an annualised accrued value which applies AS TM1 assumptions, minus elements on future contributions and growth, to that accrued pot. We also propose that these schemes provide a projected pot value and a projected income value, with the projected pot value built up in the same way as set out for non-money purchase schemes. The annualised accrued value would only be required from October 2023.
Collective money purchase schemes	As proposed in Schedule 3, Part 1, collective money purchase schemes, also known as Collective Defined Contribution (CDC) schemes would be required to provide their active members with an annualised accrued value, as well as a projected value. Deferred members would be provided with an accrued value. These values reflect the values set out for CDCs in the amendments to the rules on disclosure proposed in the Occupational Pension Schemes (Collective Money Purchase Schemes) (Modifications and Consequential and Miscellaneous Amendments) Regulations 2022, which are due to be laid in March.
McCloud judgement and Public Service Pension Schemes	Schedule 3, Part 1 of the Regulations propose that the information requirements for public sector pension schemes may include two alternative values for accrued and projection requirements to cater for those schemes and individuals affected by the McCloud judgement and Deferred Choice Underpin (as defined in the glossary).
Hybrid schemes	Trustees or managers of hybrid schemes (schemes which offer both money purchase and non-money purchase benefits) would provide the same data elements as other occupational pension schemes, as relevant to that element of the hybrid pension. Where a benefit is a mix of money purchase and non-money purchase benefits, and the calculation for value data is made with reference to both benefit types, then only one value is returned. The value returned should be that of the greater benefit.
State Pension information	Regulation 9 proposes specific requirements for what State Pension data is to be shown and the messaging that would accompany this.

Introduction

3. For dashboards to be a useful tool, and to support the operation of finding and displaying an individual’s pensions information, both trustees or managers of relevant occupational pension schemes, and individuals using dashboards must provide data. Individuals will need to provide personal data, ‘find data,’ which will allow trustees or managers to search their records for a match, and, if successful, trustees will subsequently return scheme data for that individual, ‘view data.’

4. The view data which we are proposing to require trustees or managers to provide is broadly within the scope of the Disclosure Regulations 2013, and for the most part, is available to individuals on statements issued annually or on request – although as this chapter will note, there are areas where we propose additions to ensure that the needs of individuals using dashboards are met. Throughout this chapter we have highlighted where proposed information requirements go beyond the scope of the Disclosure Regulations 2013. Chapter 3 will address the legislative requirements on trustees or managers of schemes in relation to pensions data and chapter 7 will address legislative requirements on QPDSs.

5. The Data Standards Usage Guide, published by the Pensions Dashboards Programme in December 2020 gives an overview and description of the individual data elements that we expect to see on dashboards. An updated Data Standards guide will be published by the Pensions Dashboards Programme around the same time as this consultation to reflect the requirements proposed in the Regulations and described in this consultation. Data returned by trustees or managers to dashboards would show individuals information about the pension scheme, the pension scheme administrator, the employment(s) linked to the pension scheme, if known, and accrued and projected retirement income values.

6. Dashboards would receive the pensions details back from the pension scheme following a view request made by an individual using a dashboard. The data that is sent is then presented on the screen to the individual, and the dashboard can cache this data for the duration of the individual’s session. If the individual closes their browser or logs off their dashboard (i.e., their session is closed) then that data would no longer be available.

7. Subject to the parameters set out in design standards, dashboards would not alter the data that is sent from the pension scheme but would be able to read/see the data, which they would have permission to do based on the individual’s consent to the access policy. A qualifying dashboard provider should choose the most appropriate lawful basis for its processing of view data. It may be that user consent is not required. The provider should also ensure that it complies with MaPS design standards. This will enable the dashboard to select the correct values to display to the individual and present any accompanying messaging. The individual would consent to a dashboard of their choice being able to retrieve their pension details on their behalf and display them on the dashboard.

Find data

8. Find data consists of personal data provided by individuals to the digital architecture and is sent to schemes by the Pension Finder Service within the digital architecture (a more detailed explanation can be found in the find and view chapter), to allow pension schemes to match individuals against their records. Information such as the individual’s name, date of birth and address would be verified by the Identity Service within the dashboards architecture, and other elements – NI number, email address, mobile number – would be self-asserted by the individual. Information related to the identity of the individual who is the subject of the request would be provided to schemes for the purposes of locating pension records only.

9. We have not proposed any requirements on trustees or managers to use particular data for matching purposes. We believe they should instead be given discretion over which data elements they use to suitably search their records for a match. Schemes would, however, need to ensure they take reasonable, diligent steps to search for matches and minimise the risks of data breaches or, conversely, not returning pensions matches. In this, trustees or managers will need to have regard to any guidance issued on matching by TPR.

10. Find data would be sent to schemes (from the Pension Finder Service) in a format described in standards published by MaPS, but we have not proposed any requirements on trustees or managers to hold it in the way described. This means that schemes could process the data to re-format it and enable them to search for a match in a format more akin to their systems, the same of which is true for an integrated service provider who may be undertaking these duties on the trustees’ behalf.

View data

11. ‘View data’ refers to the data that the occupational pension scheme would need to return to the dashboard and is made available to the individual once a request for information has been received, and the identity of the individual authenticated. View data would need to be returned to the individual using the dashboard in the format to be outlined in MaPS standards. View data that schemes would be expected to supply is split into three categories: administrative data, additional signpost data, and value data, which are described in more detail below.

12. We wish to give trustees or managers discretion as to how the view information should be held in their internal systems. However, this information would need to be sent to dashboards in the format outlined in MaPS standards within set time limits.

Administrative data

13. Regulation 23 outlines the administrative data that would need to be sent to an individual by trustees or managers when returning their data following a view request. It is split into three categories:

a. Information on the pension scheme – which would need to be provided by all occupational pension schemes to which the Regulations apply and gives details about the pension scheme. Proposed data elements to be provided by trustees or managers in respect of information on the pension scheme are outlined in regulation 23(1)(a).

b. Information on the scheme’s administrator – which would need to be provided by all occupational pension schemes to which the Regulations apply and gives details about the administrator of the scheme. Proposed data elements to be provided by trustees or managers in respect of information on the scheme’s administrator are outlined in regulation 23(1)(b).

c. Employment details – which would need to be provided by trustees or managers only if they hold the information and gives details about the employment that gave rise to the pension. Proposed data elements to be provided by trustees or managers in respect of employment details are outlined in regulation 23(1)(c).

14. We propose that an additional data field is provided as part of administrative data, which is the date of birth of an individual. This is being proposed as PDP user testing has suggested that qualifying pensions dashboards be able to display not only the retirement age, but the number of years the individual is away from it. The inclusion of the date of birth as a data field is for display logic purposes only – to enable dashboards to present the time to retirement: the date of birth itself would not be shown.

15. The proposed requirements to provide information on the pension scheme exceed what is currently required by trustees or managers under the Disclosure Regulations 2013. However, they have been included on the basis that this information will not be difficult for trustees or managers to provide, and the content is unlikely to change often. The administrative data elements would be useful in helping individuals using dashboards to understand more about their pension scheme and administrator, as well as providing information to enable them to get in contact.

16. Under the Disclosure Regulations 2013, there is a possibility that some new scheme members may not receive information about their pension via a benefit statement for nearly two years. While it would be reasonably rare for a member to have to wait nearly two years, it would be possible if an individual joined a scheme just after the most recent statement cycle, and then must make a full year of contributions before receiving information. However, we feel that it is reasonable for new members to receive administrative data (pension scheme information, administrator information, and employment details) on dashboards before this time. Regulation 23(3) proposes that trustees or managers would be required to provide this information to new members in response to a dashboard request no later than three months after the member joined the scheme. Despite this proposed requirement going beyond current Disclosure Regulations 2013, we feel it is reasonable and proportionate as this information should be readily available and consistent.

17. We envisage that design standards set out by MaPS will provide QPDSs with wording to show on dashboards to inform the individual using the dashboard that they may not see their pension information displayed if they are very new to a scheme.

Signpost data

18. Signpost data, which are proposed at regulation 24, would need to be provided, where applicable, by relevant occupational pension schemes by way of a website address, where individuals can see:

a. Information on member-borne costs and charges.

b. The schemes’ statement of investment principles.

c. The scheme’s implementation statement.

Response times for administrative data and signpost data

19. As outlined in regulation 23(2) (for administrative data), and 24(2) (for signpost data), we have proposed that schemes should provide the administrative data and the signpost data immediately following receipt of a view request. Providing this information would not require schemes to complete calculations, does not change often and should be readily available.

Value data

20. Value data is the collective term used to define accrued pension values data and projected pension values data elements.

21. In the Regulations, we are proposing a requirement on schemes to provide both accrued and projected values, including values which represent annual income amounts.

22. Recent qualitative research undertaken by Ipsos MORI on behalf of MaPS has confirmed the findings of previous research and shows that prospective users expect to see information about income projections, as the pyramid diagram below shows. Research undertaken by 2CV in 2017 found that “most people don’t know the value of their pensions, yet they feel this is the most important piece of information they need to make decisions about them. The most pressing information is the current value and projected value for retirement.” ^{[footnote 4]} Research undertaken by DWP and Pension Wise as part of the 2018 Pensions Dashboards consultation found that a “user need” for dashboards is “to be able to see a full picture of all my pensions.”^{[footnote 5]}

23. Additionally, the PDP published a Rapid Evidence Assessment of existing domestic and international literature on what prevents people from engaging with their pensions in June 2021. This assessment stated that “information on projected balances and income levels is generally found to increase engagement with pensions. Hence, providing information about current and future balances, as well as projected retirement incomes, is likely to enhance a dashboard”.^{[footnote 6]}

24. PDP user testing suggested that while the presentation of income-based values is important in supporting understanding and engagement. The presentation of the suite of values together – that is, accrued and projected income values alongside each other – aids comprehension further. It is easier to understand what each means if the other is also present.

25. However, our engagement with industry has highlighted the challenges certain schemes will face in providing some of these values, and we are keen to strike the right balance between delivering an ambitious and successful dashboards service for individuals, whilst acknowledging the demands placed on schemes. We are keen to further understand the challenges for industry as well as the benefits for individuals.

26. We propose that pensioner members (as defined in the Pensions Act 1995), are out of scope of pensions dashboards. Given our policy position that pensioner members are not in scope, these members would not receive information on dashboards for the scheme(s) under which they are considered a pensioner. While this will lead to a number of scenarios whereby people do not see some or any of their pensions, we believe that if a member is taking benefits from a pension (or a portion of it), they are likely to be better engaged and aware of what that pension is worth. Benefits which would be out of scope include pensions where a tax-free lump sum has been taken, and money purchase pensions which have been annuitized or are in drawdown, including partial drawdown. We have proposed that members who have taken uncrystallised funds pension lump sums (UFPLS) payments who continue to be active or deferred members of the scheme remain in scope and would need to be provided with their accrued pension information, based on the remaining value of their pension.

27. Our proposals in this section would see dashboards present a static set of values, each calculated at a specific point in time, based on a scheme’s normal retirement date. This means that different entitlements in different schemes may be payable at different times. Where this is the case, and in line with MaPS design standards, dashboard providers will be required to communicate this clearly to individuals. Dashboards would present a simplified view of values, which would be indications, rather than detailed quotes. We believe this ensures values will be presented on dashboards that are meaningful to individuals, without disproportionate burden on industry to calculate and/or make available these figures. While the values would be a simplified view to aid readability, dashboards will present contextualising information which shows additional/linked benefits (e.g., additional voluntary contributions) and information about calculation or indexation differences, as required by MaPS data standards.

28. The response times section of the Find and View chapter (chapter 3) explains the proposed requirements for response times for money purchase and non-money purchase schemes in detail. As that chapter describes, the response times differ among scheme type and the information that is to be provided.

29. The below table summarises the value data elements from different schemes that we propose that members should see:

Value: Accrued

Scheme/member type	Pot	Annualised
Money purchase	Yes – Schedule 3, Part 1, 1(2)(a)	Yes – Schedule 3, Part 1, 1(2)(b)(i)
Active non-money purchase	No	Yes – Schedule 3, Part 1, 2(1)(a)(i)
Deferred non-money purchase	No	Yes – Schedule 3, Part 1, 2(1)(b)
Active Cash balance	Yes – Schedule 3, Part 1, 3(1)(a)(i)	Yes – Schedule 3, Part 1, 3(2)(a)(i)
Deferred cash balance	Yes – Schedule 3, Part 1, 3(1)(b)	Yes – Schedule 3, Part 1, 3(2)(b)
Active CDC	No	Yes – Schedule 3, Part 1, 4(a)(i)
Deferred CDC	No	No
Hybrid	Follow rules to money purchase and non-money purchase pension elements. Where the benefit is a hybrid benefit, calculated with regard to both money purchase and non-money purchase benefits, schemes should return only one set of values.	Follow rules to money purchase and non-money purchase pension elements. Where the benefit is a hybrid benefit, calculated with regard to both money purchase and non-money purchase benefits, schemes should return only one set of values.

Value: Projected

Scheme/member type	Pot	Annualised
Money purchase	If held – Schedule 3, Part 1, 1(2)(b)(ii)	Yes – Schedule 3, Part 1, 1(2)(b)(iii)
Active non-money purchase	No	Yes – Schedule 3, Part 1, 2(1)(a)(ii)
Deferred non-money purchase	No	No
Active Cash balance	Yes – Schedule 3, Part 1, 3(1)(a)(ii)	Yes – Schedule 3, Part 1, 3(2)(a)(ii)
Deferred cash balance	No	No
Active CDC	No	Yes – Schedule 3, Part 1, 4(a)(ii)
Deferred CDC	No	Yes – Schedule 3, Part 1, 4(b)
Hybrid	Follow rules to money purchase and non-money purchase pension elements. Where the benefit is a hybrid benefit, calculated with regard to both money purchase and non-money purchase benefits, schemes should return only one set of values.	Follow rules to money purchase and non-money purchase pension elements. Where the benefit is a hybrid benefit, calculated with regard to both money purchase and non-money purchase benefits, schemes should return only one set of values.

30. As the State Pension is not an entitlement in the same way that an occupational pension is, in that actual entitlement only exists to State Pension when an individual reaches their State Pension age and meets the relevant entitlement conditions, the value data to be provided is not referred to as “accrued” and “projected.” Value information provided in respect of an individual’s State Pension will be “current amount” and “forecast amount.”

31. Furthermore, non-money purchase schemes may return accrued and projected values as lump sums rather than annual amounts if this reflects the way in which that scheme operates. MaPS Data Standards will ensure that values returned in this format can be displayed to members.

Proposed Value data requirements

Proposed value data requirements for schemes providing money purchase benefits

Accrued pension data requirements

32. The proposed requirements on schemes providing money purchase benefits for pensions dashboards, which are specified at Schedule 3, Part 1(1) in the Regulations, are as follows:

a. Trustees would need to provide individuals with the value of the member’s accrued rights under the scheme (the accrued pot value), defined in the Regulations at Schedule 3, Part 1(5), at a date specified by the scheme trustees, but which must be no more historic than the accrued value as provided on a benefit statement in the last 12 months, or from a calculation done in the last 12 months, as regulation 25(3) states. This means that, should a scheme store it, it would be acceptable to use the value from the most recent benefit statement.

b. Trustees would also need to provide individuals with the above value expressed as an annualised accrued value, defined in the Regulations at Schedule 3, Part 1(5) as the value of a member’s pension benefits built up so far, expressed as an annual income. This would follow the methodology set out in AS TM1, omitting elements which concern future contributions and fund growth, and should be based on the same calculation date as the pot value. The value should be presented as if the member has reached normal pension age, based on the member’s current pensionable salary/earnings.

33. The accrued pot value (specified at ‘a’ above) is routinely provided by schemes providing money purchase benefits as part of a member’s annual benefit statement as mandated under requirements contained in the Disclosure Regulations 2013. The annualised accrued value, as stated at ‘b,’ is a new proposal for schemes offering money purchase benefits that is not currently required under Disclosure Regulations 2013. However, we believe this information 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 and being more understandable when presented against any state pension and non-money purchase entitlement.

34. Because for this new ‘annualised’ value for accrued entitlements money-purchase schemes will be reliant on methodology set out in AS TM1, which is to be updated by the Financial Reporting Council (FRC), we will not require these values to be provided to dashboards until such a time as an SMPI has been provided to the individual, from 1 October 2023, as Schedule 3, Part 1(1)(b)(i) states. If schemes wish to provide a value before that date using the current guidance, they may do, and must use the version of the AS TM1 guidance which is current at the time of the illustration. Plans for the FRC’s consultation on AS TM1 changes are set out in more detail as part of the projected values section below.

Pension projection data requirements

35. As proposed in Schedule 3, Part 1, trustees or managers would provide individuals with an illustration of their pension, projected to the scheme’s normal retirement date, expressed as an annual income. The projection would incorporate the current value along with any future contributions and anticipated investment returns, and methodology for calculating this, alongside the methodology to convert to an annualised amount will be set out in AS TM1.

36. Should a scheme store it, it would be acceptable to use the value from the most recent benefit statement with a calculation that follows updated AS TM1 methodology, as the following paragraphs set out. Additionally, should schemes hold it, we propose that trustees or managers also provide members of money purchase schemes with the ‘projected pot’ value, defined at also at Schedule 3, Part 1, para 5.

37. Schedule 3, Part 1(1)(b)(iii) proposes that schemes offering money purchase benefits use AS TM1 as the basis of calculations for dashboards to maintain consistency with Disclosure Regulations 2013 on annual benefit statements. This would reduce the number of different calculations schemes would have to make in providing values to members across different channels (i.e., dashboards and benefit statements).

38. The FRC is responsible for AS TM1 and in part reflecting the introduction of pensions dashboards, they will be consulting in quarter one of 2022 on changes which seek to improve the consistency of projected values, particularly when comparing across different schemes. The key changes are likely to include:

a. Substantial changes to the methodology used to provide fund growth assumptions, to improve the consistency across schemes.

b. Removal of existing choice around elements of the projection calculation methodology, again to improve consistency. For example, the FRC will consult on options around the inclusion of a lump sum and the type of annuity to be used.

39. The FRC’s consultation will provide a detailed description of all the proposed changes and will provide a key opportunity for pension schemes and other interested parties to provide views. Changes are likely to be significantly more substantial than recent AS TM1 changes, so we are also keen to hear views from schemes and other interested parties about the deliverability of these values, as well as the potential impact of these proposals for individuals. We expect that there will be crossover between the dashboard and FRC consultations to allow for informed responses, though it is unlikely that this will be for the entire consultation period.

40. Because we wish for Dashboards to be able to reflect revised AS TM1 methodology, we believe that it is reasonable to give industry time to deliver the changes into annual SMPIs and subsequently to dashboards. The FRC aim to publish revised AS TM1 guidance by October 2022, but with an extended lead time, coming into force only from 1 October 2023.

41. We propose, therefore, that the requirement for trustees to provide an income projection to dashboards would only apply from the date on which an SMPI has been produced for that individual, in the 12 months from 1 October 2023. Schemes may provide projected values and an annualised accrued value on a voluntary basis at any time before an SMPI has been issued after 1 October 2023, and this may be by providing a value already calculated for a current pensions illustration; or as a new calculation provided for dashboards. In all cases, the calculation should use the version of the relevant guidance which is current at the time of the illustration. All values provided for a particular benefit should have the same illustration date.

Exemptions to providing projections – money purchase benefits only

42. There are several exemptions under regulation 17, paragraph 6 of the Disclosure Regulations 2013 that mean trustees or managers of schemes which offer money purchase benefits are not required to return pension projection information to members (although they may choose to do so). This section explains those exemptions that will apply, as stated in the draft dashboard Regulations at Schedule 3, Part 2. It is important for respondents of this consultation to be aware that where these exemptions apply, trustees or managers of schemes offering money purchase benefits will still be required to provide accrued pension data to members; Schedule 3, Part 2, 6(1) states that the exemptions outlined in that part relate only to the projected pot and projected annualised values. This means that, as well as being notified of the existence of the pension via the administrative data, they will still be provided with one form of value information and therefore will have an indication of what their pension is worth, meaning that dashboards continue to provide an important function of helping to reunite people with pensions, and providing important value information to help them make decisions about their pensions.

43. We have already stated that pensioner members are out of scope of dashboards and have proposed that exemptions under regulation 17(6) of Disclosure Regulations 2013 should be echoed in the draft dashboard Regulations, as proposed in Schedule 3, Part 2. Therefore, under our proposals, trustees or managers would not be obliged to provide projected information on dashboards if the member is within two years of retirement but can if they choose to.

44. We also propose to echo the exemptions set out in Disclosure Regulation 17(6)(c). This means trustees or managers will not be required to provide income projections to dashboards where:

a. (As per Disclosure Regulation 17(6))

i. 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
ii. since that previous illustration date, no contributions have been made to the scheme by, or on behalf of, the member, and
iii.the trustees or managers of the scheme have previously given notice to the member that information will not be given to the member again unless further contributions have been made

45. We have highlighted this to clarify that, in line with the Disclosure Regulations 2013, for the exemption detailed in Disclosure Regulation 17(6)(c) &(d) to apply, each of the criteria specified in (c)(i) and (ii) and (iii) must apply, as would be the case with the exemption at 17(d). This means, for example, that even if a member has accrued rights of less than £5000, they will still receive a projected value on dashboards, providing they are still actively contributing. If each of the three specified criteria (and therefore the exemption) apply, as mentioned at paragraph 43 (above), these members will still be given accrued pension data on dashboards. We understand that some schemes may interpret the exemptions in the existing regulations differently and will be keen to receive feedback in the consultation about the extent of this. We are also keen to understand the extent to which schemes provide such information routinely, despite the exemption.

46. The Regulations set out the specific projected pension data items schemes would need to provide, including those which will help individuals to contextualise the value shown. Additional detail relating to formatting would be set out in standards.

Proposed value data requirements for schemes offering non-money purchase benefits

Accrued pension data requirements

47. As set out previously, research shows the benefit of providing individuals with both accrued and projected income values, because it aids understanding of the meaning of each value. In addition, provision of both values gives individuals an indication of the value of the pension they have accrued so far, and the value of the pension that they could receive, should they continue their current behaviour – providing a good basis for them to consider any changes to the way in which they are planning for retirement. We are keen to ensure that values are reasonably recent in order to be of most use to individuals. Therefore, we propose that values would need to be from a statement produced within the last 12 months, or from a calculation performed within the last 12 months. This is true for both accrued and projected values.

48. For schemes offering non-money purchase benefits, the expectations of Disclosure Regulations 2013 are currently relatively flexible, with generally no annual statement requirement, and the choice of a range of values to be provided on request.

49. Unlike under Schedule 5, Part 1 of Disclosure Regulations 2013, where trustees have a choice of which values to provide to active non-money purchase members, dashboard Regulations would clarify the expectations by defining an accrued value to use for dashboard purposes, so that there is a fixed value, and therefore standardisation for dashboards.

50. The proposed accrued pension data requirements for schemes offering non-money purchase benefits, which must be from a statement or calculation produced within the last 12 months, are as follows:

a. Non-money purchase scheme trustees would need to provide active scheme members with an accrued pension value, as defined at Schedule 3, Part 1. This would be the amount payable if pensionable service were to end at the illustration date, presented as if the individual has reached normal pension age. This should be calculated in accordance with scheme rules, and assuming no increases in salary. In practice, we envisage that this effectively means the amount built up, up to the calculation date, with no expectation of forward projection, earnings increases, or price discounting. We are keen to understand whether this reflects current practice, and whether the regulations as drafted enable such a calculation.

For example: 20 years’ service at £30,000 current pensionable earnings, and an 80ths scheme = 20/80*£30,000 = £7,500

b. Our proposal for deferred members of non-money purchase schemes, as per Schedule 3, Part 1 of the draft dashboard Regulations, is for the value to be re-valued to the illustration date, in accordance with scheme rules, presented as if the individual has reached normal pension age. In practice this means the deferred pension at the date of leaving, revalued to the illustration date, which must include statutory revaluations on any non-guaranteed minimum pension. The illustration date is the date by reference to which the value data provided to an individual relates, whether that be for a statement produced within the last 12 months, or a calculation performed in the last 12 months. We accept that in the case of the former, the illustration may be up to 24 months old.

51. Regarding the accrued value at paragraph 50a (above), Schedule 5, Part 1 of the Disclosure Regulations 2013 leaves the value to be provided to active members of non-money purchase schemes open to choice. This choice being with the value calculated as either if pensionable service were to end on a date specified by the trustees or managers of the scheme, on the member attaining normal pension age, or on a date agreed between the member and the trustees or managers of the scheme.

52. By requiring the accrued value to be calculated to the end of the last scheme year, we would create standardisation for members on dashboards, providing them with an up-to-date and useful figure.

53. While this is not going outside of what may already be provided under Disclosure Regulations 2013, we recognise that depending on the scheme’s choice of which reference point to use under Schedule 5 Part 1, this may be a new calculation for some. We think it is important that dashboard users see these values consistently but are also keen to understand the deliverability.

54. In respect of the value at paragraph 50b (above), Schedule 5, Part 1 of the Disclosure Regulations 2013, requiring trustees to revalue a deferred entitlement to the date the calculation is made may present a change from current practice for some. We understand, for example, that some schemes currently provide deferred members with an historic value (including providing the value of the pension on leaving the scheme, sometimes without any price-conversion). However, we do not believe that this approach is particularly helpful, especially when values will be presented on dashboards potentially alongside other schemes; and this practice is out of line with what is set out in Schedule 5, Part 2, paragraph 5 of the Disclosure Regulations 2013. We recognise that the approach we are suggesting is also not entirely consistent with the Disclosure Regulations 2013, but we understand from informal industry engagement that we have reflected common practice, where such values are provided. We understand that, for schemes that do revalue non-money purchase entitlements, they would generally follow this method, rather that projecting the value to normal retirement date, and discounting it back.

55. Further engagement with industry has suggested that there may be an alternative, simplified approach which could be beneficial for certain schemes, particularly where processes for calculating deferred values are not already in place. This simplified approach would effectively allow schemes to provide a value which is calculated by adjusting the pension that an individual has accrued on leaving the scheme by inflation, so that it is expressed in today’s prices. Such a methodology could be provided as an option, so that schemes can use the methodology which best suits them.

56. A potential risk to this approach is that allowing schemes to select a methodology introduces inconsistency of methodology, which, depending on the complexity of the benefit, could lead to differences in the values calculated. One option may be that the proper calculation should be the norm but with an option for schemes to use the simplified method for a limited period only, to allow them to move to more accurate calculations over time.

57. We are interested in views on the impact of this, and whether, for the purposes of Dashboards, values will be close enough to be comparable, and to provide a reasonable indication of the value of a deferred pension. We are also keen to understand whether the inclusion of this methodology as an option would 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.

Pension projection requirements

58. The proposed requirement for schemes offering non-money purchase benefits as outlined in the Regulations at Schedule 3, Part 1(2) is for trustees or managers to provide active members with a projected value which is calculated following scheme rules, assuming that the member continues in pensionable service and continues to build up benefits until normal pension age, and assuming no increase in the individual’s salary. The value should be presented as if the individual has reached normal pension age. In practice, we think that this would be provided by simply assuming that the further potential years of accrual into the scheme have been accrued, without taking into account other factors. For example: currently, an individual has 20 years’ service at £30,000 current pensionable earnings but has the potential to accrue another 15 years before pension age, so the calculation would be 35/80*£30,000=£13,125.

59. Disclosure Regulations 2013 require that calculations be made without regard to any possible increases in a member’s salary, and we propose to mirror this so that people using dashboards are provided with a value which is most easily understood in comparison to their current earnings, and alongside any values they may see for State Pension or money-purchase schemes.

60. For active members, the Disclosure Regulations 2013 currently require schemes to select one of three values for statements, of which one is a projected value. Depending on whether or not a scheme currently provides a projected value, this may be a new calculation for dashboards. We acknowledge also that statements for non-money purchase schemes (except certain public service pension schemes) are only provided ‘if requested,’ but we believe that it is important for people using dashboards to be able to see these values.

61. We do not propose schemes offering non-money purchase benefits would provide deferred members with a projected value. This is because the projected and accrued values for these types of members would give a reasonably similar value (since neither calculation would involve future accrual – although we acknowledge the potential for some divergence), and as set out previously, we understand that common industry practice is to provide an accrued value.

Proposed value data requirements for schemes offering cash balance benefits

62. Cash balance pensions are comparable with other non-money-purchase schemes and benefits in the way that a pension is accumulated but are structured in a similar way to money purchase pensions in the decumulation phase, particularly in terms of the calculation of annualised pension estimates, which incorporate elements of SMPI requirements, as set out in the Disclosure Regulations 2013.

Accrued pension data

63. We propose that active members with cash balance entitlements should receive an accrued pot value, which is calculated in the same way as the accrued value from non-money purchase schemes (i.e., the amount the individual would get at retirement if they stopped contributing at the calculation date) but presented as a ‘pot’ (or lump sum), rather than an annualised value. Deferred members with cash balance pensions would also receive an accrued ‘pot’ (lump sum) value, which would be valued to the illustration date and without regard to possible increases in earnings.

64. An annualised accrued value would then be calculated for active and deferred members, based on the ‘pot’ value, using the assumptions in AS TM1, minus the elements regarding future contributions and growth. Because this uses the AS TM1 methodology, we would mandate this value only from October 2023.

Projected pension requirements

65. We also propose that active members receive a projected lump sum value. This is the amount an individual is likely to get if they continue accruing up to retirement, based on scheme rules, assuming no increases in earnings, presented as a ‘pot’ or lump sum.

66. An annualised projected income would also be provided to active members, which would be calculated using the assumptions in AS TM1 applied to the projected pot value. As with the annualised accrued value, this will only be mandated from October 2023 because schemes will need to calculate it using AS TM1.

Proposed value data requirements for schemes offering collective money purchase benefits

67. The DWP’s regulations on the Occupational Pension Schemes (Collective Money Purchase Schemes) (Modifications and Consequential and Miscellaneous Amendments) Regulations 2022, set out the proposed updated disclosure requirements for collective money purchase schemes (also referred to as Collective Defined Contribution schemes (CDCs)), post consultation. We propose that the requirements for CDC schemes reflect the values required in the updated disclosure requirements. These are broadly in line with information requirements on other schemes, and the specific legislative proposals are outlined in Schedule 3, Part 1(3).

68. We propose that active members of CDC schemes would receive an annualised accrued value on dashboards, as well as an annualised projected value. These reflect the amended Disclosure Regulations for these schemes, which are due to be laid in March as follows:

a. Annualised accrued value, which would be no more historic than that provided on the previous benefit statement. (Reference to updated Disclosure requirements: Schedule 6A, Part 4, paragraph 24)

a. Projection: an illustration of the amount of pension, which may be payable to the member at their retirement date if contributions continue, having regard to the latest actuarial modelling under the scheme. (Reference to updated Disclosure requirements: Schedule 6A, Part 4, paragraph 25)

69. We have not included a provision for schemes offering CDC benefits to provide a projected pot value because we believe that individual pot values are of less relevance for CDC scheme members. We will be interested to hear views from consultees on the range of value requirements for this type of scheme.

70. We propose that deferred members of schemes offering CDC benefits would receive a projected annualised value on dashboards. This echoes what is contained in the amended disclosure Regulations for these schemes are as follows:

a. An illustration of the amount of pension, having regard to the latest actuarial modelling under the scheme, that may be payable to the member on their retirement date. This does not consider future contributions. (Reference to updated Disclosure requirements: Schedule 6A, Part 3, paragraph 20)

71. With the Occupational Pension Schemes (Collective Money Purchase Schemes) Regulations setting out what CDC schemes must do to become authorised, which include amended Disclosure Regulations expected to come into force in August 2022 (and laid significantly before then), we believe that these schemes will have enough time to implement changes before staging, and therefore the onset of their dashboard duties. Members who are part of collective money purchase schemes will be classified as deferred members of their previous scheme, which will also be included in the proposed staging profile.

McCloud remedy and Public Service Pension Schemes proposed value data requirements

72. Schedule 3, Part 1(2) proposes that the information requirements for public service pension schemes, including those affected by the McCloud remedy and Deferred Choice Underpin, should reflect existing disclosure provisions for those schemes, including the changes which will be brought forward by the Public Service Pensions and Judicial Offices Bill, which is currently navigating its passage through parliament. The drafting of the Regulations will be updated in due course, ahead of laying in draft before Parliament, to reflect the passage of the Bill.

73. The Regulations still require these schemes to provide the same value data elements as other non-money purchase schemes, as listed under Schedule 3 Part 1(2) of the regulations and explained under the ‘value data requirements for non-money purchase schemes’ heading of this consultation document. Schemes would also be required to provide the contextual information to accompany the values, specified in regulation 24. Data standards published by MaPS would ensure that – if necessary – more than one value for the same entitlement can be displayed. This supports the McCloud remedy and deferred choice underpin for relevant schemes and relevant members, which means at the point benefits are payable they will be able to choose legacy or reformed scheme benefits for the remedy period. More information on the McCloud remedy, DCU and staging proposals for public service pension schemes can be found in, paragraphs 66-75 of the staging chapter (chapter 5).

Proposed value data requirements for hybrid schemes

74. Hybrid schemes are schemes which offer both non-money purchase and money purchase benefits to their members. Trustees of these schemes would need to provide the same data elements as other occupational pension schemes, as outlined in Schedule 3 Part 1 of the Regulations and follow the formatting and presentational requirements as detailed in standards.

75. The value data that would be provided to members of hybrid schemes would depend on the structure of the benefits within the scheme. If an individual has two or more separate benefits (i.e., a money purchase and a non-money purchase) this will be two or more separate returns to dashboards.

76. However, where a member has one benefit which is calculated with reference to both money purchase and non-money purchase formulas (e.g., one with an underpin of the other), then only the appropriate set of values should be made available to the individual. MaPS data standards will include a flag to make individuals aware that their pension has special features (e.g., non-money purchase with a money purchase underpin, or vice versa).

77. Of particular note, our expectation is that 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. This is not currently explicitly covered in the regulations and, we are keen to understand whether the approach set out would be workable, and whether or not it would cover all scenarios of hybrid benefits.

78. This means that the data that is provided could follow either of the proposed accrued and projected value data requirements for money purchase and non-money purchase schemes, outlined throughout Schedule 3, Part 1 and 2.

79. We are very keen to understand through this consultation whether the regulations as drafted, and our anticipated drafting approach for hybrid benefits, achieve the policy aims that we have set out and reflect the way in which schemes would expect to provide value data for hybrid schemes; and whether there are any further hybrid benefit scenarios which need to be accommodated in the drafting.

State Pension information

80. Individuals who access pensions dashboards should be able to view information about their State Pension.

81. The Department has gathered information on the needs of individuals in relation to State Pension information through the extensive user research that has been carried out for the on-line Check your State Pension Forecast service.

82. It is proposed by virtue of regulation 9(1)(a), that the State Pension information displayed on pensions dashboards would be:

a. The date that the individual reaches State Pension age.

b. The forecasted State Pension amount at State Pension age.

c. The estimated State Pension amount the individual may get at their State Pension age, based on their current National Insurance record.

d. The latest tax year upon which the information is based.

83. To help the individual’s understanding of their State Pension position, it is intended that specific messaging would also be presented in the Pension Dashboard about their State Pension information. Important points of understanding to convey for State Pension include:

a. The information provided can only be based on the current law and their current circumstances. The information provided may therefore be affected if there are any future changes in the law or their circumstances.

b. State Pension is a benefit, and entitlement to a State Pension does not exist until an individual reaches their State Pension age and meets the entitlement rules at that time. This means that the State Pension information shown cannot be a guaranteed position.

84. There will be some instances where State Pension information cannot be provided. Where this happens, individuals would see a specific message displayed to advise them of this and the further action they need to take.

Consultation questions

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?

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 scheme?

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 to individuals in these circumstances?

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?

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?

Question 8: Would provision of an alternative, simplified approach to calculating 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?

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 purposes of dashboards and 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?

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?

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 a feasible approach? Do consultees believe it is the correct approach in terms of user experience?

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?

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?

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?

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 Dashboard programme?

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?

Chapter 3: How will pensions dashboards operate? Find and View

1. Annex B outlines how the various components of the digital architecture will operate, this chapter will provide detail on the requirements which would be placed on trustees or managers of schemes in relation to find and view.

2. This chapter primarily relates to regulation 22, “Find requests, matching, pensions identifiers and view requests” and regulation 27, ‘Management information and reporting’ but it does also refer to information in:

a. The Regulations within Part 3, ‘Requirements relating to trustees or managers of relevant occupational pensions schemes’, Chapter 2, ‘Requirements relating to cooperation and connection’.

b. Regulation 23, ‘Administrative data’.

c. Regulation 24, ‘Signpost data’.

d. Regulation 25. ‘Value data’.

3. In the table below, we have provided a summary of the policy aims and legislative requirements that will be covered throughout this chapter. In chapter 4, we will set out the steps that a scheme would be required to follow to connect with the digital architecture.

Chapter sub section	Summary of policy aims / legislative requirements
Connection	See chapter 4 on connection.
Receiving find requests	Schemes must always be ready to receive find requests.
Completing matching	One of the key requirements we have proposed for schemes is to be ready to immediately complete matching to identify whether they hold information on an individual’s pension that matches with that held in the find request. In some cases, they will successfully make a match, in other cases they will need more information to confirm the match. This is called a possible match and we propose that schemes would resolve these within 30 days.
Registration of PeIs	We propose that Regulations would require schemes to register a PeI for both a match made and a possible match. Guidance may provide further detail on how that process could take place.
Use of intermediaries	In order to fulfil their duties to return an individual’s data via a QPDS, trustees or managers may use intermediaries. Notably, it is still the responsibility of trustees or managers to ensure data is not misused and is returned correctly.

Requirements relating to view data on trustees or managers

Chapter sub section	Summary of policy aims / legislative requirements
View data	View data is the collective term to describe administrative data, additional signposts and value data. This chapter will outline details of what this is and how we expect schemes to check the authenticity of the individual requesting the information before it can be returned.
Response times	We outline how quickly schemes are required to return view data to individuals and how this would differ from current disclosure Regulations. The chapter contains further details on how long we expect trustees or managers to have to return administrative and value data for money-purchase and non-money purchase benefits and where there is a distinction between the two data types.

Reporting requirements

Chapter sub section	Summary of policy aims / legislative requirements
Provision of information	Trustees or managers would need to report certain management information to regulators and MaPS so they can ensure the dashboard delivers the service that people expect. We will outline these requirements in more detail.

Introduction

4. At the heart of pensions dashboards is the idea that people should be able to view clear information in one place online, at a time that suits them. This must be done in a way that is secure, accurate and easy to understand.

5. These Regulations would place a series of requirements on the trustees or managers of occupational pension schemes. The FCA will make corresponding rules for providers of personal and stakeholder pension schemes. In summary, we propose that the Regulations will require trustees or managers of schemes to:

a. Connect to the digital architecture so that they can receive find and view requests.

b. Receive find requests, undertake matching and register any found pensions in order to match individuals to their pensions.

c. Receive and respond to view requests to make individuals information available to them at the dashboard of their choosing.

UK Data protection legislation

6. Within the pensions dashboard ecosystem, there will be multiple relationships that involve the processing of personal data. While it is ultimately for each party to determine its own role under data protection legislation, and the obligations that this confers, it is our view that the relationships outlined below are all examples of independent controllers successively processing personal data in a chain of operations:

a. Commercial dashboard providers and pension schemes.

b. MaPS (as a dashboard provider) and DWP (as a provider of State Pension information).

c. Commercial dashboard providers and DWP (as a provider of State Pension information).

d. MaPS (as a dashboard provider) and pension schemes.

7. As outlined on the Information Commissioner’s Office (ICO) website,ix data controllers are the main decision-makers that exercise overall control over the purposes and means of the processing of personal data.

8. Controllers shoulder the highest level of compliance responsibility and must comply with, and demonstrate compliance with, all the data protection principles as well as the other data protection legislation requirements. Controllers are also responsible for the compliance of their processor(s). The ICO and individuals may act against a controller regarding a breach of its obligations.

9. The decision that the relationships listed are indicative of independent data controllers has been taken in line with UK GDPR and the Data Protection Act 2018, as well as guidance on the concepts controller and processor from the ICO.

10. Throughout this consultation document, we go into further detail on these relationships and outline what being an independent data controller means in relation to the provision of pensions dashboard services. The diagrams below highlight where the requirements on MaPS, pension schemes and pensions dashboard services as independent data controllers must be considered and, in some places, where it is crucial to ensure that the affected parties are balancing their dashboard duties with their requirements under UK data protection legislation.

11. With respect to Find and View data, there are a number of interactions between individuals, MaPS, schemes and QPDSs. For each of these interactions, there are dashboard duties as well as UK data protection legislation duties that must be considered. Whilst it is not for this consultation to tell these actors in the dashboards ecosystem how to ensure that they comply with their dashboard and data protection duties, we have sought to indicate in the diagrams below where they will have an impact.

Find and view

Find data

1. An individual submits a find request via their QPDS or the MaPS dashboard: neither MaPS or QPDS are involved in the processing of find data. An analysis of the law and the facts points to MaPS and QPDS being controllers in respect of any data processing they undertake in order to implement a find request.

2. An individual consents to having their data sent out by MaPS via the Consent and Authorisation Service (C&A). The individual then has their identity verified by MaPS via the ID service: in respect of a find request, MaPS will act as an independent data controller and issue a find request only once an individual has given their consent and had their ID verified. This ensures that the individual is in control of the use of their data.

3. MaPS, via the Pension Finder Service (PFS), issues the find request (asserted and self-asserted data) to pension schemes and DWP: MaPS’ role in processing find data ends when a find request is issued. At this point, data is sent to pension schemes (or DWP for state pension data) who are independent controllers of find data and process it to fulfil their legal duties to receive find requests, complete matching (with responsibility for determining the means) and to register PeIs for found pensions.

4. Pension schemes and DWP complete matching using the data provided by MaPS in the find request: trustees and managers have duties under UK data protection legislation not to disclose an individual’s data to the wrong person. They must balance this with their dashboard duty to match and return an individual’s data to them. If schemes set their matching criteria so tightly that they fail to match, they may meet their UK data protection legislation duties, but are likely to fail to meet their dashboard duty which is subject to regulatory compliance action.

5. Pensions schemes and DWP register a PeI for a match made or a possible match: if there is no match, there is no lawful basis to retain the data. Where there is a possible match, schemes must seek to verify the identity of the individual.

6. Once verified by MaPS, the PeI is returned to the individual’s dashboard: the registration of a PeI is a key requirement on pension schemes which must be done in accordance with technical standards. A schemes processing of PeIs is also done as an independent controller.

View data

1. Having submitted a find request, an individual now wants to view their found pensions.

2. The individual’s dashboard issues a view request to the relevant pension scheme (or DWP for state pension) of the found pension: pension schemes (or DWP for state pension) must be ready to receive the view request. They cannot grant access to the view data until the C&A service has checked the individual’s authorisation. To do this, schemes must check the individual’s access request is authorised by checking with the C&A service.

3. Now the individual is authorised, the view data can be returned directly from the pension scheme, to the individual’s dashboard: pension schemes may rely on legal obligation (as provided by these Regulations) as their lawful basis for returning view data to dashboards. Pension schemes’ control over and responsibility for the view data stops when they send it, in accordance with their duties, to dashboards. They are not responsible for any processing by dashboards who will be subject to their own legal restrictions over the processing of view data.

4. The individual’s dashboard will display the view data in accordance with the relevant standards issued by MaPS: the MaPS dashboard or a QPDS must display view data in accordance with design standards. They will be independent controllers for that processing.

Find and view

12. As set out in the background section (annex A) of this consultation document, we have some very clear policy objectives for pensions dashboards. Reconnecting people with their lost pensions will be hugely valuable to many. However, we know that people do not simply want dashboards to indicate that they have a pension and where they can find it. They want dashboards to go beyond that by providing information about how much they might have to live on when they retire, so that they can plan for retirement. We recognise that there are several exemptions listed in the data chapter that could prevent some people from seeing projected information on dashboards in certain instances. We do not anticipate these exemptions applying to a significant number of people, but where they do individuals will still see:

a. Find data – alerting them to the existence of the pension, in the case that they were not already aware.

b. Accrued value data.

13. We are committed to a find and view approach from the outset. However, we know from the stakeholder engagement that we have conducted that there are very real concerns both about the feasibility of our proposed approach and the risk that individuals will find it difficult to understand the information that they see.

14. The responses to the Call for Input^{[footnote 7]} on staging led by the Pensions Dashboards Programme highlighted that many want a find and view approach from the outset, citing the needs of individuals that will use dashboards and the importance of including values for credibility and to engage individuals.

15. Some respondents, however, told us:

a. They preferred a find first approach because it would a) still support individuals in being reconnected with lost pots; and /or b) allow more time to work through issues relating to the standardisation of how projected value amounts are calculated.

b. It would not be feasible to stage to a find and view dashboard within the proposed timescales whilst others expressed more significant concerns around the deliverability of anything other than find only dashboards.

16. Despite these challenges, research on the issue has highlighted strongly that a find and view approach is preferred because values, not just information indicating that you have a pension, are fundamental to dashboards. Most recently, qualitative research with potential dashboard users, carried out by IPSOS Mori for PDP and published on 25 January 2022^{[footnote 8]} showed that whilst a find only dashboard has some appeal for a specific subset of potential users (those with forgotten or known to be lost pensions), a ‘Find and view’ service containing both accrued and projected value information has a wide level of appeal and resonates with the broadest possible range of potential end users and is therefore likely to drive the greatest level of interest in and uptake of the service.

17. The people that were introduced to a find only service still assumed that value information would be shown on a dashboard and service appeal dropped significantly when people realised it wouldn’t.

18. In addition, we know from user testing conducted for the 2019 ‘Pensions dashboards: Working together for the consumer’ consultation to explore issues such as pensions engagement and different dashboard models, that the high-level consumer need is “to know how much money I’ll have to live on when I retire so that I can plan for my future”^{[footnote 9]}. In addition, PDP’s Phase One Report^{[footnote 10]} published in July 2021 identified that individuals expect, as a minimum from pensions dashboards, that their personal and workplace pensions will be identified and that they will be informed of their retirement income projections. These were the main priorities for those who are less engaged in pensions and less financially confident.

Find only:

Dashboards will only find an individual’s pensions information and tell them what pensions they have.

Find first:

Dashboards may in future enable individuals to view their pensions information, but initially, people will only be able to find what pension they have.

Find and view:

Individuals will not only find what pensions they have, but they will be able to view information on them.

19. As outlined earlier in the data chapter, our ambition is to help to increase individuals’ awareness of their pensions and provide an indication of their potential retirement income. We believe this will allow individuals to take ownership of their future and make better informed decisions in relation to Pension Freedoms and their savings for retirement. It is our view that to achieve these ambitious goals, dashboards should be ‘find and view’ from the outset as opposed to ‘find first’ or ‘find only.’

20. We are clear that we must be ambitious to meet the needs of individuals. We believe our plans for pensions dashboards are challenging but very much deliverable. The needs that we have identified cannot be achieved through find only. For these reasons, we remain committed to find and view dashboards and the Regulations that we propose make this clear. In the remainder of this chapter, we have set out how we envision the find and view process working.

Requirements on trustees or managers

Requirement for trustees or managers of pension schemes to conduct matching (find data)

21. Schedule 1 to the Regulations (interpretation) contains definitions which indicate that find data is the information that trustees or managers of schemes will receive in order to conduct matching, and that matching is the process of searching a scheme’s records to see if an individual has a pension with that scheme. When trustees or managers receive find data, regulation 22 makes clear that schemes must immediately use the find data to complete matching.

22. Pension schemes would need to be connected to the dashboard digital architecture before they can receive find data and begin matching.

23. Find data is made up of certain verified identity attributes (first name, surname, current address, and date of birth) and non-verified identity attributes (for example, the individual’s National Insurance number, previous names and addresses, email address and mobile phone number). Further detail on verified and non-verified identity attributes has been set out in the glossary and in the earlier chapter on data.

24. As the Regulations set out, once schemes have connected to the dashboard architecture (see chapter 4 for further detail and Part 3, Chapter 1 of the Regulations), they would be able to receive find data from it. There would then be several things set out in this chapter that trustees, or managers of schemes need to do in order to ensure they can meet the requirements in the Regulations:

a. Acknowledge a find request.

b. Complete matching immediately (matches made and possible matches).

c. Provide an individual with their pension information, via the individual’s chosen dashboard.

Matching

Making a Match	Possible match
When a trustee or a manager of a pension scheme are confident they have found an individual’s pension record using the find data, they have made a match.	In some cases, the trustee or manager of a scheme may feel they have a possible match but cannot be certain enough to release an individual’s pensions data. Where this is the case, this would be considered a possible match.

25. When the Pension Finder Service issues a find request to pension schemes pension schemes will return a digital acknowledgement, known as an ‘ACK.’ An ACK would be returned to the Pension Finder Service to tell it that the scheme has received the find request and will begin their duties relating to matching. This is not covered in the Regulations; it is a technical and automated step which would be covered by technical standards issued by MaPS.

26. Having acknowledged the receipt of an individual’s find data from the Pension Finder Service, trustees or managers of schemes would need to immediately complete matching (see regulation 22(2)) to identify whether they hold pensions information for the individual. We are clear that schemes must immediately complete matching and may use any of the find data provided to do this in order to align with the proposed view data response times that we set out later in this chapter.

27. The requirement to conduct matching begins from the point at which the find request is received by the scheme. Receipt of requests will be immediate and automated, therefore, in practice the timer will begin when the data is sent. In this section, we will outline the specific requirements that we have proposed would need to be fulfilled by trustees or managers when conducting matching.

28. As we have outlined earlier in this chapter, in respect of find data, we believe that pension schemes and MaPS are independent data controllers. MaPS is a data controller in respect of the production of the find request. MaPS will process verified data elements from the Identity Service as well as non-verified data elements from the individual. These will make up the find request that the Pension Finder Service, on behalf of MaPS, will send to pension schemes. This is the full extent of MaPS’ role as an independent data controller of find data.

29. In meeting their legislative requirement to connect to the digital architecture, schemes will need to always be ready to receive find data from MaPS. MaPS technical and data standards will outline what schemes must do to receive the find requests in the correct way. Upon receipt of the find data from MaPS, schemes will be prepared to complete matching immediately and may use the verified and non-verified identity attributes contained in the find data received from the Pension Finder Service (on behalf of MaPS). We have proposed that it would be for the trustees or managers of schemes to set their own matching criteria that will allow them to identify whether they have a match.

30. Regulation 22(1) would also require trustees or managers to keep a record of the matching criteria that they determine to use to match individuals with their pensions and hold this for at least 6 years from the end of the scheme year in which the decision is taken. This requirement would not mean that a record would need to be made of the matching criteria used on individual searches, only of the overall policy to be used generally. Regulation 22(2) sets out that: In conducting matching, schemes would need to have regard to guidance issued by either the Secretary of State for DWP or the regulator.

31. In addition, the Pensions Administration Standards Association (PASA) recently published industry guidance on Data Matching Conventions (DMC)^{[footnote 11]}. Schemes may wish to consider this industry guidance as they determine their own approach to matching.

32. Regulation 22(3) outlines that once trustees or managers of schemes have identified a positive match, whether they are able to make a match or have a possible match, they would need to create and register a PeI. As outlined earlier, a PeI does not include any pensions information, it simply acknowledges that a match has been found. The Regulations specify that PeIs would be registered by schemes with their resource server and with the Consent and Authorisation Service. 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.

33. As we have outlined in regulation 22(4), we propose that where a scheme has identified a possible match, a PeI must still be registered in the same way as it would be for when they can make a full match. The difference here is that, in place of the value data, an error message and some specific administrative data will be provided to an individual that informs them that the scheme has been unable to match a pension to them and that they require further information.

34. Data standards issued by MaPS will outline the requirements on schemes in relation to the error message that must be provided in response to a view request when a possible match PeI is registered. The administrative data that we would expect schemes to provide in relation to a possible match would need to inform the individual of who they may have a pension with and how to contact them. We are refining the requirements for exactly what administrative data schemes would be required to provide for a possible match, and we propose the Regulations will make this clear when they are laid.

35. Where this is the case, regulation 22(4) proposes that if a possible match is not resolved within such time as may reasonably be required, the scheme must, subject to other criteria being met, de-register the find request information. Our proposal is that individuals should have 30 days to contact the pension scheme and supply all the relevant, additional information necessary to satisfy the scheme as to whether they have a match for that individual. Only once the necessary information has been provided will the scheme be able to turn the possible match into a match made. In order to do this, the scheme must contact MaPS so that the view information can be returned. If this doesn’t happen after 30 days, the scheme de-register the PeI.

36. It is our expectation that providing individuals contact their scheme within 30 days, it should be left to the discretion of the scheme to grant longer to resolve the possible match. It may well be that there are particularly difficult circumstances to resolve, or simply that not all the required information was returned within 30 days.

37. Guidance may be issued by either the regulators or the Secretary of State for DWP to outline exactly how the process of resolving a match could work, but we expect that it will be for schemes as data controllers to obtain the information that they require in a way that they see fit.

38. The Regulations set out that trustees or managers of schemes would need to delete personal information in a situation where they have conducted matching and identified no match. This means that where there is no match, there would be no lawful basis for retaining find data. Where schemes undertake matching and are successfully able to make a match, there may be some instances where a data discrepancy is identified. In this case, the scheme should consider contacting the individual (outside of the pensions dashboard ecosystem) and asking them to verify or update their personal data held that is held by the scheme.

39. Further information on this, as well as more detailed information on PeIs, will be set out by MaPS in technical standards on PeIs. We expect these will outline:

a. The proposed structure of a PeI that would need to be adopted universally by industry.

b. Instructions for trustees or managers on how to generate a PeI.

c. How schemes should register a PeI.

d. How schemes should de-register a PeI when there is no match found.

Intermediaries

40. We anticipate that in fulfilling their duties, some schemes would utilise the services of intermediaries (third party administrators, software providers and ISPs) and the Regulations would not prevent this. However, trustees or managers remain accountable for compliance with the Regulations and need to meet their duties in a way that accords with UK data protection and pensions legislation.

41. So, for example, find data sent to intermediaries by the digital architecture, or an individual’s pensions information, could not be used by intermediaries for any other purpose (such as commercial gain). Were an intermediary to misuse this information for any other purpose then, depending on the circumstances, the ICO and the individual(s) concerned may act against a scheme or its intermediary for breaching their data protection obligations.

42. Trustees or managers of schemes would be required to take the necessary steps to ensure an individual’s data security in accordance with UK data protection legislation. Data protection legislation requires trustees or managers of schemes to put in place a written contract where they use a third-party processor. This must cover the matters prescribed in Article 28(3) of UK GDPR, which includes the security of processing. We expect this would deter intermediaries from misusing data and ensure the security of dashboards.

43. Some schemes may have existing contracts in place with third parties that they will use for other dashboard duties (for example, the processing of find data for potentially millions of individuals who do not have a pension with that scheme). Where these contracts are already in place, they will need to be updated. Further information on data processing agreements is available on the ICO website^{[footnote 12]}.

44. We expect that trustees or managers will have processes in place for the selection, appointment, and management of intermediaries as with all service providers. Further information and guidance will be published by TPR to support schemes.

Duties relating to the information that pension schemes will return to individuals (view data)

45. View data is the information that pension providers will return directly to an individual via the dashboard of the individual’s choosing, which may be the MaPS dashboard or a QPDS. The Regulations set out what schemes would need to do to ensure that the data returned is accurate, secure and delivered in a timely manner. Separately, MaPS’ design standards would set out how QPDS should present this information to ensure consistency and clarity.

46. As set out earlier in the data chapter, view data is the collective term to describe administrative data (regulation 23), additional signposting information (regulation 24) and value data (regulation 25).

47. As the Regulations set out, when returning view data to individuals, there are several things that schemes would need to do to ensure that they are fulfilling their legislative duties.

a. They need to respond to a view request by providing view data (administrative and value data) to the dashboard that an individual has used to make their request for information.

48. As part of this process, they must check the individual’s relevant permissions sent by the Consent and Authorisation Service to ensure that view data is going to the dashboard authorised either by the individual to whom the data belongs or by their authorised delegate. In most cases, the individual will have given their dashboard consent before a find request has been sent. If that is the case, the dashboard will be able to successfully pull view data from the pension scheme (see sub-paragraph iv). Where that is not the case, an individual’s pension scheme, via their view interface, will ask the Consent and Authorisation Service if access can be granted.

49. Given that pensions dashboards are a digital service, we strongly believe that value data should be returned more quickly than the two-month window allowed as a maximum in Disclosure Regulations for statement requests. We will set out our proposals on this further into the chapter.

50. The values that schemes would need to provide to pensions dashboards are broadly in line with what they are already required to provide under the Disclosure Regulations 2013 but do go beyond this for certain proposed value data elements. As set out in more detail already in the data chapter, the value data that schemes would be required to provide differs by scheme and member type but falls under the broad categories of accrued pension data, and projected pension data.

Response times

51. We believe that the provision of accurate and up to date data is crucial for the successful delivery of dashboards but acknowledge that doing so may be challenging in some circumstances. The requirements that we propose placing in Regulations aim to strike a balance between ensuring up to date information is provided and is deliverable for trustees or managers of pension schemes.

52. We do not expect schemes to re-calculate the value of an individual’s pension for every find and view request through their chosen dashboard if a value has already been produced for a recent statement or calculation. The Regulations would not prevent schemes from providing up to date information every time an individual makes a request, and we believe that for the best user experience, this would be a very good outcome. To highlight our ambition for dashboards, we believe that ultimately, schemes will move towards the automation and digital storage (for ease of retrieval) of view data to ensure quick and accurate responses.

53. Where recent values have not been provided, we recognise schemes will need to have additional time to provide the necessary information. In the Regulations therefore, we have proposed setting out the minimum expectation on trustees or managers of schemes, as follows:

a. Administrative data: We believe that for all pension schemes, administrative data should be returned immediately after a view request is received (regulation 23(2), subject to 23(3)). This is important because we believe that at the point when an individual is seeking to access their pensions information on their dashboard, they should be made aware immediately of what pensions they have.

b. Value data: We have proposed that the value data which would be returned to an individual’s dashboard must be a value that has been generated for a benefit statement within the last 12 months or for another purpose, but using the same methodology, within the last 12 months. If such a value has been generated, the expectation on the trustees or managers of all pension schemes is that the data will be returned immediately (meaning straight away) (regulation 25(5)(a)). The implication of this is that we will expect schemes to store calculations made in a format that is in accordance with data standards and is ready to be returned immediately.

Regulation 25(5)(b) provides that where a relevant value has not been calculated or provided on a benefit statement within the last 12 months, Regulations propose that all pension schemes will have 3 days to return value data except for:

i. non-money purchase schemes which have 10 days, and
ii. schemes which offer benefits where the benefit value is calculated with reference to both money purchase and non-money purchase formulas, which will also have 10 days.

c. In time, we are keen for these proposed timings to be reduced to help improve the quality of the service provided by pensions dashboards. In particular in relation to money purchase schemes, we intend to move towards instantaneous responses for all requests in the future. With this in mind, we want pension schemes to think ambitiously and consider now how they can put mechanisms in place to facilitate the provision of data to dashboards as quickly as possible.

54. All values provided for one pension entitlement, i.e., accrued and projected, should be based on the same illustration date, as per regulation 25(3)(b), to ensure consistency across that pension. The data chapter outlined the specific data elements that these response times refer to. Based on these response times, it is our expectation that some value data elements will be returned more quickly than others. For example, one scheme may hold an accrued value for an individual but not a projected value and so we would expect that these would be returned at different times whilst still using the same calculation date. We believe that this represents a better outcome than an individual waiting to see all their view data returned at a later stage.

55. These proposals do not seek to prevent the return of administrative and value data at the same time, nor do they aim to prevent value data being returned more quickly where that is possible. As we have made clear, the individual seeking to access their pensions information is at the heart of these proposals. For that reason, we believe that the timescales set out in the Regulations are a reasonable starting point.

56. We are clear that where we are setting the expectation of an ‘immediate’ response, this means schemes will need to shift towards the automation and better storage of individuals pensions information. This is the only way that immediate responses will be achievable. For some, it is likely that investments in automation or better storage of pensions data will be necessary, and we strongly believe that where that is the case, schemes should consider making investments now.

57. In relation to these timings, regulation 25(5) and 25(7) make clear that the response times we are referring to are working days. The timer begins for schemes from the point at which a pension scheme receives an individual’s information from the digital architecture. Receipt of requests will be immediate and automated, therefore, in practice the timer will begin when the data is sent. Trustees or managers must therefore ensure that they are receiving requests for information correctly. However, we do not believe that this will be an issue because, as we have proposed, it will be a legislative requirement for schemes to be always connected to the digital architecture.

Reporting and record keeping requirements

58. There are several ways it is proposed in which MaPS and the regulators will be able to detect non-compliance and monitor the performance of schemes in relation to matching and the return of find and view data:

a. The primary mechanism will be through the digital architecture.
b. Where this is not possible, MAPS or the regulator will set reporting standards for trustees or managers that will require them to maintain certain records and report certain information. We anticipate that this standard-setting function will be primarily fulfilled by MAPS.

59. As outlined in paragraph 29 of this chapter, regulation 22(1) will require schemes to maintain a record of the process that they use to conduct matching. In addition to that, regulation 27 (3) requires that the information that standards will require schemes to report must also be retained on record by the provider for at least 6 years from the end of the scheme year to which it relates. This is to ensure that if requested, it is easily available to the regulators to enable them to monitor schemes’ compliance with their duties.

60. Regulation 27(2)(a)-(f)) seeks to indicate the type of information that we expect schemes to report on. This should be considered an early indication of what we expect standards may cover but the final requirements depend on the development of the infrastructure and how much of this reporting can be automated within it.

a. The number of find requests received by a scheme.

b. In relation to positive matches:

i. The number of matches that are notified to MaPS.
ii. How quickly any possible matches were resolved.

c. In relation to possible matches:

i. The number of possible matches.
ii. How many of these turned into a match made, non-matches, or remained unresolved.

d. The number of view requests received, and the time taken to respond to each one.

e. Contacts received from a particular individual including details of:

i. Queries about pensions information provided.
ii. Pensions not found following a search.
iii. Complaints.

61. There are several reasons why we do not wish to specify a comprehensive list of the reporting information that schemes must provide in Regulations:

a. Firstly, we do not believe that it is possible to have a comprehensive list of the type of information that we want schemes to report on in advance of laying Regulations. This is because further requirements may come to light following testing.

b. Secondly, it is likely that as pensions dashboards develop, so will the expectations on them and what we may need participants in the ecosystem to provide.

i. We continue to explore further options for data reports within the digital architecture. We may yet need to include additional requirements on schemes within the Regulations to ensure that all reporting requirements are covered.

62. For these reasons, we believe that it would be preferable to outline the detail on what management and reporting information schemes need to provide in reporting standards. As stated, regulation 27 will then place a requirement on schemes to adhere to these standards and provide the information that is requested by MaPS or the regulators.

Consultation questions

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?

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

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

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?

Chapter 4: Connection: What will occupational pension schemes be required to do?

1. This chapter sets out proposed requirements for trustees or managers of occupational pension schemes in relation to the initial connection of their scheme to the digital architecture, as well as the ongoing requirements of being connected. This chapter sets out the requirements on schemes which are set out in regulations 13, 14, 16, 19 and 20.

Chapter sub section	Summary of policy aims / legislative requirements
Connection windows	As set out in regulation 14, trustees or managers of occupational pension schemes would have a window of time during which they would need to have completed connection of their scheme to the digital architecture. The date of connection would need to be agreed with MaPS. The window for connecting to the digital architecture for any individual scheme can be determined by reviewing the list of deadlines set out in Schedule 2 to the Regulations. Individual deadlines for cohorts of occupational pension schemes are to be determined by the size and type of the relevant scheme. (Full details are set out in chapter 5.) At the point of connection, occupational pension schemes should be able to respond to Find and View requests as and when these are received.
Duty to cooperate with MaPS	To avoid and ease any operational setbacks, trustees or managers of occupational pension schemes would be required by regulation 13 to cooperate with requests made by MaPS relating to connection.
Adherence to Standards	In order to complete connection to the digital architecture, trustees or managers of occupational pension schemes would have to comply with all connection standards to be published by MaPS. As set out in regulation 14, trustees or managers will also need to adhere to all connection, security, and technical standards set by MaPS on an ongoing basis following connection. As dashboards develop, standards may be required to change. Trustees or managers would be required to implement changes to connection, security, and technical standards as soon as they become necessary to maintain a connection.
Pre-connection steps	As part of the connection process, trustees or managers of occupational pension schemes would be expected to complete a series of pre-connection steps by their connection deadline. These pre-connection steps will be set out in standards developed by MaPS. They are likely to include registering with the Governance Register, building (or securing) Find and View APIs and a User Managed Access (UMA) interface, completing software and security conformance testing, obtaining a software certificate from the Governance Register, and completing a test cycle.
Guidance	Trustees or managers of occupational pension schemes would be required by regulation 14 to have regard to guidance, which sets out practical advice on completing the operational steps related to their connection duties. The guidance will also provide details on expected timescales for completing pre-connection steps.
Early Connection	Regulation 16 would allow occupational pension schemes to connect to dashboards before their mandatory connection deadline. Early connection would remain at the discretion of MaPS and TPR. The trustees or scheme managers would be required to conform with all requirements set out in the Regulations, including requirements for responding to Find and View requests, from the date of connection, even where this precedes the mandatory connection deadline for the scheme. Early connection is an irreversible step. Registrable small and micro-occupational pension schemes would not be required to connect to the digital architecture as part of these Regulations (although the intention is they would be in the future) but could connect if they wish to do so and both MaPS and TPR agree.
Reporting requirements	In order to aid the running of the digital architecture regulations 14 and 20 include requirements for trustees or managers to report certain information to MaPS including around scheduled downtime, cyber-attacks, systems issues, and in the event of disconnection or change in connection.

Introduction

2. For pensions dashboards to function, trustees or managers of occupational pension schemes will need to arrange to connect their scheme data to the digital architecture and maintain a functioning connection. On an ongoing basis, they would need to be able to provide pensions information whenever a request is made by a relevant individual using the MaPS dashboard or a qualifying pensions dashboard service.

3. We are proposing that the Regulations include a requirement that trustees or managers of occupational pension schemes (which will be grouped into cohorts, as set out in chapter 5), should be required to have completed their connection to the digital architecture on or before a certain date. This would fulfil the commitment in the Government’s response to the 2018 consultation on pensions dashboards to compel pension schemes to participate in dashboards. The Government continues to believe this is the best way to deliver dashboards within a reasonable timeframe.

4. After a scheme has connected to the digital architecture, we have proposed that trustees or managers should be in a position to respond to Find and View requests (as set out in chapter 3) as and when this is requested by individuals using the MaPS dashboard or a qualifying pensions dashboard service.

5. The Regulations would require trustees or managers of occupational pension schemes to conform with standards for connection which are set by MaPS. These standards will require trustees or managers to take several steps to prepare for connection, including selecting an endpoint (see glossary) they intend to use to connect to the digital architecture.

6. Irrespective of whether trustees or managers choose to build their own software for their scheme, or rely on the services of a third party, they will ultimately be responsible for ensuring their scheme is connected to the digital architecture on time. Therefore, if a scheme does choose to utilise a third-party (such as an integrated service provider), they would need to ensure the third party is capable of meeting each of the required steps to complete connection.

7. An important consideration in relation to the proposed connection duties is that successfully fulfilling the requirement to connect to the digital architecture would be dependent to some degree on the MaPS, via the PDP, fulfilling all its responsibilities. This means trustees or managers of occupational pension schemes will be required to cooperate with requests made by MaPS.

Connection windows

8. As set out in regulation 14, we are proposing that Regulations will set a window, by the end of which, trustees or managers of occupational pension schemes would need to have fully connected to the digital architecture. Schedule 2 of the Regulations sets out deadlines for all schemes with a duty to connect. For most schemes, the window to connect is during the month prior to their connection deadline. However, for the first staging cohort, the window to connect would be during the three months prior to the deadline.

9. For further information about how the connection deadlines have been staggered for different cohorts of occupational pension schemes, please refer to chapter 5 on Staging.

10. As part of the process of connecting, we expect schemes to be able to request a preferred connection date. However, this would need to be confirmed by MaPS as they will need to manage the overall process of connecting all schemes and will need to maintain operational flexibility to ensure this is carried out in an orderly way. To help facilitate this process, we have therefore proposed in regulation 13 that trustees or managers will need to cooperate with requests made by MaPS. Further detail about this proposed duty to cooperate is set out below.

11. Completing connection would mean a scheme was ready to receive find requests, carry out a matching process, and provide pensions information to individuals via dashboards. This would be demonstrated by compliance with connection, security and technical standards and registration of the scheme by MaPS.

12. Trustees or managers of registrable occupational pension schemes will also be able to apply for a connection date earlier than their specified window, as set out below under the heading ‘Early connection.’

Requirement to cooperate with MaPS

13. Although the combination of the Regulations, standards and guidance will make clear what is expected of trustees or managers of occupational pension schemes, there are likely to be circumstances where MaPS (via the Pensions Dashboards Programme) need to communicate directly with trustees or managers in order to aid and monitor the connection process. This is particularly the case because the digital architecture will be entirely new, so there may be unexpected issues that need to be resolved. MaPS will also need to manage the practical job of co-ordinating connection for all of the relevant occupational pension schemes and personal and stakeholder pensions.

14. To facilitate this, we have proposed in regulation 13 that trustees or managers of occupational pension schemes have a general duty to cooperate with and to provide information to MaPS to aid them in the exercise of their functions relating to establishing, maintaining and managing the digital architecture. This could include communicating with MaPS (either directly or via an intermediary) to develop a plan to connect their scheme and agree a connection date.

Maintaining connection and adherence to standards

15. Once the connection process has been completed, trustees or managers would be required under regulation 14 to keep the scheme connected to the digital architecture from that point onwards (unless an exception applies under regulation 19). This would be to ensure that they are able to respond to find and view requests as and when they are made.

16. A practical effect of the requirement to remain connected to the digital architecture is that schemes will need to comply with all security, and technical standards published by MaPS on an ongoing basis. In order to protect the integrity of the digital architecture, a failure to adhere to these standards would result in the scheme being automatically disconnected.

17. We envisage that as dashboards develop, some changes to standards may need to be made. Therefore, trustees or managers will be required to implement changes to security, connection, and technical standards as soon as they become necessary to maintain a connection to the digital architecture.

18. Further detail about changes to standards and the process for consulting on and approving changes has been explained in the ‘role of standards’ section of this consultation.

Pre-connection steps

19. As part of the connection process, trustees or managers of occupational pension schemes will be expected to have completed all of the pre-connection steps set out in connection standards, by their relevant deadline.

20. These pre-connection steps would ultimately be determined by MaPS in standards, but we have provided further details below about some of the expected requirements to aid understanding of how the process would work.

Registration with the Governance Register

21. As part of the connection process, trustees or managers of occupational pension schemes will be required by regulation 14 to register with the Governance Register. Guidance published by MaPS will specify the appropriate time to register with the Governance Register and what steps they expect the scheme to have completed before undertaking registration. During this registration, we expect schemes to provide MaPS with a preferred connection date, but this would need to be agreed with MaPS, as set out above.

1. Trustees or managers will need to provide operational information which will be used to validate which scheme they are connecting to the digital architecture, and to provide contact information should there be a need to contact the scheme. This could be for notifications of upgrades, system maintenance or to resolve technical issues with the connecting party.

23. Trustees or managers will also need to provide technical information about the endpoint they intend to use to connect to the digital architecture. This could be an endpoint which has been built in-house, provided by an intermediary such as an administrator, software provider, or through a service being provided by an ISP.

24. At the point at which an occupational pension scheme has completed all of the required steps to connect to the digital infrastructure and it is compliant with all the required connection, security, and technical standards, the scheme would be listed as having completed connection on the Governance Register.

25. The date connection is completed, as recorded by the Governance Register, will be communicated to TPR so they are aware that trustees or managers have complied with their connection duties set out in Regulations.

Ensuring interface conformance

26. Pension schemes will need to build (or secure access to) find and view application programming interfaces (APIs) to communicate with the digital architecture. An API acts as an intermediary which allows two applications to “talk” to one another. The technical details of these interfaces would be set out in standards published by MaPS.

27. Pension schemes will also need to build (or secure access to) a user managed access (UMA) interface. The technical details of what is required for the UMA interface will be set out in standards published by MaPS. This element would interact with the digital architecture to check the permissions that an individual has selected with the consent and authorisation service to make sure that pensions information is only provided to those with consent to see it. The UMA interface is necessary to allow individuals to be able to permit access by an independent financial adviser, or a MaPS guidance officer.

28. Prior to being approved for connecting to the digital architecture, evidence will need to be provided in a software conformance test to show that all the interfaces meet the standards specified by MaPS. Conformance testing will also be required to provide evidence that the interfaces being used meet security specifications, which will be set out in standards published by MaPS. A “sandbox” environment (which is not connected to the live digital architecture) will be provided for schemes to carry out this testing.

29. The first time that an endpoint is being used to connect to the central digital architecture, it will be required to undergo a test cycle to ensure all aspects of Find and View are working as expected. Subsequent connections using the same endpoint will not necessarily need to undergo the testing process again. For example, an API being used by an ISP will not need to be re-tested every time a new scheme connected if it had previously been approved for use in relation to a different scheme.

Guidance

30. We do not intend to legislate to specify exactly when each of the pre-connection steps need to have been completed. Instead, we have set out in regulation 14 that as part of their duty to connect, trustees of occupational pension schemes would need to have regard to guidance issued by MaPS and TPR. The guidance will set out practical details on how to complete the steps for connecting to the digital architecture and anticipated timescales for completing these actions.

31. Regulation 14 also specifies that trustees or managers would be expected to keep a record how they have met the steps set out in guidance or taken alternative steps to achieve the same end. This would ensure trustees or managers have the evidence necessary to demonstrate their efforts if they were unable to achieve connection despite their best endeavours.

32. We believe that setting just one deadline in legislation for completing connection but making clear in guidance when trustees or managers would likely need to start work on specific steps, provides legislative certainty without being overly prescriptive about when individual steps need to be completed.

33. TPR are also planning to carry out a communications drive to educate trustees or managers on their responsibilities. As part of this, TPR plan to remind schemes of their deadlines and the activities expected of them, including expected timescales for completing those activities.

Early connection

34. We wish to encourage occupational pension schemes to seek to connect to the digital architecture before the date they are compelled to do so. This can help ease the process of connection and help make dashboards a reality for the general public sooner.

35. The call for input on staging, carried out by the PDP, highlighted some appetite from industry for early connection, particularly amongst software providers and third-party administrators which handle data for multiple schemes. It may be simpler, for example, for an administrator to connect all the data it holds at once, rather than undergo separate connections for different schemes.

36. As set out above, the default position is that occupational pension schemes would need to be connected in the month prior to their connection deadline (except schemes in the first staging cohort which must connect in the three months before 30 June 2023).

37. However, regulation 16 would allow registrable occupational pension schemes to connect to dashboards before this connection window. This includes small and micro-occupational pension schemes which would not have any statutory duty to connect to the digital architecture in this set of Regulations.

38. Where a scheme wishes to connect early, this will be subject to the approval of MaPS and their capacity to connect additional schemes and subject to MaPS consultation with TPR. MaPS will agree with TPR when TPR should be consulted.

39. The policy intention and design is to enable the mass connection of multiple schemes through single endpoints. The process of approving early connection is therefore expected to be more straightforward and streamlined, for example, for a scheme connecting via a third-party administrator or software provider which was connecting all of its clients simultaneously than it might be if a scheme was seeking to connect on an individual basis.

40. It is important to ensure that individuals using pensions dashboards receive consistent information. Therefore, any occupational pension scheme connecting to the digital architecture after Regulations have come into force would need to be compliant with all aspects of the Regulations from their point of connection onwards. This relates to all requirements set out in the chapters relating to Data (chapter 2) and Find and View (chapter 3.

41. Importantly, occupational pension schemes will not be permitted to withdraw from the digital architecture once they have completed connection (subject to the exceptions in regulation 19). Therefore, completing connection early would effectively be bringing forward the scheme’s date for compliance. For small and micro schemes that connected, they would effectively be bringing themselves into the scope of the Regulations.

42. We are aware that some schemes may hold data for some individuals which is “dashboard ready” and so suitable for early connection, and data for other individuals which will take longer to prepare for connection, perhaps because the information is older and held in a non-digital format. However, our view is that it could cause confusion if only some of the individuals which held a pension with a particular scheme were able to receive their pensions information. It would also be very difficult to monitor compliance for schemes which were only able to respond to some of the individuals they held a pension for. Therefore, if a trustee or manager chooses to connect to the digital architecture early, they would be expected to be able to respond to find and view requests from all of the individuals which have a pension with that scheme.

Reporting requirements

43. There are further specific requirements to report information which have been proposed in the Regulations relating to connection duties, including:

a. Any connection state changes, such as scheduled downtime, maintenance, or a change of endpoint would need to be reported to MaPS (regulation 14). Further details will be set out in standards set by MaPS, including about how much notice would need to be provided, how long any scheduled downtime could last and how often this could take place.

b. In accordance with standards published by MaPS, systemic issues which might affect the digital architecture (or the ability of endpoints supplying data to connect to the architecture), and cyber-attacks would need to be reported to MaPS (in addition to any requirements to report this to the Information Commissioner’s Office under UK data legislation) (regulation 14).

c. If a pension scheme becomes disconnected from the digital architecture for any reason (including from the endpoint it is using to connect to dashboards or if the scheme was no longer within the scope of the Regulations) this would need to be reported to MaPS (regulation 20).

Consultation questions

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

Chapter 5: Staging – the sequencing of scheme connection

1. This chapter sets out the order in which schemes will be compelled to provide pension information data to the digital architecture following completion of the steps to connection outlined in the previous chapter. It also sets out how scheme size will be determined and the circumstances in which a scheme may apply to delay their assigned deadline. This chapter relates primarily to regulations 3, 15, 17, 18 and Schedule 2 Parts 1 and 2.

Chapter sub section	Summary of policy aims / legislative requirements
State Pension	Government is committed to making State Pension data available via dashboards from day one of a scheme connecting to the digital architecture.
Staging objectives	We have prioritised pace and deliverability factors in developing our staging profile. This will help to bring forward the point at which dashboards can be launched successfully to the public, while ensuring dashboards are deliverable.
Staging principles	In collaboration with partners and stakeholders, we settled on a number of key principles to support our staging objectives, including: - staging should focus initially on large and medium schemes with the approach to staging small and micro schemes to be determined later - Master Trusts, personal and stakeholder pension schemes should be among the first to connect, followed by money purchase schemes used for Automatic Enrolment - Public Service Pension Schemes (PSPS) should be compelled to connect no earlier than October 2023 and before staging of medium schemes due to generally being larger schemes - staging large schemes should take no longer than two years from 2023 - schemes should be able to connect earlier than their compulsory staging deadline, where there is capacity (early connection is described in chapter 4).
Benefits and schemes out of scope of the Regulations	Regulation 3 and Schedule 1 establishes that pensioner members (pensions that are currently in payment, see chapter 2) are out of scope of these Regulations along with schemes which are based outside the UK and non-registrable schemes unless the scheme is a public service pension scheme.
Determining the size of schemes	Schemes do not need to include pensioner members when assessing their size by reference to relevant members (the definition of a ‘relevant member’ is in Schedule 1; Interpretation). Also as specified in Schedule 1, the ‘reference date’ for the number of relevant members is based on scheme return data for the scheme year end between 1 April 2020 and 31 March 2021.
Staging proposals	We concluded that staging should be carried out in three waves and that we should regulate initially for the first and second wave: - large schemes (April 2023 – September 2024) - medium schemes (October 2024 – October 2025) - small and micro schemes (not in these Regulations but expected to stage from 2026) Parts 1 and 2 of Schedule 2 set out the staging profile and provide the deadlines by which different cohorts of schemes will be required to connect to the digital architecture. We have included specific proposals for hybrid schemes (regulation 15) and explained our approach to collective money purchase schemes. Regulation 18 sets out provisions for new schemes and schemes that change size, in scheme years following the reference date.
Applications to defer connection deadline	To ensure that all schemes have a reasonable chance of being able to comply with their connection duties, in regulation 17 we propose to allow some limited flexibility in specific circumstances to defer a staging deadline for up to 12 months.

Introduction

2. The Government committed to legislate to require pension schemes to make data available to individuals via pensions dashboards.

3. In order to supply data to individuals via dashboards, on request, schemes must first connect to the dashboard digital architecture. The connection process is described in detail in chapter 4. Respondents to the Government’s 2018 consultation on dashboards overwhelmingly supported the proposal to use legislation in order to maximise the number of schemes participating in dashboards within a reasonable timeframe. The accompanying Regulations set out in detail when it is proposed schemes of different types and sizes will be required to connect to the digital architecture.

4. As set out in the Government’s response to the 2018 consultation, we are proposing a phased approach to connect different categories of schemes to the digital architecture. This is known as ‘staging’. It is proposed that categories of schemes (cohorts) will be given a date (deadline) by which they must connect to the digital architecture and be ready to provide individuals’ data to them via dashboards, on request, in mandatory stages.

5. There are circa 32,000 pension schemes to potentially stage in Great Britain^{[footnote 13]} so it would not be realistic to have all of them brought onto the dashboard from the outset. Many factors were considered in deciding how to approach staging, including the variable states of readiness of different pensions schemes, the operational capacity of the PDP to facilitate scheme connections and the regulators’ capacity to effectively monitor and enforce compliance with the Regulations.

6. Most importantly, as part of its consultation response to the 2018 consultation, the Government determined that staging should prioritise schemes by the number of members they have to maximise the level of member coverage in the shortest possible timeframe. Doing so would increase the number of individuals that are likely to find all their pension entitlements, which could bring forward the point when dashboards could be launched successfully to the public. The largest 77 pension schemes (who each have over 100,000 memberships) represent only a fraction of regulated schemes but 81 per cent of active and deferred memberships^{[footnote 14]}. It is possible to achieve 99 per cent coverage (in terms of active and deferred memberships) within two years of the first staging deadline by connecting only those schemes with more than 1,000 memberships (fewer than 2,000 schemes in total). Conversely, there are over 27,000 small and micro schemes (including Relevant Small Schemes and Executive Pension Plans), which represent only 0.26 per cent of all active and deferred memberships^{[footnote 15]}.

7. The PDP launched a Call for Input on a set of staging proposals in May 2021. The proposals were developed through collaboration between the Department for Work and Pensions and delivery partners including TPR, the FCA and the PDP. A summary of the responses to the Call for Input was published^{[footnote 16]} by the PDP in October 2021. In addition, there has been ongoing engagement with the PDP’s Steering Group and the pensions industry through a series of meetings with leading trade bodies and pensions industry representatives from across the stakeholder community including industry, Fintech, consumer groups and independent consumer experts. The Regulations have been developed considering the feedback from this engagement including responses to the PDP-led Call for Input. The section below on further staging considerations explores some of the key themes emerging from our engagement so far, including from the PDP’s Call for Input.

8. In July 2021, the PDP announced the recruitment of seven major pension organisations to participate in its test phase^{[footnote 18]}. The seven volunteers represent a potential combined provider coverage of over 30 million pensions. In December 2021, it also announced the recruitment of three organisations who are potential dashboard providers to also participate in this test phase. The early participation of all these volunteers in testing will help to create a strong foundation for later stages of the programme. We anticipate that during the testing phase from this year, the PDP will be carrying out full end-to-end testing with invited test users, with real data in a controlled testing environment, to ensure the whole process works as anticipated. We are working with our partners to consider ways we can support this testing phase.

9. Given the scale of the task of connecting so many pension schemes, a dashboard service could be made available to the public before the staging of all schemes is completed. Once the security of the digital architecture is fully assured and user behaviours and needs have been robustly tested by the PDP, individuals will be able to view their pensions information online. The point at which dashboards are launched publicly is what the PDP has termed the ‘Dashboards Available Point.’ As highlighted in the Government’s response to the 2018 consultation on pensions dashboards, user research and international evidence have suggested that although individuals may have a low tolerance for an incomplete dashboard at the onset, this could be mitigated if the gaps (i.e., schemes not yet staged) are clearly identified and it is made clear when these gaps would be filled. We envisage these gaps, such as those schemes which are not yet staged, will be identified to the individual through MaPS design standards.

10. The design standards will require QPDSs to apply warning messages to individuals, indicating the incomplete dashboard is because of gradual staging and the exclusion of small and micro schemes. This view was supported by a review of existing research^{[footnote 19]} carried out on behalf of the PDP, which found that most interviewees were accepting of the potential for some pensions not being found initially. However, their expectation was broadly that these omissions would be rectified within a relatively short period of time, typically within a year.

State Pension

11. In addition to ensuring that pension schemes connect to the digital architecture according to the proposed legislative timetable, Government remains committed to making State Pension information available via dashboards from day one - the initial Dashboards Available Point. The DWP also plans to participate in the PDP’s test phase of the programme in the spring of this year, in order to assure State Pension connectivity.

Staging objectives

12. To assess the various options by which different pension schemes could be segmented and staged (such as by size and scheme type), we settled on a set of eight staging objectives following the assessment of a range of approaches to staging. In summary, these objectives were:

a. Pace – maximising the coverage of pension entitlements potentially findable via dashboards as soon as possible to meet individual user needs as early as possible.

b. Deliverability – ensuring that schemes have a reasonable expectation of being ready to connect by their staging date and can be supported to do so by the PDP, the FCA and TPR.

c. Enforceability – providing a legally robust approach to staging that can be effectively monitored and enforced.

d. Certainty - providing certainty for schemes about the date by which they must be connected to the digital architecture.

e. Equity – minimising competition impacts for scheme managers, trustees or administrators operating in the same market.

f. Learnability – ensuring that lessons could be learned from cohorts that stage earlier to support later cohorts.

g. User information value - prioritising individuals who are either least likely to seek advice or most in need of advice.

h. Reconnection value - prioritising individuals who would most benefit from reconnecting with lost pensions.

13. Modelling by TPR helped the DWP and key delivery partners to segment different schemes into cohorts based on their size (in terms of members), pension type and sector. Using data relating to all in scope pensions, TPR developed an analytical staging tool and assigned scores for each cohort in terms of:

a. Pace

b. Deliverability for industry

c. Deliverability for the regulators (TPR and FCA)

d. Deliverability for PDP

14. In keeping with our overarching policy objectives (see annex A: Background), we agreed to prioritise pace and deliverability for the benefit of individuals by facilitating the Dashboards Available Point sooner and with greater coverage, whilst remaining deliverable for industry.

Staging principles

15. The PDP-led Call for Input, was informed by several key principles that would support an approach to sequencing in keeping with the agreed staging objectives (as described above):

a. Staging should focus initially on large (1,000 members or more) and medium (100-999 members) schemes with the approach to staging small and micro schemes to be defined later.

b. Master Trusts, personal and stakeholder pension schemes should be amongst the first to stage, followed by DC schemes used for Automatic Enrolment (personal and stakeholder schemes fall outside of the scope of these Regulations and will be covered by FCA rules).

c. Public Service Pension Schemes (PSPS) should be compelled to stage no earlier than October 2023, due to the operational implications of applying the McCloud Remedy^{[footnote 20]} but before staging of medium schemes (due to them generally being larger schemes).

d. Staging large schemes should take no longer than two years from 2023.

e. Schemes should be able to connect earlier than their connection deadline where there is capacity (early connection is described in the previous chapter).

Classes of scheme and benefits out of scope of the Regulations

16. It is proposed that for initial dashboards (regulation 3), pensioner members (see further detail in the Value Data section in Chapter 2) are out of scope of these Regulations and therefore not viewable to individuals using dashboards. Non-UK-based schemes will also be out of scope. (Further details are in the table ‘Classes of schemes and benefits out of scope of the Regulations’ below.)

17. Some respondents to the PDP’s Call for Input raised concerns about limiting the scope of dashboards to pensions not in payment as it would lead to an incomplete view of an individual’s pension information. The Government considered this as part of the 2018 consultation, including that those in partial retirement may want to see information about pensions in payment alongside those that may have been deferred. It remains the Government’s view that initially dashboards should focus on providing individuals with information on active and deferred pensions only. The scope of dashboards may evolve in future, informed by ongoing user testing. Respondents to the PDP’s Call for Input highlighted that communications to individuals using dashboards must clearly explain that not all pension schemes would be represented via dashboards. Messaging to individuals using dashboards is discussed further in chapter 7.

18. We are interested in hearing further about other types of benefits which should potentially be excluded from pensions dashboards. For example, we are aware that a number of pension schemes hold Equivalent Pension Benefits (EPBs) as a result of contracting out of the State Graduated Pension Scheme, many of which remain unclaimed (uncrystallised) though beneficiaries are likely to be well beyond pension age. These entitlements are typically very small (maximum of £45.50 per annum), and it is potentially very costly for schemes to digitise these records or, where records are already held digitally, to ensure there is sufficient data to return information to pensions dashboards.

Classes of schemes and benefits out of scope of the Regulations

	Type	Rationale
1	Pensioner members Includes occupational pensions in payment (i.e., annuitized or in drawdown)	Our priority is to focus on benefits not yet in payment to support retirement planning. Pensioner members’ entitlements may be brought into scope in the future.
2.	Non-registrable schemes (unless otherwise stated) Including Unapproved pension schemes such as Fund Unapproved Retirement Benefit Schemes (FURBS) and Employer-Financed Retirement Benefit Schemes (EFRBS) Whilst non-registrable pension schemes are out of scope, this is not the case where the relevant occupational pension scheme is a public service pension scheme	We need to ensure that TPR is able to regulate schemes participating in the pensions dashboards effectively and are therefore not including schemes currently not within TPR’s remit.
3.	Non-UK-based schemes Schemes that are administered outside of the UK are outside of our remit.	Determining the size of schemes

19. All schemes in scope (relevant schemes) will be staged in a sequence according to their type and size.

20. Respondents to the PDP’s Call for Input highlighted that, given pensioner members’ information would not be shown via dashboards, pensioner members should not be factored in when determining the size of a scheme. We have taken this feedback on board.

21. It is proposed that the number of members used for this assessment should be the number of active and deferred members (including those with pension credits) within a scheme, which are referred to in the Regulations as ‘relevant members’ (Schedule 1 Interpretation). Schemes will therefore not need to include pensioner members when assessing their size.

22. The number of relevant members should be counted as at the ‘reference date’ i.e., the scheme year end between 1 April 2020 and 31 March 2021 (Schedule 1 Interpretation).

23. We do not expect schemes to have difficulty in separating out their pensioner members from the total number of relevant members. However, if a scheme cannot separate them out it may include pensioner members to assess its size.

Staging profile

24. Based on the principles set out above, the PDP-led Call for Input put forward a three-wave approach to staging according to the size category of schemes – large, medium and small. We have largely accepted these recommendations. The Regulations build on the PDP’s suggested approach, with further detail added about how we propose to break down the cohorts of schemes within those three waves, and when their connection deadlines should be. The full staging profile for waves 1 and 2 can be found in Schedule 2 of the Regulations, which is separated into Parts 1 and 2.

25. The table below gives an overview of the three-wave approach to staging.

Wave	Compulsory staging period	Size
1 – large schemes (Part 1 of Schedule 2)	April 2023 – Sept 2024	1000+ relevant members
2 – medium schemes (Part 2 of Schedule 2)	October 2024 – October 2025	100 to 999 relevant members
3 – small and micro schemes	Staging dates not to be set in these Regulations, but we expect this is likely to be from 2026	99 or fewer relevant members

Part 1 of Schedule 2 – large schemes (1,000 or more relevant members)

26. Over half of all respondents to the PDP-led Call for Input explicitly agreed with the recommendation to prioritise large schemes within the first two years of compulsory staging.

27. As noted above, we agreed with respondents who suggested that pensioner members should not be counted when determining a scheme’s size. The revised modelling taking this into account has resulted in many schemes moving down into later cohorts and even into Wave 2 (medium schemes). This allows the staging of large schemes to conclude by the end of September 2024.

28. There are around 1,000 schemes in this category. They represent just over 3 per cent of the total number of UK pension schemes but 99 per cent of all active and deferred pension memberships^{[footnote 21]}.

29. Schedule 2 sets out a series of monthly connection deadlines for different cohorts of schemes. In keeping with the staging principles, the priority order for large schemes is as follows:

a. Large Master Trusts (the FCA will make corresponding rules for the providers of personal and stakeholder pension schemes, most of which will also be in the first cohort).

b. Other large schemes providing money purchase benefits for Automatic Enrolment (AE) ordered largest to smallest (both money purchase and hybrid schemes).

c. All remaining large occupational schemes including non-money purchase and other money purchase schemes (ordered largest to smallest), other hybrid schemes, Public Service Pension Schemes and other public sector schemes.

30. Large schemes would be expected to start connecting to the digital architecture from April 2023 with a connection deadline for the first cohort (the largest Master Trusts) at the end of June 2023. The final cohort’s deadline for large schemes is set for the end of September 2024.

31. The first cohort for large money-purchase schemes used for Automatic Enrolment would be required to connect from July 2023, large non-money purchase and other money purchase schemes from end November 2023 and Public Service Pension Schemes (PSPS) by the end of April 2024. Further considerations relating to these different cohorts of schemes have been factored into these proposals (more details are in the section below).

32. Delivering the staging of the large schemes according to this timeline would mean that, by the end of September 2024, dashboards would be able to potentially find nearly 99 per cent of all active and deferred pension memberships in the UK. This would include potentially 95 per cent of all money purchase memberships available by the end of July 2023. For non-money purchase memberships, 95 percent would potentially be findable on dashboards by the end of August 2024.

Part 2 of Schedule 2 – Medium schemes (100-999 relevant members)

33. We intend to commence the staging of medium schemes following the point at which large schemes have completed staging, from October 2024 and complete it within 13 months (by end of October 2025). Any lessons from large schemes should be firmly embedded to better support the staging of medium schemes. Also, the ISP market, which will play a key enabling role for schemes connecting to the digital architecture, will have had more time to develop. There are currently around 2,000 schemes that fit within the medium category. While they account for around 6 per cent of all UK schemes, they together hold only 1 per cent of all active and deferred entitlements^{[footnote 22]}.

34. Around a quarter of respondents to the Call for Input commented on the potential impact on individuals using dashboards of deferring the staging of medium schemes until the staging of large schemes had completed. Respondents highlighted that individuals who hold a pension in medium schemes are less likely to interact with them and medium schemes could therefore contain a higher proportion of lost pension pots. However, no evidence was provided to demonstrate the potential scale of this. As noted in the Call for Input, it will need to be clear to individuals using dashboards that not all pension schemes may have connected. The precise messaging will be considered as part of the development of the dashboard service informed by user testing.

Small and Micro schemes (not in these Regulations)

35. The timing for staging small and micro schemes will be determined later and included in a separate package of future Regulations. We expect the staging of small and micro schemes to begin in 2026. As with medium schemes this approach allows for more time to understand the pace of staging and the potential challenges for staging small schemes more fully, including the capacity for the ISP market to service these schemes. It also allows more time for the volume of small schemes to reduce as a result of scheme wind-up and market consolidation. This does not preclude these schemes from staging early voluntarily.

36. There are over 27,000 small and micro pension schemes in the UK, representing approximately 90 per cent of all schemes. However, despite the substantial number of schemes in this wave, they constitute a mere 0.26 per cent of all active and deferred entitlements^{[footnote 23]}.

37. More than half of respondents to the PDP Call for Input commented on the proposal the later staging of small and micro schemes. Just under two thirds of those agreed with the outlined approach, many citing the tighter margin between cost and benefit (compared with large and medium schemes), plus a lack of automation.

Collective money purchase schemes

38. The Pension Schemes Act 2021 made provision for a new type of pension scheme design with elements of both non-money purchase and money purchase, known as collective money purchase, and often referred to as Collective Defined Contribution (CDC).

39. As a new entrant to the pensions landscape, we wish to be cautious in our approach to the staging of CDCs. We are proposing for CDCs to be staged in the same cohort as Public Service Pension Schemes (with a staging deadline of 30 April 2024).

Hybrid Schemes

40. The regulation 15(1) sets out our position on hybrid schemes. These are schemes which provide both money purchase and non-money purchase benefits. We intend for staging duties to apply to both the money purchase and non-money purchase sections of the scheme at the same time, for whichever is the earlier connection deadline. This is to benefit members who may otherwise find it confusing if they only saw one of the entitlements they accumulated under their scheme via dashboards. Such a gap would also be difficult to explain to the individual.

41. Trustees or managers should notionally divide up their scheme as follows:

a. Count up the number of relevant money-purchase members and look up the staging deadline for a money purchase scheme of the equivalent size. Where any of these money-purchase benefits are being accrued as a result of automatic enrolment, the equivalent scheme should be considered to be a DC used for AE of the equivalent size.

b. Count up the number of non-money-purchase members and look up the staging deadline for a non-money purchase scheme of the equivalent size.

c. The earliest connection deadline of the equivalent money purchase and non-money purchase schemes is the connection deadline for the hybrid scheme as a whole.

42. Example:

A hybrid scheme where the non-money purchase (DB) section has 9,000 relevant members and the money-purchase (DC) section, which is used for AE, has 1,000 members. The earlier connection deadline applies, which in this case is the DC used for AE section (Cohort 1g – 29 February 2024) rather than the cohort that would apply to just the non-money purchase section, i.e., June 2024 (Cohort 1j). So, the non-money purchase section would be required to connect four months earlier than other non-money purchase schemes of that size.

43. The regulation 15(2) clarifies that the requirements for hybrid schemes excludes schemes where the only money purchase benefits are Additional Voluntary Contributions (AVCs).

New schemes and schemes which change cohort due to changes in their size

44. As set out above, a scheme’s connection deadline is to be set by reference to a scheme’s size on a specific date (the reference date) i.e., the number of relevant members as at scheme year end 2020/2021. Scheme year-end data provided through TPR’s scheme return process will be used to identify schemes in scope of the Regulations.

45. Schemes will however change in size during the staging profile, including as a result of membership growth, and there will be new schemes which emerge in scheme years following that of the reference date (after the scheme year 2020/2021). Regulations 14 and 18 (of Part 3, Chapter 1) set out how we propose to treat such schemes.

46. Regulation 14(7) specifies that for a scheme that is in scope at the 2020/21 reference date, the staging date remains fixed even if the scheme changes size or classification (unless all the members become pensioner members). Regulation 18(1) provides for schemes that were not in scope when the Regulations came into force, based on the 2020/21 reference date, but are in scope based on their scheme year data for the following two years after the reference date (for example, by virtue of size during scheme year end 2021/22 or 2022/23). This would include, for example, small schemes (with fewer than 100 members) which become medium or large during that period. To ensure fairness across schemes staging within waves one and two, the deadline for these schemes is the later of either:

a. six months from the end of the scheme year in which they came into scope; or

b. the staging deadline for the equivalent 2020/21 cohort

47. Example:

a. A new Master Trust scheme with 6,000 relevant members as of scheme year ending on 31 March 2022 would have a deadline in line with the equivalent 2020/21 cohort (1d) of 30 October 2023.

48. The regulation 18(2) sets out that all schemes which come into scope from the scheme year 2023/2024 onwards would be required to connect within six months (last day of the given month) from the end of the scheme year in which they came into scope.

49. As per regulation 18(3), once a scheme’s connection deadline is set (by reference to its size and type at the scheme reference date), this deadline remains fixed even if the scheme later changes in size or even type.

50. Example:

a. A scheme determined to be ‘large’ on 31 March 2021, that later reduces in size post-31 March 2021 would retain its ‘large’ connection deadline. This would also apply to schemes that are ‘medium’ as per scheme year end data as on 31 March 2021 retaining their ‘medium’ connection deadline, even if they became large post-31 March 2021. This will extend not only to size but scheme characteristic; for example, a money purchase scheme (or section) that was used for automatic enrolment, but ceases to be used for automatic enrolment, keeps its original connection deadline.

51. It is possible that a scheme could be in scope but moves out of scope if all its members became pensioner members, but then moves back into scope again. regulation 18(4) is designed to capture those schemes, which would be treated as a new scheme. Regulation 18(5) simply states that all of the requirements in Part 3 would apply equally to schemes that fall under these provisions.

Further Staging considerations

52. The above proposals have been shared extensively with industry representatives, including via the PDP’s Call for Input, and have been refined as a result of this engagement. Some of the main policy issues that have been considered are outlined below. There were 62 responses to the PDP Call for Input with responses drawn from the pensions industry, third party administrators, software providers and consumer organisations. The Call for Input focussed primarily on our staging proposals and other key areas which will be integral to the successful delivery of dashboards. The input from this wide-ranging group of respondents indicated broad support, with half of respondents explicitly agreeing that the staging proposals were in line with our policy objectives (see annex A: Background).

53. A small number of respondents suggested that accrued and projected value data should be omitted from initial dashboards in order to better achieve our objectives. Some respondents also highlighted the need for user testing to inform our approach. We have set out our proposals on value data in chapter 2 and also response times, in chapter 3. We recognise that the deliverability of our staging proposals are directly linked with these requirements. Our aim is to strike the right balance between industry deliverability and our objective to deliver dashboards as soon as possible in a way that will meet the needs of the individual. Other key themes that have been highlighted as part of our engagement are outlined below.

Data quality

54. Schemes’ data quality will be integral to the success of pensions dashboards. Through our engagement with industry, the link between data requirements, the quality of a scheme’s data, the presence of certain value data, and their readiness to connect to dashboards was often made. There are various challenges for schemes in maintaining data quality. For example, some Master Trusts highlighted concerns about employer data quality issues, which is not in their control, but which could impact their ability to match individuals using dashboards with their pensions.

55. As we have set out before, including in the Government’s response to the 2018 consultation, it is vital that schemes are doing what they can now to improve the accuracy of their data. The PDP’s website includes a pension schemes hub^{[footnote 24]} that sets out what schemes could be doing now and throughout the programme’s various delivery phases to prepare to connect to dashboards. TPR provides guidance on reviewing and improving scheme data^{[footnote 25]} and will be providing additional dashboard-specific guidance in 2022. The Pensions Administration Standards Association (PASA) provides helpful data guidance^{[footnote 26]}, which includes information about how to detect and resolve common data issues and has recently published guidance on data matching conventions to support a consistent approach.

Timeline

56. Many respondents to the Call for Input stated that more certainty on the technical and data requirements (such as the position on schemes value data, often referred to as estimated retirement income) was needed in order to give an indication of when they would be ready to connect.

57. Of those that did respond to the Call for Input, around three-quarters suggested that 12 months or more (up to 24 months) would be required from the point of certainty. Over two thirds of respondents said that the level of certainty needed would be from the point when either government laid or Parliament approved the final Regulations. Several commented that their estimates depended on what ISP solution they would decide upon, pointing out that it could take longer if an in-house solution was used. There was also some indication by Third Party Administrators (TPAs) that they could be in a position to bring schemes on board earlier than required.

Master Trusts

58. These proposals will place large Master Trusts with 20,000 or more relevant members in the first staging cohort along with most providers of personal and stakeholder pension schemes. All respondents to the Call for Input who answered this question broadly agreed with this approach. It was noted by respondents that master trusts are the main beneficiaries of auto-enrolment and scheme consolidation, are authorised by TPR and are the fastest growing pension sector, generally with large numbers of members.

59. TPR analysis indicates that Master Trusts should be relatively well-placed to be able to comply. They have existing requirements around systems and processes, and they are more likely than any other trust-based schemes to offer online access to their members, which indicates higher levels of technological sophistication and, therefore, the ability to meet the technical demands of pensions dashboards^{[footnote 27]}. As set out in the Call for Input, in respect of data, they are subject to existing requirements around disclosure (annual benefit statements), but they are also consistently more likely than other forms of trust-based DC schemes to meet TPR’s expectations in respect of administration and record-keeping^{[footnote 28]}.

60. As noted above, some respondents highlighted employer data quality issues. Others highlighted a potential competitive disadvantage being first to stage if other workplace and retail DC pensions remained unavailable when dashboards went live.

61. As part of the Call for Input, we explored whether non-commercial Master Trusts (using size as a proxy) should be allowed to stage later. We proposed that Master Trusts with fewer than 20,000 members should stage later in the first wave. Most respondents that answered this question agreed, however just under a third disagreed on the basis that the number was arbitrary and that it was unnecessary to differentiate between commercial and non-commercial Master Trusts for the purpose of staging. The proposed Regulations require Master Trusts with fewer than 20,000 relevant members to stage over subsequent cohorts in keeping with their size.

Money purchase schemes used for Automatic Enrolment

62. Of those who commented in the Call for Input on the staging of this cohort, most agreed with the proposition that money purchase schemes used for Automatic Enrolment should be staged following master trusts and personal pension schemes. It was accepted by most that these schemes should be well placed to connect to dashboards due to mostly being administered on modern digital platforms and generally have good data. However, some suggested that there needs to be flexibility for schemes who are unable to connect their entire register. Four respondents who disagreed with the proposal questioned why this cohort would be limited to only DC pensions used for AE and not DB.

63. As proposed in the PDP’s Call for Input, the Regulations will prioritise large DC schemes used for AE from the second cohort of the Regulations.

Non-money purchase schemes

64. Over half of respondents to the PDP’s Call for Input offered a view on the challenges of non-money purchase schemes in connecting to dashboards. This included concerns around the challenge of providing value data due to the complexity of benefits and a lack of digitisation. Implementing guaranteed minimum pension (GMP) equalisation and other factors were also cited as challenges that may affect when non-money purchase schemes could stage.

65. We recognise there are likely to be additional challenges for many non-money purchase schemes in connecting to dashboards. As set out above, the Regulations would require the first cohort of non-money purchase schemes with 20,000 or more relevant members to connect to dashboards by the end of November 2023.

Public Service Pension Schemes (PSPS)

66. Public Service Pension Schemes (PSPS) represent nearly 20 per cent of all active and deferred memberships in scope for dashboards^{[footnote 29]}. In line with our objectives to maximise coverage on dashboards, it is important for PSPS to stage as early as possible.

67. More than half of all respondents to the PDP Call for Input gave a view in response to the proposal that all PSPS should be staged as early as possible in the first wave. Two thirds of those who responded agreed highlighting the large numbers of members and entitlements that make up PSPS. Nearly all respondents representing PSPS either explicitly disagreed or neither agreed nor disagreed with this approach. Those that disagreed primarily reiterated the challenges associated with implementing the McCloud remedy.

68. HMT introduced the Public Service Pensions and Judicial Offices Bill to the House of Lords on 19 July 2021. This primary legislation will facilitate implementation of the McCloud remedy, which will ensure that discrimination, which arose as a result of the way the new schemes were implemented, is removed. The period in relation to which this discrimination arose began on 1 April 2015 for most schemes^{[footnote 30]} and ends on 31 March 2022 and is known as the remedy period.

69. The primary legislation sets out that retrospective changes must be introduced by 1 October 2023 but will allow schemes to implement the retrospective remedy – via the required Regulations – ahead of this date. From 1 April 2022, all Public Service Pension Scheme members will accrue in the new schemes.

70. The remedy brings about a Deferred Choice Underpin (DCU) for relevant members, which means at the point benefits are payable they will be able to choose legacy or reformed scheme benefits for the remedy period. However, Local Government Pension Schemes (LGPS) are in a different position to the other, unfunded public service pension schemes in that they have an automatic “underpin” approach to the McCloud remedy, rather than an options exercise. Hence LGPS would not need to report two different potential values for the projected benefits.

71. HM Treasury consulted on changes to the transitional arrangements to schemes in 2020. In their consultation response^{[footnote 31]}, HM Treasury set out that the DCU 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 new schemes, for the remedy period, until they make that choice.

72. Considerable work will be required in the short term by PSPS to move many members of the new schemes back to their legacy schemes for the remedy period, as well as resolving cases of members who have retired or died since April 2015.

73. Before schemes and administrators can implement new processes and IT system changes to deliver the DCU, the necessary legislation, both primary and secondary, 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 remedy will continue working for some time before making their choice.

74. Detailed scheme level work is being undertaken by HMT alongside affected government departments to fully scope out the McCloud Remedy in order to make the required changes in primary and 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.

75. Taking into consideration the impact of the McCloud remedy, we propose a staging deadline for PSPS of the end of April 2024. However, recent engagement across government has further highlighted the scale of the challenge surrounding the implementation of the McCloud remedy. Following the consultation, we may therefore need to consider what other mitigations might be needed to ensure the successful staging of PSPS in line with our staging principles.

Staging breaks

76. The staging timeline includes a series of ‘staging breaks’ which are designed to allow for any potential operational issues to be addressed and to embed lessons learned prior to the next cohort of schemes coming on board.

Applications to defer connection deadline

77. Given the benefits that pensions dashboards will bring to individuals, it is right that pensions schemes should be required to connect to the dashboard infrastructure as soon as feasibly possible.

78. However, the scale and complexity of staging means that there are many variables, some of which may be outside of the control of trustees or managers of pension schemes. Some of these issues are already known and could lead to schemes being unable to comply with the timing of the responsibilities set out in the Regulations. To ensure that all schemes have a reasonable chance of being able to comply with their staging duties, we have proposed a legislative mechanism which provides some limited flexibility in staging duties in specific circumstances.

79. Based on the responses received during the PDP’s Call for Input, we believe that it would be reasonable to offer individual pension schemes the opportunity to apply for an extension to their staging date, if they had in good faith embarked on a programme to transition data to a new administrator before staging dates were known. In such instances, if a scheme’s connection deadline conflicted with the dates of the data transition it could be deemed excessively burdensome to expect a scheme to connect twice to the dashboard digital architecture within a short period of time (i.e., with their old administrator and then the new administrator).

80. We have therefore proposed to provide the Secretary of State for Work and Pensions with a limited administrative discretion to grant a deferral to individual schemes for their staging deadline. Our proposals, included in regulation 17, would mean that the power to grant a deferral:

a. may only be granted once; and

b. must be for no more than 12 months

81. An application would only be considered to have merit if the conflict was unavoidable. Therefore, in order to be considered for a deferral, we have proposed that evidence would need to be provided to show that it would be disproportionately burdensome to comply with the staging requirements, and doing so would put the data of members at risk, as a result of either:

a. a contractual or statutory obligation on a scheme to retender their administrator before dashboard Regulations were in force; or

b. a procurement process for a new administrator or a new administration system had begun before dashboard Regulations were in force.

82. That is not to say that an extension should be granted in all cases, as in many cases a receiving administrator could already be ’dashboard-ready’ and a connection could therefore be somewhat seamless.

83. If a scheme has a genuine obligation to retender their administrator or has already started the procurement process, then this will already be known. We have therefore proposed that the Regulations would include a time limit in which applications would need to be made. Our proposals mean that any applications for extensions would need to be made within 12 months of the Regulations coming into force.

84. We will provide further guidance on the deferral process, which would include further details about what would be considered to be a procurement process. Trustees or scheme managers should however be aware that any applications to defer a staging deadline would be rigorously assessed to ensure that approvals are only provided where this is merited.

Consultation questions

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?

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.

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?

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.

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?

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?

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

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?

Chapter 6: Compliance and enforcement

1. This chapter sets out details of the new powers which would be placed on TPR to issue notices and penalties in the event of non-compliance with the requirements set out in the Regulations. The regulations relevant to this chapter are in Part 4 of the Regulations.

Chapter sub section	Summary of policy aims / legislative requirements
Compliance notices	As set out in regulation 28, for any instance of non-compliance with a requirement in Part 3 of the Regulations, TPR would have the option to issue a compliance notice to the trustees or managers of occupational pensions schemes.
Third party compliance notices	In circumstances where TPR is of the opinion that non-compliance with a requirement in Part 3 of the Regulations has been caused by a third party, then TPR would have the option to issue the third-party with a third-party compliance notice, as specified in regulation 29.
Penalty notices	Regulation 30 specifies that TPR would be able to issue penalty notices for non-compliance with a compliance notice, or third-party compliance notice, or for contravention of a provision in Part 3 of the Regulations. TPR would have the option to issue penalties of up to £5,000 to individuals and up to £50,000 in other cases, for any instance of non-compliance with the Part 3 of the Regulations.
Enforcement on a ‘per request’ basis	TPR would have the option to issue penalty notices for failure to comply with a compliance notice (or third-party compliance notice), or in respect of contraventions of individual requirements of the Regulations, for example for each time a scheme failed to respond to a request to find or view pensions information in the manner required by Part 3 of the Regulations. As set out in regulation 30, TPR may issue multiple penalty notices in one document.
TPR discretion	All enforcement action relating to non-compliance with Part 3 of the Regulations would be at the discretion of TPR.
Data protection and the role of the Information Commissioner’s Office in enforcement	The Regulations have been developed to be consistent with existing data protection requirements set out in law, including the UK GDPR. Therefore, it would remain the responsibility of the Information Commissioner’s Office to investigate any breaches of data protection law and take the action it considers appropriate, in the usual way. The Regulations would not make any changes to this existing role.

Introduction

2. The success of pensions dashboards will be dependent on the cooperation of thousands of organisations working together to provide individuals with their pensions information. The Government has concluded that the fastest way to achieve this is to make participation compulsory. A key part of this is the development of a robust and effective enforcement regime which allows for appropriate enforcement action to be taken in the case of a failure to adhere to any of the proposed requirements and provides a significant deterrent to non-compliance.

3. To achieve this, we have proposed giving TPR new powers in relation to pensions dashboards to issue notices and penalties to trustees or managers of relevant occupational pension schemes and relevant third parties. This is set out in Part 4 of the Regulations.

4. If a trustee or manager of a relevant occupational pension scheme fails to comply with any of the requirements set out in Part 3 of the Regulations, we have proposed that TPR would have the option to issue legal notices and/or penalties to that person. TPR may also issue third-party compliance notices and penalty notices in circumstances where a trustee or manager is not directly responsible for a contravention of a requirement and TPR considers that a third party is.

5. As the Regulations would require trustees or managers to comply with standards set by MaPS, a failure to comply with standards would be considered a breach of the Regulations and could therefore result in enforcement action being taken by TPR.

6. How we envisage each of the proposed notices functioning is set out in further detail in this chapter.

7. These new powers would sit alongside TPR’s existing general powers which it will continue to be able to utilise as it sees fit. For instance, TPR’s general powers include the ability to request information, require a skilled persons report; or remove or appoint a trustee where warranted.

8. TPR’s new powers in relation to pensions dashboards are complementary to its general powers and enable swift and targeted action on issues related specifically to requirements relating to pensions dashboards.

Compliance notices

9. For any instance of non-compliance with Part 3 of the Regulations, it is proposed that TPR would have the option to issue a compliance notice to scheme trustees or managers of occupational pensions schemes. This is included in regulation 28.

10. A compliance notice is a notice requiring the trustee or manager to take (or refrain from taking) the steps specified in the notice to ensure that the non-compliance is remedied and, where appropriate, not repeated. Compliance notices may also require the person to provide information to TPR within a specified time frame.

11. Compliance notices would also explain that if TPR believes that requirements set out within the notice have not been complied with in a specified time period, then a penalty may be issued.

Third-party compliance notices

12. Regulation 29 sets out that in circumstances where TPR is of the opinion that non-compliance by a trustee or manager has been caused by another person, then TPR would have the option to issue a third-party compliance notice. This could, for example, include an ISP which has been contracted by a trustee or a scheme manager.

13. Third-party compliance notices would function in much the same way as a compliance notice in that they may set out the steps that must be taken or stopped, to resolve issues within a specified time period. They may also require the third-party to provide specified information to TPR, including information about how they have complied with the notice.

14. The notice would also make clear that if the third-party fails to comply with the requirements of the notice, they may be issued with a penalty notice.

Penalty notices

15. We have proposed under regulation 30 that TPR would have the option to issue a penalty notice if they are of the opinion that:

a. a trustee or scheme manager is in breach of any of the provisions in Part 3 of the Regulations, including adherence to any standards published by MaPS that the Regulations require compliance with; or

b. the requirements set out in a compliance notice or a third-party compliance notice have not been complied with.

16. It is proposed that the maximum penalty which could be issued for a single compliance breach would be £5,000 for an individual, or £50,000 in any other cases.

Enforcement on a ‘per request’ basis

17. We know that once dashboards are available to the public it could result in millions of requests from individuals to find their pensions, followed by requests to view information about them. Therefore, there is the potential for any errors in the provision of pensions information to be amplified and cause detriment to multiple individuals and undermine public confidence in pensions savings.

18. Given the large number of requests for pensions information that could take place, we want the enforcement regime to be able to reflect the scale of any potential detriment that could be caused by failure to comply with the requirements in Part 3 of the Regulations.

19. Therefore, regulation 30 would allow, at TPR’s discretion, for a penalty to be issued for each contravention of a requirement of the Regulations. Providing TPR with the power to issue penalties on a ‘per request’ basis is intended as a significant deterrent to non-compliance. If TPR chooses to issue multiple penalties at the same time, the Regulations would allow it to issue these in one document.

20. TPR would exercise this discretion with regard to the Regulators’ Code and the principles of good regulation set out in the Legislative and Regulatory Reform Act 2006. That is to be: proportionate, accountable, consistent, transparent and targeted.

TPR discretion

21. We have proposed that TPR would have discretion in all areas relating to dashboard compliance. This means that TPR can decide when it will issue compliance notices, third-party compliance notices, and penalty notices. TPR would also be able to determine the level of any monetary penalties, subject to the statutory maximum set out above. This is in line with the majority of TPR’s enforcement activity.

22. The Government expects all trustees or managers to make every effort to comply with any Regulations that are approved by Parliament. To aid with this, TPR are planning to carry out a communications drive to educate trustees or managers on their responsibilities. The intention is that MaPS and TPR will also be issuing guidance to assist with the process of preparing to meet the proposed requirements relating to pensions dashboards. However, given this is an entirely new undertaking involving new technology, we think it would be prudent to provide flexibility for TPR to exercise its discretion and to allow for unexpected circumstances that may warrant a different approach.

Reviews and Appeals

23. As set out in regulation 33, TPR may review compliance notices, third-party compliance notices, and penalty notices if the person issued with the notice makes a written application for a review within 28 days. Details about the review process would be set out in penalty notices. TPR may also review the notice within 18 months if it otherwise considers this appropriate.

24. Following a review (or if TPR determines not to carry out a review upon receipt of a written application), regulation 34 would also allow a reference to be made to a Tribunal in respect of a penalty notice.

Data protection and the role of the Information Commissioner’s Office

25. The Regulations have been developed to be consistent with existing data protection requirements set out in law, including the UK GDPR. Therefore, it would remain the responsibility of the Information Commissioner’s Office to investigate any breaches of data protection law and take the action it considers appropriate, in the usual way. The Regulations would not make any changes to this existing role.

Consultation questions

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

Chapter 7: Qualifying pensions dashboard services (QPDS)

1. In this chapter we refer to Regulations in Part 2, Prescribed requirements for qualifying pensions dashboard services. Specifically, regulations 7, 8, 10, 11 and 12. We detail the proposed requirements that will be placed upon QPDS, including connection and functionality, displaying of the view data and reporting and monitoring of the dashboard. The table below outlines a summary of the policy intentions and proposed requirements that will be discussed throughout this chapter.

Chapter sub section	Summary of policy aims / legislative requirements
Data protection	As set out in regulation 8(3) QPDS must only store the view data in the form of temporary caching of the data for the purposes of displaying the view data in a single session. Caching is necessary to enable the dashboard to function and present the data to individuals. QPDS would be able to store PeIs and tokens only where consent has been obtained from the individual and they operate accounts for individuals.
Connecting to the ecosystem and operating within the ecosystem	Regulation 7 sets out the requirements that a QPDS would need to do to connect to the specified MaPS digital architecture. Because a QPDS must connect to the MaPS digital architecture it must adhere to all MaPS standards in relation to this connection. QPDS will be expected to adhere to the standards required of them and could be subject to disconnection by MaPS if they fail to continue meeting these standards.
Displaying of the View data	As set out in regulations 8 and 9, a QPDS would be required to immediately present the view data and state pension data when it is available. QPDS will be free at the point of use as set out in regulation 8. The function of a QPDS is to present the state pension and view data in the manner which will be stipulated in the Regulations and MaPS standards. The way in which view data is displayed is a crucial element of consumer protection. Therefore, the Regulations include a proposed duty on QPDS to display this data in accordance with the design standards.
Reporting and monitoring requirements	Regulation 10 sets out various reporting requirements on QPDS including: - providing management information to MaPS and the regulators about the return of view data by schemes - providing information to MaPS and/or the FCA that enables them to monitor that the QPDS is complying with MaPS standards, DWP regulations and FCA rules, and is providing the service it was intended to do - reporting analytical and statistical information The Regulations would also require QPDSs to support MaPS to collect survey data from individuals using dashboards to assist with evaluation of the dashboards service.
FCA authorisation and the new regulated activity	The intention is that HMT will amend the The Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 to make the provision of dashboards a new regulated activity. As set out in regulation 7, QPDSs would be required to obtain FCA authoristion. The FCA will be informed by MaPS that the dashboard provider is able to comply with the standards. A 3rd party auditor, as set out in regulation 12, will support MaPS in establishing that those standards which cannot be automatically detected by the digital architecture, have been met. Once a dashboard provider is FCA authorised they would be subject to the applicable FCA rules and principles for businesses.

Introduction

2. Within the dashboard ecosystem, there may be multiple dashboards, developed and hosted by different organisations. As set out in the Pension Schemes Act 2021 (adding section 4A to the Financial Guidance and Claims Act 2018), MaPS is required to develop and host its own dashboard. For other operators to connect their own dashboards to the digital architecture, they would need to become a Qualifying Pensions Dashboard Service (QPDS).

3. This chapter sets out the requirements that dashboard providers will need to meet in order to gain and maintain their status as a QPDS. In doing so, it focuses on a range of issues, such as the presentation and processing of data, delegated access, and data export, which have fundamental impacts on user experience and consumer protection.

4. A QPDS is a service which connects to the digital architecture to enable requests and to display pensions information to an individual. The primary legislation defines a pension dashboard as an “electronic communications service by means of which information about pensions may be requested by, and provided to, an individual or a person authorised by the individual.” (section 238A(1) Pensions Act 2004). The protection of individuals is paramount, so to be considered a “qualifying pensions dashboard service,” all the requirements in Part 2 of the Regulations would need to be met.

5. A QPDS is, by definition, (only) a means of requesting and presenting information. We have proposed that initial phase dashboards will not process the data, offering only a simple ‘find and view’ function which allows the consumer to search for their pensions and see some basic information about them (DWP Pensions Dashboard Consultation Response, 2019). A dashboard service could be characterised as a portal to view pensions information held elsewhere.

6. Part 2 of the Regulations propose several requirements which dashboard providers must fulfil and continue to fulfil if they wish to become and remain a QPDS. These requirements include conditions in relation to connection to the digital architecture, operating within the ecosystem, displaying the view data, monitoring, reporting and FCA authorisation. Standards published by MaPS will provide further information on how QPDSs must comply with these requirements. By setting out in Regulations the requirements to be met by a QPDS, we aim to achieve a consistent level of reliability and consumer protection across all dashboards. The MaPS design standards would require that the information being displayed to individuals is easy to understand and consistent across dashboards. The design standards will also ensure that dashboards are accessible. Dashboard providers must obtain FCA authorisation and they will then be required to adhere to FCA principles for businesses which includes firms communicating information to clients/consumers in a way which is clear, fair and not misleading.

7. Obtaining FCA authorisation would mean that the dashboard provider had satisfied the FCA’s application assessment and would enable them to commence operating a QPDS. In addition, the FCA plans to consult on, then make handbook rules which dashboard providers would need to adhere to. The FCA would supervise against its own rules.

8. In the PDP’s Qualitative Research with Potential Dashboard Users Summary Research Report^{[footnote 32]}, some respondents questioned whether they would be charged to use the dashboard. Throughout the development of the Pensions Dashboard, we have intended to keep this service free for the individual and we have therefore included a provision in regulation 8(1)(b) stating that QPDS must be free to use.

9. We consider it vital that QPDSs help individuals navigate where to direct complaints if they are dissatisfied with any aspect of the pensions dashboards service provided. Therefore, in the Regulations (regulation 11), we are proposing to place a requirement on QPDS that they must provide a link to the central complaints process for MaPS. The complaints process will help individuals to understand where to go if things go wrong and what available routes they can take to complain.

Connecting and operating with the ecosystem

10. In the Regulations we refer to connection to MaPS rather than specific components of the digital architecture, but more specific detail is included here which is not reflected in the regulations.

11. A QPDS would need to be connected to the digital architecture, expressed in the draft regulations as a requirement to connect to MaPS, in order to display the pensions view data and state pension data to the individual, (regulation 7(2)).

12. Once an individual starts the process of initiating a search to find their pension(s), the QPDS would direct the individual to the consent and authorisation service. The consent and authorisation service, provided by the MaPS digital architecture, will be used for the purposes of the find and identification function of the dashboard. This is to ensure that the individual accessing the dashboard can edit or revoke their consents and their terms regarding accessing their pension information and PeIs (for either themselves or those to whom the individual has granted delegated access).

13. As part of the connection process, a dashboard provider is required to register with MaPS. MaPS will publish guidance which will specify the steps dashboard providers would be expected to take before going through registration. When a dashboard provider has successfully completed the connection steps to connect to the MaPS digital architecture, alongside adhering to all technical, security and connection standards, MaPS would allow the dashboard provider access to the digital architecture.

14. 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.

15. Failure to adhere to and follow these standards would result in de-registration from the governance register and disconnection from the digital architecture. Paragraph 46 sets out a plan to introduce a third-party approach which would aim to ensure QPDS compliance with MaPS standards. A trusted third-party professional would be required to undertake an audit of the dashboard provider to ensure MaPS that compliance with the standards set by MaPS and which are a requirement of becoming a QPDS in the regulations are being met and adhered to.

Displaying of the pensions view information

16. When an occupational pension scheme has identified a match, trustees or managers would have a duty to register a PeI. Once this has been authenticated by the consent and authorisation service, it would be available to be retrieved and returned to an individual’s dashboard. When the individual requests to see the view data and once the individual’s consent has been obtained, a QPDS would then be required to present the descriptive information to support an individual’s understanding of what that return means. The descriptive information which would be returned to the individual, will be set out in the design standards published by MaPS.

17. The PeI is to be used as a reference to a specific pension: it would not identify the owner and could be reused by the pension owner across various dashboards. We have proposed that it could also be used by delegates and the owner of the pension to request access to an individual’s pension information. If the user consents at the consent and authorisation process, for a chosen dashboard to retrieve their PeIs, the dashboard can store these PeIs. As an independent data controller, the dashboard would need to satisfy itself of its own lawful basis for any such storage. Storing the PeIs would enable the individual to access their pension’s view information without the need to re-input their find data. We expect these PeIs to be stored for no longer than 18 months, but these retention limits will be determined by MaPS standards.

18. We propose placing a duty on a QPDS to display the view data received from the pension schemes as soon as it has been received (in the find and view chapter, we outline how long trustees or managers would have to return this information to QPDSs) and for the length of the individual’s session. The data must be displayed in accordance with the MaPS design standards (regulation 8(2)) so that the way the information is displayed is easy to understand and not misleading.

19. The MaPS design standards are crucial in ensuring consistency in the presentation of information and ensuring users are not confused or misled by what they see on their dashboard. MaPS design standards, as well as any relevant FCA conduct of business rules that might pertain to display of information, will have vital roles to play here in consumer protection. We believe that ensuring a degree of standardisation of the presentation of this data is an important way of enabling a consistent and positive experience for individuals. Adherence to MaPS standards and any applicable FCA Handbook rules that the FCA will consult on in due course will play a key role in consumer protection: a QPDS will be required to present a consumer’s pensions information in a way that is not misleading.

20. We want to ensure that individuals can be confident that there is a robust regime in place to protect themselves and their data. We have therefore proposed mandating that the view data would need to be displayed in accordance with the design standards which will be published by MaPS (regulation 8(2)). This should mean that the values should not be manipulated for presentation beyond the relatively restrictive bounds (where design standards will detail the circumstances where data may be added up, displayed graphically or displayed in alternatives to annual amounts). Standards will include information around the messaging which would need to accompany the return values and the way the return values must be presented.

21. Design standards, set by MaPS, will detail the circumstances where QPDS will not need to display certain information. In these instances, the dashboard may use display logic to determine when and what information needs to be omitted from the view display. For example, if a pension scheme returns a nil value, then the dashboard would be required to present a particular message to explain why a nil value has been returned.

22. The Regulations (regulation 8(3)) have made clear that a QPDS would not have access to or be allowed to store any personal data or information other than storing the PeIs or tokens to prevent the individual needing to initiate another find request. These PeIs and tokens can only be stored if the individual has given consent. This consent is extremely important from a consumer protection perspective, ensuring that individuals have a choice and can retain control over their consent, having the ability to review, revoke or amend their consent (regulation 7(5)(C)). Nor would a QPDS be permitted to use the data for any other purpose besides displaying this to the individual. Whether or not QPDSs should be permitted to enable individuals to export the data shown on the dashboard, away from the dashboard, is discussed further, below. QPDSs would be required to comply with UK data protection legislation.

Additional functions

23. We believe that it is important, particularly during this first phase of the introduction of dashboards, that the presentation of data is delivered in such a way as to instil trust by individuals using dashboards in its safety and security. Regulation 8(3) prohibits the storage of the view data and state pensions data, other than temporary caching to enable the display for a single session. We also want to ensure the data displayed has not been manipulated beyond the relatively restrictive bounds set out in regulations. Regulation 8(2) ensures that data manipulation is not permitted, requiring that the view data must be in accordance with design standards. The design standards will detail the circumstances where data may be combined, displayed graphically, or displayed in alternatives to annual amounts. This is a reasonably restrictive approach which we think is helpful in engendering trust in dashboards, but we are keen to hear feedback.

24. We are not proposing to constrain in Regulations what additional information a dashboard provider might choose to show to an individual alongside what will be required in the Regulations and through MaPS design standards. We believe that this is not a policy decision required for the regulations but that whether and what additional information which may be allowed on the dashboard is a matter to be determined and set out in the FCA rules for QPDS providers. We are keen to hear views on how this potential opportunity may be used by prospective dashboard providers and understand from potential dashboard users and their representatives whether this approach delivers an effective user experience and retains trust. We will share consultation feedback with the FCA to support their consideration of this issue.

25. Dashboards will not be able to offer any functionality which enables transactions, such as consolidating pension pots or transferring pensions, to take place. Transactions increase the potential risk for consumers, in part because for initial dashboards at least, the information provided will be high-level, and certainly insufficient for decision-making around transactions. We believe that this is an important limit in the function of dashboards and is one that we committed to during the passage of the Pensions Scheme Act 2021.

Allowing data to be exported from dashboards

26. We are conscious that there is considerable interest in the question of whether data can be exported from dashboards. While this is a matter that cannot be covered in regulations, we set out below our understanding of the pros and cons and invite your views on these and others we have not foreseen. We will share consultation responses with the FCA to support its consideration of the regulatory framework for operators of QPDS.

27. Information presented on dashboards may influence individuals’ behaviour and decision-making. At the same time as bringing benefits, dashboards may also present an increased risk that, simply because they remove the administrative effort for an individual of collating the information individually, individuals are motivated to make poor decisions that they might otherwise have not made (which in many cases, will be irreversible); or because the collation and access to information makes individuals more susceptible to scams or other malicious behaviour.

28. Pensions are an incredibly significant financial asset, often built up over very many years, and they play a fundamental part in defining the quality of an individual’s life in retirement. Any risk to them needs to be taken very seriously. As well as the important protections offered by the careful identification verification and consent measures, one potential mitigation for the inherent risk of bringing pensions data together and making it easily accessible is to seek to inhibit individuals from exporting their data outside of the dashboard environment. This export might include the movement of data to another area of the dashboard provider’s systems, so it can be used in different ways; to another organisation entirely; or to the individual themselves. Preventing individuals from exporting their data off the dashboard may provide an element of friction so that less well-considered actions, or actions taken in the absence of sufficient information, would be more difficult to make, because data would need to be manually copied across from the dashboard rather than being facilitated electronically. The prevention of exports may also reduce the risk of scams or other malicious activity, for the same reasons.

29. However, such a restriction is not necessarily desirable. We are keen to ensure that dashboards provide the opportunity to foster innovation. We will consider whether to increase dashboard functionality as both technology improves and understanding of how to maximise user experience develops. Whilst we believe that it is important in the early roll-out phase for dashboards themselves to present a consistent view of the view data (by restricting manipulation and processing, for example) in order to build trust and understanding, we believe that many dashboard providers will also wish to explore other ways of presenting and using data, so, if a user wishes to, they may request for their data to be exported to another area of the dashboard provider’s website.

30. Similarly, we understand from the experience of pensions dashboards in other countries – that people may wish to make use of their data away from dashboards. We support the principle of individuals having access to, and control of, their data, but we also recognise that the potential for dashboards to enable export, as well as bringing benefits, also brings the increased potential risk of imprudent decision making or exporting to potential scammers. We want to ensure that these risks are managed and mitigated where possible.

31. In our view, any transfer off a dashboard but within the systems of the QPDS operator, would require that the dashboard itself is no longer visible: in other words, it must be clear that the individual is no longer looking at his or her dashboard, and that the data has moved away (and therefore, the regulatory control has changed). In this case, a clear risk is that while value data will be presented on dashboards without manipulation and with all the appropriate messaging, that is no longer the case once the data moves away from the dashboard itself. We consider that MaPS design standards could require the presentation of messaging at the point of export that would communicate these risks and provide clear and prominent warnings.

32. We consider that some mitigation of consumer risk if QPDS choose to offer data export, could be achieved through a combination of MaPS design standards and, where appropriate, any relevant FCA rules. Standards and rules will be developed further as the programme progresses, and will reflect responses to consultations, but these mitigations may include the following:

a. MaPS design standards, and any relevant FCA rules, may require that people be presented with clear warnings if they are provided with the option to export their data – whether that be to another area of the dashboard provider’s site, to themselves as an individual, or to another party.

b. MaPS design standards and any relevant FCA rules may work together to ensure that any export function a dashboard provider may choose to make available upon request on the dashboard, is placed in an appropriate manner and with the appropriate prominence.

c. MaPS design standards and any relevant FCA rules may set out what can and cannot appear on or around a dashboard.

33. Dashboards will only show high-level value data, so the potential for it to be used directly by a third party is, to an extent, limited, although clearly, the potential for others to act outside the best interests of consumers may be raised even with access solely to this high-level information.

34. FCA regulation already applies to personal recommendations/investment advice and there are existing FCA requirements around DB transfer advice. The recent scams provision in the Pension Schemes Act 2021 also seeks to combat pension scams by providing due diligence measures and issuing members warnings of high-risk transfers. If the data were to be used as part of any of those activities, then that would come within the purview of the existing regulatory authority. There is a residual risk that a dashboard provider or other party might stray into carrying on regulated activities for which they do not have the correct FCA permission. If a QPDS carries out a regulated activity for which they do not have the correct permissions, the FCA can de-authorise them. We acknowledge that there is a residual risk though, that exports from dashboards may increase the potential for individuals to be adversely impacted by organisations acting outside of regulatory authority.

35. We are very aware of the importance of protecting individuals and acknowledge the potential risks that could be brought about by the proposals set out in this section: in particular, decisions made in haste or on the basis of incomplete information; and the risk of exporting data to a potential scammer or other malicious actor. However, we think that there are many benefits to be had, in terms of user experience and innovation that exporting data would bring.

36. We are keen to understand your view of the potential benefits and possible consumer risks that data export could give rise to. We invite you to share with us early ideas as to what protections could be put in place to protect consumers from harm if data export were to be permitted. We would like to share your responses with the FCA.

Delegated Access

37. The pensions dashboard model will support the advice and guidance process by providing delegated access on the government and commercial dashboards. We are proposing in the Regulations (regulation 7(5)(b)) that QPDS may allow delegated access on the dashboard. This is so individuals can give regulated financial advisors, MaPS guidance specialists, and others considered by MaPS to be appropriate, direct access to their pensions information. This can allow individuals to seek advice about their pensions from an authorised person who has the relevant permissions to give pensions advice.

38. The current Regulations propose that a dashboard may offer delegated access only to defined groups, as a means of ensuring that the delegate function is delivered by people who are appropriately qualified. This is set out in regulation 7(8) as:

a. MaPS Guiders, who, as part of the government’s MaPS, can provide guidance to individuals based on their view data and state pensions data;

b. A person with permission to advise on investments as referred to in article 53(1) of the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001- who can provide further pensions advice and guidance to individuals. Not all independent regulated financial advisors will have the correct permissions to offer pensions advice which is why we have specified that only those with this specific permission may be a delegate;

c. A person with permission to advise on the conversion or transfer of pension benefits as referred to in article 53E of the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001; or

d. Another person whom MaPS considers appropriate. This will allow further groups to be added, as testing builds an understanding the needs of dashboard users.

39. As part of the requirements that will be put in place that aim to protect individuals, the specified delegates will be put onto the Governance Register and will go through a similar consent and authorisation process to access an individual’s dashboard. The consent for an authorised delegate to access an individual’s dashboard can be revoked by the individual at any time.

40. We have proposed that QPDSs may offer delegated access, rather than must. This is, in part, because we do not wish to introduce more potential barriers to entry for potential dashboard providers than necessary. The dashboard provided by MaPS will provide delegated access, so individuals who want to make use of a delegate – or advisors who offer such services – will have that option available.

Reporting and monitoring requirements

41. We are proposing that the Regulations will require QPDSs to provide MaPS and the regulators with information relevant to their functions (regulation 10). This would allow MaPS and the regulators to monitor compliance of pension schemes and dashboard providers with their dashboard obligations, including providing the view data. The information may be required on request or on a routine basis.

42. Regulation 10 would require QPDS to report back to the regulators to ensure that the dashboard is providing the service it was designed to do. Reporting is one of the operational functions of a dashboard. By compelling a dashboard provider to report back, it will keep the activity of the ecosystem transparent to all parties involved.

43. QPDSs would have a duty to support DWP with collecting research data from people using dashboards to assist with the evaluation of the dashboards service (regulation 10(2)(C)(iii)). Alongside this, we are proposing placing a requirement on QPDSs to report analytical and statistical information, and information on performance, to help the running of the dashboard and maintain a quality service (regulation 10(2)(C)(i)). Placing these requirements on QPDSs allows MaPS to identify any problems with the dashboard which may need to be resolved. In addition, while we anticipate that most of the monitoring of the compliance of trustees or manager’s compliance with their duties will be done through the ecosystem, there may be cases where the regulator requires certain information from QPDS to support its compliance functions. The requirement to report therefore includes an information requirement by the regulator.

44. Proposed Regulations will set out the duties on reporting, and standards will provide the detail that dashboard providers would need to follow in complying with these reporting duties. This enables MaPS (and where required, TPR) to exercise a degree of flexibility around the detail of the requirements so that they can be iterated as the experience of delivering dashboards increases over time.

45. QPDSs would be monitored on their performance. The exact details of what performance-related activities will be monitored will be set out in the service level standards. This would include monitoring the dashboards for things such as failed requests and downtime. MaPS will be able to automatically detect any failure to adhere to technical, connection and security standards and this would result in immediate disconnection from the digital architecture meaning that a QPDS will no longer have qualifying status.

46. Adherence with certain standards – design standards in particular – requires a degree of judgement, and we are proposing the utilisation of an approach whereby a trusted and independent professional third party is engaged by the dashboard provider to provide – ahead of connection, and on an annual basis thereafter – assurance to MaPS that the QPDS is compliant and design standards are being adhered to.

47. The trusted professional (regulation 12) will be looking at whether the dashboard is compliant with the standards set out by MaPS, most notably the standards where non-compliance cannot be automatically detected, such as the design and reporting standards.

48. This audit would alert dashboard providers to any issues with their delivery approach so that those matters could be rectified. The dashboard provider would then be expected to provide MaPS with the assurance that their dashboard was compliant. If dashboard providers were unable or unwilling to resolve issues, then the auditor would need to report that to MaPS.

49. MaPS can then rely upon this information when confirming to the FCA that the QPDS criteria are met. We do not think we can be definitive enough in the Regulations to stipulate who these trusted third party professionals may be but instead we will refer to standards/guidance where this will be set out. We envisage that this trusted third party professional will be an individual who will be independent from the dashboard provider.

50. We are keen to gather views on this approach from potential dashboard providers and others with an interest. We are particularly keen to receive views on:

a. The deliverability of such an approach.

b. The availability of relevant organisations to deliver such an audit.

c. The degree of assurance that individuals can take from this third-party audit approach.

d. The extent to which liability is or should be transferred to the third party by their assurance of compliance.

e. Who should be this third-party trusted professional to carry out the assessment on dashboards compliance with design and reporting standards.

51. The regulations as currently drafted provide a high-level provision for the third-party audit approach, but we anticipate that there will be further detail set out when regulations are amended ahead of laying before Parliament, to reflect the outcomes of this consultation.

FCA authorisation and the new regulated activity

52. During the passage of the Pensions Schemes Act 2021 through Parliament, the Government committed that the provision of a QPDS would be a regulated activity. A regulated activity is an activity of a specific kind which is carried on by way of business and that relates to a specified investment of any kind, as defined in section 22 of Financial Services and Markets Act 2000. The Regulations stipulate those providers of QPDS would need to be authorised by the FCA and have the necessary permission to carry out the regulated activity of providing a QPDS.

53. The Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 will be amended by Her Majesty’s Treasury (HMT); and will be made once dashboard Regulations have been laid before Parliament. This amendment would make the provision of dashboards a regulated activity.

54. Providers of a pensions dashboard would be required to obtain FCA authorisation once adherence to other requirements have been met. The FCA will then take the provider through the process of authorisation.

55. Once a dashboard provider is authorised by the FCA, it would be subject to FCA principles for businesses and the relevant FCA rules, including those that would be specific to QPDS that the FCA will consult on in due course. When a dashboard provider is FCA authorised, it will then have been granted permission by FCA to carry out the new regulated activity.

56. Once authorised and regulated by the FCA, the provider of the QPDS would be expected to comply with the framework of rules that apply to authorised persons, such as:

a. Principles for Businesses - the fundamental obligations that firms must always comply with as they conduct their day-to-day business – these include, for example, ensuring communications to individuals are fair, clear and not misleading; the threshold conditions that a firm must satisfy and continue to satisfy to be given and retain its permission; and

b. Rules about the organisational systems controls and compliance arrangements that firms should have in place to protect individuals and comply with regulatory obligations to them.

57. The nature of any additional dashboard-specific rules on which the FCA might need to consult may be informed by, among other things:

a. The emerging detail of the ecosystem design and build.

b. Its role in the areas of shared responsibility on which it is working collaboratively with Government, MaPS, and TPR.

c. PDP’s user research and prototype testing.

58. Where MaPS informs the FCA that a QPDS no longer has qualifying status the FCA can de-authorise the operator of the QPDS.

Dashboards Accessibility

59. Dashboards will make information about pension savings more accessible by providing a new, easier way for individuals to see their pensions information. The QPDS will be a voluntary service that does not remove the methods consumers can already utilise to obtain information about their pension savings. As a result, dashboards are expected to have positive social impacts for the people who use them.

60. Dashboards will simply facilitate the provision of information which consumers can already access by requesting a statement from their pension provider(s). Therefore, the premise of dashboards is not seen to be discriminatory and if for any reason an individual has no digital access, they will continue to be able to access the same service as they had previously, such as receiving benefit statements annually or on request.

61. Most respondents to our 2018 pensions dashboards consultation suggested that dashboards should cater for people with protected characteristics. Some respondents also highlighted the consumer benefits of dashboards in tackling accessibility, with consumers having their data automatically gathered for them. Therefore, dashboards can provide a simple solution for vulnerable savers who might find the paperwork involved in sending statement requests to their providers, if required, a significant barrier to engaging with their pensions.

62. We also noted the responses from industry to the Pensions Dashboards Programme’s ‘staging call for input,’ with some respondents flagging the importance of making dashboards easy to use to address the needs of those with limited digital capability and for those with limited digital access.

63. We recognise that it is important that dashboards are created with accessibility needs in mind to minimise the potential for exclusion, or detriment and with this, all efforts should be made to make dashboards as universally accessible as possible. Therefore, 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 and share key insights on user needs.

Consultation questions

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 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?

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?

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

a. The deliverability of such an approach.

b. The availability of relevant organisations to deliver such an audit.

c. The degree of assurance that individuals, schemes, and regulators can take from this third-party audit approach.

d. 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?

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 organisations 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?

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?

List of all consultation questions

We ask that you provide your reasoning for your answers to the consultation questions:

Chapter 1: Overview of Pensions Dashboards

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

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

Chapter 2: Data

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 concern?

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 scheme?

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 to individuals in these circumstances?

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?

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?

Question 8: Would provision of an alternative, simplified approach to calculating 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?

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 purposes of dashboards and 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?

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?

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 a feasible approach? Do consultees believe it is the correct approach in terms of user experience?

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?

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?

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?

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 Dashboard programme?

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?

Chapter 3: How will pensions dashboards operate? Find and View

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?

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

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

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?

Chapter 4: Connection: What will occupational pension schemes be required to do?

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

Chapter 5: Staging – the sequencing of scheme connection

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?

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.

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?

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.

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?

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?

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

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?

Chapter 6: Compliance and enforcement

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

Chapter 7: Qualifying Pensions dashboard services

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 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?

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?

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

1. The deliverability of such an approach.
2. The availability of relevant organisations to deliver such an audit.
3. The degree of assurance that individuals can take from this third-party audit approach.
4. 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?

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 organisations 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?

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?

Annex A: Background

1. To produce the Regulations and detailed policy proposals set out in this consultation, we have, alongside our delivery partners, engaged extensively with interested parties since our initial period of public consultation.

2. The Government’s feasibility report and consultation^{[footnote 33]}, the response to which was published in April 2019^{[footnote 34]}, received 125 responses. It set out a policy framework and delivery model to deliver pensions dashboards in the interests of individuals.

The Pensions Schemes Act 2021

3. Following publication of the Government’s response in April 2019, primary legislation was introduced relating to pensions dashboards, in the form of Part 4 of the Pension Schemes Act 2021. This legislation amended the Pensions Act 2004 to enable the Secretary of State to make Regulations to require relevant occupational pension schemes to make individuals’ data available to the individuals via qualifying pensions dashboards services. It also amended the Financial Services and Markets Act 2000 to enable the FCA to make corresponding rules in relation to personal and stakeholder pension schemes.

4. In addition, the Pension Schemes Act 2021 amended the Financial Guidance and Claims Act 2018 to place a duty on MaPS to develop and host its own dashboard, which would show the same information that qualifying pensions dashboard services could provide. The Government also committed to provide for the introduction of a new regulated activity through which the FCA will authorise and regulate the operators of qualifying pension dashboard services (which is to be the subject of separate legislation).

Pensions Dashboards Programme (PDP)

5. The Government asked MaPS to convene the Pensions Dashboards Programme (PDP)^{[footnote 35]}, which is now responsible for the initial phases of development and implementation of dashboards. This includes the development of standards and delivery of the digital architecture that will enable dashboards to work.

6. The PDP is supported in its work by an industry steering group, which is comprised of stakeholders from across the pensions industry, including representatives from industry trade bodies, consumer groups and the financial technology (FinTech) community.

7. The PDP works in partnership with Government, TPR, the FCA and its wider stakeholder community to develop solutions in line with the legislative and policy framework set by government.

8. The dashboards will be provided by MaPS and the Government. However, in the longer-term the ownership of the infrastructure may not always lie with MaPS. The Government would look very carefully at any proposals for the longer-term ownership of dashboards, but this is not a matter for this consultation. Regardless, the Government is committed to a dashboard being provided by MaPS.

9. Since its creation, the PDP has made considerable progress in developing the digital architecture, designing solutions, and building the evidence base to support this work through an ongoing programme of research, including user testing. The programme reports on its progress every six months with the latest (fourth) report^{[footnote 36]} published in October 2021 confirming that dashboards should be available to the public from Phase 4 of the delivery programme, which begins in 2023.

10. The programme achieved a critical milestone on 6 September 2021 when it awarded the contract to build the digital architecture to Capgemini, in partnership with Origo. This marked the beginning of the programme’s develop and test phase.

11. Alpha testing (operational testing conducted by potential users, customers, or an independent test team at the vendor’s site) started in December 2021 and is running for a six-month period during which the programme is working with several volunteer pension providers, software providers, administrators, and prospective dashboard providers. The Department for Work and Pensions will work with the programme to test the State Pension data connection as part of this phase.

12. The Government, alongside the PDP and our key partners has engaged extensively with our stakeholder communities in the development of these proposals and the Regulations. We will continue to do so throughout the consultation period and into implementation. Following consultation on the Regulations, the Government will publish a response, after which the final version of the Regulations will be laid before Parliament for debate later this year.

Objectives of Dashboards

13. The Government is working with key partners to make pensions dashboards a reality. The Pensions Dashboards Programme (PDP) was established by the Money and Pensions Service (MaPS) to deliver the digital architecture that will enable dashboards to work. With them and our other key partners, The Pensions Regulator (TPR) and the Financial Conduct Authority (FCA), the Government is committed to ensuring dashboards are delivered successfully through industry, putting the interests of the individuals using them at the heart of their design.

14. Our shared vision is for pensions dashboards to enable individuals to access their pensions information online, securely, and all in one place, thereby supporting better planning for retirement and growing financial wellbeing.

15. We believe that in the long term, pensions dashboards could help with the following objectives:

a. Increase individuals’ awareness and understanding of their pension information and estimated retirement income to build a greater sense of individual control and ownership.

b. Reconnect individuals with lost pension pots, benefitting the individual and industry.

c. Increase engagement, with more people (regardless of their pension wealth) taking advantage of the available impartial guidance and financial advice.

d. Support the guidance and advice processes by providing people with access to their pensions information at a time of their choosing.

e. Enable individuals to make more informed choices in the decumulation phase (the point when a decision is made by an individual on how to access their savings) by making it easier to access some of the information on which to base these decisions.

Annex B: The Digital Architecture

1. Our three overarching design principles for the digital architecture will underpin the pensions dashboard ecosystem. These are to:

a. Put the consumer at the heart of the process by giving people access to clear information online.

b. Ensure consumers’ data are secure, accurate and simple to understand - minimising the risks to the consumer and the potential for confusion.

c. Ensure that the consumer is always in control over who has access to their data.

Key components of the digital architecture

2. The pensions dashboards digital architecture refers to the group of elements that make dashboards work. These include the components that MaPS is responsible for delivering, and which are outlined in more detail below:

a. The Pension Finder Service.

b. The Consent and Authorisation Service.

c. The Governance Register.

d. The Identity Service.

3. The digital architecture and its specific components are not referred to throughout the Regulations. Instead, the Regulations will refer to connecting to MaPS as the legal entity that is responsible for the digital architecture.

4. Capgemini in partnership with Origo will deliver the Pension Finder Service, Consent and Authorisation Service and the Governance Register on behalf of MaPS. A separate supplier is to be sourced for the Identity Service.

5. The UK Government has an ambition to make it quicker and easier for people to verify themselves using modern technology, with a process as trusted as using passports or bank statements. The Department for Digital, Culture, Media and Sport (DCMS) is developing the UK digital identity and attributes trust framework. In order to allow the Government more time to develop this trusted framework to verify people online, MaPS is in the process of appointing an interim provider on a two-year contract until 2023 when we expect the trust framework to be in place and take over.

Pension Finder Service

6. The Pension Finder Service is a piece of technology that sends out an instruction to all pension providers to search for a user’s pension. It has no direct interface with individuals to fulfil this function. The Pension Finder Service receives all its inputs from the Consent and Authorisation Service. This includes verified and self-asserted identity details and the relevant consent information.

Consent and Authorisation Service

7. The Consent and Authorisation Service initiates identity authentication and manages the consents and permissions for individuals using dashboards. It will enable the individual user to give and manage delegated access to relevant permitted others, in particular regulated financial advisers and guidance specialists from MaPS.

8. When an individual asks a dashboard to find their pensions, the consent and authorisation service within the digital architecture will check whether that person has already verified their identity. If they have not, they will be passed to the identity service to complete the process of verification.

9. Importantly, before a pension scheme confirms they have found a matching pension, they will need to interact with the Consent and Authorisation Service to ensure the person requesting the information has the appropriate permission to do so.

Governance Register

10. The Governance Register is a technical service that provides assurances that the different elements of the ecosystem (dashboards, identity services, Pension Finder Service and connections to pension schemes) meet the required standards to participate. It ensures that all these elements are connected to the digital architecture which is designed to be secure and allows access to be revoked if any party is found to be operating incorrectly. It will also enable compliance monitoring through the system.

Identity Service

11. The Identity Service will allow individuals to authenticate themselves so that they can access other elements of the ecosystem. It will work alongside the Consent and Authorisation Service to manage the initial verification of an individual’s identity (and authentication of individuals returning to their dashboard). It provides the verification required to assure trustees or managers of pension schemes that they are returning data to the correct person and no one else, following a matching exercise.

Pension Identifiers (PeI)

12. A PeI is a new concept, it is an identifier token for secure access.

13. The PeI is an identifier to the found pension and does not contain any information about the individual or the pension itself. It is a URI – Uniform Resource Indicator (a unique sequence of characters that works like an address or a postcode – telling the dashboard service where it needs to go to retrieve the pensions information) and identifies all separately identifiable pensions that an individual who submits a find request may have an interest in.

14. A PeI is the identifier of a specific pension and is used by pension schemes and DWP (in relation to the State Pension) to register a matching pension in response to a find request, and to enable the individual to request to see their pension information for that pension. An individual will get one PeI for each pensions entitlement. For example, where they have two entitlements under the same scheme, they will get two PeIs.

15. A PeI will be registered with the Consent and Authorisation Service. This is a crucial step in the process which ensures that pensions information is not shared with anyone who does not have permission to see it.

Annex C: Supplementary information

This consultation document indicates that there is significant supplementary information that will be released either now, or in the future to support pension schemes connecting to the digital architecture and providing the necessary data; and to ensure that dashboards present a trusted and clear interface with individuals’ pension value data. Below, we have outlined what information will be made available and when.

Data Protection Impact Assessments (DPIA)

• both DWP and MaPS will publish the appropriate elements from DPIAs that will identify how we intend to identify and minimise the data protection risks of pensions dashboards
• these will be published when the Regulations are laid in draft before Parliament. Some parts may not be published if, for example, they contain sensitive risk analysis

Regulatory Impact Assessment

• the Regulatory Impact Assessment will be a cost benefit analysis of the impact of the Regulations. For example, it will measure the costs to industry to provide the data, the costs to government of supplying the State Pension information and the costs to MaPS for providing the technical architecture. It may also set out and measure the benefits of dashboards, for example to consumers and the pensions industry
• given that the Regulatory Impact Assessment to be published by DWP covers the impact of the regulations, we do not believe that MaPS will be required to publish separately an impact assessment when they consult on the Standards which arise from regulations, since those costs and benefits will have already been covered
• the Regulatory Impact Assessment will also be published when the Regulations are laid

TPR compliance and enforcement policy

• this will set out TPR’s approach to regulating compliance with dashboard duties by trustees or managers and others involved in supporting them
• this will be consulted on by TPR once the Regulations have been laid

FCA consultation on rules

• the FCA draft handbook rules will outline the requirements for FCA regulated pension providers in respect of personal and stakeholder pension schemes. These schemes are not covered by the Regulations
• the consultation on these rules is planned to follow shortly after this consultation is published

Regulated Activity Order

• HMT will make the provision of a pensions dashboards service a regulated activity
• the FCA are to draft handbook rules on QPDS which are likely to be consulted on in Summer 2022

Standards

• as we outline in the consultation, there are multiple areas where the Regulations will refer to standards that need to be complied with
• standards to be published by MaPS will include: Connection and Security standards; Technical standards; Service and Operational standards; Reporting standards; Design standards; PeI (see glossary) standards and Data standards
• MaPS will publish standards for most of the above categories in draft, during this consultation. They will also publish more information on their intended approach to developing, consulting on and setting final standards, along with an indicative timeline
• we are currently working on the assumption that MaPS will have the authority to set standards after Parliamentary approval of the Regulations is sought in autumn 2022. MaPS plan to consult on the first suite of standards in the summer. This will enable them to publish a full, final and first suite of standards as soon as possible after Regulations are approved

Guidance

• TPR will provide a comprehensive package of guidance to support their regulated community in achieving compliance with new duties. This will include guidance on steps to take to prepare, and matching. TPR guidance will be published in 2022
• MaPS are committed in their published programme timeline of publishing technical guidance to support pension schemes’ technical development in winter 2021-22, and technical guidance for dashboard providers and design guidance for dashboard providers in early 2022. The draft data usage guidance published at the end of 2020 will also be updated
• MaPS will issue guidance around the process of connection, such as registering with the governance register in time, providing necessary information, whether to build or secure an API (Application Programming Interface) that meets the required standards and what testing looks like before connecting

FRC consultation on revisions to AS TM1

• the Financial Reporting Council will consult on changes to AS TM1 (see glossary) in their usual way and will refine it based on feedback from that consultation. Dashboards will then (subject to the Pensions Dashboard Regulations being approved by Parliament) begin to provide projected values, where Statutory Money Purchase Illustrations (SMPIs) have been provided on new AS TM1 methodology
• the FRC’s consultation is likely to be launched in the first quarter of 2022. It is likely that the scale of changes required may be greater than usual in light of the dashboards Regulations 

Annex D: Glossary

Key terms used in this consultation	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.
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.
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 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 2.
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.
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.
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.

Endnotes

1. Call for input on staging. ↩

2. Pensions and retirement: Help with pensions and retirement: MoneyHelper. ↩

3. Pensions dashboards: feasibility report and consultation. ↩

4. Money Advice Service. ↩

5. Pensions dashboards: Working together for the consumer. ↩

6. Research: Rapid evidence report: Pensions Dashboards Programme. ↩

7. Staging call for input summary: Pensions Dashboards Programme. ↩

8. Qualitative research with potential dashboard users: Pensions Dashboards Programme. ↩

9. Pensions dashboards: Working together for the consumer - Paragraph 86 – user needs. ↩

10. Figure 1, Page 8, Income Projections. MaPS PDP Phase One Report July 2021 - MaPS PDP Phase One Report July 2021 (pensionsdashboardsprogramme.org.uk). ↩

11. PASA announce Data Matching Convention (DMC) Guidance – The Pensions Administration Standards Association. ↩

12. Contracts: ICO. ↩

13. The Pensions Regulator: Data requests. ↩

14. The Pensions Regulator: Data requests. ↩

15. The Pensions Regulator: Data requests. ↩

16. Staging call for input summary: Pensions Dashboards Programme. ↩

17. Pensions Dashboards Programme signs up seven major data providers for initial dashboards testing phase. ↩

18. Pensions Dashboards Programme: Phase One Summary Research Report. ↩

19. Public service pension schemes: changes to the transitional arrangements to the 2015 schemes. ↩

20. The Pensions Regulator: Data requests. ↩

21. The Pensions Regulator: Data requests. ↩

22. The Pensions Regulator: Data requests. ↩

23. Pensions dashboards: information for data providers: Pensions Dashboards Programme. ↩

24. Record-keeping guidance for trustees and public service schemes: The Pensions Regulator. ↩

25. PASA: Data guidance. ↩

26. TPR DB research 2020 - Defined Benefit Survey; TPR DC research 2020. ↩

27. TPR DC research 2020
    
    TPR registry data 2021. ↩

28. TPR: Data requests. ↩

29. For Local Government Pension Schemes in England and Wales, it was from 1 April 2014, and for Civil Service by-analogy schemes, 1 April 2016. ↩

30. Public service pension schemes: changes to the transitional arrangements to the 2015 schemes. ↩

31. PDP qualitative summary report 2022 (pensionsdashboardsprogramme.org.uk). ↩

32. Pensions dashboards: feasibility report and consultation. ↩

33. Pensions Dashboards: Government response to the consultation. ↩

34. An introduction to the pensions dashboards ecosystem. ↩

35. Pensions Dashboards Programme: Progress update report. ↩