Reporting standards: Supplementary guidance

RS1.1 Relevant memberships connected

Requirement RS1.1 (as per reporting standards)

• 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:
  1. 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.
  2. 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).
  3. The number of relevant member records that are not connected.
• Points 1 to 3 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 connection provider rather than direct, the pension provider or scheme may need to provide data on relevant memberships to its connection provider, so that the provider 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.

‘Number of connections’

It doesn’t matter how a pension provider or scheme is administered underneath the ISP layer, provided the number of connecting parties supplying data and reporting on behalf of them is provided. For example, if an ISP connects 2 administrators, these need not be counted separately – what matters is the number of separate connecting parties, which in this case would be one ISP.

When it applies

RS1.1. applies when pension providers or schemes connect initially with less than 100% of relevant membership records. A scheme that connected with 100% of members to begin with wouldn’t have to report anything for RS1.1. All others need to report until total coverage is 100%. All third-party connection providers connecting and reporting on behalf of the pension provider or scheme must then report until that provider or scheme’s total connection is 100%, whether or not each third-party connection provider has reached 100% coverage for the part of the provider or scheme it has connected. The pension provider or scheme needs to inform all of its connecting parties when they must report, and when they should stop (when the provider or scheme reaches 100%).

When the provider or scheme reaches 100%, they should report one last time, with reports for RS1.1.(c) set to zero across all connecting parties.

The Financial Conduct Authority’s (FCA’s) modification by consent process

The FCA’s modification by consent enables firms to connect before the deadline in line with ‘connect by’ dates in guidance, even where they are unable to connect and comply with all rules for 100% of their relevant pension scheme members’ data. The FCA generally expects firms using this to be in a position to comply with the rules from connection for at least 80% of members. Where firms make use of this, reporting standard RS1.1. applies in addition to this modification: firms taking advantage of the modification, once connected, must still report coverage to MaPS.

Example: Scheme connected via multiple ISPs

A scheme connects via 2 ISPs.

• ISP A connects the main scheme with 100,000 relevant members. 90,000 members are connected, and the remaining 10,000 are on older system that requires additional technical work to connect.
• ISP B administers and connects the AVCs for this scheme which has 50,000 relevant member records. 100% of the AVC records are connected for this scheme.  

Both ISPs must report against RS1.1. between midnight and 6am on the second working day of each month.

ISP A will report the following information:

• There are 2 connections used by the scheme (it will obtain this from the scheme) (holdername_conn_count: 2) 
• At the previous month end there were:
  • 90,000 relevant members connected for the part of the scheme connected via ISP A (member_count_pass: 90000) 
  • 10,000 relevant members not yet connected for the part of the scheme connected via ISP A (member_count_fail: 10000) 

ISP B will report for its own part of the scheme it connects: 

• There are 2 connections used by the scheme (it will obtain this from the scheme) (holdername_conn_count: 2) 
• At the previous month end there were:
  • 50,000 relevant members connected for the part of the scheme connected via ISP B (member_count_pass: 50000)
  • 0 relevant members not yet connected for the part of the scheme connected via ISP B (member_count_fail: 0) 

Both ISPs would continue to report each month (with ISP B reporting member_count_fail as zero) until both ISPs have 100% coverage for their portion of the scheme. At this point, the scheme will tell both ISPs to report one last time.

This gives the regulators a complete picture of the scheme’s coverage (through PDP reporting linking up data for each holdername GUID for the scheme). 

RS2.1. and 2.2 find and view unavailability

Requirement RS2.1 as per reporting standards

• 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:
  1. Start and end date and time of each instance of scheduled find service unavailability.
  2. Start and end date and time of each instance of unscheduled find service unavailability.
  3. 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

Requirement RS2.2 as per reporting standards

• Applies to: Pension providers and schemes (holdername GUIDs), regardless of connection arrangements, which could be via a 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:
  1. Start and end date and time of each instance of scheduled view service unavailability.
  2. Start and end date and time of each instance of unscheduled view service unavailability.
  3. 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

‘Service unavailability’

The PDP standards’ code of connection (CoCo2.1.5) requires pension providers and schemes to target 99.5% availability 24/7 measured by calendar month. The reporting standards require reporting of any unavailability of the find and view service. These standards align with the requirement in the legislation to remain connected:

Service availability means the service being available to:

• receive find and view requests to endpoints
• process them and comply with all associated requirements including responding to these requests.

Any service interruption caused by PDP system unavailability would not be counted. 

Reasons

Connecting parties need to provide reasons for service unavailability, in agreement with the pension providers or schemes they are connecting on behalf of.

Outages running over midnight

Where the unavailability spans 2 reporting periods this must be reported as 2 separate events – one up to midnight on the first reporting period, and the second from midnight on the second reporting period. 

Outages running when the clocks go forward or backward

Report the start and end times of any unavailability as the actual start and end times. For example, in the case of a 30-minute outage:

• when the clocks go back, the end time would be reported as 30 minutes before the start time
• when the clocks go forward, the end time would be reported as 90 minutes after the start time

‘Scheduled’ unavailability

A minimum of 5 days’ notice should be given for any scheduled unavailability. This advance notice will be covered in separate guidance.

Late reporting 

PDP appreciate that technical issues may make it impossible to submit reporting data within the 6-hour window. PDP will set out guidance for late reporting separately.

Example 1: Scheduled unavailability – centralised data lake ISP

Scheme 1 connects via ISP A, which operates a centralised data lake model. ISP A’s endpoint has been unavailable for scheduled maintenance for 5 minutes, from 1pm to 1:05pm on 1 January 2026.  

Between midnight and 6am on 2 January 2026, ISP A will report: 

• When the outage started (start_date_ts: 2026-01-01T13:00:01.000Z) 
• When service was restored (end_date_ts: 2026-01-01T13:05:01.000Z) 
• That it was scheduled in advance (unavail_schedule: True) 
• The reason (unavail_reason: maintenance) 

Example 2: Unscheduled unavailability – distributed ISP

ISP B connects schemes 2 and 3. It operates a distributed model whereby view data is retrieved from the schemes’ platforms before being returned by the ISP view endpoint. ISP B and scheme 2 were both available all day on 1 January 2026. Scheme 3 had an unscheduled outage – its connection providing view data to the ISP was unavailable for 30 minutes, from 1pm to 1:30pm. 

Between midnight and 6am on 2 January 2026, ISP B will report for RS2.2, for holdername for scheme 3: 

• When the outage started (start_date_ts: 2026-01-01T13:00:01.000Z) 
• When service was restored (end_date_ts: 2026-01-01T13:30:01.000Z) 
• That it was not scheduled in advance (unavail_schedule: False) 
• The reason (unavail_reason: [reason for unexpected outage]) 

Example 3: Unavailability spanning 2 reporting periods

Scheme 4 connects via ISP C. ISP C has a scheduled outage from 11:55pm on 1 January 2026 to 12:05am on 2 January 2026. The outage has spanned two reporting periods and will need to be reported for both, which means that it will appear as 2 distinct unavailability events.

Between midnight and 6am on 2 January 2026, ISP C will report: 

• When the outage started (start_date_ts: 2026-01-01T23:55:00.000Z) 
• When service was restored (end_date_ts: 2026-01-01T23:59:59.999Z) 
• That it was scheduled in advance (unavail_schedule: True) 
• The reason (unavail_reason: maintenance) 

Between midnight and 6am on 3 January 2026, ISP C will report: 

• When the outage started (start_date_ts: 2026-01-02T00:00:00.000Z) 
• When service was restored (end_date_ts: 2026-01-02T00:05:00.000Z) 
• That it was scheduled in advance (unavail_schedule: True) 
• The reason (unavail_reason: maintenance) 

RS3.1 View requests and response times

Requirement RS3.1 as per reporting standards

• Applies to: Pension providers and schemes.
• Requirement: Must report per pension provider or scheme:
  1. Number of view requests received.
  2. For each view response that exceeds 10 seconds, the date and time of both the view request and the view response returned.

Authorised and unauthorised view requests

RS3.1(a) requires the total number of authorised and unauthorised view requests received.

RS3.1(b) requires response times that exceed 10 seconds for authorised requests only.

Where view responses span clocks changing

Provide time and date for each view response exceeding 10 seconds. If the view request and response straddle the change to BST/GMT, it is possible the start time could be after the end time.

Example

ISP has connected a scheme. It received 10,000 view requests on 1 January 2026. Of these, 100 requests did not contain valid access tokens, so are excluded from reporting. Of the remaining 9,900 view requests:

• 9,891 received a response within 10 seconds
• 9 received a response in more than 10 seconds

Of the 9,900 view requests that were authorised, the only response times to be reported are for the 9 responses where the response time exceeded 10 seconds.

Between midnight and 6am on 2 January 2026, the ISP will report for the scheme for RS3.1: 

• Number of view requests received (req_count: 10000) 
• For each of the 9 responses exceeding 10 seconds, date and time of view request and view response. For example: 
  • req_date_ts: 2026-01-01T10:00:00:000Z 
  • resp_date_ts: 2026-01-01T10:00:30:000Z 

RS3.2 Values to be calculated and calculation times

Requirement RS3.2 as per reporting standards

• 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:
  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).
• There are 2 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.

‘Working days’

Working days exclude weekends and bank holidays anywhere in the UK. This includes bank holidays that only apply to one of the UK nations. This is defined in the legislation: see Regulation 26(8)(b) and the FCA rules Annex A.

Calculations made available before the start date

Calculation data may be made available before the calculation start date. For example, if a find request is received and a PeI registered on a Monday, calculation time starts Tuesday. However, the provider or scheme may perform the calculation and make the value data available before the end of the Monday. In this case, calculation start and end date should still be recorded and returned. However, the end date would then be before the start date because the value has been made available before the 3 or 10 working days period has started. 

When to return calculation times for all values to be calculated

The aim of reporting is to track and report the time it takes for each calculation. This is not necessarily the same as view responses. A single view response against a single pension could contain multiple illustrations with multiple values (for example, a recurring income and a lump sum, or distinct tranches of income). It could therefore also have multiple values that are not available immediately and require calculation. In this case, the time taken for each calculation to be performed and the data to be made available should be recorded. Provide as many calculation start and end dates (and DBC or DCC value codes) as required.

Where administrators do all calculations for a benefit at once, a single calculation time should be provided. However, where multiple calculations are required and the calculation time could be different, calculation time for each value to be calculated should be recorded and reported. 

Differences in ISP records and scheme records as to number of benefit illustration components

There should be no difference in scheme records and the records they provide to their ISPs, since the scheme is contracting the ISP to deliver its dashboard functions on its behalf and must therefore provide the data it would be returning were it to connect direct. If something had gone wrong, however, and an ISP had records from the scheme that 2 values would need calculating for a particular member and the scheme only provided a single record (or vice versa), the ISP may need to speak to the scheme to check all values have been provided and whether its records were incorrect. Calculation times should be reported for all actual calculations.

Calculation time when there are multiple find or view requests

The legislation requires the value to be returned immediately where it has been generated for a statement provided to the member within the past 13 months, or is based on a calculation made within the past 12 months, or otherwise within the 3 or 10 working day calculation period. RS3.2 accordingly requires reporting of calculation time (days taken to make the values available), where the values are not available immediately and must be calculated. This is unaffected by any subsequent find or view requests. What is to be recorded and reported is time taken to make data available, where calculations are required. Calculation time starts from the day after the PeI is registered and ends when the calculation has been performed and the values are available for return to the dashboard.

Values not available

Where values are absent because they require calculation, the DBC/DCC codes for data standards 2.301/2.401 should be used.

Where there are other reasons for missing values, the data standards provide for other codes to be used or fields to be populated. It is the pension provider or scheme’s responsibility to determine what data should be returned to its members. 

Example 1: Single calculation required

ISP has connected Scheme 1. The scheme registered 1,000 PeIs in response to find requests on 31 December 2025.

500 were PeIs registered for pensions where there were ERI values available (from benefits statements provided in the last 13 months). These were sent view data tokens including ERI values within 10 seconds of receipt of the view requests.

The remaining 500 did not have ERI values available. They were sent ‘ERI unavailable’ codes, indicating that the scheme needed to calculate the values within 10 working days (as these are defined benefit pensions).

The scheme received 1,000 view requests on the same day – 1 for each of these PeIs. On 16 January, 10 working days after the PeIs were registered, these values have been calculated and are available. 

Between midnight and 6am on 17 January 2026, ISP will report for scheme 1, for each of these 500 values that were unavailable when the view request was made on 31 December 2025 and required calculation: 

• That the benefits were DB (eri_value_code: DBC) 
• The start date for the calculation – the day after the PeI was registered (eri_start_date_ts: 2026-01-01) 
• The end date the calculation was made available (eri_end_date_ts: 2026-16-01) 

Example 2: Multiple values to be calculated

The ISP has also connected Scheme 2. Scheme 2’s members have both a recurring income element and a separately accrued lump sum element, and so it will send 2 benefit illustrations returned in view responses:

• annual income (including ERI and accrued values for this income value)
• lump sum value (including ERI and accrued valued for this lump sum value)

All these values need to be calculated. 

Scheme 2 registered 500 PeIs in response to find requests on 31 December 2025. The scheme received 500 view requests on the same day – 1 for each of these PeIs. The view response returned for all 500 view requests included ERI and accrued unavailable codes, indicating the scheme needed to calculate the values within 10 working days (as these are defined benefit pensions). On 11 January, all of the lump sum values have been calculated, and on 16 January (10 working days after the PeIs were registered), the annual income values have also all been calculated and are available. 

Between midnight and 6am on 12 January 2026, ISP will report for scheme 2, for the lump sum values which are now available: 

• That the benefits were DB (eri_value_code: DBC) 
• The start date for the calculation – the day after the PeI was registered (eri_start_date_ts: 2026-01-01) 
• The end date the calculation was made available (eri_end_date_ts: 2026-11-01) 

Between midnight and 6am on 17 January 2026, ISP will report for scheme 2, for the annual income values, which are now available: 

• That the benefits were DB (eri_value_code: DBC) 
• The start date for the calculation – the day after the PeI was registered (eri_start_date_ts: 2026-01-01) 
• The end date the calculation was made available (eri_end_date_ts: 2026-16-01) 

Example 3: New calculations required long after PeI registered

ISP has also connected Scheme 3. Scheme 3 registered 1,000 PeIs in response to find requests and returned 1,000 view responses on 31 December 2025. All 1,000 view responses had no values available for immediate return and had to be calculated. All were calculated and made available within the permitted 10 working day period. 

A couple of years later, on 31 December 2027, one of these members uses their dashboard to make a view request, for the first time since their first use in 2025. Their values must be calculated again. The scheme cannot calculate the values and make them available within 10 working days of 1 January 2026 (the day after the registration of the pension identifier as a match made). As per CoCo2.1.7, Scheme 3 has 10 working days from the day after the view request is received to perform the calculation and make it available. It performs the calculation and makes it available on 18 January 2028, on the 10th working day from 1 January 2028 (the day after the view request was received). 

The 10-day deadline starts at the first view request where values are not available. If the user submits multiple view requests during the period when values are not yet available, these need not be tracked, and they do not affect the timeframe for calculation, which would remain 3 or 10 working days starting the day after the view request was received. 

Between midnight and 6am on 19 January 2028, the ISP will report for scheme 3, for these values that were unavailable when the view request was made on 31 December 2027 and required calculation: 

• That the benefits were DB (eri_value_code: DBC) 
• The start date for the calculation – the day after the PeI was registered (eri_start_date_ts: 2028-01-01) 
• The end date the calculation was made available (eri_end_date_ts: 2028-18-01) 

RS3.3 Values unavailable

Requirement RS3.3 as per reporting standards

• 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:
  • Item 2.004 (contact pension provider or scheme) is populated ‘true’.
  • Item 2.005 (administrative details not available, new member case) is populated ‘true’.
  • Item 2.006 (temporary system error) is populated 'true'.
  • Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘ANO’.
  • Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘PPF’.
  • Item 2.301 (ERI unavailable)/2.401 (accrued unavailable) is returned as code ‘TRN’.

Multiple codes returned in a single view response

The count of ANO, PPF and TRN is just a count of number of times each code is sent, not number of view responses. A single view response could contain multiple codes. In this case, each use should be recorded: record and report all times each code has been returned.

Example

ISP has connected a scheme, and this scheme issued 1,000 view responses on 1 January 2026. Of these: 

• 10 were returned with data standard 2.004 (contact pension provider or scheme) populated as ‘True’.
• 10 were returned with data standard 2.005 (administrative details not available, new member case) populated as ‘True’.
• None were returned with data standard 2.006 (temporary system error) populated as ‘True’.
• There were 5 occasions when data standard 2.301 (ERI unavailable) was returned as code ‘ANO’. This could represent (for example):  
  • 5 different view responses for 5 separate PeIs 
  • 5 view responses for the same PeI, or  
  • 4 different view responses for 4 different PeIs, one of which included 2 benefit illustrations, with both returned as unavailable - ANO)
• None were returned with data standard 2.301 (ERI unavailable) populated as code ‘PPF’.
• There were 10 occasions when data standard 2.301 (ERI unavailable) was populated as code ‘TRN’.
• There were 5 occasions when data standard 2.401 (accrued unavailable) was returned as code ‘ANO’.
• None were returned with data standard 2.401 (accrued unavailable) populated as code ‘PPF’.
• There were 10 occasions when data standard 2.401 (accrued unavailable) was returned as code ‘TRN’.

Between midnight and 6am on 16 January 2026, ISP will report for scheme: 

• contact_count: 10 
• missingadmin_count: 10 
• temperror_count: 0 
• eri_unavail_ano_count: 5 
• eri_unavail_ppf_count: 0 
• eri_unavail_trn_count: 10 
• accrued_unavail_ano_count: 5 
• accrued_unavail_ppf_count: 0 
• accrued_unavail_trn_count: 10