Chris Connelly
Propositions and Solutions Director
Our principal concern is maximum coverage. We are concerned that phasing delivery by sector would be problematic; not least in the communication to members. Most will not understand pensions to any degree, so any attempt to explain the multiple flavours that our industry has evolved over hundreds of years would be confusing. Any time spent explaining differences across our industry is time distracted from helping members understand their own pensions.
A Phased Approach
Our suggestion would be to phase depth of information, not breadth of coverage. We would work on a 2 phase approach, where phase 1 would be an earlier delivery of a useful tool to members to quickly reconnect with lost pensions.
We can also add value here. If we handle the GDPR permissions correctly during the members’ user journey through the dashboard search, we could enable schemes and providers to update their records with the latest contact information. They can then proactively communicate and reconnect with these lost members. We would describe this as better than a “Find” service. More like a “Reconnect” service. Phasing in this way with a relatively quick to launch and practical phase 1 tool would also have the advantage of setting members on the behavioural journey of going online to understand their pensions.
In phase 2, we would then turn to the major hurdle of providing benefit information in a way which makes it digestible and understandable to members, many of whom are not, and should not be expected to be, pension experts. We believe the route to solve this challenge is to ensure that the way in which information is presented up to members is, as far as is possible, consistent and comparable. To illustrate, if a member is actively accruing a defined benefit pension with Scheme A with an expected retirement age of 60, a deferred defined benefit with Scheme B with an expected retirement age of 62 or a DC scheme with a target retirement age of 67, we have three different benefit structures and types and three different retirement ages, so unless we can find a meaningful way to present this, our member has no easy sight of ‘what will I get when I retire’, but rather an assortment of useful but quite dissimilar information. Without comparability, members will struggle to understand. We don’t feel that there needs to be one single uniform way in which schemes project benefits, as all schemes have to operate in accordance with their actual rules, but the results need to be understandable when presented side-by-side with others when they don’t have the reams of explanatory words alongside them that they would in a scheme-specific communication.
Data Standards For The Dashboards
One way to achieve a level of comparability is to adopt a consistent framing of the information provided per scheme and benefit entitlement. Unfortunately, no such standard exists for much of the Defined Benefit (DB) sectors. When Government responded to the last consultation that no scheme would be asked to provide any more than is provided in a benefit statement, or on demand, we do not believe they fully understood this lack of standardisation. Looking across our client base, it is the smaller, or more varied DB schemes that would have the lowest coverage of automated calculations, and are least likely to provide deferred member benefit statements proactively. Indeed, even larger, more automated schemes did not necessarily automate deferred benefit statements. We are also aware across industry that many providers do not issue projected retirement figures to younger age groups, preferring instead simply to quote current accrued benefits.
Whichever way Government goes on the level 2 data, there will be a lot of work to do, whether to increase coverage of retirement quotations, full benefit statements, or to introduce the revaluation of deferred DB elements to the current date. Any work required here is likely to fall disproportionately on smaller or more complicated DB schemes.
Our suggestion would be to base the requirement on something that is also useful to the day to day running of the scheme, and not just a compliance number for dashboards. This gives schemes and members alike the ‘double-whammy’ outcome of better dashboard and better everyday servicing.
One suggestion could be to treat a dashboard request by a member as a request for a single retirement projection to an agreed date. This would avoid the relative variety you might get if you just ask for benefit statement data. There is no common standard for benefit statements, and many schemes do not produce them unless asked. Improving or increasing automation around retirement quotations is something that can be used in regular member activity, not just to service dashboard visits.
If phasing is to be used to roll out dashboards at all, it should be used to stagger when schemes and providers must send level 2 data. Phase 1 should be “find everyone”, i.e. maximum market breadth for level 1 data. Phase 2 onwards can then be sector by sector rolling out the automated provision of benefit data. You would not need to explain why certain sectors lag behind others. People would understand that it is a new service and therefore some information will take longer to go live than others. You would not need to explain the differences between sectors, just that dashboards will continually improve over time, so they keep coming back for more. This makes the provision of near-100% coverage in phase one all the more critical.
Underlying schemes and providers will make investments in automation on a cost benefit basis. The legislation being passed will obviously be a big factor in making sure that schemes and providers prioritise this work when they may otherwise not.
Considered Exemptions For Schemes
Lastly, there needs to be recognition that there will still be some schemes that could not afford or justify any more work in this area. Schemes will all be at their own stage of a life cycle. Many will be still working flat out to equalise GMP benefits, others will be carrying out activity to de-risk or even close. We recommend that a small percentage of exception schemes be allowed to respond to dashboard requests offline. Again subject to permissions in the user journey, allow schemes to acknowledge the member and then communicate with them later using the email, or address just provided as part of the “Reconnect” service.
We appreciate that this could be open to abuse, or an excuse not to improve member coverage, so you could create a framework, based on the MI captured as part of industry infrastructure that would allow FCA or TPR to monitor those data providers opting for this exception. There would need to be a controlled list of valid reasons for exception (given that there will be a legislative requirement to provide data). Perhaps controls akin to the way in which TPR can set targets for data quality that allows them to zoom in on those schemes with lower scores to assess the recovery plans those schemes have in place to improve data quality. This way you could focus on schemes who are slow or unwilling to improve automation.
For more information, we are publishing our response to the call for input questions in full below:
Existing user research indicates that people have a low tolerance for incomplete dashboards and would rather wait until the majority of pension providers and schemes are ‘online’. To be acceptable to individuals, what proportion of their pension entitlements should initial dashboards find? Please indicate any consumer or other research used in framing your response to this question.
As described in our background and context, we believe the best, and quickest route to reconnecting people with their pensions is to separate the “find” and “value” functions of Dashboards into separate phases. Having an online “find” service first will immediately resolve a gap in the industry today, reconnecting people in one place of their choosing. This places a focus on phase one to get maximum coverage before considering being fully “live”, perhaps high 90s.
People of course will never know if all the pensions found are definitely all the pensions they have, so communications will need to have that caveat that providers may be missing until the 100% mark is reached.
The advantage of phasing by the content of data, rather than by the providers of the data is that you can check user expectation as you go and prioritise based on their feedback. The additional advantage to industry is that it allows data providers to break up their own project commitments into the work required to support being part of the infrastructure, plus the priority work which has to be getting personal data in order, so that matching works. There will be zero tolerance for false positives amongst risk-averse Trustees and Employers, particularly when the service is new. If data providers don’t get the match process right, then everything else pales into insignificance.
Once that significant piece of work is done, work to make benefit related data more readily available can be delivered later as this is likely to be where the greater volume of work will be. With limited bandwidth in the market, more work inevitably means longer delivery times.
How long (i.e. how many months?) will most individuals find acceptable between first using a pensions dashboard (and finding only some of their pensions) and subsequently finding out that more of their pensions are now available to view?
This does not arise with our suggested solution. We believe it is the depth of information that could be phased, not the breadth of coverage. However, once a “reconnect” service is up and running we believe the gap between find and value data being available should aim for 12 months of phasing.
Certainly no more than 24 months for the harder sections of industry. However we have not engaged any consumer research on this. We are concerned that much of this debate is being fuelled by the need to settle a data standard when there has not yet been enough user research into what the market requires. We appear to be trying to decide what the answers will look like when we don’t really know what questions the users want to ask.
You could use the usage data arising from the “reconnect” service to assess the ages of the members using it and feed that into the second phase to decide if current values or retirement projections would be more useful to members and or more available from data providers. MaPS dashboard could also poll its early users to see what would keep bringing them back to this resource.
Are there any segments of the population for whom the majority of their pensions could be covered early by selecting a subset of pension provider/scheme types?
In the context of our proposed solution to separate the “Find” from the “Value” we need to consider this question in the same two phases. For phase one “Find” we believe the answer to be broadly “no”. We believe that the issues relating to connecting to dashboard infrastructure and the matching personal data processes are not something that is unique to any one sector and so all data providers should be challenged to provide a set of “find” results relatively quickly.
Then, in a second phase of providing Values, the answer must be “yes”, but with qualification.
When you then consider the data relating to the current or future value of benefits, there will be significant variances from sector to sector, but not necessarily exactly how the Data Scope paper sets them out. For example, within any sector there may be variances between whether the arrangement is open or closed, and also variances between size of arrangement within each sector. There is a lot of industry press suggesting DC should go first, or Master Trusts should go first because they have just been through a massive new certification process with TPR. Yet those in that sector know that there is a big variance in data requirement between a large long-standing multi-employer scheme that became known as a Master Trust versus a new world “built-for-AE” Master Trust.
The requirements of each scheme affects the length of time required to be ready for phase two when benefit data would be displayed. Here it would be expected that the bulk of the work would fall onto older, smaller or more complicated DB schemes where extra automation has not passed the cost/benefit analysis. Additionally, DC as a basis benefits from more homogenisation and the existence of more standards. There are COBS rules and SMPI laying out how to project to retirement age. No such market rules exist for DB. Dashboards cannot resolve the long history of our industry’s increasing complexities overnight, and certainly individual schemes cannot, without Industry, or its regulators, stepping in to guide.
DB has a lot more variety, and any attempt at standardisation would be deeply involved and time consuming. Being able to phase delivery of benefit related data would give industry groups the time to work on improving standards in this area.
If you have identified one or more population segments in response to Question 7, what simple, cost effective communication approach(es) could be adopted to explain to all individuals (both within and outside of the specified segment(s)) which pensions they should and should not expect be able to view on initial dashboards?
As our principal suggestion is not to phase by sector until after the whole industry has gone through the “Find” phase, this question really needs to be considered regarding benefit values. Our suggestion would be to avoid the need to distinguish between different types of pension wherever possible and just communicate these issues as a phased roll out. I.e. don’t get drawn into explaining what all the different sectors mean, but just communicate in a more general way to say that the dashboard service is new and it will take some time for everyone to provide data to it. There may be some way based on industry data, or in the proposed governance measurements that dashboards could show some sort of rudimentary progress indicator as to what percentage of the industry’s benefits are covered or how many data providers have been onboarded.
Which data items do you anticipate could be used to definitively match individuals to their pension entitlements? Of the data items listed, are there some (or some combinations) that will provide a more accurate match than others?
Our straw poll across a selection of current clients, shows that the most common fields used to identify people today includes NI Number, Surname and Date of Birth. Postcode is often used as an additional criterion but this is less reliable for deferred members than it is for actives or pensioners. Some clients also felt that gender would help confirm a match.
When you are in conversation with someone, it is easier to drill into different items, but when having to perform matching programmatically, it is likely that our schemes would want to see a fixed set of fields with zero tolerance for mismatches. As providers to those schemes, administration companies and software providers seem more open to the idea of a “possible” match as long as there was a way within the candidate architecture to be able to express a view that a match might be possible, but that the member should contact the scheme directly.
The risk of false negatives has been raised. I.e. that there is a reported fear that people will lose faith in a dashboard that doesn’t find their pensions. We understand that theoretical risk, but the risk of false positives is intolerable for most if not all schemes, and so any solutions formed by industry should reflect that position.
One possibility that has been mentioned to improve match certainty is the ability for dashboards to provide previous names and addresses as part of the data request. Some evidence exists that this information improves the match by considerable factors. Our concern, however, is the user experience. It will be difficult for users to engage with an ID&V journey anyway, so to then ask those for more historic information would just prolong the data entry. Many would drop out if they felt the journey was too hard. Gamification would help here, but we will save our views on that for future consultation on front ends.
What could help the journey is the ability for a third party to enrich the data used in the pension finder service. Many of the FinTech companies specialising in ID&V can also provide data enrichment. Traditionally this has been used to help companies clean or update gaps in CRM or marketing databases. But it could be used within each search to help matching. Once the member had validated themselves through the ID&V process, a third party data source could take what the member had entered, validate it, and then add additional fields that it held. For example, this solution could have the member type in just the current address, and then the data enrichment step of the process could add in previous addresses to send to the underlying data providers to improve the likelihood of a match.
When the Programme procures industry infrastructure, it could consider asking for more value added services like this from the ID&V community to go further than just validating data entry.
Our main concern for matching, however, is not the data item itself, but whether it is asserted by anything in the dashboard infrastructure other than the member. Many of the data items we rely on will have been checked as part of the ID&V steps within the dashboard. However, it is proposed that the NINO entered by the member will be unchecked. We believe that the increasing importance (and reliability) of NINOs warrants there being a service in the dashboard infrastructure to validate member-entered data, if only to improve the member journey. Whatever work we do for matching and clever user experience techniques will be for nothing if a member can enter an incorrect NINO and discover that they have zero pensions.
In Level 1b, we have set out the administrative data items that will be useful to individuals, as these items will enable them to see where their pension entitlements are. Which of these items would be most challenging for pension providers and schemes to supply? Please indicate in your response why this would be the case.
We do not consider these data items to be too difficult to provide from a technical standpoint, but the challenge will be whether this information can be provided in a way that is useful to the members. We are most concerned with employment data. There will be a lot of schemes that never held employer data if it wasn’t needed. Similarly we do not believe that this data, if it is missing, is even possible to re-create through data cleansing. Once it has gone, it has gone.
Related to this, some schemes will not store an employment start date but rather a start date of pensionable service which, for many reasons (such as scheme specific joining dates or under auto-enrolment where the employer uses deferment) may not align exactly with the date the person started work at the employer. It may therefore be better to have an additional field for date pensionable service started and schemes have to provide either of these dates. It should be noted that the date left scheme may also not align with the date left employment if they opted out of a scheme without leaving the employment.
One of the DWP design principles is that dashboards will initially be used for presentation purposes only (i.e. they will not alter the source data). This means that initial dashboards cannot calculate projected pensions, meaning that pension providers/schemes must supply an Estimated Retirement Income (ERI) for each pension. This includes situations where there are multiple “tranches” within a pension, i.e. multiple ERIs with multiple Payable Dates may need to be supplied. The Level 2a data tab
We do not share the DWP’s concern about dashboards being able to carry out maths. We contributed to PASA’s work in this area in 2017 which subsequently became the dashboard prototype’s core assumption. We agree that we would not wish to see a dashboard framework that would allow different dashboards to present different results, but believe that you could design a framework where all dashboards were allowed to carry out the same interpretation of data provided by schemes to make the returned values more comparable.
The alternative is, that if the requirement remains that schemes provide the equivalent of a benefit statement, all of these numbers will mean different things and be effective from different dates. No member would be able to work out where they stood.
Another alternative is to mandate that schemes all provide the same thing. This will create quite a burden on many schemes, which will be felt worst by the smaller DB schemes, i.e. those that did not pass a cost/benefit point to make automation worth investing in. Very few DB schemes produce deferred member benefit statements proactively, so very few will have automated that activity. Additionally, there is no common standard for DB benefit statements, so even those schemes who do have automation will not necessarily have the right automation to meet the requirements of Dashboard.
That being said, schemes were previously looking down the barrel of having to produce deferred benefit statements under IORP2. (Articles 38 & 39). Many will think that has gone away with the UK’s withdrawal from the EU. However, our understanding is that IORP2 predates the withdrawal agreement and therefore, unless UK specific legislation is passed, IORP2 is UK law and still needs to be implemented. If UK Government’s position is still that the implementation of Dashboard is how it will satisfy the requirements of IORP2, then our suggestion would be that we maximise the benefits of carrying out that work by allowing schemes to provide something that will be useful to them beyond just being dashboard compliant. We suggest that if schemes could provide a retirement quote online as part of the dashboard requirement, that can also be used for processing member requests and retirements: not just a number they need to produce for a website.
There would still be a long way to go to achieve that, and so our comments on the phasing of the depth of data provided still stands, but this approach would allow industry bodies to step in and work towards a common way of addressing the challenges. Many administrators today would not quote projections of retirement benefit if the member were too far away from retirement, so the approach on how to project, or what assumptions to use in the projection would be required. Much as it was for the DC market when SMPI rules were agreed.
The additional benefit of establishing a single projected ERI, is that it would avoid the difficulties currently presented by different schemes providing benefit statements that all default to different dates. Some challenges will still remain, such as agreeing which date schemes should project to. Some schemes will not allow late retirement (for example) and so their benefits would not be able to be quoted at the current state pension age if the scheme retirement age is lower. However, we believe the provision of retirement projections would be simpler than standardising benefit statements.
The other comment we would make regarding benefit data is partly related to 1b, but also to 2a. There are some schemes whose benefit structures would require them to return multiple values, but have them linked to each other. One example is a scheme with external AVCs. There would need to be a link between the scheme and the AVC benefit to show that the two are linked to each other. This is because the benefits will be of different types, but must be taken together.
The second example is where schemes accrue pension and cash elements separately in the same scheme. The proposed Royal Mail CDC scheme is one modern example: the pension benefit is calculated as a CARE-style benefit and represented as a pension per annum, whereas the pension commencement lump sum is a separate DB section with different accrual rules. It is expressed as a cash amount. Again, both need to be taken together.
Are there any “disclosure items” (i.e. items required under current disclosure regulations) that are currently challenging to supply digitally? If so, please indicate how many months it would take to make these “disclosure items” available digitally?
It would be difficult to accurately cover the variety of our clients in one simple response as different schemes will have different challenges. The only generalisation that could be made would be the assumption that smaller, older or more complicated DB schemes would be challenged more than larger, simpler ones. It would not be a reflection of the levels of automation achieved rather than the details of the data items. Even when a scheme benefit can seem simple now, it does not necessarily reflect the long histories of promises, guarantees or other special exceptions that we can never seem to be rid of.
That being said, if the requirements became clear and schemes had to provide data that they do not provide digitally today, they could always choose to conduct annual exercises to ascertain the results, and store them ready for retrieval online by a dashboard data request. That is an approach that some schemes may be able to cost-justify. For most complicated DB structures (and we believe this is mostly required for DB) the values would rarely change mid-year, so returning a value that may be up to 11 months old would not be too inaccurate.
We would also add though, that the current disclosure requirements are very heavyweight with several pages of requirements about assumptions and statements. In addition much of the current disclosure requirements are out of date, for example they are based upon the idea that a member of a defined contribution scheme will buy an annuity whereas most people nowadays do not buy them.
Rather than try and get further data on the dashboard in the initial phase it should be a requirement that members are signposted to where they can get further details. At the same time the industry should work with the regulators on disclosure requirements that work for everyone that are simple and easy to understand and informative for the average pension scheme member.
Most data items in level 3 are not currently required to be made available to individuals under the current disclosure regulations. Would any of these (or other) areas of data be able to be supplied voluntarily for initial dashboards?
With the existing cost burden and complexity on our schemes, we could not see any but the most automated schemes willing to volunteer any more information than they need to under legislation. Even then, those schemes that value engagement and go above and beyond the legislative minima today already do so in their own online tools and would rather drive traffic there, rather than do extra in the Dashboard.
Whilst we appreciate the reasoning behind trying to have the data in level 3 in one place there are two issues with making this data available to the dashboard.
-
- Some of the data is sensitive (such as beneficiaries) and if dashboards are to be available to 3rd parties (such as MaPS and financial advisers) sharing this information could present data protection issues.
- Much of this information is non-standard and to try and make this available to the dashboard could deter from efforts to share information that would be meaningful. Instead it may be more beneficial to signpost the user to the company website where this information could be viewed within their context and explanations that would make this clearer.
- Some of the data is sensitive (such as beneficiaries) and if dashboards are to be available to 3rd parties (such as MaPS and financial advisers) sharing this information could present data protection issues.
Our main concern in this area would be that to deliver the policy aims of dashboards evolving from “Find” to “Understand” to “Act”, dashboards will increasingly need to get more personal to the user. We would want to see the future direction of dashboards to be led by user feedback, not by what’s available.