Pensions dashboards standards consultation response
On 19 July 2022, the Pensions Dashboards Programme launched a consultation on pensions dashboards standards, which ran for 6 weeks. We’ve now produced updated standards based on feedback received.
The Pension Schemes Act 2021 and the pensions dashboards regulations give authority to the Money and Pensions Service (MaPS) to set standards for the pensions dashboards ecosystem, relating to the practical operation of pensions dashboards services and the digital infrastructure needed to support them. The standards will provide the rules and controls that will facilitate the ongoing connection to the pensions dashboards ecosystem.
The consultation on standards ensured that colleagues across the industry could share their views on the proposed content and identify any further needs.
There were 56 responses received from a range of stakeholders, including pension providers, administrators and potential dashboards providers which the programme team have reviewed and considered and/or implemented changes to the standards and guidance.
It’s important to note that when the drafts were published in the summer, the documents were of different levels of maturity. This is reflected in the amount of changes which have been made to each. The specific updates are noted on the publication page for each document in a change log detailing the summary of changes.
Code of connection
Overall, respondents indicated the proposed requirements and service levels were reasonable and didn’t pose a problem.
The majority of feedback was around the view response times and the deadline for providing view information when a provider or scheme receives a request from a dashboard. In response to feedback that <2 seconds isn’t long enough to allow for retrieval of real-time value data, we’re extending the view response time to <10 seconds.
The other main point was around clarity needed on the availability requirement. Data providers must be available 99.5%, 24 hours a day, 7 days a week.
Further feedback on questions asked in the consultation:
Do any of the proposed requirements pose a specific problem for your organisation, if so, what?
The prevailing view was that the proposed requirements were sensible and reasonable. Fourteen of the respondents who answered this question said they did not expect any specific issues. There were requests for further clarification of requirements, and observations that it will not be until testing and practical implementation that this will be known, but there was no substantial disagreement in principle with the bulk of the proposed requirements.
Nine respondents flagged potential issues, the main issues raised related to the response time for return of view data (which they indicated was too demanding to allow return of real-time value data), and the service availability requirements (where respondents sought clarity on whether the requirement is 24/7 or business hours).
Are there any areas that you consider are missing from the code of connection?
Eleven respondents directly answered the question (most respondents gave more general responses, indicating areas where they were seeking further clarity, or flagged possible issues). We’ve acknowledged the need for further detail where clarification was required.
Do the proposed service levels seem reasonable for a digital service?
Again, 14 respondents’ responses to this question highlighted requests for more clarification on requirements or guidance on practical matters, rather than directly answering the question. Overall, the prevailing view in the consultation responses was that the proposed requirements were generally reasonable, with most respondents seeking clarification, rather than raising fundamental objections.
Eleven respondents directly answered this question of whether the service levels were reasonable for a digital service. Seven respondents said that the service levels were reasonable for a digital service and 4 said that they were not reasonable.
Respondents who indicated some of the service levels may not be reasonable offered views that the response times (especially response time for return of view data) were quite demanding and queried whether they could be met; that the availability requirement needs to account for patching/maintenance; and that pension providers and schemes with legacy systems may struggle to achieve the proposed levels.
Where respondents sought clarity on the service levels, this was in relation to what proportion of responses must be within the times indicated as well as whether the availability requirement was 24/7 or business hours only.
While we had feedback from respondents that the view response time was too short, we did not hear a similar message in relation to the proposed find response time. There were a couple of suggestions that it might prove challenging for exceptional cases, however, for the most part respondents did not indicate the proposed 60 seconds was unreasonable.
We’ve extended the ACK response time, from <1 second to <2 seconds – this is in response to not only consultation responses but also based on our operational experience with our early participants in the test environment.
We’ve clarified that for ACK responses and view requests, the requirements are that 99.9% are returned within the <2 seconds/<10 seconds time permitted.
We’ve clarified that the service availability requirement is 99.5%, 24/7. We’ve also clarified that this means 0.5% unavailability for whatever reason is permissible – including planned outages for maintenance and any unplanned outages. Pensions dashboards are a digital service, and the service is designed to be able to allow users to make use of dashboards at any time. Reducing the requirement to ‘core hours’ rather than 24/7, could have a significant impact on the user experience and the service reputation. In particular, since the scope of dashboards is pensions not yet in payment, most users will be in employment and need to access dashboards outside of normal working hours, so reducing availability outside of usual working hours would be detrimental to the user experience. The central digital architecture will similarly be available 99.5%, 24/7.
We’ve clarified that the requirement for processing find requests is <60 seconds, since we did not get substantial push-back on this, and finding pensions is designed to be an in-session user experience.
CoCo 2.1.3 requires view request responses within 2 seconds. This prioritises a fast response for the consumer. It may, however, create a barrier to calculating real time values for some providers. We would be particularly interested in views on this approach.
Twenty four respondents responded directly to this question. Responses to the consultation indicated substantial concerns about the view response time. Just 2 respondents directly indicated that the proposed <2 seconds response time was fine. Twenty two respondents indicated that this was too fast and would make return of real-time values impossible. This would essentially require a data lake architectural solution whereby pension providers would routinely bulk-upload static values and proscribe the use of API connectivity for ISPs to call pension providers’ platforms to retrieve real-time value data by performing fresh calculations at the point of the view request.
We’ve extended the view response time from <2 seconds to <10 seconds, in response to the consultation feedback that <2 seconds would unnecessarily rule out return of real-time values by means of APIs. This would instead force pension providers to pre-load static values into a data lake at, for example, an ISP. We are also conscious of the user experience and PDP’s qualitative research which indicates users expect the service to deliver pensions information quickly, if not instantaneously. While we recognise the need to extend the response time, so as to not rule out return of real-time value data, it is important we keep the time as short as possible. Consequently, we have adopted the time the feedback we had indicated was reasonable: <10 seconds. Where data providers do not use APIs to retrieve real-time values, the target view response time should be <2 seconds.
Other changes – to security standards
We’ve reduced use of encryption standard AES-256 for all data at rest to recommended guidance rather than a mandatory standard. A couple of respondents indicated it was too demanding a prescription and as data controllers for data stored within providers’ systems (as opposed to data in transit across the ecosystem between systems), it should be for providers to determine the appropriate level of security. We are therefore recommending but not requiring this encryption standard for stored data.
When we published the data standards for consultation, it was the most mature of the standards (first version published in December 2020), so no major challenges or changes were needed.
One main question we had on data standards was about the provision of a free text function. The majority of respondents didn’t want this, even those who did raised concerned about risks and there was no emerging consensus on how long it should be. We won’t be including this in the data standards.
Consultation responses pointed out a discrepancy between DWP and our position when it came to the classification of a user who takes an uncrystallised funds pension lump sum (UFPLS). Our draft standards indicated this UFPLS user should no longer be treated as a relevant member. DWP explained in their consultation response that the UFPLS user should remain as a relevant member. The issue related to the scope of users subject to dashboards, as only relevant members are subject to the requirements. Following discussions with DWP, we have removed references, from the data standards and data usage guide, to a user who has taken a UFPLS ceasing to be a relevant member.
Further feedback on questions asked in the consultation:
Are you confident that the proposed data standards adequately cover the benefit structure of all pension providers?
Almost all responses were positive to this question and no material changes have been made. However, some updates have been made in response to other commentary regarding schemes potentially entering wind-up or the Pension Protection Fund (PPF) assessment. The proposed standards set out in consultation had these scenarios as reasons for the schemes in question to not send any information back to dashboards and instead have the members contact them directly.
It has since been clarified that these members do need to be found and have information regarding their benefits displayed on dashboards. To cater for schemes in wind-up where it may not be appropriate to provide a pension value and PPF assessment schemes values are not provided, these 2 scenarios have been moved to the “Values unavailable” reasons within the Estimated Retirement Income (ERI) and accrued pensions sections of the standard.
Can it express the correct values to all savers? If not, please share a brief description of the relevant benefit structure?
The few examples provided were already supported by the proposed data standards and so action was not needed. However, some of the descriptions and covering guidance has been amended to remove any remaining ambiguity. In particular, references to hybrid or mixed benefit schemes.
Are the values allowed for the accrued (2.3xx) and ERI (Estimated Retirement Income) (2.4xx) warnings sufficient?
Eleven respondents expressed support for our approach. There was acceptance that a dashboard cannot hope to replicate every warning that an individual focussed benefit statement can in isolation. There was also support to say that too many warnings could lead users to not read the detail. Therefore, the balance of a controlled list of common warnings is seen by most to be the right approach.
In response to the consultation, further code options have been added. These include additional codes to recognise both divorce options, and the addition of codes for underpins and ‘scheme pays’.
Are there any other common reasons or scenarios you think these warnings should cover (bearing in mind we cannot support scheme-specific warnings).
We received a small number of additional scenarios from different sub-sectors of the pensions industry, and these have been taken into consideration.
Would the ability to add a short piece of free text to cover pension provider-specific issues be workable for you, or introduce a new burden? If so, how many characters would be required and what topics would it cover?
Responses to the idea of free text were mixed. Many recognised the advantage this could give over trying to define common codes and descriptions, but also recognised the overhead in trying to draft this text, maintain it and monitor its potential misuse. Thirteen respondents were not in favour of free text, and even those who saw the value in it recognised that it may be difficult to implement. The free text option has been ruled out as even the respondents who were in favour recognised the difficulties it would introduce in addition to the administrative and oversight burden.
Without a new unique reference to link two pension elements together, the benefit values may get presented separately in a dashboard. Would the requirement for a scheme to create that new reference and share it with their other administrators be more onerous than dealing with any potential downside from not presenting the benefit values together onscreen?
There was a very broad mix of responses to this point. Some recognised that they would prefer to ensure separately administered benefits in the same scheme are presented together. Others thought that as long as the part-schemes were suitably named, that it would not be too much of a problem if they were displayed apart. Most of these respondents would like to see further user research on this point.
Fourteen respondents were concerned that their AVC provider may be unable to add a new field to store the proposed new GUID field. This may lead them to conclude that the pensions may either have to be displayed apart, or they would need to introduce a new interface to allow AVC providers to send bulk updates of the required values to schemes, so both elements of the data are presented. A further group of respondents prefer this approach.
The proposed pension link item will remain in the standards to facilitate any one of the common options, rather than enforce a particular way of linking schemes, or choosing not to link part-schemes.
Therefore, the choices schemes have when considering split scheme administration scenarios remain:
- one scheme sends all of the related data to dashboards. This will require the other administrators to send their data to the “main” scheme; or
- all part-scheme administrators decide to respond to dashboards independently for each pension search. The regulated entity will then need to decide to either:
- create a pension link and communicate it to all of the other part-scheme administrators, or
- choose not to link and trust that the members understand the values they are presented with if the benefits are not shown together on a dashboard
Early connection guidance
Respondents were generally supportive of our proposed approach to dealing with the applications for early connection. Some small presentational changes, corrections, and clarifications (including the effect of early connection is to accelerate compliance with legal duties) have been made to take account of the responses received.
Further feedback on questions asked in the consultation:
Do you consider the notification requirement to be reasonable?
Of the 26 respondents, 24 agreed it was a reasonable period and, therefore, we are keeping the proposed period.
Do you consider the minimum requirement for at least a month’s extension (for schemes with an existing date) to be reasonable?
Of 23 respondents, 20 agreed it was a reasonable period and, therefore, we will not be amending our minimum extension proposals.
We didn’t receive any major challenges in the consultation on our draft reporting standards. The main feedback we received was about challenges to regular reporting of complaints – so we have reduced this to a record-keeping requirement.
We have also made tweaks to reflect the technical build and reduced the number of APIs.
Further details on topics raised during the consultation:
Comments on overall breadth of information required
Most respondents did not directly respond to the question about the overall breadth of requirements, but rather raised issues or sought clarity on particular requirements. Eight respondents indicated directly that the proposed breadth of the reporting requirements looked appropriate or reasonable, while no respondents stated that the proposed breadth was unreasonable or inappropriate.
Technical barriers to supplying the data
There were a number of responses, but most respondents didn’t directly answer the question. Of those who did, 3 respondents indicated they would not have any technical barriers and 2 said they would face technical barriers.
Frequency of reporting and burden of reporting
Some respondents questioned the frequency of the reporting requirements. Nine respondents either queried the value in daily reporting or raised concerns about how burdensome daily reporting would be (several more raised concerns, but only in reference to daily reporting of complaints data). Four respondents stated directly that they were happy with daily reporting.
A few respondents queried whether some of the proposed reporting data could not be captured by the central digital architecture at the point of interactions, rather than secondary calls after the interactions to report data. Also, whether some data could not be derived from other data already gathered rather than being reported directly.
Near real-time for audit and monitoring
Ten respondents said they could not see any barriers to providing audit information and monitoring near-real time, while just 2 said this could be unnecessarily burdensome.
The main challenge respondents raised in relation to the proposed reporting requirements was about recording and reporting complaints. Twenty three respondents raised concerns here. The most common concerns were:
- reporting complaints would be difficult to implement because complaints will be received via direct customer contacts and logged in scheme management systems. Complaints data could, therefore, be held in separate systems from the ISP solutions used for serving pension data to dashboards, and the ISP may not have direct visibility of complaints raised with the scheme. Frequent reporting of complaints data would therefore increase the burden on industry by requiring schemes to integrate scheme complaints recording and management systems with the ISP solutions, or otherwise regularly extract complaints data from their own systems to pass to the ISP for reporting to PDP. Several respondents indicated this would be operationally complicated
- complaints are already subject to other well-established existing regulatory recording and reporting frameworks, as well as dispute resolution routes via the Ombudsmen. It was suggested the industry, therefore, already has well-established complaints management, reporting, and audit processes external to the pensions dashboards ecosystem. Requiring reporting on complaints within PDP standards could therefore risk duplicating, cutting across or generally increasing the complexity of these existing processes and structures and regulatory requirements within the industry dealing with members’ complaints and disputes
- reporting complaints would need clearly defined parameters to be clear about when a complaint should be classified as pensions dashboards related
Standards governance approach
Respondents were supportive of our overall approach to our commitments for how we manage both standards and their change. Some presentational changes and clarification updates have been made in the light of the feedback received.
Further feedback on questions asked in the consultation:
Do you have any comments on the change process and timeframes?
Most of the respondents did not have any issues with the proposals and we are keeping them. This was qualified by a number of respondents who said they couldn’t comment without sight of what the changes are; however, most appreciated that we had provided them with a firm idea of what we classified as minor or major changes and what the change process would be. Only 5 respondents wanted longer consultation/notice periods and/or needed more detail.
Due to the feedback, we made a number of clarificatory changes:
- on the frequency of changes (especially in initial period for standards)
- when we will make urgent changes
- that each update will include an explanation of the changes made
- how we will involve the industry in the change process, whilst confirming that final decision on the change to standards rests with us
Do you agree with our definitions of major and minor changes to the standards?
Thirteen respondents suggested that we should consider the impact of changes at a scheme level. We don’t consider it is appropriate to consider the impact of the changes at such a granular level. If we did, then we consider that it is very likely that all changes we make would be considered to be major changes, even if for most schemes the changes would be minor. Nevertheless, we’ve clarified that we’re looking at the impact on most schemes.
Comments provided by respondents have helped us improve our lists of examples of what could be a major or minor change. We agree with the comment that the API change is not a minor change and have deleted this reference.
When making changes, we will engage with the industry and seek their feedback on how we classify changes and the appropriateness of our approach.
Are you clear on the differences between standards, statutory guidance and recommended practice?
Twenty eight respondents agreed with our explanations. However, a number of respondents made suggestions about how we could improve the language and presentation to make the use and status of our descriptions clearer. We have taken on board a number of those comments.
We have made minor edits to reflect changes in the build on the API specifications. No substantial changes to the requirements for providers and schemes.
Further feedback on questions asked in the consultation:
Overview guidance: do any of the proposed requirements pose a specific challenge for your organisation?
Thirteen respondents didn’t consider there was a challenge for them. A single respondent requested more detail. The rest of the respondents did not consider they could answer this question as their administrator providing dashboard services would be better placed to be able to answer it or it did not apply to them.
Six respondents made a few suggestions in respect of clarifications. We have made changes to improve the clarity. We have also deleted references to what pension providers and schemes could or must do to ‘hash’ searches to reduce the need for future searches. We agree this is not a topic that should be covered in the technical standards as it is a matter for pension providers and schemes considering their UK GDPR duties. Accordingly, we’ve made the relevant deletions.
API – are there any areas where further detail is needed?
The greatest number of comments (9 responses) highlighted the need for detail in other standards as well as requests for clarity and consistency which we’ve addressed. Five respondents confirmed they did not need further details or they thought it would be best for administrators providing dashboard services to review.
Of the rest of the responses the following related to technical standards and/or APIs:
- a request for the reporting API details, which is now covered in the reporting standards
- a request for details of the framework for how to transfer PeIs between pension providers and schemes at the consent and authorisation service, which is not a functionality currently being provided and can’t be provided without changes to the legislation
- asked for more detail in the examples to answer a range of questions. The examples illustrate how different aspects of the technical standards work. They are not to comprehensively answer every situation
- sought details of the JSON schema, which we are making available now the data standards have been finalised
API – do the proposed service levels seem deliverable for your organisation? 16 responses
Five respondents believe the proposed service levels are deliverable for their organisation, although 2 respondents felt that 2 seconds to return a response for the view request may be challenging. Two respondents to this question, stated this was not relevant to their business and was better being picked up by their ISP.
Technical – do the proposed timeframes seem reasonable?
We have combined the responses to these two questions as the totality of responses and the comments were almost identical.
Eleven respondents agreed they could deliver the service levels or thought the question should be best answered by administrators providing dashboard services. Most of the rest of the comments were more concerned with the service levels in the code of connection and not the technical standards. These were considered when reviewing the return periods and our modifications to the timings in the final code of connection.
A respondent considered the technical standards change approach would frustrate innovation. The technical standards can evolve over time with updated versions as we learn from the experience of running the pension dashboard ecosystem. It is important to baseline uniformity so we can run an interoperable ecosystem and without which there wouldn’t be any dashboards.
Technical – is there any more guidance you need in relation to these requirements?
The was a wide range of responses which we have considered when improving the presentation of the standards and which we will bear in mind for any future guidance.