PASA's data matching guidance

Getting ready for dashboards takes time, and there is a lot of preparation work for pension providers and schemes to make sure pension data is ready for connecting to dashboards. I've been encouraged by the continued support across the industry to make dashboards happen and by the work that is still going on to prepare for dashboards. Industry preparation is very much what this discussion is all about. I have alongside me, Maurice Titley who co-chairs the PASA Dashboards Working Group who has agreed to talk to me about this latest guidance that they have produced to support pension scheme trustees and managers in developing their approach to matching.

Yeah, Thank you, Chris. Thanks for having me. So, yes I'm Maurice Titley, and I'm co-chair of the PASA Dashboards Working Group. So yeah. Matching. Why? Why is matching such a difficult thing to look at? So the background to matching is simply that there is no central database behind the pensions dashboards ecosystem. And for that reason, there is this concept of a pensions finder service that when a user searches for their pensions, the personal details of that user get sent out to every UK pension scheme that's connected and it needs to be matched with the records that are held by that scheme. Some of that find a request consists of verified data and some consistent data. The user might have volunteered. We don't know how much users are going to volunteer, and the challenge for schemes, trustees, and scheme managers is to work out how they are going to compare those two sets of data and what match criteria that we use to say, Yes, this is our member. I'm going to show this member the pension values that they have in our scheme or possibly where they're going to look at it and decide that it might be that member, but they're going to go down a process we'll talk about later, which is the possible match process. We decided it was really important for PASA to provide some guidance to scheme trustees and administrators. Here. It is the responsibility of the the trustees and scheme managers to set the match criteria, we produced our first guidance in December 2021, and this guidance looked at the most popular criteria that we thought the industry were going to go for. We surveyed the industry and decided NI Number, surname, and date of birth was the most popular criteria there. But it also looked at how that could be extended.

PASA's latest guidance looks at matching without a National Insurance number. Can you say why that is on your radar and how the guidance can help pension providers?

Yeah. So I think this is a really important issue. National Insurance number is one of those data items that is not going to be mandatory, as you've said, and it's not going to be verified when it's entered by users. So it could be slightly mistyped, it might not be provided at all. What we also know from working with schemes is that some schemes don't hold a National Insurance number for every member of their scheme. Some of them may even not have a National Insurance number. Other schemes might hold a temporary National Insurance number from when the individual was enrolled. At that point in time, that individual might have left the scheme and there are very few options to get hold of what the correct National Insurance number is for some of these schemes. So we can't rely on it being that it's really important to have additional criteria that the scheme can fall back on in matching that don't include a National Insurance number. And that's precisely what our additional guidance section is covering.

So how does your guidance suggest you deal with this? Do you have some examples?

I think the important thing is to have multiple match criteria, and some of the match criteria that don't have National Insurance number that we've suggested are those that involve other user-asserted data items that can be provided. So one of them is an email address. We know a lot of schemes don't hold lots of email addresses, but some do and over time I think that will become more commonplace. So the email address is another great way of getting confidence you've got the right individual that they were matched by chance. A really important one as well is the match criteria of last name, first name, date of birth, and postcode. The reason this is important is because those are the four verified fields that are going to be provided in a find request. If those match precisely, they should give the level of confidence needed to make a match-made response. And you'll see more about that in our guidance.

That's really interesting. So why is postcode so important?

If you think about that last criteria, last name, first name, and date of birth on its own, it isn't tight enough to be criteria for making a match. You could have two John Smiths born on the same day. Once you include the postcode, you're getting to the point where you can make that match. And postcodes are interesting because you can of course improve the data that you hold by doing tracing, particularly for deferred members, who may have moved house several times since they were a member of the scheme. So it's a key field to focus on for data improvement, but it's also a very important component of the match criteria that doesn't include a National Insurance number.

Makes a lot of sense. Could you explain what a possible match response is and why that is important?

A possible match is the response that a scheme can give when they look at the find data and think this is very likely our member, but we're not entirely sure. What we want to do is provide a response to the user to say, Please can you follow up with us outside of dashboards by contacting us via other routes? So we can investigate and resolve whether you are our member or not? They're key, I think to dashboards, and the success dashboards that they are a safety net. You can't improve your data to the level where you can guarantee that your personal details held are going to match the find request. It's just impossible to remain on top of data to that extent. So the possible match allows you to catch that member, which means the user will have a better experience, but also you get the opportunity to improve your data based on the information that you're receiving from the dashboard.

So that is really important for the success of pensions dashboards?

It is, and this is why it's in the regulations and the regulator's been very clear that schemes should support possible matching. Even if they're confident with their data, they need that safety net to be in place.

So what makes a good set of match criteria for a possible match response?

The important thing is that it is a set of match criteria. And there are two ways of judging them. One is to do the match criteria in combination. Each should when you look at them all as a whole. Do they provide sufficient coverage? so that you are going to pick up those individuals who are your scheme members, but for whatever reason, because their data is slightly different to yours, you won't have returned a match-made response to them. So you want it to cast the net wide enough to pick up those members. The other way of evaluating them is to make sure that each of those criteria in isolation is sufficiently focused. If you have any one criteria in there that casts the net too wide, such as match criteria that said it's the same surname, that would be way too wide and I wouldn't work dashboards and it wouldn't work for your scheme. You'd be inviting lots of people to incorrectly come and talk to you and waste their time and the administrators' time. It's really important to balance the coverage and the focus. In terms of examples of how you can achieve this. We talked a moment ago about last name, first name, date of birth, and postcode. If you were to drop postcode, that's an example of a standard match criteria that has fewer fields that you want to make a match-made but might work well as possible match criteria. The other type of possible match criteria is to use what's called a fuzzy field comparison. So if you were to go back to the original PASA criteria of surname, date of birth, National Insurance number, if you were to say we're going to call that a match, if the surname is slightly different, a couple of characters out, but it looks like a typo. Then that's an example of a fuzzy comparison. And again, using that for a possible match can allow you to resolve that data discrepancy, but also make sure you capture that member.

Okay, so there are choices that can be made here?

There are choices that can be made here, and I think schemes should talk to their Integrated Service Provider (ISP), and have a look at what the ISP supports in terms of fuzzy matching and possible match criteria. But it is an area where I think there is almost the most choice to be made in some respects and getting that right and also being able to change it. When you have the experience of dashboards being used at volume, you need to be able to change it probably quite quickly because we'll find out how much data users give us.

Now I know the administrators and providers are a little bit worried about the operational overhead involved in all of this. So how can they deal with this situation when dashboards do go live?

The first thing I'd say is what they can be doing now. They can start looking at the personal details that they hold, they can analyse those, and they can carry out some tracing work to understand how up-to-date the data is. whether there are typos that exist in some of the key data and in doing that, they can they can improve their data and get it to a better place. What you can also do from that though, is you can create some estimates as to how many possible matches you think you're going to get out of your membership and think, okay, over time, how many people do we think are going to use the dashboard? There are studies that are reported on PDP's site and other places where you can get a feel for how much potential use that might be and hence how busy your administration team might be If they're handling that level of possible matches. What you can then do as a scheme is get to the point where your data is fully ready for dashboards and work with your ISP to test out what that possible match process will look like. You don't have to connect in to do that. You should be able to test out what those steps look like and gain some confidence as to how you're going to be able to handle that process and build on that process as a pension scheme administrator.

So it sounds like there's a lot you could be doing to get ahead of the game right now.

There is an awful lot you can do to get ahead of the game. Absolutely.

What does the guidance say about directing savers in the event of a possible match and the resolution process involved?

The first thing the guidance says is that there is a pension of reference that can be provided as part of the possible match response, and this pension reference will be available to the user. If the user is going to be directed to make a phone call, it could be embedded with a link if the user is directed to a portal or website. Now another important point we make in the guidance is that this is all happening outside of the pensions dashboard ecosystem. So it's really important that administrators put the individual through their verification process, which might be the way they do things at the moment or something that's slightly amended to make sure they understand who this individual is. Once they understand the individual is who they say they are, then the question is, are they the individual who is the scheme member? They can use the information from the pension reference to have a look at how the possible match response was given, which of the criteria were biting if you like, and making that response, whether there was any fuzzy comparison going on between the two fields. And then they can conclude is this my member or not? What they then do at the end of that process is a number of options and we are going to be giving some further advice as this area evolves over the next few months in terms of the different options available and which ones we recommend in which circumstances. But that's the resolution process in a nutshell.

I think this brings us to the end of the question. So thank you very much for your time and thank you to the PASA Working Group for the excellent work that has gone into this.