---
Source: https://docs.microblink.com/verify/check
Title: Checks
Description: How Verify checks documents for fraud
---

# 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](./response.md).

## `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](./cropped.md).

## `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.


Last updated on Jun 18, 2026