DWP has released a written ministerial statement that affects the connection deadline for pensions dashboards.
Additional guidance will be published in due course.

 

Standards webinar: data, reporting and technical Q&As

This webinar provided an overview of the amendments to data, reporting and technical standards following the consultation, hosted by Principal Chris Curry and joined by Head of Policy and Insight, David Reid, and Senior Product Manager, Helen Scriminger.

These Q&As detail the questions asked by attendees and the answers given by the panel during the webinar.

Once the standards have been approved, is there a process for making updates?

The Pensions Dashboards Programme (PDP) has undertaken extensive consultation with the industry and others, and will continue to do so, in order to produce a set of dashboard standards that are deliverable and effective.

At the same time, we recognise that changes may need to be made to standards as circumstances change and we expect the standards to continue to develop over time. 

As part of our consultation on draft standards, we published proposals for how we would govern the standards and manage change over time, and respondents were supportive of our proposals.

Following the consultation, we have published an updated version of our approach to the governance of standards. It details a clear process for making changes and confirms our commitments. This includes how we will classify changes and major or minor, where we will consult on changes, the frequency and timing for introducing changes and the notice period before changes are implemented.

Regulation 23(4(c) (on matching) refers to “guidance on matching issues from time to time by the Secretary of State or the regulator”. Whilst this isn’t guidance by MaPS/PDP, do you know when it might be published?

As you identify, this refers to any guidance on matching published not by PDP/MaPS, but by the Secretary of State or regulator. We’re not aware of any imminent plans to publish guidance in this space, but any guidance on this matter will be guidance to which pension providers and schemes must have regard – essentially, providers and schemes would have to have good reason for departing from it, including being able to demonstrate how the same outcome has been achieved by different means.

In the meantime, you may wish to refer to the Pension Administration Standards Association (PASA)’s useful guidance on the choice of data matching conventions.

PDP also has several explainer videos and the data standards set out the detail on the find data providers and schemes will match against.

What will be the process for those people who live/are outside of the UK who wish to use the dashboard, and don’t have a UK based address? Is it the same as UK based? eg will the ID&V in the ecosystem not check UK based address so this won’t matter?

We recognise there will be users who live outside of the UK who have pensions in UK pension schemes and who will want to use the service. Being in the UK will not be a prerequisite to use the service. However, the extent to which the individual’s identity attributes can be verified where they live outside of the jurisdiction will depend on where the individual lives.

Where can trustees find out how the ERI warning codes will be presented to consumers. That is to say, will QPDS be able to choose their own wording or is there prescribed wording which will need to be used?

This is covered in the FCA’s QPDS consultation (launched last week on the FCA’s website). They outline their proposals on what needs to be covered in these warnings and explanation. As part of their proposals, the FCA are proposing detailing the content and but are leaving dashboards to develop their own form of wording.

What does PDP consider “where applicable” to mean in relation to employment data? If the data is available on administrators’ files but would take a lot of work to digitise, does that work need to be done?

This data will only be applicable to occupational pension schemes – hence it is optional data in the data standards. But if the scheme has it, then they must provide it. The duty sits with the scheme – the administrator is only acting on the scheme’s behalf.

I think any guidance on rounding was going to come after more testing – do you have any more insight on when schemes might see any guidance on rounding and what they should be doing in the meantime? (There is some detail in AS TM1 but that won’t be relevant for DB and certain other benefits)

There’s no guidance for DB schemes as the regulations leave discretion for how the trustees calculate the values. Dashboards will have to display the values provided.

The data standards include inflation-proofed State and DB pension income amounts, but flat-rate (ie non-increasing) DC pension incomes. In the user testing done so far, how well have most users understood this key difference between the different ERIs they’re seeing?

We have undertaken user research to understand how users will experience dashboards, including seeing different types of pensions alongside each other. This research has informed our development of the draft design standards, on which we are now consulting, and we’ll continue this user research over the coming months as we finalise the design standards.

Our proposals for the design standards include how dashboards must communicate the differences between pension types to ensure users are not confused by the different ERIs they will see. Our draft design standards set out that if the dashboards totals the ERIs or uses a graphical representation, it must explain the differences between the types, including where there may be inflationary increases that are not reflected in the totalling or graphical representation.

Where whether an underpin bites is only calculated today at either the point of retirement, or the point of transfer out (and not within an SMPI), do these data standards just require the presence of the underpin to be flagged to the member, or do you envisage additional calculations on whether an underpin might bite, over and above what is done in SMPIs today, to be performed?

The values to be returned in respect of hybrid benefits (which is another name underpin benefits). How it applies is detailed in the regulations and rules and it’ll depend on whether the individual is an active or deferred member. Schemes are given scope to choose the best value to return which best illustrates the current and ERI.

A lot of discussion of design standards to best suit savers is speculation until tested; what specific plans are there with MaPS MoneyHelper to test design standards during this process?

User testing of each dashboard offering is paramount. That’s why we’re making it a requirement for QPDS and MoneyHelper is doing the same to help it develop its offering.

MaPS has and will continue to undertake user research and testing to ensure that its proposition meets users’ needs and provides a good user experience.

Under data standard 2.3 do you want projection to NRA or TRA?

Our data standards only capture the ERI projection requirements from the regulations. The references in the regulations are to the member’s normal retirement date.

There is a separate section in the PDP data standards that is for the accrued data items. 2.406 ‘Accrued annual amount’ is the value of the pension which has been built up to the accrued calculation date, so it is being interpreted as being the value of the current pot divided by an annuity rate. There is an annuity rate that gets calculated when producing the SMPI, but the FRC are saying that the AS TM1v5 is only to be used for the SMPI and ERI data, and it is not meant to be used for the annuitisation of the accrued data items (2.406). This was from their webinar but also it is absent from the AS TM1 they have released. We are now left with an annuity gap, FRC are saying not to use the SMPI one and PDP havent confirmed how to calculate it. So, no one is taking ownership of what annuity rate should be used to calculate the value for 2.406 for DC schemes. Is there any detail you could provide please?

There should be no gap. Our understanding, from conversations with them, is the FRC is accept AS TM1 is the relevant guidance to be used to calculate the annual income in respect of a accrued DC pot.

If a member joins the scheme on, for example, 1 May 22 the end of that member’s first full scheme year is 31 March 2024. However, if the member requests view data on say 1 March 23 they fall outside of the prescription that states that the member is a new joiner because they have not requested view data within 12 months of the end of that member’s first full scheme year [regulation 26(6)]. This seems to be an error in the regulations, can you comment?

We don’t see it this way. The new joiner relaxation only lasts for a limited period and then the member is considered no longer to be a new joiner and the scheme loses the benefit of the relaxation.

How do you envisage non-profit deferred annuity values being displayed, where we know the values at the retirement date already?

Please see our design standards consultation for our proposals on the display of pensions information.

2.414 accrued unavailable. Don’t believe DWP regs or FCA COBS rules allow exemption for 2 years to retirement or less than £5k pot rule.

Our position is consistent with the regulations.

2.414 ‘accrued unavailable’ data item. Don’t think DWP regulations or FCA COBS rules allow the DCP or DCA exceptions to be used for accrued value data?

The accrued unavailable data item (2.414) can be used where the accrued values cannot be sent immediately in response to the view request. For example, where the pension provider or scheme needs to make use of the 3/10 days permitted by the legislation to carry out the calculation offline and return the data later in response to a subsequent view request.

Where a value is unavailable on a successful match and there is a requirement to provide that within 3 or 10 days, is it the intention for a data provider to do that a PEI is generated regardless of whether a view request has been made?

The pension identifier is registered with the consent and authorisation service in response to a find request, when matching against the find data received results in a positive match, and the duty to register the identifier immediately (within 60 seconds of receiving the find request) is independent of the duty to return view data when receiving view requests against registered pension identifiers.

Where value data are not available immediately, and the pension provider/scheme needs to make use of the time permitted in the regulations and rules to perform the calculations (3 days for DC; 10 days for DB), the provider/scheme must nonetheless register the match made, within 60 seconds of receiving the find request, by registering the pension identifier with PDP.

Slightly specific data standards question. There are a couple of ‘end date’ elements (eg 2.408), and it’s specified that this is mandatory for one off cash sums. What are you expecting to see here? Is it as simple as start date and end date being the same?

Yes. That’s correct. The dashboard will then apply this information when it comes to the user’s display.

Under the new ABS regulations we are considering adding the what if you pay another £50 pm more, you could have – is this being considered within dashboards?

Under the current legislative framework, dashboards can only currently display the pensions information and not undertake any current calculations or forecasting. That’s not to say this type of functionality might not be permitted in the future. It’ll need, however, legislative change before dashboards could implement it.