---
Source: https://docs.microblink.com/platform/capabilities/scan-verify-id
Title: Scan & Verify ID
Description: Scan and verify authenticity of government-issued identity documents with fraud detection
---

# Scan & Verify ID

:::tip[Availability]
Available in SDK v1.0+
:::

The Scan & Verify ID capability uses [BlinkID Verify](/verify/) to extract data from a government-issued identity document and verify the document for authenticity and physical presence.
It's a superset of [Scan ID](scan-id.md): in addition to extracting the same data fields, it also runs a suite of fraud detection checks.

For an overview of those checks and what they detect, see [Checks](/verify/core-concepts/check) in the Verify documentation.

## Checks performed

Verify runs several categories of checks in parallel:

- **Visual checks**: detect security feature anomalies, photo forgery, and AI-generated documents
- **Data checks**: detect inconsistencies in the document data, barcode anomalies, MRZ errors, and suspicious or mismatched data fields
- **Document liveness checks**: detect whether the document is physically present (specifically, whether it has been presented on a screen or as a photocopy)
- **Document validity checks**: determine whether the document is expired or whether the document type is still accepted in its jurisdiction
- **Image quality checks**: assess whether the captured images are of sufficient quality for a reliable fraud verdict

The outcome of all these checks is combined into a single `RecommendedOutcome`.
For a full explanation of what each outcome means, see [RecommendedOutcome](/verify/core-concepts/recommended-outcome).

## Configuration

### Verification policy

The main configuration option is the **verification policy**, which controls the overall strictness of fraud detection.
The available policies are:

- **Permissive**: lowest strictness; highest pass rate but also the highest risk of fraud slipping through (low FRR, high FAR)
- **Standard**: the default; a balanced trade-off suitable for most use cases
- **Strict**: fewer missed fraud cases, but more legitimate users will be rejected (higher FRR, lower FAR)
- **Very strict**: maximum sensitivity; appropriate when downstream checks can compensate for false rejections

When selecting a policy, the trade-off is between pass rate and fraud prevention.
The more permissive the policy, the more users will complete verification, but at greater risk of missed detections.
Conversely, stricter policies catch more fraud, at the cost of occasionally rejecting legitimate users.
Tune this to your risk appetite; if you have additional checks later in the workflow, you may be able to use a more permissive policy here.

For a more detailed treatment of these trade-offs, see [Evaluation](/verify/evaluation).

### Verification context

If your workflow occurs in the presence of a human reviewer (for example, account creation assisted by a staff member), select **In person**.
This disables checks that are only meaningful in remote contexts, such as photocopy detection, which a human reviewer would catch directly.

## Match levels

For fine-grained control beyond the overall policy, you can adjust the **match level** for each individual check.
Match levels range from 1 (least strict) to 10 (most strict), and can also be disabled to skip a check entirely.

For example, if photocopy fraud is a particular concern for your use case, you can set the photocopy match level higher than what the selected policy would set by default.

Adjusting any individual match level means the overall policy no longer applies uniformly; only the checks you haven't customized will follow the policy's defaults.

For more detail, see [MatchLevel](/verify/core-concepts/match-level).

## Rules

The result of the document verification can impact the overall status of the step, or it can be treated as informative without affecting the status.

In addition to this, you can configure two common rules: **age verification** and **document expiry**.
These two rules aren't affected by the step status setting described above.
This means that even if you configure the step not to be affected by Verify's recommended outcome, the step will still fail if the configured age or validity conditions are met.

## Special case: Image upload

Instead of activating the camera to scan an identity document, Verify supports uploaded images of ID documents.
The only requirement is to link the uploaded image correctly, and to ensure that Verify comes *after* the user input step.
For more info, see the [image upload functionality](user-input.md#img-upload).