PDP webinar: understanding the architecture and find and view data Q&As
This webinar provided information on the architecture and find and view data.
Chris Curry, PDP’s Principal, was joined by PDP colleagues Gary Millar (Working Group Expert) and Alistair Davis (Lead Technical Architect).
These Q&As detail the questions asked by attendees and the answers given by the panel during the webinar.
To note, “legislation” refers to the Department for Work and Pensions regulations for occupational pension schemes and the Financial Conduct Authority rules for providers of personal pensions.
When will Pensions Protection Fund (PPF) and Financial Assistance Scheme (FAS) compensation be included on dashboards?
Defined benefit (DB) pensions that have moved into the Pensions Protection Fund when the employer has become insolvent will not be in scope for initial dashboards.
Legislation determines the scope of pensions to be included. It currently does not provide for PPF information to be included.
However, the Government and the pension protection fund are committed to PPF participation in the dashboards initiative and are exploring potential routes, including legislative routes, to do so.
Will trustees need to take any further steps to comply with the statutory requirement to check members have provided consent? Can all trustees assume that this consent is present via the consent and authorisation service?
Legislation requires trustees to check with the Money and Pensions Service (MaPS) that the individual, to whom the find request relates, has consented to their view data being provided to the dashboard issuing the view request.
PDP’s central digital architecture (the consent and authorisation service) provides the means for the individual to set and manage their authorisation policies for access to their pensions information. It also provides the means for this check, as well as the pension provider or scheme checks with the consent and authorisation service as to the authorisation of the view request issued by a dashboard.
If the tokens are valid, the consent and authorisation service confirms this back to the pension provider or scheme, which then sends the data. No further check is necessary.
Will there be a single identity service provider across the dashboard, or will each pension provider be able to select their own?
PDP will provide a central identity verification and authentication service. Pension providers and schemes will be able to rely on the identity of the individual that submitted the find request having already been proven by the central identity service, and will not need to select their own identity service.
What reporting will be made from the governance register, who will do this reporting and who will be the audience of the output?
As part of our role setting up and managing the dashboards ecosystem, PDP will be overseeing the health and performance of the ecosystem through management information and reporting.
PDP will make information available to the regulators regarding any non-compliance so as to support their regulatory functions.
Will the State Pension be shown gross or net of any contacted-out deduction?
We are working with the Department for Work and Pensions (DWP) to finalise the State Pension data that will be displayed on dashboards.
It is expected that the data will align with the DWP’s existing Check your State Pension service.
Will the State Pension be based on national insurance contributions (NIC) to date or assume further NICs up to State Pension age?
PDP is working with DWP to finalise the State Pension data that will be displayed on dashboards.
It is expected that the data will align with DWP’s existing Check your State Pension service. This provides both an estimate of the State Pension based on current national insurance (NI) records and a forecast if NI contributions were to continue to State Pension age.
Find and view requests
In the find request we get 3 JSON Web Tokens (JWT). The user data, user account (used for PAT exchange) and a consent token. What details are in the consent token and are the data providers expected to be storing/using any of this information from the consent token?
PDP issues find requests and it is down to the scheme to process these. Post go-live, granular consents will be reviewed and potential functionality maybe be added as part of the consent and authorisation user interface service.
The Service Level Agreement (SLA) for returning value data is triggered by a successful find request. Can PDP provide some rationale for this decision?
Legislation, not PDP, sets the timeframe for the calculations of values where the values are not already available.
They must be provided to the member immediately where a statement has been issued within the last 13 months or a calculation made for the member within the last 12 months.
Where the provider/scheme needs to undertake a fresh calculation and so will make use of the permitted 3/10 working day calculation periods, the time period for this begins the day after the registration of the pensions identifier (PeI) in response to a find request.
This means the value must be calculated and made available for return to a dashboard within this time period. In the (probably unlikely) event that a user sent a find request, but then did not go on to send a view request, the provider/scheme would still need to ensure the data is available for return within the time period to meet the legislative requirement.
Will there be a requirement for each scheme to provide an estimated retirement income and will this include a breakdown of options?
The legislation sets out the requirements on pension providers and schemes in respect of what information must be returned.
How does the system avoid a possible match from recurring every time an individual submits a find request and it is a possible match but not a full match?
Matching is the responsibility of the pension provider/scheme. The legislation requires providers and schemes to delete the find request information where a possible match is resolved not to be a match.
However, in the draft Code of Connection, PDP indicated that pension providers and schemes may investigate whether they can store a hash of some of the details used in the search. So, when a subsequent search is initiated by the same user within a given period, a repeat search against a known no match is not needed.
This would allow pension providers and schemes to avoid repeat registration of possible matches previously confirmed not to be matches. This is a matter for pension providers and schemes, however, as data controllers, not the PDP architecture.
Will users have to do a new find process periodically (eg once a year) to make sure any new pension arrangements are captured?
A new find request would be necessary to match against new pensions arrangements.
Can pension schemes use find data to update their records? For example, where they have a successful match, but the find data contains a telephone number that the pension scheme does not already hold.
PDP cannot advise pension providers and schemes on further use of the find data. As data controllers, providers and schemes will have to determine what lawful basis they might have for such purposes.
The pensions dashboards legislation determines the lawful basis for the use of the find data for matching. Providers and schemes process this data for the purpose of matching, as they have a legal obligation to do.
Once a member has sent a find request and has matched with their pension provider(s), will that match be permanent? Or will it expire after a certain period of time?
The data retention policies are to be confirmed and will be confirmed when the approved standards are published.
Currently, the draft duration of the permission token which protects access to the pensions information is proposed to be 18 months, and is renewed when the user visits the consent and authorisation service.
Schemes in some circumstances have 3 or 10 days to provide value data (where that’s not already been calculated for a benefit statement). The 3/10 day period starts from the PeI match date, which gives some time for manual calculations after the initial match. How will that 3/10 period apply for future years (for example in year 2, year 3)?
If a user returns to view some time (for example 3 years) after they send the find request, the legislation still requires the values to be returned immediately. This is also the case if they have been provided in a statement in the last 13 months or a calculation for the member within the last 12 months.
But if this does not apply and the values must be calculated, it may not be possible for the pension provider or scheme to return the values within 3/10 working days of the registration of the match. This is because since more than a year could have already passed since the match was registered.
This is a current gap which we expect to address in our final standards, in line with the policy intent that where fresh calculations are needed, values are made available within 3/10 working days.
The pension identifier (PeI) will be valid for 18 months, is that also true for a possible match?
No, the legislation states that where a possible match is registered, if the individual to whom the find request relates does not make contact with the provider/scheme within 30 days, the find request information should be deleted. The pension identifier for the possible match should then be de-registered.
Similarly, if they do make contact but the possible match cannot be resolved within such a time that may be reasonably allowed by the provider/scheme, again, it should be de-registered.
Will PeI’s be deregistered, and a new find request required upon change of administrator/ISP?
Under the transfer of schemes, the current direction of travel is to maintain the find request but this is still currently being established as part of the connection journey work.
Can we expect industry guidance on AVCs?
There is industry-led activity looking at implementation in respect of AVCs.
The PASA dashboard working group is looking at this, as are the LGA, and they are working with the regulators and PDP on this work. We expect industry-led guidance will come out of this.
Will end-users have to pay to use dashboards when they go live?
No. All pensions dashboards will be free for people to use and to view their pensions information online, securely and all in one place.
The Money and Pensions Service is creating a dashboard, and there may be other commercial dashboards available too.
When will dashboards be publicly available?
A specific date for dashboards available point (DAP) will be when the Secretary of State is satisfied that the dashboards ecosystem is ready to support widespread use by the general public. This will be following consultation with the Money and Pensions Service (MaPS), The Pensions Regulator (TPR) and the Financial Conduct Authority (FCA).
The Secretary of State will provide notice at least 6 months ahead of DAP. Their decision will be based on sufficient levels of coverage, assurance of the safety, security and reliability of the service, and testing of the user experience.
If pension providers and schemes connect in line with the staging profile set out in guidance, then DAP could come before the connection deadline on 31 October 2026.
Will the updates to standards in the new year be baselined versions or minor amendments with a view to baseline at a later date?
PDP is considering its approach to the publication of standards. This will include at what stage to seek the approval of the Secretary of State for Work and Pensions.
PDP will notify industry of any updates and changes to standards.