Approach to governance of standards


The Pension Schemes Act 2021 delegates authority to the Money and Pensions Service (MaPS) to set standards, specifications, and technical requirements (which we refer to as standards) for pensions dashboards ecosystem participants. This includes:

  • pension providers – trustees and managers of occupational pension schemes and managers of stakeholder and personal pension schemes
  • those acting on behalf of pension providers – such as integrated service providers (ISPs) (who are also included with pension providers in our term data providers)
  • providers of qualifying pensions dashboard services (QPDS)

The Pensions Dashboards Programme (PDP) has produced these standards as part of MaPS, and references to PDP in any of the documents should be read as ‘PDP as part of MaPS’.

The purpose of these standards is to ensure the security, stability, and effective operation of the ecosystem. They set out the technical and operational detail underpinning the primary and secondary legislation and the Financial Conduct Authority (FCA) rules. Standards are separate from, but designed to complement, the FCA’s regulatory framework. As the FCA regulates the conduct of firms carrying out an activity, the FCA’s Handbook rules will apply to QPDS firms and can impose standards on those firms (aligned to FCA’s statutory objectives) when carrying out the qualifying pensions dashboard service. The FCA will consult on its proposed Handbook rules in due course.

Standards also provide more flexibility, allowing for further iteration and development as the service matures. As a digital service, the pensions dashboards ecosystem needs to be able to implement changes in service requirements in a simple and timely manner.

These standards will be mandatory requirements for QPDS and all pension providers (who are required to connect to our ecosystem). They detail how operationally, technically or in practice ecosystem participants must meet the duties set out in the relevant regulations and rules. They are necessary to ensure the ecosystem functions effectively and efficiently, and to ensure the interests of consumers are put first.

To further support QPDS and pensions providers were issuing guidance. References to our guidance on this page are for background purposes. Because of the importance of the standards for the security, stability and credibility of pensions dashboards, non-compliance could lead to disconnection from the pensions dashboards ecosystem. In addition, failure to adhere to the standards and consider/have regard to guidance will be evidence of breach of legal duties and may be used by the FCA or The Pensions Regulator (TPR) in any regulatory action. 

Content of the standards

Standards and guidance:

  • data standards – the data formatting requirements pension providers must follow when returning pensions data
  • design standards – requirements for presentation of the pensions data on dashboards and design of the dashboards, including; messaging, signposting, onward customer journeys  
  • reporting standards – the data required from QPDS and pension providers to monitor the health of the pensions dashboards ecosystem, compliance and performance
  • technical (and API) standards – the requirements for how pension providers and QPDS interface with the central digital architecture and with each other, including connectivity mechanisms, protocols for authorising the sharing of information, and the generation and registration of pension identifiers (PeIs)

Code of connection: 

  • security standards – the technical and procedural standards to ensure security of the ecosystem
  • service standards – the technical and procedural minimum service requirements including; service availability and response times, connection state changes (including planned interruption to information technology systems) and notification requirements
  • operational standards – the operational processes participants must follow to connect to the ecosystem and to maintain connection, including; onboarding procedures, dispute management and escalation, and service level failure protocols


Where possible, PDP have harmonised procedures and rules, to simplify governance of the standards and make them as simple to adhere to as possible, whilst ensuring they will deliver ecosystem security, stability, and effectiveness.

The approach to governance is detailed in the following section:

Initial setting

PDP have developed the initial standards in collaboration with industry and consulted on them. The final version will be approved by the Secretary of State for Work and Pensions.

Subsequent changes

Source of change

Changes to standards have several drivers and sources:

  • new or amendments to existing legislation – which either indirectly or directly impacts the standards and guidance
  • changes to third party standards – where third party standards are being leveraged then should they change; any impact would need to be reviewed
  • PDP (including those by our supplier) – continuous improvement and product evolution including user testing
  • those required by regulators
  • appropriate changes identified by the community – recommendations by participants or because of testing

Whilst this list is not exhaustive, it illustrates the diverse of sources of change.

How to request a change

All requests to change a standard must come through our governance process where they will be evaluated for impact and benefit. As our part of governance process, we will consider who to engage with. This may include; TPR, FCA, DWP (Department for Work and Pensions) and industry stakeholders and the participant community.

Decision makers

Once the change proposal is at the required level of detail the following will be responsible for approving the change to be implemented:

  • PDP – for minor technical changes
  • Secretary of State (SoS) – for all other changes

Change management


Changes fall into two camps: minor and major. Minor are changes that do not impact all participants or have minimal impact on all participants.

Examples of minor change that affects all participants:

  • additional testing requirements within the code of connection
  • technical addition of a new API
  • change to optional element of data standards whilst remaining optional

When publicising these changes, we will explain how we have assessed these changes as minor. When assessing whether a change is minor, we will review the impact at a pension and QPDS level.

Major changes will be consulted on. Examples of major changes could include:  

  • technological developments (incurring significant pension provider or QPDS resource to implement)
  • changes in the way the schemes are required to connect and receive or return information (eg an upgrade of the API standard to a newer technology stack, or the use of new security software)
  • substantial changes to business processes required to meet duties (eg additional reporting requirements that mean pension providers or QPDS are required to supply significantly more information, or more regular reports to PDP for monitoring purposes)


The government has issued consultation principles and we will follow them, where applicable.

Notification period

Where possible this will be 12 months for major and six months for minor changes.

Implementation frequency

To assist those implementing the standards with their planning, updates will be applied annually for major, and bi-annually for minor changes.

  • major and minor – October
  • minor only – April

More frequent updates may be applied in an emergency. This is classified as something required to maintain the security or integrity of the ecosystem and as much notice as can be allowed will be provided given the circumstances.

During the initial launch of pensions dashboards there may be a need to have more regular change cycles.


To ensure each version is clearly recognisable and auditable the following versioning numbering will be applied:

  • primary version – whole number indicating the major standards release
  • secondary version – a branch of the primary version all branches must be backwards compatible with the primary version

Example would be – version 3.2

Deprecation and compatibility

Once a standard has moved to the next primary standards release then the old standard and all branches attached will be retired at the point the primary standard is implemented.

All live branch versions must be support below the branch number the participant has chosen to implement.


Live standards versions – 3.0, 3.2, 3.3

If a participant chooses to adopt 3.2, they must also support 3.0, but do not need to support 3.3


Third party standards

Where third party standards are used when connecting to the central technical architecture, PDP will review regularly to ensure they remain current, appropriate, and usable by QPDS and pension providers. Where appropriate PDP will actively engage with the third-party standards providers to explain the effect changes to their standards may have on ecosystem participants.


Standards will be used to check QPDS and pension provider compliance with, amongst other things, their dashboard connection and reporting obligations.

Where appropriate, we will work with QPDS and pension providers to help reconcile any potential compliance issues. However, as adherence to the standards is an important requirement, and vital to the security, stability, and credibility of the pensions dashboards ecosystem, we will also put in place processes to escalate all breaches we identify to FCA/TPR.

Failure to adhere to our standards, or have regard to our guidance, can be used as evidence of breach of legal duties and may be used by the FCA or TPR in any regulatory action. Also, we reserve the right to disconnect any QPDS or pension provider the ecosystem for breaching their dashboard duties, which for pension providers would mean they would not be able to meet these obligations.

Curation (notification, publication)

Publication – MaPS will be responsible for publishing the standards (currently on the PDP website)

Notifications – we will provide further details on how we will notify ecosystem participants for the following changes:

  • urgent – requires action immediately
  • notification – something that people need to know and may require action
  • information – for information