Manually review a verification

When the platform cannot make a clean automated call on a verification, the verification lands in manual review. A human reviewer reads the evidence and records a verdict. The reviewer surface lives on the applicant detail page in the console.

When a verification lands in review

A verification moves to awaiting_review when one or more of its checks produced findings the rules engine decided to escalate, or when the check returned manual_review directly. Verifications in this state appear on the applicants list under the Awaiting review filter.

Track the verification-status taxonomy in Track verification status.

Open the reviewer surface

Open Dashboard → Applicants, then open the applicant you want to review. The page surfaces three reviewer panels side by side:

• The applicant header with the status pill and the current decision card (when one has been recorded).
• The findings panel, listing every finding produced by any check on the verification, with paging and per-finding evidence.
• The decision panel, which renders one of three states based on the current status: Approve / Decline buttons for awaiting_review, Change-decision for an already-decided verification, and a read-only summary for auto-approvals with no reviewer row.

The decision panel only mounts when your role can review verifications. Without it, you can still read the verification but cannot act on it.

Read the evidence

Open each finding in the findings panel and review the evidence it carries. The evidence shape depends on the finding type:

• Watchlist findings show the matched authority (OFAC, EU, UN, PEP, FCA, and so on), the match confidence, and the canonical person record from the matched source. The reviewer-watchlist guide goes deeper; see Watchlist hits.
• Court records and adverse-media findings carry the structured case data with a date, a jurisdiction, and a description. Records that are not FCRA-reportable under the federal rule are dimmed; see Background-check decisions (FCRA) for what that means.

Use the dimmed state as a hint, not a rule. State-specific lookback caps can render additional records non-reportable even when the panel does not dim them.

Identity-document evidence

When a verification ran the id_verification check, the applicant detail page shows an identity-document evidence panel with the images the applicant captured: the document front, the document back (for a two-sided document), and the biometric image (the selfie, or the reference frame captured by an active-liveness scan). A tile only appears when that image exists for the run: there is no back tile for a single-sided passport, and no biometric tile when the workflow template’s biometric mode is none. Click a tile to enlarge it.

These images are special-category personal data, so the platform protects them tightly:

• Authorized and audited. Each image is fetched only for an authorized reviewer of the verification’s own organization, and every view emits an audit event (kyc.idv.evidence_viewed) recording who looked at which image. There is no shareable link: the image is streamed through the console for the duration of your view and is not exposed as a URL you can copy or forward.
• Region-scoped. An organization’s images are read only from its own region’s storage; the evidence panel never reaches across regions.
• “Image removed” state. If an image has been deleted under the platform’s retention schedule or an erasure request, the tile shows an Image removed (retention/erasure) caption instead of a broken image, so the absence is explained rather than looking like an error.

Make a decision

Click Approve or Decline in the decision panel.

• Approve records the verification as completed with outcome: approved. The panel optimistically updates in place and a toast confirms the action.
• Decline opens the decline modal. You must cite at least one finding or at least one rule that was triggered with action decline or review. A notes-only decline is forbidden. Pick a reason code from the dropdown. When the verification carries a background-check, an expandable Compliance reminders for background-check declines panel appears above the buttons; opening it is left to you.

Both paths emit kyc.session.reviewer_approved or kyc.session.reviewer_declined audit events. Changing an existing decision emits kyc.session.reviewer_decision_changed.

Request more information

There is no dedicated “request more info” verdict. If you need more evidence before you can call the verification, leave it in awaiting_review, contact the applicant through your own channel, and come back to the surface once you have what you need. The decision panel only commits when you press a button. The verification stays open as long as you need it.

Audit trail

Every reviewer action emits an audit-log row through the writer that is HMAC-chained per (org_id, namespace) series. The row carries the decision, the cited reasons, the reviewer identity, and the timestamp. A subsequent change is a separate row tagged reviewer_decision_changed: the original decision is never overwritten, so the chain shows the full history.

For terminology, see the Glossary. If a verification was declined and you need to understand why, walk the verification-declined FAQ.