DWP has released a written ministerial statement that affects the connection deadline for pensions dashboards.
Additional guidance will be published in due course.

 

Standards webinar: code of connection, early connection and governance Q&As

This webinar provided an overview of the amendments to the code of connection, early connection and the governance of standards following the consultation, hosted by David Reid, Head of Policy and joined by Gary Millar and David Marjoribanks from our Policy team.

These Q&As detail the questions asked by attendees and the answers given by the panel during the webinar.

Do we need to provide multiple calculation estimates eg low, medium and high?

No. The only information required to be provided to the dashboard is set out in the regulations and rules. Providing these estimates is not one of those requirements. However, under the FCA’s proposals for dashboards, dashboard will be required to explain the estimated nature of the pensions values displayed on dashboards.

How will dashboards display variation between a retirement income versus retirement income plus lump sum?

Dashboards will be required to display only the pensions information provided and not the options open to users in relation to how they may be provided. If the user is after this further information, dashboards will explain they should contact the pension provider and scheme directly.

Can you provide an example of the type of failure to meet standards that would qualify for forcible disconnection?

We’ll be sharing more detail in the next year on our approach to disconnection and refusing to connect. This will be as part of explaining how we propose to maintain the pensions dashboards ecosystem.

Can providers provide AVC policies to the ecosystem without bundling with the master policy that may be with another provider?

As the AVC is an investment on behalf of the pension provider/scheme then the primary duty to provide the information in relation to it is through the pension provider/scheme.

The AVC provider should be liaising with the pension provider/scheme about when the pension provider/scheme will connect with the pensions dashboards ecosystem and how they can support the pension provider/scheme to supply this information to dashboards after the pension provider’s/scheme’s connection date.

In our data standards, we’ve set out a number of different means for how pensions providers/schemes can do this (including a pensions link so the dashboard can link the returns on when it displays them to the user).

Can you clarify please, where a scheme is acquired (post-connection), what is the timeline for the new administrator to re-connect the scheme to the dashboard after acquisition of a pension scheme is completed?

The answer for both is really the same. Therefore, we’re tackling these 2 question together.

Once connected to the pensions dashboards ecosystem a pension provider/scheme must stay connected. This is the important requirement and it falls on the pension provider/scheme. If there is likely to be a change in circumstances which could affect the connection, then the pension provider/scheme must plan to ensure it doesn’t happen. We appreciate that sometimes there will be circumstances outside of the pension provider and scheme’s control. For these circumstances, we suggest the pension provider and scheme should have put in place contingency planning and, in any event, act swiftly to restore its connection by another means.

Schemes and pension providers are required notify MaPS of any connection state changes, including using every endeavour to ensure that the scheme remains connected at all times.

The SLAs for data providers to match and view include calls to the PDP. We cannot be responsible for third party performance, so these should be removed from the SLA. When will we get SLAs for the PDP central infrastructure services?

Registering pension identifiers with the central digital architecture and checking authorisation of view requests with the it do indeed involve calls to on the central digital architecture.

Schemes and pension providers are not responsible for our performance: if the central digital architecture is down or experiencing problems, this will not affect pension providers’ and schemes’ compliance with their duties.

This is why the central digital architecture availability will similarly be 99.5% 24/7, 365 days a year. The required response times also considers the time required for these central digital architecture interactions.

CoCo2.2.4 – new requirement: this suggests a data provider will not be able to remove a PeI if the PAT has expired. There will be occasions, for example an asset is crystalised/moved where a data provider, will need to delete a PeI, even if the PAT has expired.

Updating the pension identifier registration does require a valid PAT (an UMA token used to register the pension identifier and used for authorisation of view requests against the pension identifier).

There may be occasions (likely quite rare) when schemes/providers won’t be able to update or remove the registration of the PeI because the PAT has expired. This could be where the pension owner has ceased to be a relevant member and therefore fallen out of scope of dashboards. Here the pension provider/scheme is then required to de-register the pension identifier as soon as possible, in accordance with the legislation. But the PAT could have expired due to a long period of non-use of dashboards by the user (long enough that the PAT has expired, but not so long as their account and all their data at the central digital architecture has been deleted in accordance with the autodeletion periods).

This is why the code of connection (2.2.4) requires schemes/pensions providers to notify the central digital architecture where a pension identifier needs to be de-registered but where the scheme/provider is unable to do so.

The previous find response times stated that 99% must be <15 seconds with 1% <60 seconds. Is that still the same?

The requirement in respect of responses to find requests has not changed from the proposal we consulted on: the requirement is to complete matching and register any pension identifiers for positive matches within 60 seconds, with a target of completing this within 15 seconds.

If 100 pensions get matched to a find request, do they all have to be registered with the PDP in the 60 seconds? Do PDP support 100 concurrent calls to their APIs or is there a limit?

The requirement to register any pension identifiers within 60 seconds is absolute, not relative to traffic. The central digital architecture is set up to be able to handle sufficient levels of concurrent calls.

When will connections to dashboards begin for public service and Civil Service scheme administrators and what testing has currently taken place regarding these connections? I assume that the current 2015 Remedy work has to be completed prior to this taking place and therefore posing a delay

These schemes are required to connect by the end of September 2024 under the regulations. Once connected, public service pension schemes are required to provide value data on request once a Remediable Service Statement (where applicable) has been issued to the member, or from 1 April 2025, whichever is the sooner.

Are there any ‘acceptability’ criteria for early onboarding? That is to say, are there circumstances in which an early onboarding request, requested in time, would be rejected? And if so, what are they?

Yes. For example, this could be due to our capacity crunch at the proposed time of onboarding or as a result of an objection raised by The Pensions Regulator which they raise when we consult with them. For more details see our early connection guidance.

We have 3 schemes with different connection dates – just to confirm, if we want to harmonise connection dates we would need to go down the formal early connection application route?

Yes. To effect this harmonisation, you’d have to apply for early connection in respect of the later two schemes’ connection dates to be brought forward to synchronise with the other scheme’s connection date.

For completeness, you should also be aware of the limited deferral options under the regulations and FCA rules.

(Early Connection) I know you mentioned they must apply at least 2 months before their requested staging date and for it to be at least a month earlier however, is the ‘maximum’ time limit someone can request (ie wave 3 or wave 2 clients can request to stage in April 23)?

No. We’ve outlined the minimum periods. We encourage earlier approaches as this will help us plan our operational capacity.

What are the expectations of delegated accesses (now and going forward) and confirmation of the scope for this. Currently this is specified as ‘where a user allows a regulated financial advisor or a MaPS guidance specialist to view their pensions information. a. Will all the access permissions needed by a delegate to view a relevant member’s data be provided at the consent and authorisation service level? b. Will a delegate, currently in-scope, provide the relevant member’s details for whom they are authorised to view their data, in addition to their own details to CAS, so it is available to match to? c. Do data providers have to do a second check that the delegate, pre-authorised by CAS, has an active interest on the plan/policy?

We are building this functionality and will provide more details in due course.

Is it foreseen that delegated access may be extended to ‘authorised representatives’ on relevant members’ plans/policies – we have examples of the only ‘active interest’ on a plan/policy being that of an authorised representative and where the relevant member has delegated this interest (possibly due to customer vulnerability)

Is it foreseen that delegated access may be extended to enduring power of attorney authorisations?

We are currently concentrating on building the functionality in respect of the delegated financial adviser and MaPS’ guiders. We’ve no current plans to extend delegated access out. We won’t be considering the issue until after the build of the initial functionality is implemented.

How “spiky” do you think usage will be? (eg Dutch dashboard usage spikes significantly during their annual “Pension Awareness Week” equivalent). Will response time limits still have to be met in these spikes?

Response time requirements are to ensure a good user experience and safeguard the reputation of the pensions dashboards ecosystem.

Response time limits are independent of traffic, not relative to traffic. Pension provider and scheme systems will need to be set up to be able to cope with fluctuating levels of traffic.

Will Salesforce allow for onboarding to be completed in advance of the staging deadline, to allow ISPs to manage the effort of onboard multiple schemes with the same staging date. ISPs with Public Service customers will have a high number of schemes onboarding between 01/09/2024 – 30/09/2024. Just to be clear, we’re not suggesting early connection for this schemes, just the normal onboarding process in advance, perhaps using an effective date.

All pension providers and schemes must connect to the pensions dashboard ecosystem before their connection deadline but within their connection window – which for most schemes will open a month before their connection deadline.

Why are you using April for major changes? Using October would avoid an already busy time due to tax year end.

Apologies we misspoke during the webinar. To be clear, we won’t introduce major changes in April; only October. Avoiding an already very busy period for pension providers and schemes was one of the reasons for choosing October over April.

For the governance process do you plan to have some sort of standing working group of industry or will it be ad-hoc?

The approach to the governance of standards sets out the main framework for how we will approach the monitoring, review and amendment of standards. We’re working through the optimal operationalisation of this framework and whether to establish working groups is one of the options we’re considering.

We have an unfunded scheme that we believe is out of scope for dashboards, but the benefits are integrated with a scheme that is within scope – we would like to treat both sets of benefits as in scope but do we need that formally approved before doing so?

Only pension schemes within the scope of the regulations can connect to the pensions dashboard ecosystem.

Is it possible to administrators to apply on behalf of schemes?

Yes. Our approach has been to facilitate either direct pension provider/scheme connection or allow for administrators or integrated service providers (ISPs) to connect on their behalf (which we think is the option most pension providers/schemes will go for).

v1.0 standards are expected summer 2023, there is a risk standards will continue to change until this point impact pensions provider delivery. The movement from v0.11 to v0.12 impacted our build schedule already. What allowance will be given for future changes?

v1.0 of the standards will be in place in December and once the Regulations come into force. We’re focusing on this delivery at the moment and have no immediate plans for further amendments. However, all these standards will be subject to our commitments around governance and further development of standards to ensure certainty and stability for industry planning.

Design standards v1.0 are following a different track. They are currently out for consultation. They aim is for them to be finalised in Summer 2023, alongside the FCA’s final regulatory framework for dashboards.

Could you confirm there are requirements/standards applicable to ensure identity of the end user? For example – we don’t want someone impersonating an individual and obtaining key pension information.

All dashboard users will have their identity attributes verified and authenticated by the PDP identity service. The identity service is an important element of the protection for consumers, pension providers and schemes, and dashboards. It’s part of providing confidence to everyone that dashboard users’ pension data is secure and it’s safe to use pensions dashboards.

The identity service will verify and authenticate identities in line with the principles defined in Government Digital Service (GDS)’s Good Practice Guide 45 and Good Practice Guide 44.

Could you confirm there are requirements/standards applicable to ensure identity of the end user? For example – we don’t want someone impersonating an individual and obtaining key pension information.

All dashboard users will have their identity attributes verified and authenticated by the PDP identity service. The identity service is an important element of the protection for consumers, pension providers and schemes, and dashboards. It’s part of providing confidence to everyone that dashboard users’ pension data is secure and it’s safe to use pensions dashboards.

The identity service will verify and authenticate identities in line with the principles defined in Government Digital Service (GDS)’s Good Practice Guide 45 and Good Practice Guide 44.

The SLA for the 99.5% uptime 24/7 has evolved with further detail of this including planned and unplanned downtime & 24/7. Would you be willing to receive further feedback on this SLA through the PDP support email address even though there is no open consultation on this?

The PDP support inbox is available for all queries and comments. We welcome all input to support us to fulfil our function of not only setting the standards, but also keeping them under review and updating where necessary to ensure they remain fit for purpose over time.

Where a Value is unavailable and therefore a provider must upload it to the dashboard within a 3 or 10 day timescale, the Rules seem to indicate that the clock starts once a PEI is generated on a successful find and not on a view request. Is this interpretation correct?

Yes. The Regulations and Rules specify that:

• where the value has been generated for a statement provided to the member within the past 13 months, or is based on a calculation made within the past 12 months, it must be returned immediately
• but where this does not apply and the value must be calculated, them the calculation must be completed and the value available for on dashboards within 3/10 working days from the day after the date on which a pension identifier is registered for a positive match or (if appropriate) from the date on which it is re-registered as a match made

The 3-day time limit applies for money purchase benefits. The 10-day limit applies for all other types of benefits.

Can an ISP register / connect to the CDA in their own right initially or must ISPs register in combination with a provider or scheme?

ISPs may only connect to the CDA if they are connecting at least one regulated relevant pension provider/scheme. This is to ensure that we only connect regulated entities within scope to the pension dashboard ecosystem, so as to protect the ecosystem and all participants within it. Once connected with at least one relevant pension provider or scheme, the ISP can subsequently connect further clients through its established connection.

Is there any flexibility made for those schemes changing admin system in terms of onboarding dates? but no extra dispensation, I assume?

The connection deadlines are set in the Regulations and Rules, they’re not set by PDP. The Regulations set out a staging profile with deadlines for each relevant scheme to have completed connection (see Schedule 2 of the Regulations). There are different mechanism under the Regulations and Rules for deferral in certain circumstances if conditions are met. It is different for occupational pension schemes as opposed to FCA-regulated entities.