​Proposed approach to collaborating with industry to deliver private sector dashboards

Introduction

The Pensions Dashboard Programme (PDP), as part of the Money and Pensions Service (MaPS), is making significant progress towards delivering pensions dashboards. More than 70% of memberships are now connected to the Central Digital Architecture (CDA), alongside the MoneyHelper Pensions Dashboard (MHPD), and small-scale testing is underway.

Collaboration with industry has been central to PDP’s delivery approach. The cornerstone of this has been the ‘industry participant’ approach. This involved a group of 20 or so industry participants – those organisations who are connecting directly to the CDA as, or on behalf of, pension providers and schemes.

This approach enabled early reviews and iteration of standards and processes, leading to successful connection to the CDA and ultimately the connection of millions of pension records.

Delivering private sector dashboards

PDP’s immediate focus remains the successful connection of providers and schemes and the support of the end-to-end testing process. Nevertheless, we are committed to ensuring that private sector dashboards (PSDs) will be delivered.

The rationale for PSDs is settled, and the Financial Conduct Authority (FCA) and the Department for Work and Pensions (DWP) have both set out the parameters of their operation. PDP has engaged with industry to understand how they might develop PSDs within those parameters and some of the business and operating models that might be employed.

PDP are looking at how to best support the delivery of private sector dashboards, including how to best apply the industry participant approach.

There are many similarities to the connection of providers and schemes, but also some key differences. We want to engage with industry on how the best features of the industry participant approach can be used to develop our operating model for PSDs.

Views are welcome from all parts of industry and other interested parties, in particular:

• organisations who are considering becoming a pensions dashboard operator
• organisations who intend to support others in bringing a pensions dashboard to market, including technology providers
• organisations who are part of the existing industry participant group

The proposal

This document sets out:

• the policy, legislative and regulatory and operational context of PSDs
• how the existing industry participant group has operated to support the connection of pension providers and schemes
• considerations for the application of the approach to PSDs
• a suggested proposal
• how to respond to this proposal and how we will use the information

Timing

Private sector dashboards

Policy background

Pensions dashboards will allow individuals to see their pensions information, including their State Pension, in one place online at a time of their choosing. The aim is to help reunite savers with lost or forgotten pensions and increase in individuals’ engagement to support better retirement planning.

As well as the MoneyHelper Pensions Dashboard (MHPD), delivered by the Money and Pensions Service (MaPS) on behalf of the government, the intention is for other organisations to be able to operate pensions dashboards. This is to extend the potential reach of dashboards by positioning them in digital spaces already frequented by users, and to enable them to be tailored to users’ needs. The central digital architecture (CDA) being delivered by PDP is therefore designed to enable multiple dashboards to operate.

In October 2024, the Minister for Pensions announced that the MHPD would be launched first, with private sector dashboards to come later, providing the opportunity for learning from MHPD and enabling PDP to prioritise the connection of providers and schemes and the launch of the MHPD.

The Minister for Pensions has reiterated the government’s commitment to PSDs and PDP continues to prepare the infrastructure for their connection and launch.

The legislative and regulatory environment

To operate a PSD, organisations need to:

• be or become authorised by the FCA, get permission to undertake the new regulated activity of operating a dashboard, and meet the FCA’s requirements for firms undertaking this activity
• comply with requirements for Qualifying Pensions Dashboard Services (QPDSs), as set out in Part 2 of the Pensions Dashboards Regulations and the Pensions Dashboards Regulations (Northern Ireland)
• comply with standards to be published by MaPS, with powers delegated by the dashboard regulations, covering connection, technical and security requirements, reporting, and dashboard design
• procure an independent audit of compliance with the requirements in the regulations (including the delegated MaPS standards), ahead of connection and annually thereafter

PDP is not seeking feedback here on the approach set out by DWP and FCA, who have already consulted widely before finalising their requirements.

Architecture

Like pension providers and schemes and the MoneyHelper Pensions Dashboard, PSDs will become part of the pensions dashboard ecosystem and will need to connect to the central digital architecture (CDA) provided by MaPS, in compliance with standards published by MaPS.

The following is a high-level summary of how users interact with PSDs and how their pensions information is retrieved:

1. A PSD user will begin their journey on their PSD of choice.
2. The user will then be directed to the CDA’s consent and authorisation service and identity service, which will enable them to verify their identity and provide details which will be used to match them to pensions.
3. The pension finder service then sends this ‘find data’ to pension providers, schemes, and DWP for the State Pension. This data is not stored in the CDA.
4. If a match is made, pension providers and schemes will register this with the CDA. The PSD will be able to retrieve their pensions information (‘view data’), directly from pension providers and schemes, and DWP, for display to the user.

The PSD may be delivered via an app or web page, but the interaction with the CDA, and the user journey, remains the same.

Potential operating models

The FCA’s rules for pensions dashboard services set out different models by which a dashboard might be brought to market. These are:

1. The firm authorised to operate a dashboard does so alone.
2. The firm authorised to operate a dashboard is supported to do so by another party in a contractual relationship relating to specific discrete functions (such as elements of technology) but maintains control and decision-making.
3. The firm authorised to operate a dashboard provides another firm with exclusive access to their dashboard, maintaining control and decision making themselves, and ensuring that this is clear to the user. This model is described as ‘third party dashboard arrangements’ in the FCA rules.

The locus of control is the critical element in terms of the regulatory position of the operators, but in terms of delivery and the need for interaction with PDP, there may be more than one party involved.

The FCA’s rules enable PSD providers to offer users additional ‘post-view services’. These would enable dashboard users to further engage with their found pensions and support retirement planning. Such services would be non-transactional, but could be chargeable subject to the fair-value requirement under the Consumer Duty. A post-view service could be pre-populated with dashboard data where the user has given consent for their data to be exported.

User experience

As with pension providers and schemes, operating a PSD involves the technical process of connecting to the dashboard ecosystem and transacting information. In addition, it involves developing a front-end user interface, which might be a webpage or app.

The design and functionality of that user interface will need to:

• be compliant with DWP’s regulations
• receive view data in the format prescribed by the MaPS data standards
• translate this data into a meaningful display for the user in accordance with the MaPS design standards and with FCA’s rules

It will need to be user tested – a requirement both of the FCA and of the draft design standards published by MaPS.

The industry participant approach

The industry participant approach involves a group of industry organisations working in close collaboration with PDP, following agreed ways of working. It enables dialogue between PDP and industry, allowing organisations to test and shape requirements or processes early on, benefiting programme delivery and industry’s ability to plan successfully.

Applying the approach to connection of pension providers and schemes

This approach has been successfully applied to a group of around 20 organisations who are either facilitating the connection of pension providers and schemes to the pensions dashboards ecosystem, or connecting directly. This group have worked closely with PDP throughout the technical development of the ecosystem, and were previously known as the ‘voluntary participant’ group.

The group does not include:

• providers and schemes themselves, unless they are connecting directly (where PDP has needed to engage with the providers and schemes specifically, they have been able to do so via the industry participants, or via other means, including the regulators)
• other stakeholders, such as industry bodies, prospective private sector dashboard providers, and other interested parties (PDP convenes other forums to support engagement with these groups)

Despite there being around 3000 providers and schemes in scope of the regulations and rules, the vast majority are not connecting directly and will connect via one of around 20 third parties. In most cases, these third parties also manage matching and providing information back to dashboard users. These third parties may be an integrated service provider (ISP) or a third-party administrator (TPA). While the trustees and managers of the providers and schemes are ultimately responsible for complying with the requirements in the regulations/rules and MaPS standards, they will do so primarily via these third-party organisations who act on their behalf in a supplier relationship.

Because this relatively small group is fulfilling the bulk of the requirements placed on the trustees and managers of pension providers and schemes, and have the technical capability needed to do so, it has been possible for PDP to develop close working relationships beneficial to PDP and industry participants.

How it works

The group was initially formed following an industry engagement exercise, covering all parties intending to connect directly to the CDA. The group remains open to others, pending agreement to the terms below.

To support the group’s successful operation, members agree:

• a framework agreement, which sets out the arrangements for connecting to the CDA and the terms under which members will collaborate with, and provide assistance to, MaPS and any other members of the group for the purposes of enabling MaPS to deliver the programme
• a non-disclosure agreement, to facilitate open conversation between parties and with PDP

The group also operates under a terms of reference which sets out its aims, membership, roles, and ways of working, including meeting frequency.

Members engage through a mix of group meetings, one-to-one sessions with PDP colleagues, and access to the support ticketing system (Jira) to log queries and ask questions.

Benefits of the approach

The industry participant relationship has been critical in the progress made to date, bringing benefits to PDP and to industry.

For PDP, it has enabled:

• ongoing engagement with a very knowledgeable and responsive group of industry experts
• the iteration of standards, scrutiny of drafts, testing and refinement ahead of publication (these standards included the API specifications which were necessary to enable the exchange of information between ecosystem participants)
• support with the building and testing of the CDA
• collaboration on production of guidance documents
• support with end-to-end testing of the dashboard service
• the ability to test, learn, and iterate the connection service with a small number before confirming the process and rolling out and then supporting connecting parties through the connection process
• insight and intelligence to inform industry engagement and support
• understanding other industry priorities, to help inform the timing and release of information
• oversight of industry communication and publications

For industry participants, it has enabled:

• early sight of developing standards, guidance, and connection service processes ahead of publication, enabling build work to commence ahead of publication
• opportunity to feed back issues and contribute to the drafting of requirements, ensuring a proportionate approach that did not introduce undue burdens
• connection activity to be supported more closely than it might otherwise have been in a more business-as-usual context
• an ongoing view on progress in the programme, to support business planning
• resource planning for different phases of the project
• publication of information and insights for trustees and members

Applying the industry participant model to private sector dashboards

Although there are similarities between the connection to the ecosystem by pension providers and schemes and the requirements for private sector dashboards, the differences mean that consideration needs to be given which elements can be applied and what changes might be needed.

Purpose and scope

Like pension providers and schemes, PSD operators must connect to the pensions dashboards ecosystem and transact data, in compliance with standards.

PSD operators must also deliver a user-facing front-end, governed by FCA rules and DWP regulations, and following the design standards published by MaPS. The design standards will be finalised with input from industry, and user-testing may need to be supported or facilitated by PDP.

This means that the scope of the PSD group is likely to need to be wider than that of the group involved in connection. The aims of the PSD group may be to:

• support the iteration of standards, including the review, testing and refinement of drafts of relevant standards, including the design standards, which are exclusive to PSDs, and security, technical, connection and reporting standards (such standards exist for pension providers and schemes, but equivalents will be developed for PSDs, including API specifications which will support PDP delivery while enabling industry to provide feedback and make progress with development work)
• support PDP as it ensures that the CDA includes all the necessary functionality to support multiple dashboards
• allow PDP and industry to collaborate on the development of guidance that explains processes and requirements
• support development of the process of PSD connection, including the incorporation of new stages such as user testing and the third party audit; and interactions with the FCA’s authorisation process
• provide support on interpretation of data and design standards and sharing of best practice
• help PDP understand and develop the support model needed for PSD operators
• help PDP understand and incorporate any necessary changes to the support model for dashboard users
• ensure that industry is closely involved with progress in the programme to support its own business planning
• develop the approach to user-testing of PSDs, including the potential use of synthetic and real user data
• support end-to-end testing of dashboard journeys which include PSDs

Membership of the group is not a pre-requisite for becoming a dashboard operator and does not represent the start of the connection journey. Similarly, it does not guarantee a successful application to the FCA for authorisation/permission. The proposal set out here is primarily focused on the development of the processes and requirements which will be necessary to connect to the dashboard ecosystem and operate as a PSD. Nevertheless, participation in the group is likely to provide prospective PSD operators with insight which may be a factor in the speed at which they can develop their dashboards.

Operating models and regulatory locus

As described above, the different operating models for PSD operators may involve connecting directly or entering into arrangements with others to do so on their behalf. There is potential that one connecting party, or one party providing front-end solutions, might act in a working group on behalf of multiple dashboard operators. On the other hand, the requirement that the regulated party retains clear control and decision-making means that more than one party needs to be involved for a single dashboard connection.

For PSDs, there may be more variation in the level and type of activity that might be contracted out to another party. Because PDP’s role potentially extends beyond facilitating technical connection and testing of information transactions, and includes support of front-end user testing, it may be necessary to extend the scope of the group to more than one party responsible for a single dashboard.

We would particularly like to gather views on the operating model where a regulated dashboard operator provides access to their dashboard to another organisation’s members. It may be that only the regulated operator need be part of the group in these circumstances.

As with the connection of pension providers and schemes, PSD operators are likely to work with suppliers who do not interact directly with the pensions dashboards ecosystem and, therefore, do not need to join the industry participant group. For example, suppliers of internal technology.

Coverage

The existing industry participant group for connection of pension providers and schemes represents total or near total coverage of the group of parties who will be connecting as, or on behalf of, providers and schemes. This comprehensive coverage was not intended by design and has not been critical for the functioning of the group. However, high coverage has been helpful in that is has enabled comprehensive collaboration, and allowed PDP to manage connection across these schemes in a single, staggered, cohort, which is effective and efficient.

Comprehensive coverage is not required for the PSD group, but there may be benefits to ensuring that a range of organisations, different operating models, and different suppliers are represented.

There is no legal obligation for any party to become a PSD operator, and for those intending to do so, there is no legislative deadline to connect, and so it may be less likely that such coverage is achieved. There may be commercial or other incentives for prospective PSD operators to be part of the group, including helping their development and preparation activity. However, membership of the group does not guarantee authorisation by the FCA.

Depending on the size and make-up of the group, it may be necessary and more efficient (both for PDP and for industry participants) to engage smaller sub-groups for specific activities. These might include supporting early-version developments of products or testing of processes, for example, where the make-up of the groups might be dependent on the specific task at hand.

Preparedness

While there were different levels of interaction with the programme before the existing industry participant group was convened formally, the level of understanding of requirements and development undertaken was somewhat uniform, in part driven by the need to prepare to meet a statutory connection deadline.

For prospective PSD providers, levels of engagement, understanding and development are currently very mixed. As a fixed timetable cannot be provided yet, some organisations are not yet committing resource, while others have invested significantly over a long period. A working group will either need to manage these different levels of engagement, or provide some support to ensure that all members are able to actively contribute.

Commercial concerns

For the existing industry participant group, ISPs are providing a commercial service, meaning that they are direct competitors for the business of providing services to pension providers and schemes. This means that the group has needed to be sensitive to commercial concerns, with a need for fair treatment and some formal structures in place to avoid unfair commercial advantage and to allow organisations to be able to contribute freely. It is likely that we might seek to replicate some of that best practice here, including the use of framework agreements and non-disclosure agreements.

Alternative approach

An alternative approach has been proposed which focuses on the requirements relating to API specifications. In this ‘API-first approach’, MaPS would develop and publish the API infrastructure, largely based on the connection of the MHPD, which has already taken place, and make available a sandbox environment. It would then enable a market to develop organically because developers would be able to build out from existing infrastructure, and along the way create expert communities.

Our view is that there are a number of lessons that PDP can take from this approach, particularly in the context of building on the existing infrastructure developed through the connection of MHPD. PDP is reflecting on this as we plan our work. Nevertheless, we believe that there remains a central need for systematic engagement between PDP and the industry, given the range or activity needed to bring PSDs to market, including PDP’s own work to develop CDA functionality, the need to manage the connection journey; and the work needed to finalise and agree design standards.

Proposal

Based on the existing industry participant model, a working group for PSDs might look as follows. We would welcome views, as set out in the questions contained in the survey.

Proposed approach

• The industry/voluntary participant engagement model has been a successful approach to enabling PDP to collaborate with those who are actively involved in supporting providers and schemes to meet the duties in the dashboard regulations and Financial Conduct Authority (FCA) rules.
• Our proposal is to set up a group which replicates this model to support the delivery of Private Sector Dashboards (PSDs)
• We would like to take lessons from an API-first approach, but believe that a wider industry engagement is still important in bringing together all elements of work necessary to bring PSDs to market.

Proposals for membership

• The group should only include those who are, at the time of setting up, actively planning to operate a dashboard, either themselves or in collaboration with others who have touchpoints with PDP.
• This may mean that a) more than one party is part of the group on behalf of a single dashboard; and b) one party would be involved with delivering more than one dashboard.
• Those who are suppliers, but who do not have direct ‘touch-points’ with PDP are not included. For example, there may be a party who is providing a secondary technology or infrastructure service as a secondary supplier who need not be involved; but conversely, a supplier who is involved in the development of a user-facing front end may need to be part of the group as they will need to be involved in testing.
• Those who change their plans and decide not to pursue a dashboard should not remain a member. The group may accept members who enter the market later. PDP will be the decision-maker.
• Other forums will be convened for strategic-level input and for information-sharing.

Proposals on activities and scope

It is proposed that the following activities and scope be included in the remit:

• Support the iteration of standards (all standards including design standards) and guidance: scrutiny of drafts, testing and refinement.
• Support PDP as it develops central digital architecture (CDA) functionality to support multiple dashboards.
• Support development of the process of connection, including the incorporation of new stages such as the FCA authorisation process, the third party audit, and user testing.
• Facilitate user-testing of PSD front-ends, including, potentially with synthetic and real user data.
• Provide support on interpretation of data and design standards and sharing of best practice.
• Enable end-to-end testing of dashboard journeys which include PSDs.
• Help PDP understand and develop the support model needed for dashboard operators.
• Help PDP and MaPS understand and incorporate any necessary changes to the support model for dashboard users.

It may be necessary to engage smaller sub-groups for specific activities. These might include supporting early-version developments of products or testing of processes, for example, where the make-up of the groups might be dependent on the specific task at hand.

Proposals on ways of working

• PDP and MaPS will provide some early information sessions to ensure that all parties have sufficient knowledge and understanding to participate fully from the outset.
• A terms of reference will be drafted to set out expectations of all parties relating to meeting style and frequency and ways of working.
• PDP will engage regularly and share materials at a formative stage.
• Group members will seek to provide timely input and support.
• The model of governance used for the existing Industry Participant group – including a framework agreement and NDA will be replicated here to facilitate effective working and free flows of information.

How to respond

We are keen to get your input as we develop our engagement approach. Please respond to as many questions as you can. If you are an existing industry participant or another interested party, and are not intending to provide or support provision of a PSD, not all questions will be relevant, but we welcome your opinions and any reflections on the current process.

How we will use your information

The information you send to us may need to be passed to colleagues within PDP/MaPS. It may be published in a summary of responses received. We may also share information with our key working partners: the FCA, the Pensions Regulator (TPR) and the DWP. Also, 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 this exercise, 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.