The Government has restated its commitment to delivering pensions dashboards in a written statement.

Skip to content
Pensions dashboards programme logo
  1. Home

Code of connection

The code of connection sets out how pension providers and schemes connect to the dashboards ecosystem and what they need to do to remain connected. It provides assurance that the systems and services of all participants in the ecosystem are managed and controlled to the appropriate levels. It comprises connection standards, security standards, technical standards, service standards and operational standards.

Draft version 1.2

All PDP standards are published as ‘draft’ until approved by the Secretary of State for Work and Pensions. Find out more about PDP’s approach to standards governance.

PDP recommends providers and schemes align with the current version whilst preparing for connection. This version was developed following industry consultation and review by PDP volunteer participants.

PDP may make further changes before seeking formal approval. Only necessary changes will be considered and we will work with industry to understand potential impacts.

Changelog

Refer to the changelog for updates since the last publication.

Corrections log (errata)

Refer to the corrections log (errata) for known issues and corrections for the current version. These corrections will be included in future versions.

Back to top

Introduction

Summary

1. Pensions dashboards are apps, websites or other tools which help individuals view information about their multiple pensions in one secure place online, at a time of their choosing. They bring together information on all a user’s (in-scope) pensions, including their State Pension, occupational and personal pensions. This supports individuals’ engagement with their pensions and their retirement planning.

2. The Money and Pensions Service (MaPS) set up the Pensions Dashboards Programme (PDP) in 2019 to design and build the central digital architecture (CDA) and services that make pensions dashboards possible. PDP is responsible for the supporting governance framework, service design and operating model for the pensions dashboards ecosystem.

3. The pensions dashboards ecosystem enables millions of individuals to connect with their pensions information through multiple dashboards across thousands of pension providers and schemes. Find out more about the pensions dashboards ecosystem and its components.

4. MaPS is responsible for operating its own non-commercial pensions dashboard as a public service.

Purpose  

5. This code of connection is issued by MaPS under delegated powers given by the Pensions Dashboards Regulations 2022 and the Pensions Dashboards Regulations (Northern Ireland) 2023 (referred to hereafter as ‘Regulations’) and the Financial Conduct Authority (FCA) and the Rules of the Financial Conduct Authority (FCA) (hereafter ‘Rules ’).

6. The code of connection sets out requirements that must be met to connect to the pensions dashboards ecosystem and to remain connected. It consists of standards that are distinct, for legislative purposes, but are gathered together in one code of connection setting out all the connection and service requirements in one place. The code of connection comprises:

  • connection standards
  • security standards
  • technical standards
  • service standards
  • operational standards

7. The code of connection provides assurance that the systems and services of all participants in the ecosystem, which access and use the central digital architecture and interoperate with other ecosystem participants, are managed and controlled to the appropriate levels.

8. Together, these will ensure that the pensions dashboards ecosystem provides a secure, well-functioning, effective service which garners user trust and satisfaction, which facilitates pension providers to comply with their legal duties, and enables multiple dashboards to operate, creating choice for users and scope for innovation.

Application

9. These standards apply legally to the trustees or scheme managers of occupational pension schemes (pension schemes) and the managers of stakeholder and personal pension schemes (pension providers) connected to, or required to connect to, the pensions dashboards ecosystem. This version does not include any standards that apply to dashboard providers. The standards for dashboard providers will be published separately.

10. The code of connection standards are important for pension providers and schemes to understand, whether they are connecting directly to the ecosystem or connecting using a third-party supplier such as third-party administrators or software providers (integrated service providers, or ISPs). In these cases, third parties will apply the standards, by sending the data to MaPS, on behalf of their client pension providers and schemes. PDP expects much of the implementation of the standards will be undertaken by these third parties on behalf of multiple clients. A pension provider or scheme connecting via an already-connected third party will use the third party’s processes to meet our standards. However, as the standards apply to the pension provider or scheme, the pension provider or scheme is responsible for compliance with them, even if implementation is delegated to a third party. When referring to pension providers and schemes, this includes any of these third parties.

Jurisdiction

11. These standards apply to all United Kingdom pension providers subject to the dashboard duties in the FCA Rules for pension providers, and all United Kingdom schemes subject to the dashboard duties in the Regulations.

Other standards

12. These standards should be read in conjunction with the other PDP standards (technical standards, data standards and reporting standards).

Compliance

13. Standards are mandatory requirements and, therefore, compliance by pension providers and schemes is compulsory.

Version

14. This is the v1.2 version of the draft code of connection. Refer to the changelog for updates since the last publication.

Back to top

1. Security of the dashboards ecosystem

1.1 Securing ecosystem communication (technical standards)


CoCo1.1.1

  • Requirement: Must implement at a minimum and must always support Transport Layer Security (TLS) encryption profile 1.2 for all ecosystem communication. Where a connection is successfully established between both parties using v1.3, they must not fall back to 1.2.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.1.2

  • Requirement: Must implement Mutual TLS (mTLS) encryption for all system-to-system communication within the ecosystem.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.1.3

  • Requirement: Must use the Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms for any Public Key Infrastructure (PKI).
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.1.4

  • Requirement: Should encrypt data at rest in accordance with industry good practice. Parties are responsible for choosing the most appropriate encryption standard to protect sensitive data.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

1.2 Security testing (security standards)


CoCo1.2.1

  • Requirement: Must undergo an initial IT Health Check, performed by an independent third-party scheme accredited by either the Council of Registered Ethical Security Testers (CREST) or CHECK approved organisation prior to connecting to the ecosystem.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.2

  • Requirement: Must ensure the scope of the IT Health Check covers as a minimum scope the new infrastructure and services introduced to connect to the ecosystem. This must include both ‘external’ connection testing of systems to prevent unauthorised access, and ‘internal’ testing to assess for vulnerabilities and ensure internal networks and systems are securely configured and properly maintained.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.3

  • Requirement: Must report IT Health Check results to MaPS, and present on the findings to MaPS to receive approval.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.4

  • Requirement: Must use the Common Vulnerability Scoring System (CVSS v3 or higher) scores for classifying vulnerabilities identified in annual IT Health Checks. Medium, High or Critical, must have a remediation plan in place and approved by the PDPSA. Any allowed exceptions must be remediated within 12 months and resolved by the subsequent re-test (see 1.2.6).
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.5

  • Requirement: Must keep IT Health Checks and subsequent remediation plans for a period of 6 years. MaPS reserves the right to request to see IT Health Checks and remediation plans to address identified issues.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.6

  • Requirement: Must annually re-take a CREST or CHECK accredited IT Health Check within 12 months after the initial test or any significant change to the infrastructure and services in scope, and report on the outcome of the IT Health Check to MaPS.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

CoCo1.2.7

  • Requirement: Must carry out a retest of an IT Heath Check on the request of MaPS.
  • Reason for requirement: Security control to maintain the security and integrity of the ecosystem.

1.3 Security monitoring and incident response (security standards)

CoCo1.3.1

  • Requirement: Must collect and retain event data and undertake activities that will help detect actual or potential security incidents and must have a protective monitoring policy that describes the use cases you are aiming to detect, which can be used to define event data collection. The policy must include both detection of technical attacks as well as important abuses of business processes.
  • Reason for requirement: Security control to help reduce the impact of security incident on the ecosystem.

CoCo1.3.2

  • Requirement: Must have a security incident management plan, which you should test periodically. This will include named responsible owners and pre-defined processes to respond to common forms of attack.
  • Reason for requirement: Mandatory security control. Helps reduce the impact of security incident on the ecosystem.

1.3 Security monitoring and incident response (service standards)


CoCo1.3.3

  • Requirement: Must report incidents that impact on the dashboards ecosystem or other participants to MaPS and other entities as required, within 24 hours of identification. Incidents should be reported to MaPS at [email protected].
  • Reason for requirement: Security control to help reduce the impact of security incident on the ecosystem.

CoCo1.3.4

  • Requirement: Must contribute threat intelligence relating to the ecosystem security to MaPS, and receive and act appropriately on intelligence received from MaPS. Incidents should be reported to MaPS at [email protected].
  • Reason for requirement: Security control to help reduce the impact of security incident on the ecosystem.

Back to top

2. Service levels and required behaviour

2.1 Service response times, availability requirements and service restoration requirements (technical standards)


CoCo2.1.1

  • Requirement: Must acknowledge receipt of find requests by the find interface, by means of ACK (see technical standards) in <2 seconds (99.9% of ACK responses to acknowledge receipt of a find request to be returned in <2 seconds, measured over a 24 hour period). ACK response time is the time lapse between receiving the find request from the pension finder service and sending the ACK.
  • Reason for requirement: Effective traffic management. ACK is a synchronous automatic response to confirm receipt of the find request.

CoCo2.1.2

  • Requirement: Must complete responses to find requests, including registering any pension identifiers (see technical standards) within 60 seconds for positive matches (including both matches made and possible matches; negative responses are not required) following sending of the ACK.
  • Reason for requirement:
    • User experience. Finding users’ pensions is designed to be an in-session experience.
    • Efficient traffic management. Pension provider or scheme architectural optionality. 60 seconds does not require a particular architectural solution and supports searching across distributed systems as well as centralized architectural solutions.
    • Pension provider or scheme burden. Registration of matches in response to find requests is a synchronous response, requiring pension providers and schemes to undertake matching and register a pension identifier for any found pensions.

CoCo2.1.3

  • Requirement:
    • Must respond to view requests in <10 seconds (99.9% of view data payloads retrieved from systems and returned to the dashboard that issued the view request in <10 seconds, measured over a 24 hour period).
    • View request response time is the time lapse between receipt of a dashboard view request and return of the view data payload (this includes the authorisation call to the consent and authorisation service to check authorisation of the view request).
    • View response time applies regardless of the view data payload. For example, whether the values are returned immediately in response to the view request, or whether a 3/10 working day calculation period applies. If the pension provider or scheme uses the permitted 3/10 working day period to calculate the values, the initial view response (comprising the administrative data and signpost data, accompanied by the relevant ERI/accrued value unavailable code in the data standards) must still be <10 seconds.
  • Reason for requirement:
    • User experience. Viewing pensions information is designed to be an in-session experience.
    • Architectural optionality. 10 seconds supports return of real-time data by means of APIs to retrieve data from pension provider or administration platforms.
    • Return of view data is a synchronous response.

2.1 Service response times, availability requirements and service restoration requirements (connection standards)


CoCo2.1.4

  • Requirement: Must restore service within 2 hours in the event of an endpoint outage, without loss of data ACKed before the outage.
  • Reason for requirement: User experience. Pensions dashboards are a digital service. Efficient traffic management.

CoCo2.1.5

  • Requirement:
    • Must target availability of at least 99.5%, 24/7, measured by calendar month.
    • For clarity, 99.5% availability means 0.5% unavailability for whatever reason.
  • Reason for requirement: User experience. Pensions dashboards are a digital service. The central digital architecture will be available 99.5% 24/7.

CoCo2.1.6

  • Requirement:
    • Must generate, send, receive and retain unique transaction identifiers and timestamps in audit logs for all API interactions between ecosystem parties.
    • Transaction identifiers must be generated by the party initiating the transaction in accordance with the technical standards, issued to the other party to the transaction via the relevant API in accordance with the technical standards, and retained in the audit logs of both parties to the transaction for 6 years.
  • Reason for requirement: Ecosystem audit. Enables correlation of business audit logs across parties to support forensic investigation.

CoCo2.1.7

  • Requirement: Must, where a view request is received and a new calculation is required for return of the value data and the values cannot therefore be provided immediately (the values have not 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), calculate the values and make them available for return to dashboards within the same calculation timeframe as required by the Regulations (Regulation 26(5)) and FCA rules (COBS 19.11.29). For example, 3 working days where all the benefits are money purchase benefits; 10 working days for all other cases. While the legislation sets the clock for the return of the first values to the registration of the pension identifier, for subsequent returns more than 3/10 working days after the registration of the pension identifier where values are not available for immediate return and new calculations are needed, the values must be made available for return within 3/10 working days, from the day after the receipt of the view request.
  • Reason for requirement: Align timing for subsequent calculations with the calculation times for initial calculations set out in legislation.

2.2 Service notifications (service standards)


CoCo2.2.1

  • Requirement: Must give a minimum of 5 working days’ notice to MaPS (the means for the provision of this notice is TBC) in advance of a scheduled service unavailability. Service unavailability includes any gap in service due to the service being unavailable or impaired.
  • Reason for requirement: Effective service management.

CoCo2.2.2

  • Requirement: Must notify MaPS (through the connecting organisation, not directly from pension provider or scheme to MaPS, if connecting via a third party) as soon as possible of any change in connection arrangements. This includes changes ‘internal’ to the connection solution used, such as moving from a data lake ISP model for processing of find or view requests to using a federated model with onward connectivity between ISP and provider or scheme.
  • Reason for requirement: Effective management of the ecosystem.

Back to top

3. Procedural requirements for connection

3.1 Onboarding (operational standards)


CoCo3.1.1

  • Requirement: Must nominate and provide MaPS with contact details for the following:
    • primary business contact
    • primary technical contact
    • security lead
    • test manager
    • service manager
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.1.2

  • Requirement: Must provide data required to register with MaPS as a pension provider or scheme:
    • scheme name
    • regulator-issued registration code
    • regulator number
    • regulating body
    • holdername (see technical standards)
    • holdername view endpoint (view_data_host_url)
    • details for the pension provider or scheme find-requests endpoint (find_request_path_url)
    • view-data endpoint
    • refresh endpoint
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.4

  • Applies to: Pension providers.
  • Requirement: Must supply PDP with their Firm Reference Number (FRN) and name as registered with the Financial Conduct Authority (FCA). 
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.5

  • Applies to: Pension schemes.
  • Requirement: Must supply PDP with their Pension Scheme Reference (PSR) number and name as registered with The Pensions Regulator (TPR). 
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.6

  • Requirement: Must supply MaPS with:
    • first name
    • last name
    • email address of the initial contact undertaking the preregistration process
    • the primary business contacts (if different to the initial contact)
    • the primary technical contact
  • Reason for requirement:
    • As part of the preregistration process MaPS will validate the details provided directly with the pension scheme or provider, using a trusted contact provided to MaPS from the relevant regulator.
    • Identity checks will be undertaken by MaPS for the initial contact undertaking the preregistration process, the primary business contacts (if different to the initial contact) and the primary technical contacts, including when new primary business or primary technical contacts are added. The identity check will validate both the identity of the individual and their organisation email address.
    • Due diligence checks of the connecting organisation (ISP, pension provider or pension scheme) will be undertaken by PDP using data from company registers.
    • Providers and schemes must meet with the PDP engagement and technical teams as part of this process.

3.1 Onboarding (connection standards)


CoCo3.1.7

  • Requirement: Must execute the test suite provided by MaPS in participants’ own environment and submit successful test evidence through Salesforce in accordance with the MaPS test pack.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.1.8

  • Requirement: Must participate with MaPS during the execution of the test suite in the MaPS pre-production environment. Submit test evidence through Salesforce in accordance with the MaPS test pack.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.1.9

  • Requirement: Must participate with MaPS to execute operational acceptance testing (OAT) in the production environment, to prove successful connection prior to live acceptance.
  • Reason for requirement: Effective management of the ecosystem.

3.1 Onboarding (operational standards)


CoCo3.1.10

  • Requirement: Must provide a transition or implementation plan (steps).
  • Reason for requirement: MaPS is required to ensure that the provider has identified the correct steps to enable them to connect. This is standard practice for IT changes. This would need to be reviewed by the technical team, who would need the ability to request further details if they are not satisfied that this connection would be safe for our ecosystem.

CoCo3.1.11

  • Requirement: Must provide implementation team roles or responsibilities and contact details (if not part of the transition plan).
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.12

  • Requirement: Must provide a release note.
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.13

  • Requirement: Must provide proposed transition date.
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.14

  • Requirement: Must provide a backout plan.
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.15

  • Requirement: Must provide outstanding defects or issues.
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.16

  • Requirement: Must provide service transition plan.
  • Reason for requirement: Ensuring connection of legitimate parties only.

CoCo3.1.17

  • Requirement: Must provide evidence that internal service acceptance has been carried out.
  • Reason for requirement: Ensuring connection of legitimate parties only.

3.2 Business as usual service maintenance requirements (operational standards)


CoCo3.2.1

  • Requirement: Must have and upon request provide MaPS with a defined remediation route for service level failures.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.2.2

  • Requirement: Must have and upon request provide MaPS with internal escalation frameworks and processes. Ensure staff know how, to whom and when internal issues should be escalated.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.2.3

  • Requirement: Must have and upon request provide MaPS with a framework for raising issues and monitoring issues to resolution.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.2.4

  • Requirement: Must make all reasonable efforts to support forensic investigation where required, including supporting mediated access to business audit logs.
  • Reason for requirement: Effective management of the ecosystem.

3.2 Business as usual service maintenance requirements (connection standards)


CoCo3.2.5

  • Requirement: Must ensure that any contracted third parties managing connection to the ecosystem on behalf of the pension provider or scheme severs the connection of the pension provider or scheme if directed by MaPS. For example, where the pension provider or scheme ceases to have any relevant members, or if the provider ceases to be registrable with the regulator.
  • Reason for requirement: Ensuring only relevant pension providers and schemes remain connected to the ecosystem.

3.2 Business as usual service maintenance requirements (service standards)


CoCo3.2.6

  • Requirement: Must keep key contacts (see CoCo3.1.1) up to date at all times via the MaPS connection portal on Salesforce and communicate any personnel changes to MaPS immediately.
  • Reason for requirement: Effective management of the ecosystem.

CoCo3.2.7

  • Requirement: Must keep pension provider or scheme registration data (see CoCo3.1.2) up to date at all times and inform MaPS immediately of any changes. For example, as a result of mergers and acquisitions.
  • Reason for requirement: Effective management of the ecosystem.

Back to top

Corrections log (errata)

This section includes known issues and corrections for the current version. These corrections will be included in future versions.

The corrections log (errata) is currently empty.

Back to top

Changelog

First published:19/07/2022

Last updated:19/11/2024

Version 1.2

19/11/2024

Download draft code of connection version 1.2

This zip folder contains:

  • Code of connection v1.2.pdf

The last published version of the standards was code of connection 1.1, released in June 2024. Since then, PDP has undertaken further work through review by the volunteer participant organisations and input from regulators.

We do not expect to make further changes to this 1.2 version of the draft standards before seeking formal approval.

High-level thematic changes since version 1.1

In agreement with the regulators, we have made the following changes to code of connection standards:

  • Removed all references related to commercial dashboards. Commercial dashboards focused standards will be provided and maintained in a separate code of connection document in due course.
  • Removed references to PDP programme and replaced with MaPs.
  • Removed references in CoCo2.1.3 to 3/10 working day calculation where a subsequent view request is required and moved into new standard (CoCo2.1.7).
  • Updated when availability requirement (99.5%) will take legal effect.
  • Updated Operational Acceptance Testing to clarify that test scripts will not be required to be executed by participants.
  • Removed references to expired Protection API Token (PAT).

Detailed log of all changes from code of connection version 1.1

All sections

  • Removal of commercial dashboard references.
  • The code of connection will now focus on pension schemes and providers. A follow-up set of commercial dashboard standards will follow in due course.
  • PDP references removed to maintain consistency across all standards as should refer to MaPs.

CoCo2.1.3

Removed 3/10 working day calculation where a subsequent view request is required.

Split out into new standard (2.1.7) - it is not a facet of the 10 seconds view response requirement, but a distinct requirement to mirror the legislative time permitted to calculate values.

CoCo2.1.5

Update to when availability requirement (99.5%) will take legal effect. Having consulted with industry and the regulators, it was agreed that this can be deferred to a later date. Prior to availability of 99.5% taking effect as a mandatory requirement, providers and schemes should make best endeavours to meet this availability target to support the testing of the user experience that is so essential. However, they will not be held to this as a matter of compliance.

CoCo2.1.7

New standard - 3/10 working day calculation for subsequent calculations required more than 3/10 working days after the registration of the pension identifier. Align timing for subsequent calculations with the calculation times set out in legislation. View response time applies regardless of the view data payload. For example, whether the values are returned immediately in response to the view request, or whether a 3/10 working day calculation period applies.

CoCo2.2.2

Removed as an expired Protection API Token (PAT) can now be used for find requests.

CoCo2.2.2

Added standard to require notification of connection arrangements change, to reflect the legislative duty to notify MaPS of change in connection arrangements.

CoCo3.1.9

Updated standard, to reflect providers must participate with MaPS to execute operational acceptance testing (OAT) in the production environment, to prove successful connection prior to live acceptance.

Version 1.1

21/08/2024

Download draft code of connection version 1.1

This zip folder contains:

  • Code of connection v1.1.pdf

Changes in this version 

Removed all guidance references as PDP will release code of connection guidance to support the standards. 

CoCo2.1.1

Corrected description of ACK from “asynchronous” to “synchronous”. 

CoCo 3.1.2

Clarified terminology for 'holdername view endpoint' and the 'view-data endpoint' and the 'view_data_host_url'. Terminology now aligns with the technical standards. 

CoCo 1.1.3

Added new standard covering PKI and mandating the use of Elliptic Curve Digital Signature Algorithm (ECDSA). 

This is the PKI that PDP uses and requires participants to use ECDSA to ensure connectivity with the central digital architecture. 

CoCo2.1.3

Following consultation with industry added clarification around a scenario in CoCo2.1.3 covering the 3/10 working day calculation period for view request responses. 

Version 1.0

21/11/2022

CoCo1.1.1

reason:

amended for accuracy

change:

added – recommend implementing TLS v1.3 in addition to v1.2 where possible – ie should initially attempt communication via v1.3 and establish a connection via 1.3 where both parties to the interaction support v1.3, but retry using v1.2 if the other party does not support v1.3 (NSCS advise v1.3 is designed to be more secure than previous iterations)

requirement:

must implement at a minimum and must always support Transport Layer Security (TLS) encryption profile 1.2 for all ecosystem communication where a connection is successfully established between both parties using v1.3, they must not fall back to 1.2


CoCo1.1.2

reason:

amended for accuracy

change:

clarifying the requirement applies to all system-system communication

requirement:

must implement Mutual TLS (mTLS) encryption for all system-to-system communication within the ecosystem


CoCo1.1.3

reason:

we had some consultation push-back on requiring this rather than allowing providers to determine the appropriate level of encryption based on their categorisation of the data, and we had questions over whether it applied to backend systems too. We have decided it is too strong a prescription, and it is for data controllers to determine the appropriate level of encryption for data at rest within their systems. We are recommending but not requiring use of this encryption standard for data at rest

change:

added – recommend encryption of data at rest in accordance with industry best practice: recommend implementation of encryption standard AES-256 for data at rest within pension provider/QPDS systems (e.g. view data cached temporarily at a QPDS; pension identifiers stored on a QPDS user account; transaction identifiers/audit logs stored by pension providers/QPDS)

requirement:

removed


CoCo1.2.1

reason:

amended for accuracy

change:

added ‘critical’ to the defects not permitted, and added qualification that ‘medium’ defects will usually be required to be fixed, but we may allow reasonable exceptions. Clarified this relates to connecting infrastructure rather than back-end systems, in response to consultation feedback on scope

requirement:

must undergo an initial IT Health Check carried out by an independent third-party CREST-accredited scheme on interfaces to the ecosystem must cover as a minimum scope the new infrastructure introduced in order to connect to the ecosystem (PDP Security Working Group will verify this scope) must report IT Health Check results to PDP and attend the PDP Security Working Group to present evidence and receive PDP approval must evidence that IT Health Check results either: (a) identify no critical, high or medium defects (minor defects are permissible), or (b) show any critical, high or medium issues identified have been addressed (medium-level defects should be fixed prior to connection, but PDP may allow reasonable exceptions, if a valid case can be made and approved by PDP that the threat can be adequately mitigated through other controls) must evidence a remediation plan, approved by the CREST-accredited IT Health Check assessor, for addressing any minor defects identified within a year, and to have resolved them by the subsequent annual re-test (as per 1.2.2.)


CoCo1.2.2

reason:

acknowledgement of the cost of undergoing IT Health Check: if no infrastructure changes, this will be an unreasonable cost. Amended retention period to align with other required data retention periods on pension providers

change:

added qualification that over time we expect to reduce this. Added ‘critical’ defects not permitted and qualification that PDP may allow reasonable exceptions for medium defects changed retention period to 6 years

requirement: must annually re-take a CREST-accredited IT Health Check, covering at a minimum the infrastructure and services used to connect must ensure any critical, high or medium defects are addressed immediately (PDP may allow reasonable exceptions for medium defects, if the threat can be adequately mitigated through other controls) must keep evidence of all IT Health Checks for 6 years


CoCo2.1.1

reason:

there were indications from a couple of consultation responses that the ACK time was too demanding. In addition, feedback from Origo working with the Alpha providers in test has indicated <1 second is too fast and needs to be <2 seconds

change:

changed response time from <2 seconds from <1. Clarified the SLA – 99.9% requirement: must acknowledge receipt of find requests by the find interface, by means of ACK (as per technical standards [add reference]) in <2 seconds (99.9% of ACK responses to acknowledge receipt of a find request to be returned in <2 seconds) ACK response time is the time lapse between receiving the find request from the PFS and sending the ACK


CoCo2.1.2

reason:

several consultation responses sought clarification on what %s required change made to clarify that all finds must be completed within 60 seconds, in view of the user experience (finding pensions is designed to be an in-session experience) and also cost (increasing response time would mean increasing the size of the CDA cache and more traffic, increasing costs) PDP’s qualitative research supports this: that most respondents expected the service to deliver pensions information quickly, if not instantaneously

change:

clarified this is an absolute requirement, not % finds SLA

requirement:

must complete responses to find requests, including registering any pension identifiers for positive matches (including both matches made and possible matches; negative responses are not required) with the consent and authorisation service in <60 seconds following sending of the ACK


CoCo2.1.3

reason:

responses to the consultation indicated widespread concern about the view response time. We asked a question directly about the extent to which this might proscribe return of real-time values and force use of static data, uploaded periodically to a central data lake at the ISP, rather than allowing use of APIs to retrieve more up-to-date values from administration platforms. Most respondents who responded directly to this question indicated <2 seconds would be too fast and would make return of real-time values impossible, and require a data lake architectural solution and static values – and some indicated it was too fast, even regardless of whether the values were real-time or static. 19 respondents said <2 seconds was too demanding, while only 2 supported it. Respondents gave a range of suggestions for reasonable view response times, including 5 seconds, 10 seconds, 15 seconds and 20. The average suggested time (both median and mode) was 10 seconds: Changed response time from <2 seconds to <10 seconds.

change:

recommend that, where static values are bulk-uploaded and stored locally in a central data lake solution, rather than calculated real-time via APIs to distributed data systems, the target for view request responses should be 2 seconds.

requirement:

must respond to view requests In <10 seconds (99.9% of view data payloads retrieved from systems and returned to the dashboard that issued the view request returned in <10 seconds) view request response time is the time lapse between receipt of a dashboard view request and return of the view data payload (this includes the authorisation call to the consent and authorisation service to check authorisation of the view request) view response time applies regardless of the view data payload – i.e. whether the values are returned immediately in response to the view request, or whether a 3/10 working day calculation period (as per legislation) applies – if the pension provider uses the permitted 3/10 working day period to calculate the values, the initial view response (comprising of the administrative data and signpost data) must still be <10 seconds


CoCo2.1.4

reason:

PFS design does not currently include queueing find requests

change:

removed erroneous reference to processing backlog; added requirement that no data be lost following AC

requirement:

must restore service within 2 hours in the event of an endpoint outage, without loss of data ACKed before the outage


CoCo2.1.5

reason:

there was some push-back on the service availability requirement in consultation responses. Many respondents sought clarity on whether this was 24/7 or business hours only, with 4 respondents indicating that whilst reasonable for core hours when dashboards may be expected to be used, such a requirement would be unreasonable if 24/7 and there should be a more relaxed SLA overnight, to allow for routine patching windows, database back-up, etc. There were also questions about the availability both of the central digital architecture, and of the PDP helpdesk to assist with identifying where outages are caused by the data provider’s interface vs the central digital architecture and to support resolution of service

pensions dashboards are a digital service, and if the requirement was core hours rather than 24/7, this could have a significant impact on the user experience and the service reputation if users attempt to use dashboards outside of the core hours (since if a data provider’s endpoint is down, find requests/view requests will not be serviced) and we believe 99.5% 24/7 is commensurate with other digital services. CDA will be available 99.5% 24/7, and data providers need to match this – as a digital service, should be available 24/7, not business hours only

overall, more respondents (9) who directly responded to the question about the reasonableness of the proposed requirements indicated that the proposed service levels were reasonable than those who indicated that the proposed requirements were not reasonable/too demanding (4), and most respondents (12) who directly answered the question about whether any of the proposed requirements would pose specific problems said they did not see any specific issues

change:

clarified that this applies to data providers rather than QPDS. Clarified that the requirement is 99.5% 24/7. Removed erroneous reference to unscheduled downtime – 99.5% is required regardless of scheduling, 0.5% downtime includes both scheduled and unscheduled removed erroneous reference to best endeavours out of hours – hours are irrelevant, the requirement is 24/7


CoCo2.2.2

reason:

requirement now redundant, final regulations require providers to de-register the pension identifier as soon as possible if the possible match is resolved not to be a match

change:

guidance only – in the event of no match being made against a find request received (including when a possible match is resolved not to be a match, or is not resolved), the find request should be deleted – or, alternatively, data providers may investigate whether they can store a hash of some of the details used in the search so that 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


CoCo2.2.3

reason:

requirement now redundant, final regulations require the pension provider to re-register the PeI as soon as possible where the member ceases to be a relevant member

change:

guidance only – pension provider matching processes should support multiple concurrent possible matches: matching may identify multiple potential matches for different users for the same pension


CoCo2.2.4

reason:

if the PAT is not expired, the pension provider will not be able to de-register – so PDP needs to know so that we can de-register

change:

added requirement to notify PDP if pension identifier de-registration is not possible, so that PDP can manually de-register


CoCo2.2.1

reason:

clarified that scheduled outages for maintenance still count towards 0.5% allowed downtime

change:

added – wherever possible patches and upgrades should be applied without any service outage, but reasonable exceptions where updates require a short outage to re-boot to apply upgrades may be allowed, with advance notification (such outages nonetheless count towards the 0.5% downtime permissible)


CoCo2.2.5

reason:

moved to guidance, since we don’t have specific requirements here – we are leaving it to providers to judge when to notify us of issues, rather than attempting to set out precise details of exactly when and concerning what providers should notify us of, which would likely miss things – it is preferable to leave it high-level and to provider discretion

change:

moved to guidance rather than specific requirement – should notify PDP of any threats to the performance or security of the ecosystem as soon as they are known and contribute intelligence relating to ecosystem security to the PDP security operating centre, as well as receiving and acting appropriately on any security intelligence received from PDP


CoCo2.2.6

reason:

requirement added to mitigate risk of find requests not being processed without the user’s knowledge, resulting in pensions not being found. PDP may use this information to then notify dashboards users that they may need to re-send find requests if they have/re not sure whether they have a pension with any of the affected providers. Otherwise, the find request will simply have been lost, and there could be pensions missing as a result. Could also be valuable intelligence to pass to regulators (evidence of non-compliance with duties to undertake matching against received find requests)

change:

new requirement


CoCo3.1.1

reason:

consultation respondents queried how routine absences were accounted for

change:

added – recommend sufficient staff are assigned to the required roles to cover routine absences – the PDP Salesforce platform allows the addition of multiple users for a single required role, allowing deputies to act for the required key roles where the primary contact is unavailable


CoCo3.1.2

reason:

new requirement to provide these data items at onboarding

change:

must provide data required to register with PDP (MaPS) as a pension provider: (part) scheme name, customer-facing name(s), dates over which customer-facing name(s) are applicable, regulator-issued registration code, regulator number, regulating body, holder name, holder name view endpoint, and details for the data provider find endpoint, view endpoint, PAT refresh endpoint


CoCo3.1.3

reason:

new requirement to provide these data items at onboarding

change:

must provide data required to register with PDP (MaPS) as a QPDS: regulator-issued registration code, regulator number, dashboard redirect URL, dashboard UMA claims redirect URL


CoCo3.2.1

reason:

added – recommend following ITIL service incident and problem management processes best practice guidance

change:

must have a defined remediation route for service level failures


CoCo3.2.2

reason:

revised to make clearer this pertains to internal issues within a provider

change:

must have internal escalation frameworks and processes and ensure staff know how and to whom internally issues should be escalated and when


CoCo3.2.3

change:

must have a framework for raising issues and monitoring issues to resolution


CoCo3.2.4

reason:

requirement to comply with forensic investigation including mediated access to audit logs was erroneously missing from version consulted on but is needed to support investigation

change:

new requirement to ensure cooperation with investigation


CoCo3.2.5

reason:

If a pension provider must be dis-connected, but was connected via an ISP, PDP cannot disconnect, without also thereby disconnecting all the other clients of that ISP connecting via the same endpoint, putting these other pension providers in breach of their duties – the ISP must disconnect the pension provider requirement added to ensure ISP does so – to be compliant, the pension provider must then contract with the ISP to provide for its disconnection if instructed

change:

new requirement to ensure ISP doesn’t keep a pension provider connected when it shouldn’t


CoCo3.2.6

change:

moved from onboarding to BAU operational standards


CoCo3.2.7

change:

new requirement to ensure registration data is maintained and kept up to date to account for changes to part-schemes, holdernames etc eg due to mergers and acquisitions

Back to top