Pensions Dashboards – PDP Consultation on Standards

Background

The PDP has issued a consultation on its draft standards and guidance, along with a call for input on its design standards.

In this response

• Responses to specific consultation questions and related comments

Responses to specific consultation questions and related comments

General comments

Interpretation

To minimise the risk of any inconsistency or ambiguity between the legislation and the standards, we suggest that each document has an interpretation section stating that:

• defined terms in the standards have the meaning given in the regulations
• in the event of any conflict between the standards and the regulations, the regulations will prevail.

Definition of “pensioner”

We note that the standards expand on what is meant by a “pensioner” for dashboard purposes.  We raised concerns on this point in our response to the DWP’s consultation earlier in the year, as the definition used in the draft regulations (section 124 of the Pensions Act 1995) did not tie in with the intention as set out in the DWP consultation.  Similarly, the draft standards (eg paragraph 12 of the data standards) refer to a definition under the “Pensions Act” but it is not clear which Act it is referring to, nor is it clear that the description in the standards matches the legislative definition.  In particular, it is unclear how dashboards should apply to members in drawdown arrangements or those who have taken an UFPLS as part of their overall DC benefits.

We suggest this is picked up with the DWP to ensure that the definition used in the draft regulations accurately reflects the policy intention.  The standards can then cross refer to those regulations to ensure consistency throughout.

Data standards and data usage guide

Are you confident that the proposed data standards adequately cover the benefit structure of all pension providers? Can it express the correct values to all savers? If not, please share a brief description of the relevant benefit structure?

We do not think that the data standards allow for correct values to be provided in respect of the following:

• DB schemes with a final salary link (ie where the DB section of a scheme is closed to future accrual but final DB benefits will be calculated with respect to the member’s salary on leaving employment, rather than the date DB accrual ceased)
• DB schemes that have a DC underpin (or, conversely, DC schemes with a DB underpin)
• schemes that have DC benefits accruing for initial pensionable service but then change to DB after a given number of years.

Given the huge number of complex benefit structures, we expect that there will be other structures that are not covered under the current draft and, even with industry feedback, may not be catered for in the final document.  As such, we think it is essential that, in these situations, pension providers are able to return a warning explaining that they are unable to provide the financial values of an individual’s benefits at this time (as suggested in paragraph 33 of the data standards usage guide).

On a related note, it would be helpful if TPR could acknowledge the situations in which providers are unable to return view data (as set out in paragraphs 28 to 33) and how they will approach these cases in their compliance and enforcement policy.

Are the values allowed for the accrued (2.3xx) and ERI (Estimated Retirement Income) (2.4xx) warnings sufficient? Are there any other common reasons or scenarios you think these warnings should cover (bearing in mind we cannot support scheme-specific warnings).

We think it is important that providers can use these warnings where they are unable to provide data due to a complex benefit structure, as discussed above.  We are comfortable that the “Other significant warning – call provider for information” warning should be able to cover these cases but it would be helpful if the PDP could confirm in its consultation response that it agrees with this approach.

We agree with the approach of having a limited number of warnings, as there is a risk that adding too many specific warnings could confuse members, particularly as the outcome in each case will be the same, ie that they need to speak to the provider.

On a point of detail, we suggest the warning referred to above uses the term “contact” rather than “call” as some providers / administrators may have put an email address as their preferred method of communication.

Is the intention that the “Benefit illustrated does not show all the potential entitlement” is only used where the value provided is a minimum value? If not, our concern is that the use of “all” suggests that there are more benefits to be provided, rather than that the estimated values may differ from those values provided.  We suggest the wording is amended to make sure it reflects the underlying intention.

Would the ability to add a short piece of free text to cover pension provider-specific issues be workable for you, or introduce a new burden? If so, how many characters would be required and what topics would it cover?

In our view, it could become confusing to an individual if they have several warning flags, as well as a short text piece to read.  Our preference would be to ensure the warning flags are clear and cover all eventualities (with the sweep-up warning to “contact provider for information”), rather than add another layer of complexity to the project.

General comments on the data standards

Whilst not falling under any of the specific questions above, there were a few points of detail that we spotted in our review that we thought it was worth raising.  We’ve set these out in the table below.

Setting standard / approach to governance of standards

Do you agree with our definitions of major and minor changes to the standards?

While the examples seem in line with what we would expect for minor and major changes, we are concerned that the definition of a minor change (“changes that do not impact all participants or have minimal impact on all participants”) is a bit wider than the examples suggested.  As currently drafted, a change that does “not impact all participants”, but has material implications for affected participants could be classed as a “minor change”.  We would expect any change which has a significant / material impact on any provider in terms of resource and / or cost to fall under the “major change” umbrella.

Consultation document

Are you clear on the differences between standards, statutory guidance and recommended practice?

We are clear on the difference between standards, statutory guidance and recommended practice. However, we are concerned that it is not always clear, either in the guides themselves or in the standards (eg Part 1 of the Technical Standards), whether guidance is statutory (“have regard to”) or recommended practice, or when a standard is straying into guidance.  It would be really helpful if:

• the language used is consistent throughout the suite of documents, so it is clear what is expected of providers, eg

• • • “must” for anything mandatory (ie in the standards)
    • “should” for statutory guidance
    • “recommend” for recommended practice,

and that any approach to terminology is clearly explained

• it is made clear on the face of a document what type of guidance it is, eg on the front page, introduction and in headers throughout.

To bring this out in some examples:

• the “early and voluntary connection” guidance has “mandatory guidance” in the header. It is useful to  have something in the header to flag what the guidance is, but the use of “mandatory” is confusing as it is only the standards themselves that are mandatory – statutory guidance is drafted on the basis of “have regard to” or “comply or explain”
• the “connection process and guidance”, which we understand is statutory guidance, page 3 says “we recommend any organisations considering this option register their interest early…”. Is this statutory, ie organisations should register their interest early, or is it recommended practice?
• we understand from the consultation document that the data standards usage guide is “recommended guidance” but there is nothing on the face of the guide that makes this clear.