Virtually all identity verification (IDV) flows begin by asking the user a single question: “What’s your name?”
Simple enough, right?
But the reality is that names can be deceptively complex. They can be shortened. They can be misspelled in a plethora of different ways. They can be swapped out for nicknames and aliases with little-to-no connection to the person’s original, legal name.
When you’re setting the internal logic that guides your identity verification processes, all of this complexity needs to be taken into account.
That’s where the concept of match requirements comes into play.
Below, we define match requirements and explore how the concept should ultimately be factored into your IDV processes.
What are match requirements?
Match requirements is a term we use to refer to the internal logic that you set for determining whether or not a variation of a piece of data (such as aliases, nicknames, alternative spellings, or misspellings) will trigger a “match” when found in a report or other type of verification.
The more precise your match requirements are, the less likely these variations will trigger a match. Meanwhile, the less precise your match requirements, the more likely that variations may be flagged as a potential match.
In other words, your match requirements determine how wide you are casting your net as you search for potential matches.
The less strict your match requirements, the more likely you are to catch legitimate mentions of your user in a report they are scanned against, even if their name is misspelled or otherwise altered. Unfortunately, it also increases the likelihood that you will have to deal with false positives. More strict match requirements, meanwhile, will lead to fewer false positives, but increases the likelihood that you may miss a legitimate mention of your user.
In the end, it’s a spectrum, and most businesses will find themselves somewhere toward the middle. As names are run through the verification process and you begin to see the outcomes, you can adjust your match requirements to find the setting that is ideal for you.
Does matching only apply to names?
No. Any time you are collecting information from a user and then comparing that information against databases, reports, or through other means of verification, you are looking for a match.
For example, other pieces of information that are commonly run for potential matches include an individual’s date of birth and country. In fact, these are often paired with an individual’s name to reduce the risk of false positives.
That being said, most of the discussion around matching does tend to revolve around names, which is why the majority of this article focuses on names.
Types of match variations
Variations of a user’s name can come in a variety of different forms. Below, we’ve compiled a short description (with examples) of the most common types of match variations that you should be aware of as you consider the logic that guides your verification processes.
Aliases (AKAs)
An alias is simply another name that an individual goes by in addition to their real name. They can also be called AKAs (also known as) or nicknames. They are very commonly used by celebrities, where they are sometimes called stage names.
While similar to hypocorisms in some ways, they’re different in that a hypocorism is usually a diminutive version of a name while aliases can be very different from the user’s real name.
Example:
- Original name: Taylor Swift
- Alias #1: Tay-Tay
- Alias #2: T-Swizzle
Abbreviation
Many common names have the potential to be shortened or abbreviated, and it’s up to you to decide if you want abbreviations flagged when you run a report.
Example:
- Original name: Jonathan Peterson
- Abbreviation: Jon Peterson
Match abbreviations are similar to match hypocorisms (below), but different in a key way. An abbreviation simply shortens an individual’s name. It does not add or change the letters found in a name. A hypocorism, on the other hand, does change the letters in an individual’s name.
Hypocorism
A hypocorism is a fancy way of referring to pet names that are commonly used in place of an individual’s name. Often, hypocorisms are diminutive forms of a person’s name. But they can also be seemingly unrelated to the original name. While often shorter than an individual’s full name, hypocorisms are different from abbreviations (discussed above).
Example:
- Original name: Robert Peterson
- Hypocorism #1: Bob Peterson
- Hypocorism #2: Bobby Peterson
Transliteration
If an individual’s name is comprised of non-Latin characters, you’ll need to decide whether or not you wish to transliterate their name and include the transliterated version alongside the original in any reports you run. Transliteration is the process of replacing non-Latin characters with their Latin equivalents; for example, substituting Latin characters for a name originally written in Cyrillic.
Example:
- Original name: 朱辰
- Transliteration: Zhu Chen
Please note that transliteration is an extremely complicated process, and its performance can vary drastically depending on the language. If you choose to perform transliteration when setting your match requirements, it is important to ensure the proper configuration of the tool you are using.
Fuzziness (Edits)
In the world of match requirements, fuzziness is simply a measure that describes how many edits (or typos) are allowed in a term before it triggers a match. With this in mind, we’ve broken out four specific types of match variations that are related to typos below.
Addition
An addition (also called an insertion) is a specific type of variation in which an extra letter is mistakenly added to a name. Most often, this is a letter that is already in the individual’s name and which is simply duplicated in error, but it can also be the addition of a new, unrelated letter as well.
Example:
- Original name: Thomas Henry Jefferson
- Insertion #1: Thoomas Henry Jefferson
- Insertion #2: Thomas Henryy Jefferson
Subtraction
A subtraction, on the other hand, refers to the opposite phenomena. Instead of a letter being added to an individual’s name, a letter is subtracted from the name altogether.
Example:
- Original name: Thomas Henry Jefferson
- Subtraction #1: Tomas Henry Jefferson
- Subtraction #2: Thomas Henry Jeferson
Substitution
In a substitution, a letter in an individual’s name is replaced (or substituted) for another letter. But the total length of the name stays the same — there has been no insertion or subtraction.
Example:
- Original name: Thomas Henry Jefferson
- Substitution #1: Thomis Henry Jefferson
- Substitution #2: Thomas Henri Jefferson
Transposition
In a transposition, the letters within an individual’s name are transposed. This means that the name contains all of the letters that it is supposed to contain, but the order of two of those letters have been mistakenly swapped.
Example:
- Original name: Thomas Henry Jefferson
- Transposition #1: Tohmas Henry Jefferson
- Transposition #2: Thomas Herny Jefferson
An example in action
As just one example, let’s imagine that you have a new customer interested in opening an account. They provide the name “Thomas Jimenez” as a part of the account creation process, and as is your standard process, you run reports against the following datasets:
- Watchlist and sanctions
- Adverse media
- Politically exposed persons (PEP)
The name “Thomas Jimenez” does not trigger any flags during this process. But because you have set your match requirements to account for subtractions, the name “Tomas Jimenez” does come up in an adverse media report that mentions financial crimes in Colombia.
This match automatically triggers the need for enhanced due diligence and manual review of the case. In the end, it is determined that this individual is not the same person mentioned in the adverse media report, and they are allowed to open their account.
It’s a balancing act
Looking at the example above, there are two arguments that can be made.
The first is that the presence of fuzzy match requirements did more harm than good. The new user was deemed not to be the same person that was mentioned in the adverse media report, and yet they were initially flagged as a potential risk. In a worst-case scenario, this may have led to that person being denied service them abandoning the sign-up of their own accord — perhaps because it was taking too long.
The second is that the presence of fuzzy match requirements did exactly what they were designed to do. Because the match requirements accounted for match subtractions, a name that nearly matched the new customer’s name was flagged in an adverse media report, alerting your business to the potential for risk and triggering enhanced due diligence. While this led to the introduction of more friction into your IDV processes, it also ultimately made those processes more secure and reduced the amount of risk that your company would have unknowingly been exposed to.
The reality is that neither of these arguments are wrong. At the end of the day, determining the match requirements for your business will require you to balance friction against security. Ultimately, only you are capable of making the decision as to what is best for your business.
Controlling for false positives
As mentioned above, relying solely on an individual’s name (and variations of their name) during matching can trigger a lot of false positives — especially for names that are very common. With this in mind, businesses should consider different ways that they might be able to control for these false positives.
A highly effective means of doing this is to bring other pieces of identifying information into your match process. These additional bits of information, paired with an individual’s name, can bring your number of false positives down to a much more manageable level.
Some examples of the type of information you might bring into the match include the person’s date of birth (or birth year) or their country of residence.
Match requirements made easy
Here at Persona, we understand how important it is to balance security and flexibility when crafting your IDV processes. That’s why all of our solutions — from our Verifications to Reports to our Cases and everything in between — give you complete control.
Identify which reports your users should be scanned against; establish the ideal monitoring schedule for your business; determine which additional information (such as an individual’s date of birth or country of residence) to run alongside their name in order to reduce false positives; and set the match requirements that best allow you to balance risk and security.
Not sure which match requirements are ideal for your business or industry? You don’t have to go at it alone. A member of our support team is always available to chat through your workflow to ensure that you are choosing the best possible settings for your use cases.
Interested in learning more? Start for free or get a demo today.
.png)
.png)
