What is the purpose of the Data standards guide?
The first version of the Data standards guide outlines the data elements that will go into the data standards, to help providers to review and prepare their data, in preparation for voluntary connection to pensions dashboards from 2022 onwards and staged onboarding from 2023.
What pensions will be shown on pensions dashboards?
Dashboard users will be able to see any UK-based pensions that the pensions finder service successfully locates, including:
• state pensions
• defined benefit pensions
• defined contribution pensions (including a remaining balance after any lump sums have been withdrawn)
Non-UK based pensions will not be shown on pensions dashboards.
What should providers do to get their pension data dashboard-ready?
We have a list of five suggested actions for pensions providers to take to get their data dashboard ready.
What is an integrated service provider?
Integrated service providers (or ISPs) are intermediaries that hold data securely on behalf of pension providers. They will receive the find requests from pensions dashboards and match individuals with pensions, using that data.
We expect some organisations, such as administration software providers, financial technology providers and others, to develop solutions to enable pension providers to integrate with the pensions dashboards ecosystem in this way. These are contractual relationships between the two parties, which are outside of the scope of the pensions dashboards ecosystem.
What was the call for input on data standards?
During the summer of 2020, the Pensions Dashboards Programme ran a call for input on data standards. The call for input asked nine questions relating to the content of our Data Scope and Data Definitions working papers and the responses helped shape the first version of the data standards guide.
What is the Data Working Group and who participated?
We set up the Data Working Group in the summer of 2020, to help the Pensions Dashboards Programme develop the first version of the Data standards guide. You can find a list of participants on the Data Working Group webpage.
What are you going to be testing in relation to data standards?
Our testing is looking at three areas:
1. how dashboards can best present the view data to ensure it makes sense to users
2. what future dashboards could look like (this will involve us having further conversations with the DWP and industry)
3. to what extent our find data will mean a sufficient number of pensions can be found
What is the find data?
The find data is the information that data providers will receive from the pensions dashboards ecosystem, which they can use to match people to their pensions.
Which elements of the find data will the identity service verify?
Currently. we expect that the identity service will always verify:
• first name
• date of birth
• current address
The identity service may not check other find data elements that users supply.
Pension providers will always receive an assertion data element, to indicate whether the individual or the identity service has verified the data.
Why are some find data elements optional and others mandatory?
Some find data elements are optional to reflect the fact that this information may not be provided to pension providers by the pension finder service.
For example, alternative name will not be populated if the user has not entered an alternative name in the dashboard. Similarly, previous address, email and mobile information may not be provided in all circumstances. In determining their own matching criteria, pension providers should take the optionality of find data elements into account.
Where can I get further information on good practice for matching, to help define what personal information data my organisation should use to match against?
We will engage with pension providers as to how many, and which combinations of elements on the list they would need to be able to match against, to identify an individual’s pension. This is important to ensure that we have sufficient coverage to go live and also, to identify whether we need to provide additional guidance on when to match.
We are aware that there are industry bodies addressing this challenge, which plan to issue guidance of their own, incorporating technical input from the industry’s leading software providers.
Why is the PDP not defining the matching rules to be adopted by pension providers?
The PDP is defining the list of data elements to find matching pensions but not defining the matching rules to be adopted by pension providers, as providers will hold different data and use different processes. We want providers to feel comfortable with their matching process.
Our research, via the call for input and Data Working Group, demonstrated that pension providers adopt different rules to match individuals to their pensions. Provided sufficient pensions can be found (and we’ll check this) pension providers best understand their own pension data and are best placed to determine which elements they wish to match on.
It will be up to each pension provider to determine their own matching rules against the find data, to ensure these rules minimise the risk of returning the wrong person’s data and that they are comfortable with the level of risk their own data quality gives them.
How can I use ‘alternative name’ in my matching process?
Ultimately it will be for each pensions provider to decide what data fields are suitable and trustworthy to match on.
One option you might consider, is to try to match on given name first and then perhaps check for the alternative name instead, if the first name doesn’t match. But it will be for each pensions provider to decide how to weight the certainty of a match performed in this way.
How do we deal with a close match?
Feedback from the Data Working Group indicates that when pension providers cannot locate a matching pension for an individual but believe that there is a strong possibility that such a pension exists, they would like an option to alert the individual that they may have a pension for them and ask them to get in touch.
We will investigate this close match process further and develop a solution when we have established the pension finder service.
Can you provide more information on the format of given name (eg use of hyphens, apostrophe etc)?
We will provide more detail later in the programme as we finalise the technical aspects of the message formats.
Can I use a previous address to help match my pensions?
Previous addresses may be useful in giving you increased confidence in your match, but it will be for each pension provider to decide if they can rely on it, or use it as an additional comfort factor.
Can I use email and mobile phone data to update my pension record and contact the individual?
Not currently. As part of our ongoing work into usability and liability, the Pensions Dashboards Programme will assess whether individuals wish to allow pension providers to update their contact information as a result of data added or updated during a dashboard visit.
If our research indicates this would be desirable in future, we would need to develop the functionality for individuals to provide their permission for this use of their data when they register on their chosen dashboard, or begin a new search.
What is view data?
View data is the information that pension providers will have to return to individuals to see on dashboards.
View data will include information about:
• the pension
• details about the pension administrator and how to get in touch with them
• if appropriate, employment information relating to the pension
• an estimate of the retirement income the individual may receive
• if appropriate, the current value of the pension
• signposts to additional information about the pension
How do the data standards support different pensions relating to the same person?
If they are separate pensions owned by the same person, we would expect pension providers to send multiple returns to the search request.
How does the data standard support pensions with both defined benefit (DB) and defined contribution (DC)?
We will be refining our guidance on mixed benefit schemes as we work through the details, but for now, the assumption is that pensions with both types of benefit can send values for both elements together in the same response if they are both applicable.
For other pensions, where the overall value may be the greater of X or Y (for example) we encourage you to get in contact with us at email@example.com so we can ensure our data standards cover as many common types as possible.
View: estimated retirement income (ERI)
Why are some view data elements optional and others mandatory?
For some data elements, the description is flexible enough to permit pension providers to supply the information they believe is most suitable.
In general terms, the following definitions apply:
• mandatory – the data element must be provided in all circumstances
• conditional – the data element must be provided in particular circumstances, which we explain in the detailed data definitions in the Data standards guide eg it could become mandatory or allowed to be present only if another data element is present
• optional – the data element can be provided, if it is relevant and available
What does conditional mean in the Data standards guide?
This relates to the optionality of data elements in the Data standards guide. In certain circumstances, whether the data element is populated may depend on the value of another data element, so it is ‘conditional’. For example, if alternative name is provided then an alternative name type must also be populated.
What figure should I provide for the estimated retirement income (ERI)?
You will need to provide the information that disclosure regulations already require you to, when an individual asks for a benefit statement. Of course, many providers do more than this, so it will be for each provider to decide, which estimated retirement income figure they believe to be most appropriate to show on the individual’s dashboard.
How does the Data standards guide deal with pensions with different retirement ages for different parts of the same pension?
The Data standards guide allows for all pension estimate values to also show the date to which they have been projected.
Is the value of a deferred pension at date of leaving appropriate as an ERI for deferred DB pensions ?
Ideally, the ERI information for a deferred DB pension would be revalued to today’s date but we recognise that this value may not be available in all circumstances.
Will pensions dashboards make calculations to ensure more comparable and consistent ERI values?
Dashboards will not be allowed to make any calculations. They will only be allowed to present the data given to them by the pension providers. They may employ some simple display logic, for example, converting an annual pension into a monthly figure, or vice-versa, but no calculations that fundamentally change the value sent by the pension provider. This may be subject to review in future as technology advances and the service matures.
How will dashboards work with the lack of comparability of numbers from different bases?
The Pensions Dashboards Programme recognises that ERI values may not be consistent, nor directly comparable, due to differences in pension providers assumptions (on future service/contributions, retirement ages, revaluation/investment growth, type of annuity etc).
Longer term, we would like there to be a common and consistent approach for all pensions.
View: pension arrangement
What does an inactive pension status mean?
We use this term to describe a pension that is no longer accruing service, or no longer receiving contributions.
Further information on data standards
If you have any additional queries about our data standards publications please email firstname.lastname@example.org.
Our glossary provides a useful set of definitions for some of the terms you may come across in these pages.