Overview
Proof-of-address (POA) verification emits warnings onpoa_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_risksplus the multi-document name check. - Standalone API (
POST /v3/poa/) — warnings come fromcheck_poa_risksonly. There is no retry loop, no verified-ID context, and only one document, soNAME_MISMATCH_ID_VERIFICATION,POA_NAME_MISMATCH_BETWEEN_DOCUMENTS,POA_MAX_ATTEMPTS_EXCEEDED, andFUTURE_ISSUE_DATEare 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_DATEandPOA_NAME_NOT_DETECTEDare hard-coded to Decline on this endpoint.POA_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATIONandUNPARSABLE_OR_INVALID_ADDRESSare 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, andPOA_MAX_ATTEMPTS_EXCEEDEDare never produced — a future-dated document is not auto-declined on this endpoint.
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 (matchingVerificationSettings 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_documentplusadditional_names) is scored, and the best-scoring candidate is kept. - Match threshold — the default
poa_name_match_score_thresholdis 86; a score below it fires the relevantNAME_MISMATCH*warning.
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)
Related
- Proof of address report — full response shape, overlay-manipulation forensics, status semantics
- Proof of address overview — accepted document types
- Data models — Proof of address — canonical schema and Warning object
- Webhooks —
status.updatedcarries POA warnings