The Government has restated its commitment to delivering pensions dashboards in a written statement.
Reporting standards draft consultation
Introduction
See the draft version 2.2 of the reporting standards.
The consultation is now closed.
1. 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.
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. This includes setting standards.
3. MaPS is empowered to publish standards relating to the practical operation of pensions dashboards services and the digital infrastructure needed to support them. This is a power delegated to MaPS 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’).
4. MaPS published standards including reporting standards approved by the Secretary of State for Work and Pensions and the Department for Communities (Northern Ireland) in March 2025. As such, these standards are part of the legislative framework for pensions dashboards and connected pension providers’ and schemes’ compliance with them is compulsory.
Why we are consulting
5. This paper sets out our proposals to update the reporting standards to implement routine daily reporting of data to MaPS via API. An API is an application programming interface – a set of rules and protocols that enables different software applications to communicate with each other.
6. The reporting standards set out requirements on pension providers and schemes for generating and recording operational information and reporting it to MaPS on a regular basis. The information supports the oversight and management of the dashboards ecosystem and compliance monitoring and enforcement.
7. The current reporting standards, published in March 2025, require only the generation and retention of records for the data requirements specified, and that these records must be made available to MaPS on request. However, the publication made clear MaPS’ intention to implement (at a later date) routine reporting of this information to MaPS via API, and indicated the expected frequency for this (daily). This reiterated the intention as stated in previous publications, including in our 2022 consultation on draft standards, that once implemented, reporting would be daily, via API.
8. This consultation now seeks views on proposals for the implementation of reporting APIs. The draft revised standards that embody these proposals would require all connected pension providers and schemes to submit reporting data on a daily basis.
Who this consultation applies to
9. This consultation is primarily aimed at parties affected by the proposed changes to the reporting standards who will be accountable for compliance with the updated reporting standards or who will implement the changes in practice on their behalf:
- Pension provider and scheme managers and trustees
- Third-party administrators
- Third-party connection providers
10. It may also be relevant to stakeholders in the broader pensions sector, including trade bodies representing pension providers and schemes and administrators, pensions administration bodies, and other bodies representing pension professionals. We welcome views from any interested parties.
What we want to change
11. The reporting standards cover requirements in relation to generating and reporting data about:
- Coverage of relevant member records
- Service availability for find and view
- View requests and responses, including offline calculations performed and returns of value data unavailable codes
12. Our proposals concern only the mechanism and the technical requirements and business rules for reporting this data to MaPS, moving from ad hoc on-request reporting to implementing daily reporting by API. The existing reporting standards were developed through engagement with industry over years, including formal consultation in 2022 as well as further iteration, publications, and engagement before we finalised the requirements. The reporting standards were approved by the Secretary of State for Work and Pensions and the Department for Communities (Northern Ireland) and published in March 2025, becoming legally binding. We do not propose to change any of the fundamental data requirements for what must be recorded and reported as set out in the current reporting standards.
13. Our proposals for automated reporting via API cover the reporting standards 2.1 (find service unavailability), 2.2 (view service unavailability), 3.1 (view requests and response times), 3.2 (value data calculation times), and 3.3 (values unavailable) but exclude RS1.1 (coverage – relevant memberships connected). We have de-scoped the latter from automated reporting on the basis that it is a time-limited requirement which ceases to apply beyond 31 October 2026 and the effort to implement reporting via API for this would be disproportionate.
14. Reporting of coverage data for RS1.1 will therefore remain as set out in the existing approved reporting standards: a requirement to retain records to be made available to MaPS upon request on an ad hoc basis, up to 31 October 2026. Our proposals here for automated daily API-based reporting therefore do not affect RS1.1, for which the requirements will remain exactly as set out in the approved reporting standards version 2.0 as published in March 2025.
General requirements for reporting
15. Once implemented, the updated reporting standards will require all of the other required reporting data to be submitted to MaPS via reporting API on a daily basis, between midnight and 6:00am for the previous day’s events.
16. This will require each connected party to submit data for every connected pension provider or scheme, or part thereof, as represented by an active holdernameGuid in the connection portal, to the CDA reporting API using distinct endpoints for each reporting standard.
17. For data completeness, our proposals include that daily submissions for all reporting standards except RS1.1 will be required, even if there is no reportable data. In such cases, a ‘null submission’ will be required. This is to support identification of missing data, distinguishing this from a report to confirm the absence of reportable data.
18. Our proposals provide for record resubmissions in the case of data errors being identified by pension providers and schemes after a report has been submitted. In such cases, the resubmitted records must fully replace the erroneous records.
19. We propose to require a submission status to be provided as part of the submission of reporting data to MaPS, identifying whether it is on time, late, or a correction. ‘On time’ refers to the submission being first attempted within the specified reporting window – even if, due to retriable errors being received from the CDA reporting API endpoint, the record is actually received by the CDA outside of that window.
Clarification to reporting of calculation times
20. We have identified an ambiguity in the wording of RS3.2 which we propose to address to clarify and make explicit when calculation times must be reported. Value data calculation time only needs to be reported for standard cases where pension providers and schemes use the 3 or 10 working day calculation time as permitted by the legislation. This would be where there are no recent (from a statement in the last 13 months or calculation within the last 12 months) values available to return immediately. In these cases, the data standards 2.301/401 ERI/accrued unavailable codes ‘DCC’ and ‘DBC’ are used. In all other cases, where other unavailable codes are returned, calculation time need not be reported. Counts of specified other codes must be reported as per RS3.3, however.
21. Pension providers and schemes should note that the value data required and the timeframe for returning it is determined by the legislation based on the nature of the benefits provided to the member under the scheme. The timeframe starts the day after the registration of the pension identifier as a match made (or updating of a possible match to a match made), not from the return of an unavailable code in response to a view request against that pension identifier. Some specific legislative exemption may apply, such as the period allowed by the legislation before providing data for a new member, or the exemptions from providing projected values for DC benefits in the circumstances for which codes ‘DCHA’ or ‘DCHP’ are provided. Unless such an explicit exemption applies, pension providers and schemes have duties under the legislation to calculate the values within the prescribed timeframe. This duty is not annulled by returning an unavailable code. Even though calculation times need not be reported for cases other than 'DCC' or 'DBC' cases under the reporting standards, pension providers and schemes will need to ensure they keep records to be able to demonstrate they have the appropriate processes in place to provide the value data required by the legislation to members in a timely manner.
Reporting build time
22. To implement daily reporting, all pension providers and schemes (or their third-party connection providers) connected to the ecosystem must build reporting systems capable of calling the CDA reporting API, building against the MaPS API specification.
23. We engaged with directly connected parties in the autumn of 2025 to understand estimated build time, based on the technical API specifications. Estimates we received in response indicated that completing the reporting system builds would take up to 4 months to complete.
24. Our own CDA reporting API build-time estimate is similarly around 4 months, with the CDA reporting API build expected to complete in time to support testing with connected parties in summer 2026.
Testing requirements
25. Implementing these updated reporting standards will require all connected parties to undergo testing to prove successful integration to the CDA reporting API and compliance with all the requirements for reporting.
26. Connected parties will need to undergo the following testing:
- System testing: This is performed by the connected party within its own testing environment, using a MaPS-provided test harness or stubbed application and test pack, including defined test scenarios to be performed using test scripts defining the outcomes to be achieved. Schema validation for each reporting endpoint, to evidence that the test harness or stubbed application returned the correct responses to attempted reporting-record submissions, will need to be evidenced. This will require submitting evidence to MaPS through the connection portal. Internal system testing evidence will need to demonstrate that the party has completed all tests successfully before MaPS approves its promotion to connect to the pre-production environment to undertake integration testing.
- Integration testing: This is performed within the MaPS-provided pre-production CDA environment, within a scheduled testing window. The connecting party will need to connect to the CDA reporting API endpoints and execute test scripts. Test reports will then need to be submitted to MaPS through the connection portal. The reporting data submitted will also be checked by MaPS against the connecting party’s source data. Once approved by MaPS as having passed integration testing, the connecting party will be promoted to the production environment.
- Production monitoring: Once the connecting party has passed integration testing and been promoted to the production environment, it will need to pass a production monitoring phase, in which MaPS will perform monitoring and data checks on the data being submitted to the production environment CDA reporting API.
Approach to implementation
27. We intend to approach implementation of automated reporting by pension providers and schemes in a similar way to the approach we took towards their initial connection to the ecosystem, with early voluntary implementation by directly connected parties taking place ahead of mandatory implementation. The mandatory implementation date will be when the updated reporting standards would take legal effect, requiring daily submission of data to MaPS.
28. It will not be possible for all parties to undergo testing and implement reporting in production simultaneously; this will need to be staggered. All directly connecting parties will need to work with MaPS to connect to the pre-production environment to undergo integration testing in sequence, based on the party’s readiness (as evidenced by internal system testing).
29. We therefore expect to work with parties to implement their reporting by API ahead of the formal implementation date. The latter will be the last date by which all testing must have been completed and daily reporting implemented. Failure to have implemented daily reporting in production by this date will mean the pension providers or schemes will be non-compliant.
30. In practice, we expect to have worked with all directly connected parties to have implemented API reporting in advance of this deadline. We believe our proposed implementation deadline allows for sufficient time for all parties to undergo all building and testing in advance of compulsory reporting coming into effect.
Mandatory implementation date
31. The data covered in the reporting standards is important for informing the Secretary of State’s determination of the readiness of the dashboards service for the launch of the MoneyHelper Pensions Dashboard to the public. It is also important to provide regulators with the data they need to perform their functions in respect of oversight and enforcement of compliance by pension providers and schemes.
32. We therefore propose to implement the updated standards, with the requirement to have undergone all testing and to be submitting data by API on a daily basis by 30 November 2026.
33. Given the importance of this data for determining the readiness of the service for launch to the public, if this implementation date were to be later, this would mean that MaPS would need to collect the data manually on request more frequently leading up to the service readiness assessment, leading to administrative overheads for industry and MaPS. We propose to implement the automated reporting of this data via API by 30 November 2026 to ensure MaPS, the regulators, and the Department for Work and Pensions (DWP) have the necessary data to inform the determination of the launch of the MoneyHelper Pensions Dashboard.
About this consultation
When to respond by
This consultation opened on 28 January 2026 and closed on 30 April 2026.
How to respond
The consultation is now closed.
How we will use consultation responses
The information you send to us may need to be passed to colleagues within PDP/MaPS. It may be published in a summary of responses received and referred to in the published consultation response. We may also share information with our key delivery partners: the FCA, The Pensions Regulator (TPR) and the DWP. All information contained in your response, including personal information, may be subject to publication or disclosure, if requested under the Freedom of Information Act 2000.
By providing personal information for the purposes of the public consultation exercise, you consent to its disclosure and publication. If this is not the case, you should limit any personal information provided, or remove it completely. If you want the information in your response to the consultation to be kept confidential, you should explain why as part of your response – although we cannot guarantee to do this.
This consultation is being conducted in line with the Cabinet Office consultation principles.
Next steps
Following this consultation, we will consider responses and publish a response, as well as publishing final reporting standards requirements, confirming the implementation deadline. As we have done previously for standards prior to their approval by the Secretary of State and Department for Communities, we will clearly identify the final requirements as ‘draft’ until approved. Once approved, we will publish the updated reporting standards, which will then take legal effect from the implementation date.
List of consultation questions
- We propose an implementation date of 30 November 2026 by which time every connected pension provider and scheme must have completed requisite testing and be submitting reporting data daily to MaPS within the prescribed daily reporting window. Considering our proposed technical specification and testing requirements, do you agree this is deliverable, proportionate and reasonable?
- What challenges, if any, do you anticipate facing in meeting the implementation deadline?
- Do you agree our proposed approach to testing and voluntary implementation by connecting parties in sequence in advance of the mandatory deadline is deliverable, proportionate and reasonable? Do you envisage any challenges?
- Author:
- Pensions Dashboards Programme
Published: 28 January 2026
Last updated: 05 May 2026