Skip to main content
Table of contents

Introduction to matching

When a verified user needs to access your service, you will trust the user’s identity, but may need to check if the user’s identity can be linked to information held by your service. This process, known as ‘matching’, helps you to be sure that the John Smith trying to use your service is the same John Smith you already have on file.

Because there’s no unique identifier for citizens, finding the record involves matching verified information about the user (such as name, address, and date of birth) to a record in a local datastore(s) with a local identifier. For example, if you run an NHS service, the local identifier may be an NHS number.

An identifier on its own is not a proxy for an identity. Identifiers are not usually private and it’s hard for government to control their privacy. On rare occasions, some identifiers may be shared by different people. Because of this, you should not use identifiers on their own to prove identity and should follow the matching advice offered in this guidance.

If your service does not handle matching properly, there’s a risk that a user won’t be able to access your service or that your service will think they’re someone else. This can put your service at risk of reputational damage and compliance issues.

To mitigate these risks, your service must:

This page was last reviewed on 12 April 2019. It needs to be reviewed again on 12 October 2019 by the page owner #verify-tech-notifications .
This page was set to be reviewed before 12 October 2019 by the page owner #verify-tech-notifications. This might mean the content is out of date.