Skip to main content

Overview

Proof-of-address (POA) verification emits warnings on poa_verifications[].warnings[] for every quality, authenticity, or matching issue detected during extraction and forensic analysis. Each warning is a Warning object with feature set to "PROOF_OF_ADDRESS". A handful of risks always force Declined; the rest follow a per-risk action (DECLINE / REVIEW / NO_ACTION) configured on your workflow. Every risk below is verified against the live decision pipeline; the exact short and long description strings are reproduced verbatim in the tables.
POA extraction introduces a 5–15 second latency per document. Warnings are written only when the workflow step completes; do not poll faster than every 5 s.

Two production paths

POA warnings are produced on two different paths, and the risk set differs between them:
  • Workflow sessions (the POA step inside a verification session) — the upload endpoint first runs blocking validation with a retry loop (see Retry behavior), then the final stored warnings are computed by check_poa_risks plus the multi-document name check.
  • Standalone API (POST /v3/poa/) — warnings come from check_poa_risks only. There is no retry loop, no verified-ID context, and only one document, so NAME_MISMATCH_ID_VERIFICATION, POA_NAME_MISMATCH_BETWEEN_DOCUMENTS, POA_MAX_ATTEMPTS_EXCEEDED, and FUTURE_ISSUE_DATE are never produced by the standalone API. The pre-extraction validation errors are discarded on this path.
POOR_DOCUMENT_QUALITY is defined in the risk enum and reserved in the action mapping, but no code path in the POA pipeline produces it — it never appears in warnings[] on either path. Do not branch on it.

Auto-decline warnings (always force Declined)

These risks are in AUTO_DECLINE_RISKS; when logged, the POA status is Declined regardless of configuration, and log_type is always error. FUTURE_ISSUE_DATE is also listed in AUTO_DECLINE_RISKS, but it has a single producer in pre-extraction validation (an issue date more than 7 days in the future) whose errors only feed the workflow retry loop — it surfaces as a blocking upload error there, is never produced by the standalone API, and is not written to warnings[]. See Retry behavior.

Configurable warnings

Each of these follows an action knob on the workflow’s POA node (DECLINE / REVIEW / NO_ACTION). The warning’s log_type mirrors the configured action: error for Decline, warning for Review, information for No action.
There is one shared action for all name and address mismatches: poa_name_or_address_mismatch_action covers both name risks, both address risks, and the cross-document name check — you cannot configure name and address mismatch behavior separately. On the standalone API the same group follows the poa_address_mismatch_action request option (the poa_name_mismatch_action option is accepted but never read).

Standalone API differences (POST /v3/poa/)

The standalone endpoint builds the same risk-to-action mapping but with request-level options that only accept DECLINE or NO_ACTION (all defaulting to DECLINE):
  • UNABLE_TO_EXTRACT_ISSUE_DATE and POA_NAME_NOT_DETECTED are hard-coded to Decline on this endpoint.
  • POA_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION and UNPARSABLE_OR_INVALID_ADDRESS are informational here — their actions default to No action and are not configurable per request.
  • FUTURE_ISSUE_DATE, POOR_DOCUMENT_QUALITY, NAME_MISMATCH_ID_VERIFICATION, POA_NAME_MISMATCH_BETWEEN_DOCUMENTS, and POA_MAX_ATTEMPTS_EXCEEDED are never produced — a future-dated document is not auto-declined on this endpoint.
See the POST /v3/poa/ API reference for the request options.

Retry behavior (workflow sessions)

In a verification session, the POA upload step runs blocking validation before the document is accepted. When it finds a blocking error — INVALID_DOCUMENT_TYPE, UNABLE_TO_EXTRACT_ISSUE_DATE, FUTURE_ISSUE_DATE, POA_NAME_NOT_DETECTED, MISSING_ADDRESS_INFORMATION, POA_COUNTRY_MISMATCH_WITH_PROVIDED, POA_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION, UNSUPPORTED_DOCUMENT_LANGUAGE, or POA_DOCUMENT_EXPIRED — the upload is rejected with 400 and the risk code as the message, and the user can try again with a better document. For POA_DOCUMENT_EXPIRED, the 400 body also includes expiration_reason (printed_expiration or age_window) so your UI can show the accurate reason; on the age_window path it additionally includes max_age_months. On the printed_expiration path max_age_months is intentionally omitted, because the document was rejected for its printed expiration date rather than an age window. Once the user has burned poa_max_retry_attempts attempts (default 2, configurable 2–5), the submission is accepted anyway: the stored warnings are recomputed from the saved document, POA_MAX_ATTEMPTS_EXCEEDED is appended, and the status is resolved from the full risk set. This is why FUTURE_ISSUE_DATE can block an upload yet never appears in warnings[].

Configurable settings

The workflow’s POA node exposes these knobs (matching VerificationSettings fields):

Name matching logic

POA name matching tolerates common variations:
  • Middle names and initials are matched leniently (presence/absence is allowed).
  • Candidate names — every name detected on the document (name_on_document plus additional_names) is scored, and the best-scoring candidate is kept.
  • Match threshold — the default poa_name_match_score_threshold is 86; a score below it fires the relevant NAME_MISMATCH* warning.
The numeric scores are exposed on the report as name_match_score_expected_details and name_match_score_id_verification (0–100). Score values are useful for fine-grained review even when no warning has been raised.

Examples

Overlay manipulation (Decline by default)

Expired document + missing address (auto-decline)

Name mismatch (Review by default)

Warning types