Overview
What is the Inquiry Comparison check?
Persona’s Inquiry Comparison check is used to verify that attributes extracted from the Government ID match what what you already know about the user.
How this check can be used
- If you know the user’s name is “John Smith” and the birthdate is “January 1, 1990”, you can prefill that information when creating the inquiry. The Inquiry Comparison check can then be configured to ensure that the name and birthdate extracted from the Government ID are “John Smith” and “January 1, 1990” respectively.
- If you’re having the user submit two forms of ID, you can utilize the Inquiry Comparison check on the second ID submission to ensure its attributes match the first.
An example of a a Government ID Verification’s Inquiry Comparison Check configuration. The configuration includes Match Requirements for three attributes: First name, Last name, and Birthdate with distinct conditions for what is considered a match for each attribute.
Requiring the check
Requiring the Inquiry Comparison check means that any submission that does not meet the match requirements will fail the verification attempt. If the check is not required, the verification will pass even if the check itself fails.
Configuring Match Requirements
When comparing attributes within Persona, we define them as:
Claimed attributes
are values you already know about the userExtracted attributes
are the values you will be extracting off a Government ID
The Inquiry Comparison check allows you to set Match Requirements for how the Claimed attributes
and Extracted attributes
are compared and at what level of fuzziness is considered a match. One condition
is used for each attribute you want to compare. And for a specific Verification attempt, all conditions must be met for the Inquiry Comparison check to pass.
In the example above, you can see that there are three check conditions: on First name, Last name, and Birthdate.
Conditions per attribute
Each per-attribute condition (within a Match Requirement configuration) can have two components:
- Normalization methods - standardizes the claimed and extracted attributes before they are used in comparison methods
- Comparison methods - determines what level and how claimed and extracted attributes are compared to be considered a match or not a match
In the example, the First name attribute is selected to further configure. If this configuration were used, when comparing first name values there would be a few Normalization Methods applied to the Claimed and Extracted first name values. And then there a set of possible Comparison Methods that would constitute a match.
Normalization Methods
A normalization method standardizes both the extracted and claimed values before the comparison is performed. Normalization methods are useful to ensure a consistent format between values so that accurate comparisons can be made.
Some examples of the most common normalization methods for First names and Last names:
Method | Function |
---|---|
remove_prefixes | Removes name prefixes like "Dr.", "Mr.", and "Ms." |
remove_suffixes | Removes name suffixes like "Jr.", "Sr.", or "III". |
remove_special_characters | Removes characters that may have been accidentally typed into the name (punctuation, quotes, and symbols) |
fold_characters | Strips any accents off characters for comparison— i.e "àéïøû" would be normalized into "aeiou". |
Comparison Methods
Comparison methods are used to specify what level of matching you’ll accept between two values to consider the verification check passed.
- For example, you might allow more tolerance on first names (because users often use shortened names or nicknames) and need stricter matching on last names.
These are all the comparison methods available:
Note: Adjusting or changing the Match Level
dropdown offers an alternative way to easily apply a comparison method.
Method | Function |
---|---|
string_similarity | Applies word matching algorithms to determine the similarity between two strings. |
string_difference | Measures the edit distance between two strings. e.g. "Tony" and "Tiny" have an edit distance of 1. By default a partial match is 1 character. |
nickname | Checks if one string is a nickname of the other string e.g. “Jim” is a nickname for “James”. Note that we don't recommend using Nickname matching if you're running reports on the user, as reports will generally use the full name |
substring | Passes as partial match if one string is a substring of the other string, for example "John" is a substring of "Johnny". The minimum length for either name is 3 characters. |
tokenization | Splits strings with whitespaces or hyphens into tokens and considers a partial match of at least one token match. For example, if a value is "Mary-Anne" and the threshold is set to 1 for tokenization then "Mary", "Anne", or "Mary Anne" would be considered a match. |
date_similarity | Specifies how many attributes in a Date field (year, month, day) need to match. |
date_difference_{x} | Specifies how much tolerance any specific Date field (year, month, day) can have. |
Where else will I see normalization and comparison methods?
All of Persona’s “Comparison” checks leverage the same match requirements, normalization, and comparison infrastructure. The Inquiry Comparison check is also available within Persona’s Database verification.