No NINo… and other known unknowns: the challenges of data matching for pensions dashboards

The selection of data items which will be used to match members to their pension entitlements is an area where trustees will need to take an active (and well documented) decision. And as I commented in my previous blog it’s also the key to the whole dashboards experience – details of member’s benefits may well be useful and accurate, but members need to be able to successfully find them first!

The Pensions Administration Standards Association published their initial guidance on data matching in December. It was a great starting point, and really helped focus minds on the importance of data accuracy, as opposed to just its presence. Yet as we have got to know more about the data users will provide, its recommendation to aim to match on just three data items seems increasingly unrealistic. Further thinking on the mechanics of matching records with the information users will provide has revealed some gaps which trustees should be aware of.

• National Insurance number. This is as close to a unique identifier as the industry gets, but it is not going to be a mandatory field for users. Those users genuinely without an NI number will be given the opportunity to tick a box to indicate this. For those users who can’t be bothered to grab their payslips to find out what theirs is and enter it, what will the impact be? Should schemes match on the other information they’ve provided? Or return a hard ‘no’? Moreover, if one is supplied, should a positive or possible match be returned if all characters agree apart from two which are transposed?

• Surname. It’s pretty likely that this field will not only be entered, but also be entered correctly, by the user! But trustees should watch out for any members with surnames such as Davies/Davis or Clark/Clarke for example, where it’s likely incorrectly addressed post would have been successfully received in the past, but would not produce a positive match on dashboards. There is also the issue of people who have married or divorced and now have a different surname. Users will be asked to provide an alternate surname, and it’s difficult to see how this item could be discounted from matching criteria (in doing so it would arguably put women at a disadvantage).
• Current address. This is a mandatory – and verified – field, and will therefore be useful for many schemes. But it is a notoriously unreliable data set for deferred members – unless traces are carried out regularly, there will be many current addresses entered by users which just do not match. It may be that trustees want to avoid using this for matching altogether.
• Forename. Trustees will need be aware how this is held on their systems – in many instances only an initial will be held for that field.

How will a possible match be defined?

As the Pensions Regulator identified in their recent initial guidance, the ability to return a possible match is helpful, flagging with a member the need to provide more information before a positive match is confirmed. So what might a possible match look like in practice? This may end up being determined by the capabilities of the trustees’ integrated service provider (ISP), if one is being used. Will an ISP be able to code up their system to return a possible match in scenarios where all chosen items match but there are minor differences, for example:

• Only six of the first eight digits of a National Insurance number are correct
• Two characters of a surname don’t match
• The current address doesn’t match, but the past address does
• Only the initial letter of the forename is held, but it does match.

And should an ISP consider all data matching items provided by a user at once, or take a stepped approach looking to see if, for example, three items match perfectly first, then ‘widening the net’ in stages?

Possible matches will take resource – from both the scheme and the member – to resolve, so trustees should aim to minimise producing them, while fulfilling their dashboard duties. Once more, our recommendation is to get to know your data! Trustees will be expected to record the rationale behind the decision they make on choosing data matching criteria, but they can also adjust the criteria over time should experience show such action is needed.

At LCP we are currently busy with a pilot based on real scheme data to test how different approaches to matching stand up when run past a digital ID verification process. Meanwhile, PASA are due to release their next instalment of guidance on this tricky subject in the coming months. For now, there is one thing we do know: there are no neat solutions when it comes to data matching.

LCP has a team of pensions dashboards experts available to help you plan your connection journey using our 3-step blueprint. To make sure you are dashboard smart - get in touch with your usual LCP contact if you want to know more.