This was the second in a 3-part series of webinars to support our consultation. This webinar focused on connecting to the ecosystem and the standards and guidance pension providers and dashboards providers will need to be able to connect. We introduced the code of connection (comprising of the security, service and operational standards), the technical standards, the connection process and guidance for pension providers and our guidance for early connection.
These Q&A’s detail the questions asked by attendees and the answers given by the panel during the webinar.
Who’s responsibility is it to provide the reporting data?
The regulated firm/scheme, however in practice this will likely be provided on their behalf by the third party who provides their connection to the ecosystem.
Why can the central digital architecture not provide this information?
In some instances this is because the data is only known by either the QPDS or data provider in other instances this is to complete an audit trail.
Will there be a need to retain data at either the dashboard or the data provider?
The simple answer is yes, where data is not routinely required, but might be requested later under the reporting standards. However, note that no pensions data is retained at the dashboard – they may store the data temporarily only, for the purpose of display to the user in a single session.
Will you be running a consultation on the design standards as well and if so when will this be?
Yes, we will. Later this year and to coincide with or shortly after the FCA consultation on dashboard rules.
Will pension providers be compelled to supply data to all eventual dashboards?
Yes, any dashboard that is connected to the digital architecture – and therefore meets all of the conditions to be a dashboard and is authorised and regulated by the FCA – and here the user has provided their authorisation.
Do all dashboards need to follow the same standards? Do you have concerns about differences in appearance across different dashboards?
The standards will apply to all. They provide a minimum and consistent display experience and protection but leave enough room for dashboard providers to be able to adapt them to suit how they communicate with their clients (eg tone and branding).
On the data standards, 2.104 states Conditional – if this is available it should be provided (administrator email)?
Conditional means that if you’ve got it, then you must provide it.
Thanks for all the publications and these webinars. The design standards call for input is silent on displaying a rough and ready total estimated income, which we know consumers want to see – probably the MAIN thing most want. What is PDP’s thinking on this? I know it’s problematical.
The design standards are intended to be facilitative. We’re open to the view information being published in a tabular or illustrative form. This leaves rooms for dashboards to give a running total, if they think this is appropriate. If you think there are restrictions we should add, or explanations, then we’d be interested in hearing them and we’d consider how to include in the final document.
Are you able to confirm what has changed between the recently published data standards and the draft standards released in January?
Yes. We’ve published a summary of changes on our data standards page.
My worry is most pension savers don’t read lots of what is issued to them, are you concerned that putting lots of warnings and commentary, that it may confuse savers or put them off using the dashboard?
That’s something we’re concerned about and that’s why user testing is so important to ensure we’re communicating the right measures but equally not overloading the user. It’s the balance we know we need to achieve.
What sort of disclaimers do you expect to appear on the dashboards? Are these covered in any of the standards that are currently being consulted on. If not, when do you intend to consult on this?
The scope of the disclaimers is in the design standards call for input. We’re looking for comments in your responses.
The data standards are very detailed, and have an administration focus. Should trustees of schemes with complex benefit structures be asking their outsourced administrators to check and confirm during the consultation period that there are no issues?
Absolutely. That’s part of the reason for the consultation. We want to hear whether there are potential issues with any benefit structure.
If a member signs up with multiple dashboards, will a common data collection system call for the information once or will the same data have to be provided multiple times?
The request for the pension information for a user will be the same, but will be per dashboard provider and per view. Dashboards cannot store data, so any time a user wants to view their data on any dashboard, a view request will be set to the data provider who will have to provide the data for display each time.
Would it be open to commercial dashboard providers to include information about other products eg lifetime ISAs, if they make it clear that that’s not part of the dashboard?
Rules on dashboard advertising an similar will be covered in the FCA dashboard rules, which will be consulted on later this year.
NINO is a very important field for pension schemes. What user testing are you doing to collect this in the best way? And what % of completion are you aiming for?
We’ve been undertaking lots of user testing to review exactly this issue. However, we’ve built the central technical architecture find functionality on the basis that not all users will have NINOs and these individuals should not be excluded from dashboards.
Will there be any guidance/statements on what should be covered in ISP contracts – or it this purely an area for legal advice?
TPR has issued guidance connection issues and we suggest trustees refer to it.