I’m just a girl. Standing in front of a dashboard. Asking it to tell me what pensions I have.
Pensions dashboardsOk, so dashboards aren’t the stuff of a rom com set in Notting Hill, but it does sound almost romantic in its simplicity, doesn’t it? I type my name, address, date of birth and National Insurance number into a pensions dashboard and up pops a list of my pension entitlements – showing me just what my future retirement might look like.
But what pensions show up in that list will depend on whether the data I’ve typed in matches the data pension schemes allow it to match with – as this will be decided on a scheme by scheme basis by trustees. One scheme might only show entitlements if the surname, date of birth and National Insurance details match; another might also look at forename and address before flagging a match.
In December 2021, the Pensions Administration Standards Association (PASA) published its guidance on Data Matching Conventions – outlining how trustees might match the data sent by dashboard users (‘find requests’) to the data held on members’ records. The publication promotes the need for consistency in the industry’s approach to the issues surrounding matching, and suggests three options trustees should consider when setting their own conventions, depending on the accuracy of surname, date of birth and National Insurance number.
Why can’t all schemes use the same matching criteria?
While sounding obvious, the purpose of matching is to link a user with all their pension entitlements (positive matches), and only their pension entitlements.
If every scheme’s data was highly accurate, we could say all schemes should return a positive match if the member’s surname, date of birth and National Insurance number matches what is held on their systems. But if that data isn’t accurate, then some pensions won’t be found. Users will be told they don’t have a pension when in fact they do – a so called ‘false negative’ - and may act on incomplete information. So schemes with less accurate data may want to go further and – if those items don’t produce a match – look at forename, maiden name and address.
Indeed, there may also be reasons specific to certain schemes for choosing a particular matching convention. If the sponsoring employer is the predominant employer in an area and employees are often related – sometimes with very similar National Insurance numbers and – in the case of twins – the same date of birth, then the trustees may want to include forenames in their matching convention. Twins living in the same house working for the same employer isn’t common, but it does happen!
However, cast their matching net too widely, and trustees may end up returning a positive match when there isn’t one.
A third way would be to return a ‘maybe match’ – telling users they may have a pension entitlement and to contact the administrator to find out more. This seems like a neat solution, but schemes will be expected to return as many positive matches as they can without relying on this option, and such matches would increase demand on administrators fielding queries from users for whom they may not even administer a pension.
In short, the approach trustees take will ultimately rest on the presence and accuracy of their scheme’s data, and will involve balancing the need to comply with dashboard regulations alongside the risk of causing a data breach.
What can trustees do now?
We recommend trustees:
- Familiarise themselves with PASA’s guidance so they are ready to discuss which matching criteria they might use for their scheme;
- Assess their scheme’s data for presence (the Common Data scores required by the Pensions Regulator will help with this);
- Assess their scheme’s data for accuracy. How confident trustees are on the presence and accuracy of their scheme’s data will help them decide the approach they take to matching.
Matching isn’t just something that happens in bookshops in Notting Hill – it’s a key part of making sure pensions dashboards are successful and can connect users to as many of their pensions as possible.