Check

A check is one verification unit with semantic meaning. For example, a check might tell you "the document is a photocopy", but also things like "the photo is blurry".

Verify has a lot of checks, which abstractly represent all the complex underlying fraud detection logic and our AI models. These checks have a slightly recursive structure, and they get grouped into higher-level checks.

For example, screen and photocopy checks are a type of document liveness check, and the result from each of them, and both of them together, tells us whether the document is physically present.

In the response, the outputs of these checks are represented as Result objects of a few different types depending on the behavior of the check and its natural API. These different types provide additional information and metadata, but at their core they can all be either Pass, Fail, or NotPerformed.

Same core results with additional metadata when applicable

 

MatchLeveDataCheck

Pass

Fail

NotPerformed

TieredCheck

CertaintyLevel

Pass

Fail

NotPerformed

DetailedCheck

Current checks

In the following section, we'll be taking a look at the checks we currently perform in Verify. Since some of the checks' names change between the v1 and v2 API, we'll be using abstract terminology and structure which may not exactly map to either API version.

The purpose of this section is to provide a high level overview of the checks we perform, and to help you understand what your results mean. For handling the actual API responses programmatically, consult the API references:

• v1 API reference
• v2 API reference

VisualCheck

This is the high level check representing all visual (fraud) checks we do. It doesn't include visual issues that aren't directly related to fraud like glare, blur, etc. Those fall under the ImageQualityCheck.

At a lower level, it includes the following checks:

• SecurityFeatures
• PhotoForgeryCheck

DataCheck

This is the high level check representing all data checks we do. This includes more straightforward things like "are the dates in logical order?", and very complex things comprised of hundreds of internal checks like our BarcodeAnomalyCheck available for AAMVA documents.

At a slightly lower level, it includes the following checks (and then even more lower level checks for most of these):

• MatchCheck
• DataMatchCheck
• BarcodeAnomalyCheck
• SuspiciousDataCheck
• DataIntegrityCheck
• MrzCheck

DocumentLivenessCheck

This is the high level check representing the document liveness checks we do. At it's core, our passive liveness approach comes down to three things, powered by various AI models:

• ScreenCheck - whether the document is presented on a screen
• PhotocopyCheck - whether the document is a photocopy, be it a cutout or a full page copy (color or grayscale)
• HandPresenceCheck - whether the document is physically held in hand

The HandPresenceCheck is something we've come to realize not everyone wants, and not every UX is suited for it. That's why it doesn't impact the overall liveness verdict, and why we've changed it to a processIndicator in the current v2 API.

DocumentValidityCheck

This is one of the more basic checks that essentially checks whether the documents is usable for identification purposes (regardless of whether it's genuine or not).

It's comprised of two checks:

• ExpiredCheck - whether this particular document is expired (controlled by the treatExpirationAsFraud setting - true by default)
• VersionCheck - whether this type of document is acceptable in its jurisdiction today, regardless of whether the particular document expired or not

ImageQualityCheck

This is a high level check that's the final output of a very large suite of heuristics and ML models whose purpose is to assess whether the captured images are suitable for verification purposes. In the v2 API, this information is conveyed through the processIndicators field.

At a slightly lower level, it includes the following checks:

• ClarityCheck - a combination of a lot of heuristics and ML models that assesses the clarity of the image
• BlurCheck - checks whether the image is blurry enough to be unverifiable
• CropCheck - it's not possible to perform all of our checks without full context, so this check's job is to reject images where the document is too close to the edges

OverallFraudCheck

It's not enough to just run a bunch of checks on the document images. Not all checks are equally reliable, most are sliding scales, there are dependencies and additional factors like image quality issues.

The OverallFraudCheck's job is take all of these inputs and figure out whether the document is genuine or not. This can sometimes not be possible, and in those cases the OverallFraudCheck will be NotPerformed.

This can happen for a variety of reasons (e.g. the document is not supported, or the image quality is too poor to be verified) and the cause may not be immediately obvious without poring over the detailed results. That's why we've introduced the RecommendedOutcome field in the v2 API, which is an abstraction over the OverallFraudCheck's and everything that goes into it.

Final notes on checks

It's important to understand that a Check is an API concept. It's meant to be a grouping of other checks, and even deeper of layers of logic, models, and expert systems. That means that for most API Checks, we do hundreds of underlying checks on the document data, the image, and the metadata.