The pensions dashboard: an actuarial perspective

Abstract

The pensions dashboard has been talked about across the industry for a long time. With the proposed implementation date of 2019 (although it has been questioned by some whether this is achievable or not), it is time to consider the actuarial aspects behind providing individuals with details of their pension benefits.

This paper outlines the perspective of the IFoA’s Future Pensions Landscape working party. The paper considers the objectives of the dashboard and the functionality that may be required to deliver on those. It also highlights the difficulties of the necessary consistency between different types of benefits and the need for alignment with other pensions communications. Lastly, it considers what is needed to enhance the dashboard to enable members to understand what their benefits might look like at retirement and the opportunities the dashboard delivers for further modelling and financial planning.

Objectives and functionality

Much has been made about the difficulty (or otherwise) of delivering on the promise of a pensions dashboard, but ultimately that will depend on what it aims to provide for the individual. The working party has considered the short and longer-term opportunities with a dashboard and what functionality these may require. It is clear that a balance between functionality and deliverability must be struck to ensure that something meaningful is delivered within a reasonable timeframe (2).

Different types of benefits

The working party has considered the features of occupational and personal pensions, defined benefit (DB) schemes (5.21), defined contribution (DC) schemes (5.25) and the state pension (3). We believe that it is essential to deliver key information around each of them in a way that is consistent but takes account of the differences between them, including the need to:

• use scheme/benefit-specific pension commencement dates (4);

• display accrued and prospective benefits at retirement in real terms (5.6, 5.20);

• display dependants’ benefits when a part of the scheme rules (5.12);

• display details of benefits in payment or already in drawdown (5.4);

• ensure that deferred DBs are revalued to a recent date (5.22);

• be clear about the level of pension increases payable using inflation linking as a default (5.17); and

• outline any options on a benefit such as tax-free pension commencement lump sum (5.8).

Having included the above, the dashboard must then consider how to allow for consistency of projection of benefits to the scheme/benefit-specific pension commencement dates. For DBs, this can be achieved relatively easily in real terms by allowing merely for future accrual based on the current position and benefit structure. For DC benefits, this needs a standardised approach. After consideration of multiple options (5.25), we have recommended a simplified projection approach using a risk-based allowance for real investment growth depending on the assets held (or a risk categorisation) (5.50). This would enable the dashboard to carry out consistent projections across DC pots. In an ideal world, we recommend that benefit statements use projections aligned to this approach, too.

In order to build confidence in any dashboard (and in pensions in general), consistency between benefit statements and scheme provision of information is key (8). This includes the need for dates and speed of information provision, the type of information provided and assumptions and projection approaches to be standardised.

We have also considered other hybrid benefit structures that exist. Many or all of these can revert to using the approach outlined for DB, DC, or a combination of the two along with the expertise of a provider to achieve the aims of consistent dashboard provision (6).

We have also tried to allow for some of the legacy or complex issues within the UK pensions landscape that we consider relevant to the provision of a usable dashboard, such as the need to include Guaranteed Annuity Rates, and the need to explain the various risks and uncertainties with both DB and DC provision (7).

Future opportunities for supporting financial planning

The working party has considered the longer-term opportunities to use the dashboard to assist individuals with planning for their retirement. We recommend that the dashboard infrastructure be set up with this in mind from the beginning, even if the deployment of this type of support is a long way away (9) or even provided through third parties (10).

The working party looks forward to the Department for Work and Pensions feasibility study on the dashboard (which is due for publication) and welcomes the chance to influence the shape of what has the potential to be a huge engagement opportunity for the pensions industry.

1. Introduction

1. 1.1. “The dashboard offers a great opportunity to give people straightforward access to their pension information in a clear and simple form – bringing together an individual’s savings in a single place online” (Opperman, 2017). This statement immediately raises the question – what pension information should be included, and how should it be presented?

2. 1.2. The fundamental difference between defined benefit (DB) and defined contribution (DC) pensions is well known, but in addition, DB scheme design is hugely varied and many DC schemes will come with their own particular features. Pension scheme members already receive a lot of information, but it is set out in different ways, using different assumptions and illustration dates, and it can be hard for members to see how it all combines to deliver an income in retirement.

3. 1.3. Presenting pensions information consistently will require decisions on what information to show, what assumptions to use and whether to realign existing disclosures. Information will need to be presented as simply as possible, but that will mean stopping short of a complete picture. What is necessary to show and what can be omitted? If not shown directly, what should be signposted? As advisors at the heart of helping to run the UK’s pension schemes, actuaries are well placed to set out the challenges and potential solutions.

4. 1.4. To date, there has been relatively little actuarial involvement in the development of the dashboard. This document sets out the perspective of the Institute and Faculty of Actuary (IFoA)’s Future Pensions Landscape working party on the pensions dashboard. It is intended as a contribution, on behalf of the IFoA, to the debate around what a pensions dashboard should and could do. We aim to highlight some of the key decisions that will have to be made, by drawing out what it might mean to present all of someone’s pension information in one place, in the varied and fragmented UK pensions field. We explore the trade-offs of how one could present complex information and options in a clear and simple form. We suggest ways in which the UK pensions framework could evolve to support the development of a dashboard, and which aspects might be prioritised in the medium term.

5. 1.5. We have focused on actuarial matters in a broad sense, including:

   • an understanding of pensions systems and the broader context in which they are found;

   • evaluation of financial risks;

   • communication of complex information to non-specialists;

   • projecting DC benefits;

   • working with the detailed specifications of defined benefits;

   • experience of working with many different schemes, each with their own history, quirks, and data difficulties; and

   • experience working with stakeholders across the pensions industry, including trustees, sponsors, administrators, lawyers, investment advisors, corporate advisers, employee benefit consultants and regulatory and government authorities.

6. 1.6. The recommendations within this paper are an outline of our initial thinking in key areas. We have made them to generate and add to the conversation around the dashboard. They are specifically aimed at ensuring that the content of any dashboard is sound from an actuarial perspective. They may not, in isolation, be considered appropriate or reasonable without the context of the dashboard.

2. The Big Picture: Dashboard Objectives and Functionality

1. 2.1. The working party has considered, against the background of literature published to date, what functionality the dashboard should have. In order to understand these requirements for the dashboard, we need to consider its objectives. Why is it being developed, and what is its ultimate purpose? We wholeheartedly support the overall concept of a ‘Pensions Dashboard’, bringing together all of a user’s pension information in one. Done well, it should encourage people to think about their income in retirement, and to engage more readily with the decisions they have to make. It is therefore very important that the dashboard be a success. We believe that this will only happen if people can access it, understand it, see value in the information it provides and trust the source of that information. It needs to be simple enough for people with limited financial literacy to use and understand. This becomes even more important if the information it provides is to flow into further tools for managing pensions (see section 2.12). In order for users to trust the information provided, it needs to show data which is complete and consistent (with other sources such as benefit statements).

2. 2.2. Given the scope of possible functionality against the work needed to put the infrastructure in place to simply collect the relevant data, the working party considers it useful to consider short-term objectives separately from longer-term aims, and essentially to see the delivery of the dashboard as a phased roll-out.

3. 2.3. An initial phase could involve identifying and bringing all information about all of an individual’s pensions together in one place. This may be followed by the display of more insightful and meaningful details, which involves utilising the underlying data to provide projections, and could assist with financial planning. Finally, long-term goals of more sophisticated modelling and functionality to enable members to actively manage their pensions might be considered.

Phase 1 – Tracing Service and Basic Pension Information

1. 2.4. At the initial development stage, we see that the dashboard might almost be a simple tracing service, collating information already available into one place. It might not even be a “dashboard” at this stage. A true “dashboard” could follow later, although it is essential that the name of the product be meaningful and set suitable levels of expectation for individual users.

2. 2.5. At its simplest, the dashboard could only list the names and contact details of an individual’s pension arrangements. However, the discussion around the idea of a dashboard usually assumes that members will be given some form of information about the value of or expected income from their arrangements. This will be considered in the next phases of development and would normally require some projection of future benefits. If the dashboard were to show projected pensions, it would require some actuarial assumptions to be made.

3. 2.6. For individuals to use the dashboard, the information shown needs to be trustworthy. In some respects, this means that information needs to be consistent with that from other sources. Showing accrued benefits with no future allowances may be the first step of the dashboard, as it is not possible to provide any additional functionality without the underlying data. This would be a place to bring together all pension provisions (or at least UK-based, registered provisions) as well as the state pension.

4. 2.7. Given the infrastructure needed to hold and collate this data, and the amount of time required for potential legislation necessary to mandate this provision of data to be put in place, it may take a few years to get to the stage where all information on all of an individual’s pensions is shown in the dashboard.

5. 2.8. The aim of the dashboard at this stage is to provide pensions information in one place in a standardised format. To be effective, it should show individuals the pensions they have accrued to date and be presented clearly and simply.

Phase 2 – Enhancing the Dashboard as a Financial Planning Tool Using Projections

1. 2.9. Once the basic dashboard is established and all information is available in a standardised format, further functions can be considered. The dashboard can be incrementally developed over time. This next phase would then be to make the dashboard useful for financial planning. For this, projections would need to be made, especially given that the state pension incorporates future accrual. This raises many more questions, such as what financial assumptions should be used, what further contributions to assume, what retirement age(s) to use, how to show projections simply and without many caveats whilst making it clear that figures are not guaranteed and different models give different results, how to show contingent benefits and whether to show drawdown options or simply annuitise all DC savings. These points are explored later in this paper.

2. 2.10. At this stage, the key enhancements to the basic dashboard would:

   • show individuals the pension they might receive if they continue with their existing pension arrangements;

   • show information that would help individuals to make decisions on their pension provision by acting as a ready (but probably incomplete) starting point for appropriate financial advice;

   • be careful not to present uncertain outcomes as certain; and

   • separately identify accrued and prospective pensions.

3. 2.11. As far as possible, this information should be consistent with other pensions information readily available to individuals including benefit statements issued by DB schemes and Statutory Money Purchase Illustrations (SMPIs). This provides users with clearer information and helps providers maintain systems and processes. However, for reasons which are discussed later, full consistency with SMPIs might not be possible, depending on the projection approach adopted. Alternatively, existing disclosures could be harmonised with the dashboard.

Phase 3 – Future Developments for Managing Pensions

1. 2.12. What should come next is harder to predict. Once basic data and some projections are available, what should the dashboard do? Should there only be a single, public sector owned and regulated dashboard or multiple dashboards? How should innovation be encouraged without losing the integrity of or trust in the data shown? Could there be a central simple dashboard which holds all basic factual data and which shows mainly accrued pensions and possibly some projections, but allows other interfaces to access these data to allow more functionality and more sophisticated modelling? Would this keep simplicity for some users but provide the option to do more for others?

2. 2.13. We do not consider these as core objectives for the initial dashboard, appropriate though they may be for later development. We think there is a danger that the initial build of the dashboard tries to deliver everything, which would delay the project. We think it is better for the dashboard to start with central, limited objectives, but be built with consideration to potential future functionality developments. Again, we discuss some of these points further in our paper.

3. State Pensions

1. 3.1. The working party considers that the state pension is a key component to the dashboard and should be included from day 1. It was confirmed in the 2018 Autumn Statement that the state pension is to be included in the dashboard, but there are still some key points to be considered to ensure that this gives the individual the information required to understand this benefit alongside other pensions savings.

2. 3.2. The state pension is a significant part of an individual’s retirement income. It should be included in the dashboard to show a comprehensive view of an individual’s pension arrangements which will lend itself to informed decisions about retirement.

3. 3.3. State pension information can be accessed relatively easily from the government’s website, at https://www.tax.service.gov.uk/check-your-state-pension. The dashboard will enable people to see everything in one place rather than to have to track each pension down individually. The dashboard should be linked to the state pension service and, should the Department for Work and Pensions (DWP) have responsibility for the dashboard, this should be relatively simple.

4. 3.4. The consumer groups who contributed to the Pension Dashboard Project’s paper, Reconnecting people with their pensions, agreed that the state pension needed to be included from day 1, as consumers would only be able to see the real value of their pensions from full coverage (ABI, 2017, Pensions Dashboard Project – Reconnecting People with their Pensions).

5. 3.5. The inclusion of the state pension on the dashboard is in line with the Financial Conduct Authority (FCA)’s view (FCA, 2015, The Retirement Income Market Study). It recommended the development of a dashboard to enable customers to view their lifetime savings, including the state pension, in one place.

6. 3.6. Additionally, most international examples of the dashboard include the state pension, and this is viewed as the norm.

7. 3.7. There are some disadvantages to including the state pension, but the working party does not consider them significant enough to outweigh the benefits of showing it.

   • Once an individual is past their state pension age, this information is not currently available from the government’s website. However, it could be made available to the dashboard if the government were in support.

   • State pension age is generally equal to or later than the default or normal retirement age at which people’s benefits are usually expressed, and this will introduce inconsistencies that need to be explained.

8. 3.8. The state pension information must:

9. • Be consistent with the information displayed on the government’s website.

10. • Show retirement income per year/month/week (the user should be allowed to select the period most useful for them).

11. • Be displayed separately from DC and DB occupational and private pensions.

12. • Show the age from which it is payable, if not already in payment.

13. • Allow the user to display (by clicking) the information used to calculate the state pension, e.g. date of birth, number of working years, gender, etc.

14. • Display either the state pension in payment (our preference) or display a notification that the state pension is in payment once past the state pension age.

4. Assumed Pension Commencement Date

1. 4.1. The dashboard will need assumptions and data about the date at which each pension is to commence payment. In practice, an individual could have several pensions with different retirement ages. These different retirement ages mean that any illustrations they will have received will often assume different commencement dates for different pension arrangements. The dashboard could show pensions with different commencement dates, or could show pensions adjusted to a common retirement age. We have considered the pros and cons of each approach.

Scheme-Specific Commencement Dates

1. 4.2. The simplest approach would be to use separate pension commencement dates for each arrangement, with the date supplied by the provider. The commencement date could be:

   • normal retirement date for an active member of a DB scheme;

   • the earliest date at which the pension can be taken without reduction for a deferred member of a DB scheme;

   • the normal retirement date or other date specified by the member for a DC scheme (as per SMPIs); or

   • state pension age for the state pension.

2. 4.3. The advantage of this approach is simplicity, as no additional calculations would be required to convert the pension to a retirement date different to that usually shown. However, the dashboard would then show pensions at different ages, which means that the pensions would not be directly comparable. In practice, while not ideal, the range of scheme retirement ages for most people might be quite narrow, i.e. unlikely to be below age 60, and unlikely to be above their state pension age (currently up to age 68).

3. 4.4. The obvious disadvantage of this approach is that individuals may find this confusing if trying to plan for a specific retirement age. However, with the ever-increasing popularity of phased retirement, this is no longer the problem that it once may have been.

Common Assumed Commencement Date

1. 4.5. An alternative approach would be to show all pensions with the same commencement date. This could be the individual’s state pension age or another age, such as the commencement date of the largest pension, or an age chosen by the individual. This approach would result in better comparability but would require additional calculations by either the provider or the dashboard.

2. 4.6. For example, DB scheme pensions would need to be adjusted by up-to-date early/late retirement factors. For some schemes, the adjustments would not be straightforward, and it might not be practical for the dashboard to perform the adjustment.

3. 4.7. Even if a common assumed commencement date is used, it is arguable that pensions at scheme-specific normal retirement ages should also be shown for consistency with existing statements. In the case of DBs, where benefit promises are expressed as being payable at a particular age, it will usually be necessary to show pensions without any early or late retirement factors for consistency with earlier illustrations and the way the pensions promise has been expressed.

4. 4.8. “Equalisation” and other cases of more than one normal retirement age within the same scheme present a further difficulty for DB arrangements. It is fairly common for members to have different early retirement terms in respect of their pensionable service on or after 17 May 1990 to earlier service, and often different terms again from a later date. More generally, as scheme design has changed over time, members may have multiple “tranches” of benefit each with their own retirement terms.

5. 4.9. There would also be difficulties with DC schemes as an assumption would need to be made about the investment return (and underlying investment strategy) over the period between the date used for scheme-specific calculations (e.g. SMPIs) and the common assumed date. However, it would be relatively easy, over the medium term, to align providers DC SMPIs with individuals’ state pension ages. Since late 2018, all state pension ages are now above 65 for future retirees, and this is likely to be the oldest relevant “retirement age” for a member whose benefits are not already in payment. That is, it will be the earliest age at which they can access all their retirement benefits. We discuss in section 8.34 below the merits of aligning SMPIs with individuals’ state pension ages.

6. 4.10. A further issue is that the pension from some arrangements (e.g. the state pension) might not be available at all from the assumed commencement date.

7. 4.11. The working party considers that, initially at least, pensions should be shown with scheme-specific commencement dates. This is the simplest approach and avoids the difficulties noted above from having a common assumed commencement date. This will highlight to members different benefits that they have payable from different ages.

5. Information to Be Presented on the Dashboard

1. 5.1. In the course of a working lifetime, an individual will potentially accrue pension benefits in many different schemes or arrangements with significantly different features. As a result, the information that may need to be supplied and presented to ensure that the dashboard delivers for individuals is significant. We have considered the features of the different types of pension arrangements and options, and outlined key areas where care will need to be taken to ensure the individual is presented with an accurate picture of their benefits.

Multiple Arrangements in Schemes

1. 5.2. It is not uncommon for members to have two or three arrangements in a single scheme. For example, a DB scheme may have had DC Additional Voluntary Contributions (AVCs), then closed to DB accrual and opened a new DC section. It will generally be clearest to present these arrangements separately (although care will need to be taken concerning the information around opportunities to take a pension commencement lump sum).

2. 5.3. The working party considers that DC AVCs ¹ in trust-based schemes should be shown on the dashboard and treated as a separate pension arrangement. However, we note that illustrating future AVC contributions or accrual for a minority of active members can involve disproportionate work for schemes and might be best left to their individual disclosures.

Pensions in Payment and Not Yet in Payment

1. 5.4. Discussions around the dashboard tend to focus on pensions not yet in payment. However, it may be valuable to display benefits already in payment (possibly from multiple arrangements) or – in the case of drawdown – available to be drawn upon. This will be particularly important for members where part of their benefits is already in payment, but other benefits have not yet commenced. For example, a member in their early 60s may have accessed their money-purchase benefits, but decided to wait for their DBs to be payable at a normal retirement age of 65, and be unable to access their state pension until they are 68.

Pension and/or Drawdown

1. 5.5. Individuals now have considerable flexibility in how they access their pension funds following the introduction of pension freedoms. The dashboard needs to be simple and concise, and therefore the working party considers that the dashboard should only show the accrued DB pension (possibly with the maximum pension commencement lump sum), the projected DC fund at retirement and an illustration of the annuity income that DC fund could provide. Showing drawdown options would make the dashboard more complicated and harder for individuals to understand. The working party considers that drawdown options can be illustrated using additional modelling, which could be driven from the dashboard or could be provided separately by Independent Financial Advisors (IFAs) and/or providers.

Accrued Pensions, Funds and Future Accrual, and Contributions

1. 5.6. The working party considers that the dashboard should show both the accrued DB pension and expected pension income from existing DC rights along with, separately, the pension which may accrue or be expected from future DB accrual or DC contributions. This will help individuals understand how much they have built up and how much they might get if they remain in their existing arrangements. However, it should be noted that illustrating future accrual is not always straightforward. For example, AVC options might be taken up by only a few percent of a scheme’s active membership. In general, a member will only be an active member of one scheme, with no more than two active arrangements (e.g. the main occupational arrangement and an AVC arrangement alongside it). It may be simplest to leave responsibility for illustrating future accrual to the scheme concerned.

2. 5.7. Future DC contributions pose two extra complications:

   • new contributions could be invested differently to existing assets; and

   • the pattern of a member’s further contributions tends to be more uncertain, e.g. linked as a percentage of salary or a series of irregular lump sum payments? However, existing SMPI guidance, the Actuarial Standard Technical Memorandum (TM1) (FRC, 2016, AS TM1 – Statutory Money Purchase Illustrations) already provides instructions on which expected future contributions to take into account. Interpretation of this guidance for fixed rates of contributions and a set percentage of salary can vary ; however, and it may be that stricter guidance is required to ensure consistency.

Pension Commencement Lump Sums

1. 5.8. Some DB pension schemes, particularly in the public sector, provide a pension and a separate cash sum as the default benefits. The dashboard should show the pension and cash sum separately for such schemes.

2. 5.9. For other schemes, members can usually choose to take part of their pension as a pension commencement lump sum (PCLS). The SMPI rules allow providers to calculate the statutory illustration assuming that the individual takes some of their fund as a PCLS. However, in practice, we understand that few providers do this.

3. 5.10. Some members have enhanced tax-free lump sum options derived from their pre-6 April 2006 rights. This is often a valuable benefit, although many members may not be aware that they have an enhanced entitlement, and so this should be noted on the dashboard.

4. 5.11. The working party considers that the dashboard should include flexibility to allow a PCLS to be shown with a reduced pension, although the focus should be on the core pension benefits. It should also highlight the options around taking a PCLS from different schemes and benefits.

Dependants’ Pensions

1. 5.12. The working party considers that the dashboard should clearly note the amount of any dependant’s pension assumed in the projections. This is important for DC schemes, as the level of the individual pension will depend on the amount of dependants’ pensions. The existence of a dependant’s pension is assumed, although the working party considers that it would be preferable for no dependants’ pensions to be assumed for DC schemes. The information may also be helpful to individuals for their own planning. For DB schemes, it is useful to remind members of what their dependants’ benefits are, as they will often be an important part of their financial security, and members may not be aware of or may misunderstand what those benefits are.

2. 5.13. For DC schemes, it may be necessary to make a default assumption about the level of any dependant’s pension. The actuarial guidance for SMPIs, TM1, does not require a dependant’s benefit to be assumed, and not every member will need one. There are two issues to consider here.

   • First, the existence of or potential for the existence of a dependant at the eventual time of a member’s death. The potential existence is particularly important for younger members, who may not currently have a dependant(s) but are more likely to by the time they retire.

   • Second, the benefit level assumed to be purchased, where a dependant is assumed or expected.

3. 5.14. Possible approaches include the following.

   • A common assumption for all DC arrangements, e.g. 50% of the member’s pension. This may understate the likely initial pension for a member who does not have dependants, or require additional provision for them. However, it would encourage members to consider provision for their dependants, as it would require an element of “opting out” to remove it.

   • No dependant’s pension assumed. This would be consistent and meaningful for all members, but would overstate the projected benefit for members who eventually purchase a dependant’s pension. It might increase the frequency of members overlooking provision for their dependants. It is, however, consistent with the way most members use their DC benefits in retirement.

   • Scheme-specific assumptions following SMPIs. This would introduce a mix of assumptions, but would at least be consistent with the illustrations members receive directly from their schemes.

4. 5.15. The working party suggests that the dashboard assume no dependant’s pension be purchased by DC funds, although this should be made clear to users with information around the impact that purchasing a survivor’s benefit may have on their income in retirement.

5. 5.16. Pension providers should be expected to keep details of members’ dependants, or lack thereof, up-to-date – the dashboard can be a prompt for members to supply providers with changes of circumstances. The dashboard data for each scheme could include a dependant’s status for each member, along with the date of its last verification. It would then be relatively straightforward for the dashboard to use the latest data and show the appropriate projection. However, this would probably require a difference in treatment between the youngest members (who are quite likely to not have a current dependant but have one by the time they retire) and members nearing retirement (whose status may be more settled).

Pension Increases

1. 5.17. The majority of annuities purchased do not increase in payment amount. SMPI illustrations may be based on any permitted rate of increase to pensions in payment, although in the past, an index-linked pension had to be shown and most providers still provide SMPI illustrations on this basis. Where an assumption about pension increases is required by the dashboard for DC benefits, the working party suggests that the default be that pensions increase in line with inflation.

Charges

1. 5.18. It may be useful for the dashboard to present a statement of or otherwise quantify the ongoing charges for each arrangement. These are typically a percentage of assets and/or a periodic, specified amount, although they might vary depending on the value of a member’s pot and the type of the arrangement. Some schemes also charge a percentage of new contributions, meaning the amount credited to the member’s account is less than the amount paid in. We do not believe that this information needs to be set out alongside details of pension benefits (and perhaps should not be, to avoid overloading the initial display of information), but the member might be able to click through for this level of information.

2. 5.19. We note that each (trust-based scheme) DC member’s annual benefit statement must include a web address containing the costs and charges information for their scheme. In addition, new regulations impose a duty on trustees from 6 April 2019 to disclose, on request from active members and from recognised trade unions, investment information concerning the top level of pooled funds for which public information is available.

Real or Nominal Amounts

1. 5.20. The working party considers that projections should be shown in terms of today’s money, so that individuals can compare their potential pension with their existing income. This requires that DB pensions be revalued to a recent date (either index or in line with scheme-specific fixed rates), but not include an amount for projected future revaluation. Future revaluation should be implicit in the pension amount shown. DC projections should not include any inflationary growth, only estimated investment growth in excess of inflation. The inflation element should be implicit in the “real” pension amount shown, so that SMPI illustrations are shown in terms of today’s money.

Specifics of Defined Benefit Schemes

1. 5.21. Active members:

   • The working party considers that the dashboard needs to provide both the accrued and projected pension. Without showing the benefits accrued to date, the dashboard might be misleading for active members with (in theory) many years of future accrual that they might not actually obtain.

   • We note that the disclosure regulations for active members in DB schemes do not require the accrued pension to be disclosed, but it would not require significant additional work for providers to display that amount separately.

2. 5.22. Deferred members:

   • A pension without any revaluation since the member deferred may significantly underestimate the likely benefit at retirement age. A pension with revaluation up to retirement age would not be in today’s money and would not be comparable with SMPI projections. The working party therefore considers that schemes should be expected to at least provide the value of the pension at leaving, and a revalued deferred pension to a date within the last year. Ideally, deferred pensions should be revalued to a current date – the fairly standard deferred revaluation mechanisms in general use might allow providers to supply data based on members’ dates of leaving with the actual revaluation calculations done by the dashboard.

3. 5.23. Pensioners:

   • This is usually meant to mean members with pensions already in payment. However, it is usual to treat members the same way if they were above the projected retirement age, or whose benefits could be put into payment immediately and without early retirement reduction.

   • Where a pension is in payment, it will be useful to show the current amount of that pension.

   • It may be useful to indicate how that pension will increase in future years. However, for DB schemes, this can be complex as different tranches of benefits may be indexed in different ways.

   • Some pensions in payment will be reduced at the end of a “bridging period”, typically at age 60, 65 or the member’s state pension age. These reductions are often not well understood by members (MP’s to monitor HSBC pensions clawback, Espadinha, 2018), so stating the end date of the bridging pension and the reduced amount (assuming no further increases from the date of the illustration) would be a useful addition to the dashboard. Bridging pensions could be shown separately to a member’s main benefits to reduce the risk that a member assumes their higher pension will continue indefinitely.

   • Where a member is entitled to immediate payment of their pension without reduction, but has not yet opted to take that pension, they will often be entitled to a later retirement increase. Ideally, this should be included in the value of the pension shown, particularly where the postponement period is significant.

4. 5.24. Update frequency

   • Note, unlike DC schemes, a member’s DBs are unlikely to change materially from 1 year to the next. That is because a member’s accrued benefits (or, for active members, their prospective benefits) will usually only revalue by inflation from 1 year to the next, and are not exposed to market movements in the way DC benefits are. The working party recommends that DB benefits be updated on a regular basis (possibly annually in line with benefit statements).

Specifics of Defined Contribution Schemes

1. 5.25. DC fund values can be relatively easily obtained, and comparing them is a straightforward exercise. However, projecting pensions that will be payable from these funds introduces significant complexity.

2. 5.26. We considered five approaches for determining projected pensions for DC schemes. Each option is described below. We also assessed the data which providers would need to give to the dashboard under each scenario.

Option 1 – use provider’s latest SMPI

1. 5.27. The first option considered is to use the latest SMPI projection. This is relatively simple and limits the additional calculations needed for the dashboard. It also means that no additional actuarial assumptions are required for the dashboard. However, providers have some discretion on the choice of assumptions and, as a result, different providers might use different assumptions for similar asset classes. This results in some inconsistency between different providers’ projections, but ensures those projections would be consistent with the SMPIs.

2. 5.28. For individuals still contributing to a DC scheme, the SMPI illustration would need to split the projected pension between the pension from the accumulated fund and the pension from future contributions. Currently, SMPI illustrations are based on the accumulated fund plus future contributions.

3. 5.29. However, the latest SMPIs could be more than a year old, and therefore the projections could be substantially out of date. Furthermore, where an individual has several pension arrangements, it is possible that, using this approach, the statements could be at a wide range of dates. This may cause confusion (but no more than if someone today looked back at their most recent statements from different providers).

4. 5.30. Illustrations at different dates within a period of 12 months may be sufficient for members many years away from their expected retirement date, given the uncertainty over a similarly long period of time. Where members are approaching their retirement, there is an argument that the projections should all be at the same recent date to enable better planning. However, before the member is able to access their benefits, unless the projections are “live” and action can be taken straight away, there could be market movements of similar magnitude to that between illustration dates some months apart.

5. 5.31. A possible attraction of the pensions dashboard is that it might be possible to use the data for modelling to help individuals understand their pensions and make decisions. However, the SMPI-based approach described here limits the modelling which can be performed, as there is no information on the assets held.

6. 5.32. For the reasons above, this is not the working party’s preferred approach in the long-term, but it might be the most feasible in the short term. Inconsistency between different SMPIs could be addressed by harmonising the SMPI requirements.

1. 5.33. The Occupational and Personal Pension Schemes (Disclosure of Information) Regulations 2013 (The Disclosure Regulations) would need to be amended to require the statutory illustration to be shown with and without future accrual. The working party considers that this amendment would in any event improve the usefulness of SMPIs.

Option 2 – provider supplies updated SMPI illustration

1. 5.34. An alternative approach to option 1 would be for the provider to update the SMPI calculation to the latest effective asset valuation date. This would address the concerns in option 1 regarding out-of-date information. It would need to be decided how frequently schemes would be expected to provide refreshed data, e.g. every month, day, or live. This might vary by arrangement – a small provider might only be expected to provide annual updates, at least at first, but more regular updates might be expected from larger providers. For the purposes of the dashboard, the working party does not consider it critical that all valuations be provided on the same date. This might be actuarially consistent, but it is not necessary to give users an idea of their benefits, particularly if it is already accepted that the valuations are not “live”.

2. 5.35. SMPI illustrations use annuity rates based on gilt yields at of 15 February of the previous tax year. If providers calculate projections using a recent fund valuation, it might be appropriate for the annuity rate to be based on more recent gilt yields. However, as with valuation dates, the working party does not think that perfect consistency is critical in the context of the dashboard. It might often be spurious. It might not be practical for every provider to use up-to-the-minute gilt yields. For example, a pragmatic approach might be to use gilt yields on the first working day in the month prior to the fund valuation. This is an area which could be discussed with providers. The projection rules would need to specify a date for determining annuity rates to be used.

3. 5.36. A variant approach would be for the providers to project a fund to a date, and then the dashboard could be responsible for the annuity calculation and the implied income calculation. That would allow the dashboard to make use of market annuity pricing or more up-to-date market information than would be reasonable to expect of all pension schemes.

4. 5.37. As with option 1, limited modelling can be performed using dashboard data as asset information would not be available.

1. 5.38. Providers would need to consider whether accumulation rates would need to be adjusted as market conditions change during the year. However, assumptions can often be expressed as the market yield on particular gilts plus or minus a fixed margin, which makes them readily updateable. An advantage of the approach for SMPIs is that accumulation rates are set at one date and should reflect market conditions at that time.

Option 3 – dashboard calculates projected pension on SMPI or similar basis using recent data

1. 5.39. Under this approach, the provider supplies the dashboard with sufficient information so that they can calculate projected pensions on the SMPI basis or similar. This would enable the provider to use the latest available asset values.

2. 5.40. This approach has significant practical difficulties. The provider would need to supply the dashboard (or intermediary) with detailed and recent asset information so the dashboard could perform the calculations. Many DC assets are invested in funds with a mixture of assets which may vary from time to time, and some DC funds are invested in a lifestyle approach with the balance of assets changing systematically in the period up to retirement. It is unlikely to be practical for the provider to supply the dashboard with sufficient information for the dashboard operator to make a reasonable assessment of the potential return which can be achieved from the assets.

3. 5.41. The provider would also need to provide information about charges for the dashboard projection for the purpose of the projection. Charges can be constructed in various ways, and the collection of the information would be complex. However, for most arrangements, providers ought to be able to provide:

   • an annual percentage charge of assets;

   • (if relevant) an additional specified annual charge amount;

   • a percentage charge on new contributions; and

   • where charges are more complex, or the information cannot be provided in a form suitable for the dashboard, then a default level of charges could be assumed. This should be at the higher end of the range of possible charges to minimise the risk of understating the impact of charges and might be 1% of the fund value as in the current FCA projection rules.

4. 5.42. Given the issues noted above, the working party considers that this approach is not practical (without the significant standardisation and simplification we discuss in option 5 below).

1. 5.43. The projection rules would need to specify a date for determining the annuity rates to be used.

2. 5.44. As with option 3, the impact of changing market conditions would need to be considered when setting accumulation rates.

Option 4 – dashboard calculates projected pension on simplified basis with no allowance for real investment growth

1. 5.45. A very simple approach would be for the DC projection to be carried out using SMPI assumptions, but with the assumed accumulation rate set at the rate of inflation. As with options 2 and 3, the annuity rate would be based on market conditions at or close to the fund valuation date. Under this approach, it is assumed that all asset classes will provide the same return, and no allowance is made for returns above inflation, which might be achieved from risk-seeking assets, or for returns of less than inflation as currently implied for many bonds.

2. 5.46. There could also need to be a simplified approach to allowing for charges, e.g. use an accumulation rate net of charges. Alternatively, given the variation between charging approaches, the same approach outlined under option 3 could be used for this option.

3. 5.47. This approach is the simplest of those we have considered. The calculations are straightforward, and no judgements are required by the dashboard operator on the potential returns from assets.

4. 5.48. The projections would be lower than the SMPIs for return-seeking assets. This could cause confusion and arguably the projections could be considered too conservative in such cases. On the other hand, the real gross redemption yields are negative for many bonds, so this approach might overstate returns for a conservatively invested arrangement – which would be increasingly likely as members approach their target retirement age if there is lifestyling.

1. 5.49. The projection rules would need to specify a date for determining the annuity rates to be used.

Option 5 – dashboard calculates projected pension on simplified basis with simple allowance for real investment growth (our recommended approach)

1. 5.50. Under this approach, rather than supplying the dashboard with detailed asset information, the provider would supply a risk rating for the funds (it may be possible to link this to the sector definitions set by the Association of British Insurers (ABI, 2017, ABI Sector Definitions) or provide other guidance). This could be on a very simple basis, where the risk rating would be low for funds mainly invested in gilts and cash, and high for funds mainly invested in equities and other return-seeking assets. There could then be intermediate classifications. Another approach could be to ask providers to state what proportion of a member’s assets is in the major asset classes. In calculating projections, the dashboard would then assume a return based on the risk or asset classification. The tables could be reviewed every few years by the responsible authority, along with other assumptions, such as mortality. Providers would be able to regularly review where a fund sits in the table. Examples of the possible classifications and assumed returns are set out below:

Three-Tiered Classification

Five-Tiered Classification

Seven-Tiered Asset-Based Classification

1. 5.51. While it would be good to specify returns for different asset classes, there are challenges:

   • many funds are composite and, in some, the balance can change (e.g. mixed 40%–85% shares funds);

   • funds with guarantees and/or protection would lower the expected return;

   • funds with derivatives;

   • absolute return funds;

   • alternative assets might be too simplistic when there are many different types with widely varying returns (e.g. property, commodities, infrastructure);

   • new types of fund will emerge and may not easily fit into the classification;

   • expected returns can vary within these classifications depending on risk taken; and

   • potential returns may change over time and therefore the table would need to be reviewed.

2. 5.52. Some providers already classify funds by risk, and guidance could be given to providers in classifying the risk level. The definition of “risk” itself will need to be considered. We usually refer to investment risk, but even “safe” assets such as cash are exposed to inflation risk.

3. 5.53. Lifestyling asset strategies could be accommodated, but would require additional categories and/or separate information. Historically, lifestyling has transitioned growth assets towards long-dated high-quality bonds and cash, to reduce mismatching risk for members expected to purchase an annuity and take a cash lump sum. However, the introduction of the 2014 “pensions freedoms” is likely to lead to different lifestyling strategies for members even with the same scheme, depending on whether they are expected to take their retirement benefits as cash, an annuity, or a drawdown fund. Additionally, the lifestyling periods and transition speeds vary and may involve steps from a high-risk asset category to a low-risk category via a medium risk asset class. Although lifestyling is typically over no more than 10 years before the expected year of retirement, it could mean that simple projections based on current asset allocations slightly overstate the expected benefits.

4. 5.54. A potential difficulty of using simplified asset classes is that not all investment products can be easily placed in these categories, e.g. diversified growth funds. For example, many funds involve a mix of assets that might not be stable over time, e.g. where managers have considerable tactical discretion.

5. 5.55. This approach outlined in this section will still result in differences from existing SMPI illustrations, as the returns derived from the table above will not always be the same as assumed by the provider in their SMPI illustrations. However, the differences will not be as great as in approach 4, while the calculations required by the dashboard are much simpler and practical than in approach 3.

6. 5.56. The same considerations apply around the allowance for charges as per option 4.

7. 5.57. The simpler the approach taken to investment returns and charges, the easier it will be for more of the calculations to be done by the dashboard rather than by the scheme provider, as less data will be needed and fewer assumptions and judgements will have to be made. However, the simplification comes at the cost of glossing over some of the differences in investment strategies and charging structures.

8. 5.58. A more sophisticated approach would be to be to use each provider’s estimate of the annual percentage and/or amount charges it will take from the member’s funds. However, there may be consistency issues between funds by using product-specific charges along with generic investment returns. Where members’ assets are invested in similar ways, it may be appropriate to show lower net returns from higher-charging products. On the other hand, some investment products will charge higher fees for activity that is expected to lead to higher gross returns, or is necessary for investing in those particular assets.

9. 5.59. Overall, the use of risk-based simplified asset returns is the approach we would recommend if it is important that all funds of the same asset type be assumed to have the same expected returns. In those circumstances, the working party would also recommend that benefit statements be harmonised with the new projection methodology.

1. 5.60. The projection rules would need to specify a date for determining annuity rates to be used.

Defined Contribution Pots Already in Drawdown

1. 5.61. Where DC rights have crystallised as a drawdown fund, the value of the fund should be shown. As with uncrystallised DC rights, it may be useful to show an illustration of what sustainable income could be provided from that fund. As the flexibility of income options is one of drawdown’s chief attractions, a relatively simple rule of thumb might be sufficient, rather than a detailed projection.

6. Other Scheme Designs

1. 6.1. The working party considered DB and DC schemes as the two main types of pension provisions. However, there are others, and it is possible that more designs will be developed in the future.

Hybrid Schemes

1. 6.2. For hybrid schemes, where it is possible to separate DB and DC elements (e.g. where DB accrual is based on a capped salary with the excess salary being pensioned on a DC basis), the working party considers that the different elements should be shown as separate pensions in the dashboard.

2. 6.3. For hybrids where the benefit is the greater of DB and DC pensions, the provider will need to use their judgement on how the pension should be treated for the purposes of projections. For schemes where a DC underpin is in place but is unlikely to bite, then the working party considers that the scheme should be treated as DB. Where the DB element is unlikely to bite the scheme should be treated as DC.

3. 6.4. Schemes where a DB is always provided, with a further DC benefit if a member’s funds are sufficient (e.g. a so-called DC scheme contracted-out on a salary-related basis is likely to have to provide a Guaranteed Minimum Pension (GMP) and/or a reference scheme benefit irrespective of the final fund value), will be difficult to project because the eventual DC benefit is the difference between the projected DC pot and the DB pension. It may be acceptable, as a cautious approximation, to show the DB element and then treat any DC funds in excess of the DB element at the valuation date as a separate DC fund.

4. 6.5. Where the position is less clear (for example, where a GMP needs to be provided in all circumstances before any residual DC benefit is available), the provider could use their judgement and might choose to perform projections themselves rather than supplying data for the dashboard to perform the calculations. However, this would not sit well with DC projection options 4 and 5 (described above from section 5.45 onwards), which would not otherwise require calculations from a scheme.

Other Designs

1. 6.6. It will not be possible for the dashboard to perform calculations for all types of design and, in such cases, the working party considers that the provider should provide an accrued pension and a pension assuming future accrual and contributions at a recent date using methods and assumptions consistent with those used for DB and DC pension projections.

7. Other Issues

Treatment of Guaranteed Annuity Rates

1. 7.1. The working party understands that there are hundreds of thousands of pension policies with a GAR. The impact of GARs and the terms under which they operate vary considerably. A minimal approach is to simply flag the existence of any attaching guarantee, preferably with a more useful description that the user could click-through to. However, the working party considers that the inherent difficulties relating to GARs are not sufficient reason to exclude them from the dashboard and suggests that the dashboard show projections allowing for the possible impact of any GARs and that the dashboard comment on the existence of the GAR and state that the GAR may be lost under certain circumstances.

2. 7.2. This is an important issue as recognised by the DWP in recent guidance (DWP, 2017, safeguarded-flexible pension benefits: simplified valuation and introduction of personalised risk warnings). A large number of individuals lose their GAR, for example, when taking benefits early.

Risk/Uncertainty and Limitations

1. 7.3. There are risks with all types of pensions, and the dashboard should make this clear. However, a full list of risks with explanations on the dashboard could obscure the key information. The working party therefore considers that there should a high-level statement about risks with sign-posting to a page or pop-up box with more detail. Items which might be covered include:

For DB schemes:

• scheme not meeting benefits, and sponsor default. It is important, however, that this message also highlight the existence of the Pension Protection Fund;

• future accrual depends on continuing membership and scheme remaining unchanged;

• revaluation terms and caps may mean benefits gradually lose value relative to prices and earnings;

• lower pension if benefits taken early;

• higher pension if benefits taken later; and

• contribution increases for future accrual.

For DC schemes:

• investment performance;

• annuity rates;

• pension from future contributions assumes contributions paid up to retirement age;

• lower pension if benefits taken early;

• higher pension if benefits taken later;

• pension amount will be different of taken if pension taken in different form (e.g. pension increases and dependant’s pension);

• GAR might not apply under some circumstances;

• impaired life annuities might increase the pension; and

• drawdown options and sustainability risk of chosen income levels.

1. 7.4. In addition, there could be a link to a page showing the impact of changes in key assumptions, for example, the impacts of assuming an additional 1% p.a. and 2% p.a. to the accumulation assumption, or a corresponding reduction by the same magnitude.

2. 7.5. A stochastic approach could be taken for some users. However, this may be difficult to interpret for many users. The working party thinks that a detailed illustration of investment risk is best left to third-party providers building on the dashboard data, but not something a centralised dashboard should attempt itself. This would require appropriate guidance for providers to avoid inconsistencies.

Are SMPIs Needed If the Dashboard Shows Projections?

1. 7.6. If the dashboard is successful and has universal coverage, then the need for SMPI illustrations may disappear. However, we should expect that many individuals will not log into the dashboard. Although there will also be many members who do not look at the paper SMPIs sent to them, if an individual is required to take online action to see their projections, then it is perhaps inevitable that even fewer people may see their projected benefits.

Who Should Set the Assumptions for the Projections?

1. 7.7. This could be the Financial Reporting Council (FRC) (who sets SMPI assumptions), the FCA (who sets point-of-sale projection assumptions), the new Single Financial Guidance Body (the public body that will be responsible for pensions guidance) or another entity. There is a strong case for one of the existing assumption setters to set the assumptions for the dashboard or for a new entity to set assumptions for all projections. Having one assumption setter will reduce the possibility of inconsistent approaches, will be more efficient and can reduce the number of consultations.

Annuity Rates – Mortality Assumptions

1. 7.8. SMPI illustrations use standard unisex mortality tables with an allowance for future improvements. The table and the model used to determine the future rate of improvements are produced by the Continuous Mortality Investigation (CMI) of the Institute and Faculty of Actuaries. In practice, when setting annuity rates, insurers will use mortality assumptions generated by their internal teams using their own data. The assumptions for an individual annuity may also take account of factors including where the individual lives, and the size of the annuity. Insurers may also offer different terms for impaired annuities.

2. 7.9. It may be possible for the dashboard to provide a better estimate of an annuity using current information about annuity pricing and any information available about the individual. However, the working party considers this approach to be too sophisticated for illustrations, and that it is better for the dashboard to state that the annuities rates available at retirement may differ from those assumed in the projections. Attempts to tailor potential pricing to individuals are likely to be problematic, given the high level of underwriting in the current market. In addition to medical questionnaires, the use of pot size and postcode to determine rates is also widespread, meaning any “general” annuity rate offered may be no more accurate than a rate estimated from general actuarial tables. Care would also need to be taken where providers offer their own annuities and want to illustrate these. These quotes might be more accurate, but could privilege providers’ own products over the wider market if wide products are not also taken into account.

Annuity Rates – Yield

1. 7.10. SMPI illustrations are usually based on recent gilt yields.

2. 7.11. It would also be possible to calculate annuity rates using forward rates, i.e. considering the yields implied by current market prices, and applying these to future dates. Arguably, this would be the market’s best estimate, all things being equal, of the yields that would determine future annuity rates. However, this would mean individual annuity rates being calculated for each member (or each cohort, split by years of birth) and require access to detailed gilt yield market information. That might be possible for the dashboard and large providers, but might not be feasible for smaller schemes.

SMPIs and FCA Projections

1. 7.12. The SMPI assumptions that apply to the annual statements for occupational pensions, personal pensions and stakeholder pensions are set out in Appendix A, along with the point-of-sale projections for personal pensions and stakeholder pensions subject to the FCA’s Conduct of Business Sourcebook (COBS) 13 assumptions.

2. 7.13. The FCA states that “COBS projection requirements were introduced to enable consumers to see what return they might get on their investments, to compare product charges, and to see how charges could affect returns, before deciding which product is most appropriate for their needs” (FCA, 2017, rates of return for FCA prescribes projections) – this is different from the dashboard’s objectives, and may justify slightly different assumptions than for SMPIs, e.g. the capping of the accumulation rate.

8. Interaction with Existing Benefit Statements

1. 8.1. Personal and occupational pension schemes must disclose certain information about members’ benefits to them. These disclosures are a natural starting point for the information providers would upload to the dashboard. However, not every member receives an annual benefit statement, and not every statement includes all the information that the dashboard is envisaged to need. For consistency and efficiency, it may be desirable that benefit statements and the dashboard show the same information the same way. This would give clear alignment of the objectives and requirements for benefit statements and the dashboard.

2. 8.2. Not all schemes are subject to the same disclosure requirements. In this section, we concentrate on occupational (with 2 or more members), personal, and public service pension schemes based and tax registered in the UK.

3. 8.3. However, it should be noted that when the public calls for “all of a member’s pensions” to be shown in one place, a member may have pension benefits outside of what is typically meant by pension schemes, and these would present particular challenges (perhaps disproportionately) to incorporate in a dashboard. For example:

   • overseas arrangements on which no UK tax relief has ever been granted. These could be a significant source of income for people who have spent part of their working life outside of the UK. With no UK jurisdiction over these schemes, it is likely to be impractical to bring these funds under the dashboard.

   • overseas arrangements on which UK tax relief has previously been granted. These arrangements will typically have to comply with Her Majesty’s Revenue and Customs (HMRC) reporting requirements and benefit restrictions. However, it is likely to be disproportionate for them to provide data to a UK dashboard if only a minority of their members are connected to the UK.

   • unregistered arrangements (i.e. not registered with HMRC for tax relief), historically known as “Unfunded Unapproved Retirement Benefits Schemes (UURBS)” and “Funded Unapproved Retirements Benefits Schemes (FURBS)” but now both known as “Employer Financed Retirement Benefits Schemes (EFRBS)”. These are typically pre-2006 arrangements set up for high earners; and

   • individual trust-based arrangements.

4. 8.4. Many disclosures required by pensions legislation can now be provided electronically. However, whether provided electronically or by paper, it is likely that most statements have been discarded by members, and relatively few read and understood.

Defined Benefits – Active Members

1. 8.5. Basic scheme information must be given to active members within 1–2 months of joining a DB arrangement. This is normally provided in the form of a membership booklet.

2. 8.6. Thereafter in most schemes, active members are only entitled to benefit statements on request, and no more than annually (accepting that some schemes have regulations and/or rules that compel the provision of benefit statements). However, in practice, schemes will usually issue a statement annually to these members. Trustees and Scheme Managers may state the amount of benefits that would be provided (with regard to possible increases in the member’s salary) assuming pensionable service would end on an appropriate date, usually the scheme’s normal pension age.

3. 8.7. This means it is possible for trustees to meet the disclosure requirements by estimating a member’s pension based on their total prospective service, without stating the accrued pension (for example, calculated at a date within the last 12 months). Since members cannot rely on remaining in the same employment, on the same DB accrual terms, until retirement age, this can mislead members as their actual entitlement might be much less than their prospective entitlement. The working party considers that all active DB members should be told their accrued entitlements on an annual basis.

Defined Benefits – Deferred Members

1. 8.8. When a member leaves active service before normal pension age, they must be provided, within 2 months, of the “information as to the rights and options (if any) available to a member”. This is generally known as a “leaver statement”. Deferred members are explicitly entitled to be informed of, on request, the amount of their accrued pension that would be payable in future (in practice, this would be included in the leaver statement).

2. 8.9. However, the deferred pension will be calculated at the date the member ceased active service in the scheme, and schemes do not have to revalue these benefits until the member is at or close to retirement. Even on a member’s request, some schemes will refuse to tell a member what their deferred pension would be if revalued to the current date. This makes it harder for members to understand their true DB entitlement, as the revaluation since they deferred may be significant. Consider the following example.

   • The member was born 1 July 1953 and is male.

   • The member was aged 65 years on 1 July 2018.

   • The member had accrued a £500 p.a. guaranteed minimum pension before leaving active service on 1 July 1987, aged 34. For simplicity, this example member has no other accrued pension, although there would typically be a pension in excess of the GMP, revalued separately.

   • GMP revalues at 8.5% for each complete tax year until age 65.

   • GMP at age 65 is 500 × 1.085³⁰ = £5,779.

   • The member is approaching retirement age and, in September 2017, asked the scheme how much their pension was expected to be. The scheme confirmed it was £500 p.a. when they left service, but would be revalued according to certain rules. The member does not understand the revaluation and is disappointed that their pension appears so small.

   • It would have been more meaningful for the member to understand that a £5,779 p.a. pension would be payable to them from the following year, as that would be a significant contribution to their retirement income.

   • The above example used the maximum fixed rate of GMP revaluation; however, both the “section 148” and “limited rate” revaluation on GMP and revaluation on non-GMP benefits can still be substantial. For example, if the member’s £500 p.a. did not include a GMP, and had been revalued in line with price inflation according to the statutory order, it would have been expected to be nearly £1,191 p.a. at the time of the member’s initial request.

3. 8.10. As recommended in section 5.22 above, the dashboard will need to show deferred members’ benefits revalued to a date within the last year.

4. 8.11. The working party recommends that annual benefit revaluations be made available to all deferred members through the pensions dashboard, showing their benefits revalued to the effective date of the statement. By default, it would make sense that deferred members be given a right to be directly provided, on request, their deferred pension amount revalued to the current date no more than once a year. We would encourage schemes to inform deferred members of their revalued benefits periodically, but accept for reasons of cost and marginal value that it need not be annually.

5. 8.12. For some schemes, the data may not be immediately available for the revaluation calculations. However, it is data that would be needed for retirement calculations and for the dashboard. Regular revaluation statements for deferred members would improve the quality of these members’ data, both through the necessary administration work that this entails, and contact with members through their queries in advance of them taking their benefits.

6. 8.13. If, in addition, regular statements were issued directly to deferred members (could be annually but need not be), it would also help keep members’ address details up to date through more frequent contact and prompts for member-tracing. However, this would come at a significant cost for schemes.

Defined Benefits – Dates of Illustration

1. 8.14. Historically, the benefit statement cycle has been driven by individual “scheme years”, and DB schemes illustrate members’ benefits at different dates. When viewed together in the dashboard, it would be consistent if these illustrations were calculated as at the same date. 5 April, the end of the tax year, may be a suitable date for standardising benefit statements, as this is already the date on which “pension saving statements” are calculated for annual allowance ² purposes, and so would reduce the additional administration required.

2. 8.15. In looking for a standardised date of illustrations that is consistent with the dashboard, it might be appropriate for DB benefit statements to be aligned with the tax year end.

3. 8.16. It would be valuable for annual DB benefit statements to be issued as promptly as practical after the beginning of the tax year. These would allow them to tie in with the data on the dashboard, if this is derived from DB benefit statement calculations. Pension administrators and employers would be able to suggest a reasonable timeline. There may be a need to finalise pensionable earnings and member movements ahead of bulk statement exercises, which can take some months. However, given modern technology, this should not take more than 12 months.

Defined Benefits – Options

1. 8.17. The “basic information” given to active members (cf. section 8.5) gives very general information about how a member’s benefits would be calculated in particular situations. The “information as to the rights and options (if any) available to a member” given to early leavers (cf. section 8.8 above) is in equally general terms. However, a DB member will not usually be told, before the stage of asking for a retirement quotation, details such as:

   • the current terms on which they can commute their pension for tax-free cash; ³

   • the amount of any scheme-specific protected cash they have. Some members, before 6 April 2006, built up rights to take more than 25% of their benefits in the form of a tax-free lump sum, and these rights could be “grandfathered” under the current pensions tax regime; and

   • the current reductions that would apply if they took early retirement.

2. 8.18. Other options for information to display might include:

   • a transfer value. There are statutory rights to transfer values, but some schemes allow members “non-statutory” transfers, e.g. where a DB member did not cease to accrue benefits at least 1 year before normal retirement age;

   • a bridging or “levelling” pension. A member might be allowed to increase their initial pension, in exchange for a lower pension in later years. This can help members better manage their income where they have retired before their state pension age; and

   • an (increased) dependant’s pension. A member might be allowed to reduce their own pension in exchange for better provision for a spouse, or another dependant, upon the member’s own death.

3. 8.19. Commutation and early retirement terms (“factors”) will vary by the specific age of a member. The terms of many schemes will be revised from time to time, to take account of changing financial conditions and life expectancy. Understandably, schemes do not put this information in members’ benefits statements, as it would be lengthy and subject to change. The dashboard could be a way of making the terms of those options available to members in a more manageable and accessible way. The terms on which a pension can be paid early or commuted for cash are important factors in a member’s retirement decision-making. However, the working party does not consider it essential that early retirement and cash commutation factors be included in the early stages of the dashboard. Whether early retirement and commutation terms can be incorporated should be considered for a later phase of the dashboard and assessed against competing priorities.

4. 8.20. The source of any tax-free cash is also important in members’ decisions about what to do with their benefits. For example, it will often be advantageous to a member with DB and DC benefits in the same scheme if they are able to take some or all of their DC rights as tax-free cash, without having to commute any of their DB rights. In contrast, other schemes might treat the DB and DC rights entirely separately, meaning only 25% of the DC can be taken tax-free, and further tax-free cash would require the commutation of DB pension rights. The working party recommends that benefit statements include a short note on whether, and how, members can take tax-free cash, in a verbal form suitable for uploading to the dashboard along with members’ benefit data.

5. 8.21. Furthermore, and where relevant, confirmation of the existence of “grandfathered” cash entitlements could be flagged in a member’s benefit statement. The working party also recommends that, in a future phase of the dashboard, schemes provide the value of members’ uncrystallised rights and tax-free cash at 5 April 2006 to the dashboard. ⁴ This would make it easier for advisors and modellers to estimate the maximum tax-free cash available to a member. However, the working party does not consider it essential to include this information in the first phases of the dashboard. The data are needed for the administration of members’ retirement options, but will not be available for all schemes immediately, as some schemes prefer to calculate it as and when needed. However, the working party considers that as knowledge of pre-2006 pensions practices is inevitably declining, good data administration may require these elements to be calculated and recorded sooner rather than later.

6. 8.22. It would be valuable for benefit statements to confirm the age at which a member first becomes eligible to take their benefits early. For most members, this will be age 55. However, there are subgroups of members who have the right to take their benefits at age 50, and this can be an important benefit where members need an additional income, for whatever reason, in their early 50s.

7. 8.23. Bridging, levelling, and spouses’ pension options are not essential to the purpose of the dashboard. The working party suggests that it would be good practice for schemes to mention relevant options in members’ benefit statements. The working party recommends that the existence of these member options be flagged in the dashboard, but that this is not a first phase priority. These options could be flagged at a scheme rather than member level, and the dashboard does not need to set out the detailed terms. Take-up is likely to be low and individual members can apply for more detail from their schemes.

Defined Benefits – Summary Funding Statements

1. 8.24. Following the completion of an “actuarial valuation” or an “actuarial report”, ⁵ trustees send members a “summary funding statement”, outlining the funding position of the scheme along with, where relevant, a summary of the trustees’ and sponsoring employer(s)’ agreement to improve the funding position. Although the funding position is relevant to the security of members’ benefits, a large proportion of the members’ benefits (with the exception of long-serving high earners) are protected by the Pension Protection Fund, and the implications of a particular funding level may be misunderstood by members.

2. 8.25. The working party does not consider it important for summary funding statements to be uploaded to the pensions dashboard although, in a later phase of the dashboard, this might be a useful addition for the benefit of some financial advisors.

3. 8.26. In this document, the working party has recommended additional benefit statements and matters to be included in the benefit statement, where we consider they add member value. To balance that, we suggest that summary funding statements do not need to be individually sent to each member, and that benefit statements could direct (the few) interested members to an online version of the latest statement.

Defined Contribution Benefits – Statutory Money Purchase Ilustrations (SMPIs)

1. 8.27. Basic scheme information must be given to new members when they join a DC arrangement. The information included in these joining packs typically contains generic scheme illustrations.

2. 8.28. Valuations of DC rights must generally be given annually. However, the calculation date varies between schemes, as it is determined by the trustees of a scheme or the pension scheme provider.

3. 8.29. If the dashboard is to present members with valuations of their benefits at consistent dates, then SMPIs would need to be prepared at a common date, and updated within a reasonably narrow window. For the same reasons as for DBs (section 8.15 above), the working party recommends that SMPIs be aligned with the tax year.

4. 8.30. Similarly, it would be appropriate for annual DC benefit statements to be issued as promptly as practical after the beginning of the tax year. The working party recommends consulting pension administrators and employers over how promptly would be a reasonable expectation. However, it envisages that this would be much shorter than the 12 months now currently allowed.

5. 8.31. As we drew attention to in section 5.28, the current disclosure regulations do not require a projection solely based on existing assets at the effective date of the projection. The working party recommends that SMPIs must include a projection assuming no further contributions are made to the arrangement, alongside any projection which includes continued contributions at the current level (increased in line with inflation).

6. 8.32. If the dashboard is intended to illustrate the effect of making or continuing future contributions, this information is already available on the benefit statement. One could view this as a necessary part of a holistic dashboard, enabling members not only to understand what they have built up but also the actions they could take to improve their retirement positions further.

7. 8.33. An alternative view might be that very few members will be contributing, or considering contributing, to more than one scheme, and that individual schemes are best placed to illustrate to the members their options and the effect of making a particular one-off lump sum or series of contributions. Any projection of further contributions or accruals needs to clearly set out the assumptions made about those future contributions or accruals.

8. 8.34. We discuss in section 4.9 above the differences in SMPI illustration ages and how these would be easier to align than for DB benefits. State benefits are likely to remain a major, and often principal, source of retirement income for the vast majority of future retirees. However, under current law, state pensions cannot be accessed before state pension age, whereas DB and DC benefits can usually be accessed at earlier ages than their associated “normal retirement date”, albeit on actuarially reduced terms. The DC retirement age is not essential to the DC promise being made (“Defined Contribution” is by definition in terms of the member’s and employer’s contribution), but it does affect the projected benefits, as would the actual age at which those rights are used to purchase an annuity or drawn upon. If DC projections were to be aligned at a single age, it would make sense to align them with individuals’ state pension ages, as the latter are fixed by the state and do not regularly change.

9. Additional Modelling

1. 9.1. Depending on the data provided, the dashboard could be used either as a direct platform or data source for third-party providers to model and show:

   • the uncertainty in DC pensions;

   • the impact of different investment strategies;

   • how changes in annuity conditions might affect the pension;

   • the impact of making additional contributions at various rates;

   • the impact of taking pensions at a different date;

   • the impact of taking the benefits in different forms (dependant’s pension, PCLS, pension increases); and

   • income streams from different decumulation strategies.

2. 9.2. The modelling could be deterministic or stochastic.

3. 9.3. Guidance could be provided on the assumptions and methods to be used in models so that modelling is carried out consistently.

4. 9.4. In the working party’s view, the development of interactive modelling would go beyond the dashboard’s core purpose, considerably complicate its operation, require many caveats, and delay its implementation. This functionality could be left to third-party providers to develop at a later date, using the information displayed by the dashboard. The FCA or Government may need to regulate the way dashboard information is used, as it would any other provider of financial services, but it does not need to develop these services itself.

10. One or Many Dashboards

1. 10.1. There has been much debate around the potential desire for one or many dashboards and the commentary in the 2018 Autumn Statement has not made this any clearer. It is not a binary choice, and many options exist within the middle ground – either from the outset or as part of a phased implementation or evolution of a core dashboard product.

2. 10.2. The format of any dashboard will depend on the objectives of DWP and the needs of individuals. Ultimately, this is a policy decision which will be influenced by technology infrastructure far more than actuarial thinking. However, the opportunities for modelling benefits and potentially allowing members to interact with their benefits or even obtain advice may depend on the decisions taken around this.

3. 10.3. It will be key that whatever decision is made allows for the sensible regulation on the use of the data provided by a centralised dashboard, or alternatively on the content and functionality of separate dashboards hosted by the private sector. Similarly to Open Banking, the principle of giving a member access to and ownership of their retirement planning is essential.

4. 10.4. The working party believes that it is appropriate, under all scenarios, that a core set of data be made available either from a central dashboard or for separate private sector dashboards. This, combined with appropriate regulation of dashboard content, will ensure consistency between provider’s offerings.

5. 10.5. Should a single central publicly run dashboard be chosen, it should be noted that many individuals who use it will take the information provided and wish to use it to go on to manage their pension benefits. By allowing private sector dashboards to link to this data easily, members will be able to do this in a more straightforward fashion.

6. 10.6. It is also the view of the working party that allowing a free flow of data (which technology could provide anyway) to private sector dashboard equivalents will deliver incentive for the pensions industry to provide individuals with a better overall pensions product.