Data management and matching

Find data

Find data overview

Find data is the information a user will provide to the Money and Pensions Service (MaPS) to send to pension providers and schemes to match against their records. This will consist of both:

• identity/biographical data that has been verified by the identity service
• data that the user volunteers, but which is not verified by the identity service, such as previous addresses, mobile numbers and National Insurance number

MaPS does not store this data. It is processed by MaPS only to distribute to pensions providers and schemes to match dashboards users to their pensions.

Pensions providers and schemes will need to work out how they are going to use the incoming data for comparison against their scheme data and come up with a set of matching criteria.

PDP is not responsible for determining the match criteria. The matching criteria, including when to make a possible match, is the responsibility of the pension provider or scheme.

Find data journey

The find data journey starts when the user accesses the dashboard. The dashboard redirects the user to the consent and authorisation user interface to perform authentication and identity verification actions against the ID verification provider.

Where a pension is found, or where a possible match is identified, the pension provider or scheme registers a pension identifier (PeI) for the match/possible match. This is securely stored at the consent and authorisation service. The dashboard can then retrieve registered pension identifiers for the user, subject to the user having authorised this at the consent and authorisation service. The dashboard uses the pension identifiers to make the view call to the pension providers/schemes where the user’s pensions information resides.

When the user starts another session, the dashboard will use the pensions identifier to check that the user is already authorised.

Retaining find data

DWP regulations and FCA rules set out some requirements on data deletion in the case of possible matches.

Once the pension provider or scheme makes the return to the dashboard indicating there has been a possible match, the dashboard user has 30 days to contact the scheme to resolve the match.

The 30-day period is important. If the user does not make contact within this time, the pension provider or scheme must delete the find data and de-register the PeI. If the user does make contact within the 30 days, the pension provider or scheme may retain the find data for as long as it thinks is reasonable to resolve the match.

Matching criteria and approaches

How to match data

PASA published an update to their guidance for pension providers and schemes on the range of approaches to selecting matching criteria. This is the criteria when determining if an individual from the find data matches the member records they hold.

PASA Data Matching Convention (DMC) Guidance

Chris Curry, Principal of the Pensions Dashboards Programme (PDP), interviewed Maurice Titley, co-chair of PASA’s Pensions Dashboards Working Group, to discuss this guidance.

Chris Curry’s interview with PASA on data matching guidance

Possible matches

A possible match is where an individual’s personal data partially matches the criteria, but a definite match is not made between a find request and scheme records. Supporting possible match responses where needed is a requirement of the legislation, and is clearly set out in The Pension Regulator’s guidance on pensions dashboards.

Possible match responses are an important safety net to help provide a positive dashboard experience. If a scheme holds a minor discrepancy within a member’s personal details, then the individual would not find their pension without the help of possible matches.

Possible match responses sent to users do not contain any sensitive pensions data. They just contain limited information to allow the user to get in touch with the provider or scheme. Then they can provide further information to resolve the possible match.

Although PDP standards and architecture facilitate possible matching and their resolution, possible match criteria are chosen by providers and schemes who can refer to PASA’s guidance on matching without a NINO and possible matching.

Match criteria beyond National Insurance numbers

It is expected a National Insurance number will usually be volunteered as an unverified data item when someone searches for their pensions. However, in some cases this may not be provided, and some pension providers and schemes may not hold this information accurately for every member.

It is important to consider additional criteria to use for matching that does not include a National Insurance number. This will help maximise the opportunities to match savers to their pensions.

One of the example match criteria in PASA’s guidance is last name, first name, date of birth and current postcode. It is expected that all of these will be verified fields provided in a find request, which adds confidence when using these for matching. Other examples such as last name, date of birth, email address can be useful where additional information like email address is volunteered.

PASA guidance for choosing possible match criteria

PASA’s guidance on possible matching includes 2 main considerations when choosing a set of match criteria for possible match responses:

• sufficient coverage: look at the set of match criteria as a whole – does it pick up a high enough percentage of scheme members who have failed to be fully matched due to data discrepancies? Sufficient coverage helps to avoid the negative outcome of members not seeing any reference to their scheme pension on dashboards
• sufficient focus: make sure that each of the match criteria in isolation is sufficiently focussed to avoid individuals being invited on a wasted journey to contact the scheme’s administrator. For example, if one of the criteria is to match only on last name, that would return a possible match for anyone who happened to have a last name. This would be too wide a catchment

PASA highlight the importance of balancing coverage and focus, and being prepared to make changes when high volumes are using pensions dashboards.

Matching responsibilities and UK GDPR

All these possible matching duties sit alongside UK GDPR duties and do not replace them.

Possible matching will involve UK GDPR decisions pension providers and schemes must make. As a data controller, the pension provider or scheme should ensure it complies with its UK GDRP duties, including satisfying itself it has a lawful basis to process personal data.

Reference numbers and possible match returns

When a pension provider or scheme makes a return indicating a possible match, they can also include a reference number.

It is not compulsory to use the reference number when making a possible match return. It’s a decision for the pension provider or scheme when to use the reference number.

If used, the reference number would be used to link the dashboard user when they make contact with the pension provider or scheme.

It helps pension providers and schemes in linking the contact with any relevant stored information and the details of the possible match PeI. This will be used to update or de-register the record at our central digital architecture when the outcome of the possible match process is known.

Avoiding possible match loops

If a pension provider or scheme has a possible match which resolves into a no match, they don’t have a record to update. If the same customer repeats the process when a subsequent find request is made, this is called a possible match loop.

The technical standards contain information on identifiers that can be used to identify where repeated requests are issued in relation to the same user and avoid possible match loops.

View data

View data overview

View data is the information pension providers and schemes return to a user’s dashboard following a match against their records.

The pension finder service securely sends the find data, which has been supplied by the user to the Money and Pensions Service, to pension providers and schemes. Pension providers and schemes check this information against their records to see if there are any matches.

When a match is made, the pension providers or schemes register the match and return data to the user’s dashboard.

View data includes:

• contact information for the provider/administrator
• a description of pension type (such as State Pension, defined benefit or defined contribution)
• information about the employment to which the pension relates (for occupational pensions)

It also includes the date payable and a measure of pension value including accrued value to date, and an estimate of how much the user could receive in retirement.

The Pensions Dashboards Regulations and corresponding Financial Conduct Authority rules specify the data items to be returned and the timescales for the return of pensions information to members via dashboards. Legislation also states that the main pension provider or scheme must ensure all elements of the benefits, for which they are responsible, are made available to their members via dashboards.

View data is only stored by pensions providers and schemes, and the dashboard only stores the data temporarily for display until the user exits the dashboard.

View data journey

A user will access the dashboard and initiate a view operation. On receipt of a view request a pension provider or scheme will check with the consent and authorisation service to confirm that the token it has received from the dashboard is valid.

The pension provider view API is called, authorisation for the call is checked, and if authorised the pensions data is returned to the dashboard.

Data preparation and cleansing

Responsibility for data accuracy

Pension providers and schemes are responsible for data accuracy and will match individuals with their pensions based on the user’s personal data. Getting data ready is a crucial part of the process for pension providers and schemes preparing data to connect to pensions dashboards.

It is important that providers and schemes regularly review the quality of their current data.

Pension providers and schemes will also need to review the pensions values that will be returned to dashboards and ensure the pensions data is digitally available.

Once connected to the dashboard, users can request their pensions information anytime, so it is critical for providers and schemes to regularly check and make sure all data is accurate and up to date.

Data preparation

Pensions providers and schemes will match individuals with their pensions based on users’ personal data. Getting data ready is a critical part of the process for pension providers and schemes preparing data to connect to pensions dashboards.

It is vital you review the quality of your current data and focus on the elements that may be used to match users with their pensions.

You will also need to review the pensions values that will be returned to dashboards.

Once you are connected to a dashboard, users can request their pensions information anytime. Pension providers and schemes need to ensure their pensions data is digitally available, accurate and up to date before connection.

Get your data ready for pensions dashboards explainer video

TPR provides useful information on the benefits of preparation for dashboards and how their checklist can help in their latest blog.

Read TPR’s blog about their dashboards preparation checklist

Download TPR’s dashboards preparation checklist

When schemes need to be ready to produce pensions value information

The requirements apply when your scheme has connected to the pensions dashboards ecosystem and has made a match, following the receipt of a find request, in respect of a relevant member.

The full suite of pensions value information is the accrued value and annualised income that this pot could produce. It is also the estimated retirement income (ERI) value and annualised income that this pot could produce. All these values should be calculated at the same time and using the same underlying accrued pot.

View data response times and the 3/10-day rule

3/10-day rule in legislation

The Pensions Dashboards Regulations and corresponding Financial Conduct Authority rules specify the timescales for the return of pensions information to members via dashboards.

The legislation sets out that where the value has been generated for a statement provided to the member within the past 13 months, or is based on a calculation made within the past 12 months, the information must be returned immediately. But where neither of these apply, pension providers and schemes are permitted a set amount of time to undertake the necessary calculations and return the values.

How the 3/10-day rule is applied

Pension providers and schemes have 3 working days where all benefits provided to a member are defined contribution (money purchase) or 10 working days for all other cases, to calculate and return the prescribed pension value data to the dashboard. The clock starts for these 3/10 working day calculation times for the first values to be provided the day after the pensions identifier (PeI) is registered as a match made.

When the PeI is registered as a possible match, it does not trigger the 3/10 working day period for return of the values. In the case of a possible match, no value data should be returned. It is only for a full match (including where a possible match is re-registered as a match made) that the 3/10 working day rule applies.

The time permitted for the first calculation of the values and making them available for return to dashboards is therefore tied to the match being made in response to a find request, rather than to receipt of a view request. The values must be calculated and made available for return to dashboards within the 3 or 10 working days.

For repeat visits by a user, once a calculation has been made, the value should be available for immediate return.

If users request their values after time has passed

The legislation still requires the values to be returned immediately if they have been provided in a statement in the last 13 months or a calculation for the member within the last 12 months.

But if this doesn’t apply and the values must be calculated, it may not be possible for the pension provider or scheme to return the values within 3/10 working days of the registration of the match, since more than a year could have already passed since the match was registered.

This is covered in the code of connection.

3/10 rule and response times in PDP standards

The above timescales for calculating and making available the required pension values as set out in legislation sit alongside the requirements for the technical response times. These will be set out in PDP’s service standards which are contained in the code of connection. The draft code of connection sets out that responses to view requests must be returned to dashboards within 10 seconds of receipt of the view request.

The technical view response time applies to the pension value, regardless of the view data being returned.

If the values are not already available, the pension provider or scheme will still be required to return the administrative and signpost data. This will include a code to indicate the values are being calculated and the user should come back to view them (this code is set out in the data standards).

In this instance, the administrative and signpost data must be returned within the 10 seconds technical response time. The scheme is permitted the 3/10 working day calculation period to then calculate and subsequently return the value data.

Penalties for exceeding the 3/10-day rule

A failure to provide data within the response times would constitute a breach. Enforcement is set out in the legislation.

The Financial Conduct Authority (FCA) may take action against firms that do not comply with its dashboard requirements for pension providers.

The Pensions Regulator (TPR) also has powers to issue compliance notices and penalties if trustees or managers fail to comply with their pensions dashboards requirements.

Additional voluntary contributions (AVC) pension data

Responsibility for making AVC data available on dashboards

Under the legislation, the main pension provider or scheme must ensure all elements of the benefits for which they are responsible are made available to their members via dashboards.

This includes where there is an AVC pension linked to the main pension. We are aware that AVC pensions are usually administered by a separate provider.

Returning AVC data

Pension providers and schemes do not always have to return AVC data. The system has been built to be reflective of how the pensions industry operates.

Many AVC providers will want to connect to the ecosystem directly, or via a third party and return data via a separate connection to the one used by the main scheme. Some AVC providers will want to provide the AVC data to the main pension provider or scheme.

Irrespective of the setup, the pension provider or scheme should work with the AVC provider to ensure data for the AVCs are available on dashboards in a joined-up way. PDP has created the pension link, outlined in the data standards to make it easier for providers to ensure their returns are linked up when displayed on a dashboard, even where there are multiple sources for those returns.

Making AVC data available for pension provider or schemes with separate AVCs, or split benefit administration

1. The main pension provider or scheme will return both the main scheme values AND the AVCs: in this option, the pension provider or scheme will need to make sure it is getting a feed of relevant data from the AVC provider. This would be a better option to use if the AVC provider does not hold enough personal information to carry out its own matching process.
2. The main pension provider or scheme will return the main scheme values AND the AVC provider will return the AVC values but WITHOUT generating a pension link: The provider or scheme could decide that it does not consider it too confusing for the two sets of data to potentially be displayed apart from each other if the AVC benefit was suitably named. This is likely to be an option where the pension provider or scheme and AVC provider’s communications with the user have always been separate. In this case, they may choose not to create a new unique identifier. However, pension providers are reminded that they are responsible for ensuring all of their user’s benefits are displayed on dashboards.
3. The main pension provider or scheme will return the main scheme values AND the AVC provider will return the AVC values but WITH generating a pension link: If it is decided that although both benefits are to be returned separately, they should be displayed together. The main scheme pension provider or scheme should generate a pension link identifier and pass the identifier to the AVC provider. Both the main pension provider or scheme and the AVC provider will then need to populate the pension link field in their view data payload. This serves to enable dashboards to join together the values for the purpose of display to the user. The user will then understand the links between these values.

For options 2 and 3, the pension provider or scheme should investigate to what extent they need to be satisfied that the AVC provider’s matching policy is consistent with their own policy.

Displaying AVC policies before the main scheme’s connection

As a consequence of the staging profile, many AVC providers may be connected to dashboards in advance of the main pension provider or scheme.

Until the main pension provider or scheme has been connected, the AVC provider should only make value returns to dashboards when the benefit is a free-standing AVC benefit, therefore not an investment on the part of the main scheme.

The AVC provider can also use the employer details, if these are held, to draw the user’s attention to information which can help the user understand how the AVC pension was built up.

Local Government Association (LGA) Pensions Dashboards connection guide for Local Government Pension Scheme (LGPS) administering authorities

The LGA has produced guidance to help pension providers and schemes identify the steps they need to take to connect to pensions dashboards. This guidance provides information on:

• creating a project plan to implement dashboards
• actions and decisions that providers and schemes need to take
• recommendations on common approaches to matching and providing value data in relation to AVCs

LGA Pensions Dashboards connection guide for LGPS administering authorities

Showing value data from different sources with a ‘pension link’

What pensions links are

The pension link is a unique identifier (UUID) that schemes may use to connect benefits together where different parts of the overall benefit are provided by 2 or more different pension providers or schemes.

Pensions links allow 2 or more parts of an overall pension benefit to be provided by separate data providers and still be displayed together on dashboards.

This ensures dashboards display the value data returned for different sections of the same scheme, from different sources, together within the summary of information.

The most common example of where a pension link would be used is where a pension provider or scheme returns the user’s main pension provider benefits to the dashboard. The AVC provider also returns AVC data directly to the dashboard rather than via the main scheme. The dashboard can see the benefits are linked and ensures they are presented together to the user. This is consistent with the design standards.

Hybrid schemes who have separate administrators for each section could use this too if they also wish to send the benefit data separately but have them visually displayed together on the dashboard.

Pensions links are defined in the data standards.

Using pension links

Where a pension link is used, one pension provider or scheme generates the identifier and passes it to the other provider. Both parties will include the pension link in their view request returns. Dashboards will be able to identify that these pensions will need to be linked on the dashboard display.

Raise a new query