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](/guides/verification/track-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](/guides/verification/reviewer-watchlist).
- **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)](/guides/verification/reviewer-background-checks-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](/glossary). If a verification was declined and you need to understand why, walk the [verification-declined FAQ](/guides/faq/verification-declined).