Reporting 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.

Introduction

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 as well as any occupational and personal pensions. This supports individuals’ engagement with their pensions and their planning for retirement.

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 also 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 pensions dashboards across thousands of pension providers and schemes. Find out more about the pensions dashboards ecosystem and its components.

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

Purpose

5. These reporting standards are 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 Rules of the Financial Conduct Authority (FCA) (hereafter ‘Rules’).

6. The reporting standards set out requirements on pension providers and schemes for generating and recording operational information and (later) reporting it to MaPS on a regular basis. The information will support the oversight and management of the dashboards ecosystem and compliance monitoring and enforcement.

Application

7. 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.

8. Information provided in accordance with these standards must be provided at the level of an occupational pension scheme (identified by a Pension Scheme Registry (PSR) number) or personal pension provider (identified by a Firm Reference Number (FRN)). Regardless of which party is sending the data, a single connected party may send reporting data for multiple providers or schemes that are connected by means of that connecting party. Each report must include the relevant holdername GUID (the unique identifier provided by the pension provider or scheme during connection, see technical standards) for the pension provider or scheme to whom the data relates, identifying a regulated entity and the endpoint serving data for it.

Note: An endpoint is the specific location within an API that accepts requests and sends back responses allowing the system components to communicate with each other.

9. The pension provider or scheme is responsible for compliance with the standards, even if implementation is delegated to a third party. It is therefore important for pension providers and schemes to understand the standards whether they are connecting directly to the ecosystem, or connecting using a third-party supplier such as a third-party administrator or software provider (integrated service providers, or ISPs). In the latter case, the third parties will apply the standards by sending the data to MaPS on behalf of their client pension providers and schemes. A pension provider or scheme connecting via an already connected third party will use the third party’s processes to meet these standards. When referring to pension providers and schemes, this includes any of these third parties.

10. Where a provider or scheme has split administration (for example, a main scheme and a separate AVC provider), and is connecting to the dashboards ecosystem via multiple connections to the ecosystem, reporting for that pension provider/scheme in accordance with these reporting standards must be via each connecting party that is connected and supplying data on behalf of the scheme. Each connecting party must provide data against all of the requirements in the reporting standards for the part of the scheme’s connection that connecting party represents.

Jurisdiction

11. These standards apply to all United Kingdom pension providers subject to the dashboard duties in the Financial Conduct Authority (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 code of connection).

Compliance

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

Version

14. This is version 1.2 of the draft reporting standards. Refer to the changelog for updates since the last publication.

Summary

15. These standards cover requirements in relation to retaining records and (later) reporting data about:

1. Coverage
2. Service availability
3. View responses

16. From April 2025, when pension providers and schemes start connecting in line with the ‘connect by' dates in guidance, the reporting standards require only the generation and keeping of records to be made available to MaPS or regulators upon request, not the routine reporting of this data to MaPS.

17. At a later date (to be confirmed, but not expected to be before October 2025), and with sufficient advance notice, these standards will take effect as requirements for routine reporting of this data to MaPS. Open API specifications and JSON schemas for this will be published at a later date.

18. Pension providers and schemes should note that the data to be sent to MaPS in accordance with these reporting standards will not be the only source of information about compliance. During the period that routine reporting of this information to MaPS is not implemented, regulators will still have access to other data relating to providers’ and schemes’ compliance. MaPS obtains this information directly through the connection service and management of the central digital architecture as well as the MoneyHelper dashboard.

1. Coverage

RS.1.1 Relevant memberships connected

• Applies to: Pension providers and schemes, where, once connected, less than 100% of relevant membership records per provider or scheme (at holdername GUID level) are initially connected.
• Requirement: Must record:

a. The total number of connections (ISPs, or combination of ISPs and direct connection) used by the pension provider or scheme to connect to the dashboards ecosystem.

b. The number of relevant member records that are connected for find and view through the connecting organisation sending the data (where ‘connected’ means all records for these members are available).

c. The number of relevant member records that are not connected.

Points a to c must be recorded up until the connection of 100% of relevant membership records per provider or scheme (at holdername GUID level), at which point this requirement ceases to apply, or until 1 November 2026, whichever is first.

If a connection is via a third-party supplier rather than direct, the pension provider or scheme may need to provide data on relevant memberships to its supplier, so that the supplier can report on its behalf.

Where a provider or scheme acquires a new book of business before 1 November 2026 which then reduces connected records to less than 100%, the memberships connected/not connected monthly report requirement is reactivated until 100% is reached again.

• Frequency: Reported between midnight and 06:00am on the second working day of each month, for the total number of memberships connected and not connected as at the previous month end. Applies once the regular reporting requirement is implemented.
• Rationale:
  • Ecosystem management: MaPS needs to know membership coverage. It will be essential to MaPS and regulators’ advice to the Secretary of State for Work and Pensions on the determination of the dashboards available point.
  • Compliance: Legislation will require all membership records to be available, though it is anticipated that, initially, some pension providers and schemes will connect with less than 100% coverage. In these cases, data is needed on what proportion of memberships are available over time, until 100% is reached. This should be reported to the regulators, as per regulatory requirements. From 1 November 2026, there is no requirement to report this to MaPS, but it must be reported to the appropriate regulator. See FCA’s modification by consent and TPR breach of law reporting requirements.
  • API: Coverage API.

2. Service availability

RS2.1 Find unavailability

• Applies to: Pension providers and schemes (holdername GUIDs), regardless of connection arrangements which could be third-party or direct, or number of regulated entities serviced by a single find endpoint.
• Requirement: Must report, per pension provider or scheme, per calendar month:

a. Start and end date and time of each instance of scheduled find service unavailability.

b. Start and end date and time of each instance of unscheduled find service unavailability.

c. Reason for each instance of unavailability.

• Assess this by aggregating the unavailability of:
  • the provider or scheme
  • the find endpoint, if different
  • any relevant intermediaries, if there are any
• Frequency: Daily between midnight and 06:00am for the previous day, once the regular reporting requirement is implemented.
• Rationale:
  • Compliance: In accordance with legislation, pension providers and schemes are expected to remain connected at all times. The code of connection requires 99.5% service availability per calendar month (CoCo2.1.5), service restoration within 2 hours in the case of endpoint outage (CoCo2.1.4), and 5 days’ notice for scheduled service unavailability (CoCo2.2.1).
• API: Pension provider or scheme availability API.

RS2.2 View unavailability

• Applies to: Pension providers and schemes (holdername GUIDs), regardless of connection arrangements, which could be third-party or direct, or number of regulated entities serviced by a single view endpoint.
• Requirement: Must report, per pension provider or scheme, per calendar month:

a. Start and end date and time of each instance of scheduled view service unavailability.

b. Start and end date and time of each instance of unscheduled view service unavailability.

c. Reason for each instance of unavailability.

• Assess this by aggregating the unavailability of:
  • the provider or scheme
  • the find endpoint, if different
  • any relevant intermediaries, if there are any
• Frequency: Daily between midnight and 06:00am for the previous day, once the regular reporting requirement is implemented.
• Rationale:
  • Compliance: In accordance with legislation, pension providers and schemes are expected to remain connected at all times. The code of connection requires 99.5% service availability per calendar month (CoCo2.1.5).
• API: Pension provider/scheme availability API.

3. View responses

RS3.1 View request numbers and response times

• Applies to: Pension providers and schemes.
• Requirement: Must report per pension provider or scheme:

a. Number of view requests received.

b. For each view response that exceeds 10 seconds, the date and time of both the view request and the view response returned.

• Frequency: Daily between midnight and 06:00am for the previous day, once the regular reporting requirement is implemented.
• Rationale:
  • Compliance: The code of connection CoCo2.1.3 requires 99.9% of view responses to be sent within 10 seconds of receipt of the view request measured over a 24-hour period (CoCo2.1.3).
• API: View response API.

RS3.2 Values to be calculated and calculation times

• Applies to: Pension providers and schemes.
• Requirement: Must report per pension provider or scheme, each instance where at least one ERI value or accrued value is not available for immediate return, reporting after the event, once the calculation has been performed and made available. For each instance of the data not being initially available for immediate return but rather requiring calculation:

a. Whether all the benefits for which calculations are required are defined contribution (DC), or not, by reporting the unavailable code returned as per the data standards (codes ‘DBC’/’DCC’ for data standards 2.301/2.401).

b. The calculation time (time taken for the data to be available for return).

There are two separate points when the clock starts for the time taken for the data to be made available. Providers and schemes will need to differentiate these to report calculation time:

1. For the first calculations required following registration of the pension identifier, calculation time is measured from the day after the registration of the pension identifier as a match made.
2. For subsequent calculations required, calculation time is measured from the day after the receipt of the view request.

• Frequency: Daily between midnight and 06:00am for the previous day, once the regular reporting requirement is implemented.
• Rationale:
  • Compliance: The legislation (Regulation 26(5)(b)(i) and (ii); COBS 19.11.29) requires that where view data is not available for immediate return and must be calculated, calculations must be available within 3/10 working days, from the day after the day the pension identifier is registered as a match made (or reregistered as a match made, having previously been registered as a possible match). CoCo2.1.3 specifies where a subsequent view request is received and a new calculation is required, calculations must be made in the same timeframe, starting from the day after the receipt of the view request, rather than the day after the registration of the pension identifier.
• API: Value data unavailable API.

RS3.3 Values unavailable

• Applies to: Pension providers and schemes.
• Requirement: Must report per pension provider or scheme the total number of returns in view data responses of each of the data standards codes below:

a. Item 2.004 (contact pension provider or scheme) is populated ‘true’.

b. Item 2.005 (administrative details not available, new member case) is populated ‘true’.

c. Item 2.006 (temporary system error) is populated 'true'.

d. Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘ANO’.

e. Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘PPF’.

f. Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘TRN’.

• Frequency: Daily between midnight and 06:00am for the previous day, once the regular reporting requirement is implemented.
• Rationale:
  • Compliance: These codes define circumstances where values are not returned.
• API: Value data unavailable API.

Technical annex

The technical annex provides pension providers and schemes with visibility of the data format and values required for each reporting standard. This will enable providers and schemes to store necessary data to support compliance ahead of reporting schemas and APIs specifications becoming available.

Coverage – RS.1.1 Relevant memberships connected

Field name: holdername_conn_count

Data type: Integer.

Mandatory: Yes.

Description: Must report the total number of connections (ISPs, or combination of ISPs and direct connection) used by the pension provider or scheme to connect to the dashboards ecosystem. As PDP connects at holdername level, the field is named holdername_conn_count.

Field name: member_count_total

Data type: Integer.

Mandatory: Yes.

Description: Must report total number of relevant member count, held by the provider or scheme.

Field name: member_count_pass

Data type: Integer.

Mandatory: Yes.

Description: Must report the number of relevant member records that are connected for find and view through the connecting organisation sending the data.

Field name: member_count_fail

Data type: Integer.

Mandatory: Yes.

Description: Must report the number of relevant member records that are not connected.

Service availability – RS.2.1 Find unavailability

Field name: start_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme, per calendar month the start date and time of each instance of find service unavailability.

Field name: end_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme, per calendar month the end date and time of each instance of find service unavailability.

Field name: unavail_schedule

Data type: Boolean (‘true’ or ‘false’).

Mandatory: Yes.

Description:

• False: Unplanned unavailability.
• True: Planned unavailability.

Field name: unavail_reason

Data type: Free text.

Mandatory: Yes.

Description: Must report reason for unavailability.

Service availability – RS.2.2 View unavailability

Field name: start_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme, per calendar month the start date and time of each instance of view service unavailability.

Field name: end_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme, per calendar month the end date and time of each instance of view service unavailability.

Field name: unavail_schedule

Data type: Boolean (‘true’ or ‘false’).

Mandatory: Yes.

Description:

• False: Unplanned unavailability.
• True: Planned unavailability.

Field name: unavail_reason

Data type: Free text.

Mandatory: Yes.

Description: Must report reason for unavailability.

View response – RS.3.1 View request numbers and response times

Field name: req_count

Data type: Integer.

Mandatory: Yes.

Description: Must report per pension provider or scheme the number of view requests received.

Field name: req_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme for each view response that exceeds 10 seconds, the date and time of the view request.

Field name: resp_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Must report per pension provider or scheme for each view response that exceeds 10 seconds, the date and time of the view request.

Field name: resp_status

Data type: Boolean (‘true’ or ‘false’).

Mandatory: Yes.

Description: Status of the view response:

• False: No view response was returned.
• True: View response was returned.

View response – RS.3.2 Values to be calculated and calculation times

Field name: eri_value_code

Data type: Enumerated list.

Mandatory: Yes.

Description: Must report per pension provider or scheme, each instance where at least one ERI value or accrued value is not available for immediate return, reporting after the event, once the calculation has been performed and made available. For each instance of the data not being initially available for immediate return but rather requiring calculation:

1. Whether all the benefits for which calculations are required are defined contribution (DC), or not, by reporting the unavailable code returned as per the data standards (codes ‘DBC’/’DCC’ for data standards 2.301/2.401).
2. The calculation time (time taken for the data to be available for return).

Field name: eri_start_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Start date/time for the calculation countdown clock.

Field name: eri_end_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: End date/time for the calculation countdown clock.

Field name: accrued_value_code

Data type: Enumerated list

Mandatory: Yes.

Description: Must report per pension provider or scheme, each instance where at least one ERI value or accrued value is not available for immediate return, reporting after the event, once the calculation has been performed and made available. For each instance of the data not being initially available for immediate return but rather requiring calculation:

1. Whether all the benefits for which calculations are required are defined contribution (DC), or not, by reporting the unavailable code returned as per the data standards (codes ‘DBC’/’DCC’ for data standards 2.301/2.401).
2. The calculation time (time taken for the data to be available for return).

Field name: accrued_start_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: Start date/time for the calculation countdown clock.

Field name: accrued_end_date_ts

Data type: Date/time - ISO8601 format. For example, 2021-11-25T14:24:01.248Z.

Mandatory: Yes.

Description: End date/time for the calculation countdown clock.

View response – RS.3.3 Values unavailable

Field name: isp_count

Data type: Integer.

Mandatory: Yes.

Description: Total view responses for item 2.004 (contact pension provider or scheme) is populated ‘true’.

Field name: missingadmin_count

Data type: Integer.

Mandatory: Yes.

Description: Total view responses for item 2.005 (administrative details not available, new member case) is populated ‘true’.

Field name: temperror_count

Data type: Integer.

Mandatory: Yes.

Description: Total view responses item 2.006 (temporary system error) is populated 'true'.

Field name: eri_unavail_ano_count

Data type: Integer

Mandatory: Yes.

Description: Total view responses item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘ANO’.

Field name: eri_unavail_ppf_count

Data type: Integer.

Mandatory: Yes.

Description: Total view responses item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘PPF’.

Field name: eri_unavail_trn_count

Data type: Integer.

Mandatory: Yes.

Description: Total view responses item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘TRN’.

Corrections log (errata)

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

Changelog

First published:19/07/2022

Last updated:19/11/2024