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).

If you're looking for API documentation:

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)

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
"result": "unidentified" 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

When 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": "unidentified" no matches are found
"result": "consider" otherwise

Number of addresses: As per JMLSG definitions, this check will only attempt to find a match using the applicant's current address.

Mortality: Only checked in the UK.

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 against total_number of sources under the total_sources sub-breakdown that is under the sources parent breakdown.
clear against the result value under the address 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": {}
        },

...