Pensions Dashboards – Matching Criteria



As people move through their working life, many will have several jobs with many different employers. As a consequence, they can end up with pension savings in many places.

This makes it increasingly difficult to understand what an individual has in place for retirement, particularly if there are pensions they do not know they have.

The aim of pensions dashboards is to enable individuals to access their pensions information online, securely and all in one place. This will include any pensions that they are not aware of.

One of the keys to the success of dashboards will be the ability to find all pensions across the 40,000 schemes that exist. This is dependent on the scheme selecting the right matching criteria to match an individual’s personal information to the records that they hold.

Find data

Each time a user attempts to find their pensions, all schemes or their agents (in the form of an integrated service provider (ISP)) will receive a structure request from the central digital architecture1 (as provided by Pensions Dashboards Programme (PDP)).

This request will contain specific information relating to the user, some of which has been verified against third party sources, such as credit registers, and some which has been provided directly by the individual themselves.

Data Field Verified or not
First name Verified by ID provider
Last name Verified by ID provider
Date of birth Verified by ID provider
Address Verified by ID provider
National insurance number
Self-asserted by individual
Previous addresses Self-asserted by individual
Previous names Self-asserted by individual
Email address Self-asserted by individual
Mobile phone number Self-asserted by individual

The data fields above (also referred to as the ‘matching data set’) are provided to enable schemes to search across their databases to find the user. It should be remembered that every find request will be sent to all schemes, therefore there will be thousands that do not match against a scheme member.

The matching of members is based on defined matching criteria. Setting the criteria is the responsibility of schemes, or more precisely trustees.

Matching Criteria

Matching criteria are established by identifying the fields in the matching dataset that are most likely to contain the accurate data held by the scheme. A search is then conducted over these fields to identify matches. As a baseline it could be considered that a combination of national insurance number, last name and date of birth provide a good basis for matching, and in the majority of cases this will be sufficient. However, there are circumstances where it may be appropriate to utilise a different set of criteria; for example the data could indicate address could be more appropriate than date of birth.

Studies have been undertaken to determine options for matching criteria. The Pensions Administration Standards Association (PASA) has published a well- considered approach to  matching which has been adopted across the pensions industry as a baseline.

PASA Data Matching Convention

Their study looks at a range of options and the benefit of layering additional data onto a base match as required.

Initially trustees may look to only support positive matches where all selected elements match exactly. In time, as confidence in the match process grows, trustees should be encouraged to consider the use of ‘maybe matches’. In effect, a maybe match is where most of the personal information matches the scheme’s member data but there is sufficient difference not to be absolutely certain that the individual is a match. The option is to return a response that asks the individual to make contact and we can then subsequently evidence it is (or is not) a match and make necessary updates to records.

The PASA guidance reflects approaches using the core fields of Surname, DOB and NINo and breaks the approach down into three options:

  1. Option 1 – Exact match on Surname, DOB and NINo otherwise do nothing
  2. Option 1 enhanced – Where surname does not match include alternate name and if exact match return a positive match otherwise do nothing
  3. Option 2 – Match on Surname, DOB and NINo but also include rules to generate ‘maybe matches’. This provides flexibility and should enable broader responses
  4. Option 3 – If Surname, DOB and NINo nearly match, then compare with other data elements to check whether making a positive return is appropriate

The danger with selecting any approach is that it could either make the rules too rigid or too simplistic, depending on how they are applied. The risk inherent from being too rigid is that genuine matches may be missed because of small data errors e.g. Surname spelled incorrectly on admin system (Pocock vs Poccock, Smith vs Smithe vs Smyth).

If the solution is too flexible the other way, the risk of a false positive match being made and incorrect disclosure of data is increased.

The reality is that each scheme will need to determine its preferred approach and provide confirmation of the matching criteria they wish us to put in place.

Data Quality

The success of any matching criteria is directly dependent on the quality of the personal information held for individuals by the scheme (or their administrators). There are many reasons why information may be incomplete or inaccurate, for example:

  • Information was not provided when the member joined the scheme
  • The member has moved and not notified a change of address
  • The member has got married, divorced or changed their name for any other reason and not notified the scheme

It is vitally important therefore that all schemes review the data that they hold and undertake whatever remedial steps are required to ensure that data is accurate.

This review should focus on two things:

  1. Is the data complete? – is there information contained within all the data fields required for a match, and does it conform to the correct format?
  2. Is the data accurate? – after verifying that the information is complete, schemes should ensure that it is up-to-date and relevant.

Data completeness

When considering data completeness, the scheme needs to consider a number of elements:

  1. What format should the data be in?
  2. What is the impact if it is present but incomplete versus it not being there at all?
  3. Who provided the information in the first place?

Data completeness is what the Pensions Regulator’s Record Keeping tests measure and so trustees should review their last such review with a focus on proposed matching criteria.

When looking to complete data, the scheme should be mindful of taking shortcuts that will compromise accuracy e.g entering dummy information just to complete records.

Data accuracy

Ensuring data accuracy is a far harder exercise to accomplish, given that all fields may be complete and meet the appropriate data structure, but remain inaccurate because the information is wrong.

Trustees should note that the Pensions Dashboard is not the only reason why data accuracy is important. Accurate data ensures that the correct benefits are being paid to the correct members at the right time, the fundamental duty of pension schemes, and will also be crucial as a scheme comes to buy-out with an insurance company.

There are some things that can be reviewed to provide a first simple view of data accuracy:

  1. Dates of birth that do not make sense –
    a. 01/01/1900 is often used as a filler
    b. Dates of birth where the age is unrealistic e.g >110
  2. Addresses that show as n/a or not known
  3. National insurance numbers captured as AB123456C or using any of the HMRC forbidden characters

Utilising third party agencies that can validate data will go a long way to helping schemes improve the quality of their data, however many of the agencies can simply highlight what is incorrect and not necessarily provide a proposal for correcting data. Where that occurs, the scheme can contact the member to request the updated information. If it is the address that is incorrect, the scheme may not be in a position to contact the member and the issue is magnified.

Broadstone are producing a separate briefing note on data cleansing and proposed actions.

Broadstone’s View

At Broadstone we broadly support the approach outlined in the PASA guidance and thoroughly recommend that trustees familiarise themselves with the document that has been produced.

While we are aware that there is no ‘one size fits all’ set of criteria that will be suitable across all schemes, we believe that schemes should look to make Option 1 or Option 1 enhanced
their initial approach and where appropriate add complexity once testing and trialling, with their data, has commenced.

However, we recognise that there will be variances in data quality between schemes and will look to work with each scheme ahead of staging to provide a proposed set of matching options that the trustees can determine are most appropriate. We will then apply those criteria through an onboarding/test phase and ensure that they are operating as effectively as possible.

Need more help? Contact us today.