Verifications & Checks

A verification check is a single step in a workflow — one unit of identity verification logic. Checks are executed by the workflow engine in the order defined by your workflow graph. Each check produces an independent pass/fail result.

Check lifecycle

pending → passed
        → failed
        → error
        → skipped
        → requires_retry

Each check attempt is stored as an immutable record with an incrementing attempt number. Retries create new records rather than overwriting the original.

Check categories

Extraction

Biometric verification

Document evaluation

Compliance screening

Fraud detection

Decisioning

Auto-injected checks

Some checks are automatically added to every workflow run regardless of your workflow configuration:

• watchlist_screening — Required for compliance. Always runs.
• risk_assessment — Required for fraud scoring. Always runs.
• identity_crossref — Runs for certain plan tiers to detect form/document mismatches.

You cannot remove auto-injected checks, but you can configure how their results affect the workflow outcome.

Check results in the session result

After a session completes, each check’s result is available in the check_results object:

1
{
2
  "check_results": {
3
    "document_ocr": {
4
      "status": "passed",
5
      "details": {
6
        "fields_extracted": 12,
7
        "mrz_valid": true,
8
        "barcode_valid": true
9
      }
10
    },
11
    "face_match": {
12
      "status": "passed",
13
      "score": 0.94,
14
      "liveness_passed": true
15
    },
16
    "age_verification": {
17
      "status": "passed",
18
      "extracted_age": 28,
19
      "minimum_age": 18
20
    },
21
    "watchlist_screening": {
22
      "status": "passed",
23
      "hits": 0
24
    },
25
    "risk_assessment": {
26
      "status": "passed",
27
      "risk_score": 12,
28
      "risk_level": "low",
29
      "triggered_signals": 2
30
    }
31
  }
32
}

Configuring checks in workflows

Each check can be configured with parameters specific to its type. For example:

1
{
2
  "type": "policy",
3
  "policy": "face_match",
4
  "config": {
5
    "security_level": "strict"
6
  },
7
  "on_pass": "next_step",
8
  "on_fail": "review_terminal"
9
}

See Workflows for how to build verification graphs with checks, conditionals, and routing logic.

Standalone checks via API

You can also run checks independently of a session through the checks API:

$
curl -X POST https://api.withverifa.com/api/v1/checks \
>
  -H "X-API-Key: vk_live_your_key_here" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "check_type": "sanction",
>
    "external_ref": "user_abc123",
>
    "name_first": "Jane",
>
    "name_last": "Doe",
>
    "birthdate": "1997-06-15"
>
  }'

This is useful for:

• Running AML screening on existing customers
• Adding phone or email risk checks after onboarding
• Re-screening identities on a schedule

See the API reference for the full list of check endpoints.

Related

• Workflows — Orchestrate checks into verification pipelines
• Screening & Reports — AML screening and continuous monitoring
• Fraud Signals — The 150+ signals behind risk assessment