Skip to main content
Version: v2

Checks

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

Verify has numerous checks, and they abstractly represent the 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.

The checks are returned as a checks array in the response.

VisualCheck​

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

At a lower level, it includes the following checks:

  • SecurityFeatures
  • PhotoForgeryCheck
  • GenerativeAiCheck (cloud-only)

DataCheck​

This is the high-level check representing all data checks. This includes things like "are the dates in logical order?", and more complex things comprised of hundreds of internal checks like the 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. At its core, the 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 optional and not suited to every user flow. It does not impact the overall liveness verdict.

DocumentValidityCheck​

This checks whether the document 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 expiration

ImageQualityCheck​

This is a high-level check that's the final output of heuristics and ML models whose purpose is to assess whether the captured images are suitable for verification purposes. This information is conveyed through the processIndicators field of the response.

At a lower level, it includes the following checks:

  • ClarityCheck: checks the clarity of the image
  • BlurCheck: checks whether the image is blurry enough to be (un)verifiable
  • CropCheck: it's not possible to perform all checks without full context, so this rejects images where the document is too close to the edges. See also how to accept cropped images.

OverallFraudCheck​

OverallFraudCheck takes into account the previous checks and determines 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, for example the document is not supported, or the image quality is too poor to be verified. Moreover, the cause may not be immediately obvious without inspecting the detailed results. The RecommendedOutcome field in the API response is an abstraction over the OverallFraudCheck and everything that feeds into it.