Identity matching in the BRP-Coupling Point

National Authority for Identity Data

The search algorithm used by the BRP Link Point to determine whether a person logging in with an eIDAS resource already appears in the Basic Registration of Persons (BRP).

Last change on 15th of October 2024, at 8:31 (CET) | Publication Standard 1.0

• Publication category: Other algorithms
• Impact assessment: DPIA
• Status: In use

General information

Theme

Organisation and business operations

Begin date

10-2018

Contact information

[e-mail]

Link to publication website

https://www.rvig.nl/logisch-ontwerp-brpk

Responsible use

Goal and impact

In digital government services within the Netherlands, the citizen service number (in combination with DigiD) is used to establish a reliable link between the person logging in and the person in the service provider's database.

In digital services within Europe, this works in a similar way, but slightly differently.

A citizen can log in to the digital services of the Dutch government with a notified eIDAS device. With that login, the Dutch government agency is provided with a set of identifying data to determine who that citizen is. With that set of identifying data, a "Uniqueness ID" is also provided by the country issuing the eIDAS resource. At the first contact, the service provider must determine, based on the identifying data received, whether the citizen already exists in the database or is a new customer. We call this process 'identity matching'. The service provider is supposed to store the Uniqueness ID for use in subsequent contacts.

Performing error-free identity matching is non-trivial. The identity data sent along by the other EU country may differ from the data registered in the Netherlands. For example, the different spellings of diacritics (Müller/Mueller) or double sounds (Tchaikovsky/Tchaikovsky/Chaikovsky). This can lead to different types of errors; the person is mistakenly not recognised as a new client registered when there was already a registration under a different name, or vice versa: the person is mistakenly linked to another person with a somewhat similar name.

In the Netherlands, the choice was made to perform this important and error-prone step in the service provision process centrally, so that not all individual government organisations have to do it themselves. This avoids duplication and errors. The facility designed for this purpose is called the BRP Interface Point. In the BRP-Point, Identity Matching is performed by a combination of a comparison algorithm, combined with manual assessment by experts. The comparison algorithm is based on the Intelligent Search in the BSN Management facility - Rijksdienst voor Identiteitsgegevens (overheid.nl).

Considerations

If an intelligent search algorithm were not deployed, the matching of persons would take place on the basis of a 1-to-1 comparison of the search data entered with the personal data in the database. However, experience shows that the personal data provided by the other EU country do not always match exactly with the data present in the Dutch basic register. For example, many organisations do not have the full first names of the person, but only the initials, or only the first name in full. It is also common that diacritical marks such as ã, â, ä or ligatures such as Ӕ are not registered or not registered correctly. Furthermore, there are many different spellings in circulation of (especially) foreign names. In a 1-to-1 comparison, these search queries would wrongly lead to the answer Not Found; we call this a false negative result. The person who logs in with his eIDAS credential and is already registered in the Basic Registration of Persons in the Netherlands with a BSN will then not be recognised. This will certainly lead to problems with the requested service. Introducing some form of intelligent search in this case increases the hit probability, thus reducing the false negative rate.

At the same time, such a search algorithm may increase the likelihood of false positives by finding persons who do not meet the intended search query. This may lead to linking a logged-in person to another person's BSN. This situation should be avoided as much as possible.

When weighing up the advantages against the disadvantages, we chose to add measures that exclude the occurrence of a false-positive result as much as possible. This creates a balance between preventing false negatives without simultaneously increasing the percentage of false positives too much.

Human intervention

Human intervention takes place the moment the matching process finds two or more possible hits in the BRP and the logged-in user has not entered (the last three digits of) the BSN. In such a case, the logged-in user receives a message on the screen that a manual search is started and that he or she should try again later. Specialised data managers then assess the results and determine whether a match can be made between the logged-in person and an existing registration in the BRP. If so, this link is made manually and the person can then proceed with the requested service.

Risk management

The matching process is monitored and a front office is available where eIDAS users can report with questions and any problems. In the unlikely event that a person is linked to someone else's registration, a system function is available that allows the data manager to manually break this link.

The underlying search algorithm is designed to be easily adapted and refined. The more persons log in with an eIDAS resource, the better the search algorithm can be tailored to all occurring situations.

Legal basis

The legal basis for the process is the eIDAS regulation. In the Netherlands, the eIDAS regulation is implemented by the EU Electronic Identities and Trust Services Implementation Act.

Links to legal bases

• Wet uitvoering EU-verordening elektronische identiteiten en vertrouwensdiensten: https://zoek.officielebekendmakingen.nl/stb-2017-13.pdf
• eIDAS-verordening: https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:32014R0910

Link to Processing Index

Volgt binnenkort

Impact assessment

Data Protection Impact Assessment (DPIA): PIA uitgevoerd op 4 mei 2018. Opvraagbaar bij RvIG

Operations

Data

The set of data used by the algorithm is determined by the data that may be exchanged within eIDAS for Identity Matching. These include:

• Uniqueness ID
• Citizen Service Number
• Given names
• Noble title/predicate
• Sex name prefix
• Sex name
• Sex name at birth
• Date of birth
• Place of birth
• Country of birth
• Sex designation
• Data indication in research person
• Date of start of research on person
• Date of death (not stored)
• House number
• House letter
• House number addition
• Postal code
• Country address abroad
• Abroad address
• Survey entry address
• Enquiry date address

Technical design

The process of logging in with a foreign eIDAS resource broadly follows the steps below:

• The Dutch eIDAS node receives a login request; this request contains a UniquenessID and the person's standard set of attributes: Name, Family name, Date of birth);
• Check whether the BSN is needed for the requested service:
• BSN not needed: then the Uniqueness ID is encrypted and a polymorphic pseudo-ID and the received attributes are provided to the service provider;
• BSN is required: start the Identity Matching process via the BRP Link Point to determine whether and if so which BSN belongs to the received attributes;
• At the user's first login, the UniquenessID is still unknown in the eIDAS node. Therefore, the UniquenessID and attributes are forwarded to the BRP Link Point. On subsequent logins, the match made between the UniquenessID and the (encrypted) BSN is reused. Identity matching then does not have to be done again;
• The BRP-Point queries the extended set of identifying data:
• If there is no answer, the Identity Matching process cannot be performed, and the requested service is refused. After all, the BSN is needed for the requested service in this case;
• If the requested data is provided, then a request follows for the user to voluntarily provide her BSN;
• If exactly 1 person is found in the BRP and the BSN matches the BSN provided, the match is recorded;
• If exactly 1 person is found and the user has not provided a BSN, the user is asked to confirm the last three digits of the BSN found. This question is asked to prevent a false-positive match;
• If the user does not confirm the BSN found, then no match follows;
• If the user confirms the BSN and the first names are not exactly the same, a manual check follows for extra assurance that it is actually the same person;
• Similarly, if more than one person is found and the user has not provided a BSN, a manual check follows.

The search engine uses the following rules when searching for possible matches:

1. The following translations are performed on both sides (the supplied and the registered BRP data):
2. Diacritical characters (à á â ã ä ā ă ė ä å ç ő ą ě) are removed;
3. Special characters (Æ æ Đ đ Ħ ħ ı ĸ Ŀ ŀ Ł ł Ŋ ŋ ʼn Ø Œ œ ß Þ þ Ŧ ŧ IJ ij) are converted according to ICAO rules for the machine-readable strip of the identity document;
4. Upper case letters shall be converted to lower case;
5. Any character other than a..z or 0..9 is replaced by <space>;
6. All <spaces> are removed;
7. Phonetic equivalents are converted to a code(longest first):
8. TE_1: v w
9. TE_2: a ae
10. TE_3: tsch sch tch ch zj zh sh ch sj jh kh x s
11. TE_4: schtsch sj ch chtch sc
12. TE_5: i j y
13. TE_6: oe ou yu ue o u
14. Multiple equal characters in succession are replaced by 1 character;
15. Remaining characters "h" are deleted.

External provider

National Authority for Identity Data