Identity Enhanced report
Start here
This is an introductory guide and overview for the Identity Enhanced report. This guide is primarily written for users of API v3, but the report is equivalent to "Identity KYC" in API v2 (read more in our migration guide).
You'll find API documentation separately.
Introduction
An Identity Enhanced report validates an applicant’s address, date of birth, name, and mortality (where applicable) by cross-referencing their details against a range of verified databases.
Identity Enhanced is the API v3 Identity report. It is typically used for "Know Your Customer" (KYC) purposes. For example, if you are providing a financial service.
For applicants in the United States, the Identity Enhanced report can optionally match the Social Security Number, either the full 9 digits or the last 4.
The result breakdowns indicate which of these elements was positively matched, and the underlying source or sources of that database match.
Identity Enhanced reports will be run in the country of the applicants address. Please make sure that the country is supported (see next section).
Supported countries for Identity Enhanced
You can review the full list of supported countries for Identity Enhanced reports in our API documentation.
Note that this is NOT a list of documents that Onfido supports: you can review that list separately.
Sources used for Identity Enhanced
Source name |
Definition |
Credit Agencies | Data comprised of consumer credit applications |
Voting Register | Data comprised of voter registration within a country |
Telephone Database | Data provided by both landline and mobile providers. In the UK, this is landline only |
Government | Any standard publicly accessible data collected by government entities. These include driving licence data, motor vehicle registration, court filings, property ownership registers, permanent place of residence registration and other similar data sets |
Business Registration | Data comprised of business registrations, corporate directors filings and business hierarchy data |
Consumer Database | Opt-in consumer data leveraging database marketing and other similar opt-in data sources |
Utility Registration | Data comprised of utility registrations such as electricity, gas, water accounts |
Postal Authorities | Data provided by postal authorities |
Commercial Database | These are corporate/private databases where users have opted-in and allowed for their information to be used for the purpose of verification of their identities |
Proprietary | This is when a data provider chooses not to divulge the source of the data to us for varied reasons, and also includes social media based data |
Register of Deaths | Negative source for known deaths (UK only) |
Fuzzy Matching
Onfido's third-party subprocessors utilize fuzzy matching on the name and address fields during identity record searches. This is because names and addresses can be provided in many different ways and errors in data submission or collection can be quite high. Fuzzy matching allows a more accurate confirmation of a person's identity during a record check by capturing data variations.
Examples of accepted data variations:
- A person named "Catherine Stanley" enters their name as "Catherine Stamley" or "Kate Stanley"
- An address is entered as "1/26 Rowland Close" or "Rowland Close, 26a"
Report logic
If the applicant address is in the UK:
-
"result": "clear"
the applicant is not found in mortality lists AND- at least one match on the applicant's name and current address, and a match on the applicant's name and date of birth (either in the same or different source) OR
- 2 matches on the applicant's name and current address from 2 different sources
-
"result": "consider"
either:- the applicant is found in mortality lists, or;
- only one match on the applicant's name and current address or name and date of birth, or;
- no matches are found
This follows the definition of 2+2 as per the JMLSG Guidelines 2014 Section 5.3.69.
If the applicant address is outside of the UK:
"result": "clear"
at least one source matches the applicant's name and current address"result": "consider"
the name and date of birth is matched, but no name and address matches are found"result": "unidentified"
no matches are found
If the applicant address is in the US and the SSN or the last 4 digits of the SSN are provided:
-
"result": "clear"
- at least one source matches the applicant's name and address, AND the last 4 digits of the SSN are matched
-
"result": "consider"
either:- no name and address matches are found, or;
- no SSN match
Notes:
- Mortality: Only checked in the UK.
- Number of addresses: As per JMLSG definitions, this check will only attempt to find a match using the applicant's current address.
Building your own logic
You can (optionally) build your own logic around report results.
For example, you may require matches to be found on 2 or more sources and at least 1 match on the applicant's name and current address.
In this example, you would add criteria of:
>=2
againsttotal_number of sources
under thetotal_sources
sub-breakdown that is under thesources
parent breakdown.clear
against theresult
value under theaddress
parent breakdown.
Here's a partial Identity Enhanced report result with some comments to help explain this:
HTTP/1.1 201 Created
Content-Type: application/json
...
"breakdown": {
"sources": {
"result": "clear",
"breakdown": {
"total_sources": {
"result": "clear",
"properties": {
"total_number_of_sources": "3" ## --< ADD ">=2" CRITERIA HERE>
}
},
}
},
"address": {
"result": "clear", ## --< ADD "clear" CRITERIA HERE>
"breakdown": {
"credit_agencies": {
"result": "clear",
"properties": {
"number_of_matches": "1"
}
},
"telephone_database": {
"result": "clear",
"properties": {}
},
"voting_register": {
"result": "clear",
"properties": {}
}
}
},
"date_of_birth": {
"result": "clear",
"breakdown": {
"credit_agencies": {
"result": "clear",
"properties": {}
},
...