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 for one or more of these reasons:

• A check needs a person: its result needs judgment, or the check could not produce a result.
• One of your rules sent it to review. A rule whose action is to decline also sends it to a person: a rule never declines a verification on its own.
• Rules you set to Influence the review decision moved it into review.
• A finding about the applicant’s details, device or internet connection needs a look.
• The platform ran into a processing error and parked the verification instead of completing it automatically.

Verifications in this state appear on the applicants list without any filtering on your part: the list opens on the Needs review filter, which is exactly this set minus the verifications the platform parked there after an error. The Awaiting review status filter shows the same set with those parked verifications included.

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.

Why the verification is in review

The review list at the top of the page says why the verification is waiting for you. Each flagged check and each finding has its own card. Three reasons have no card, so the list states each of them in a line of its own:

• One of your rules sent it. For example: Your rule “Out-of-state ID” sent this verification to review. The line names the rule your team wrote. When the rule’s name cannot be found, it reads: One of your rules sent this verification to review.
• Rules you set to influence the review decision sent it. The line reads: Rules you set to influence the review decision sent this verification to review. No number or threshold is shown.
• Nothing more specific is known. Only when nothing on the page is flagged, the line reads: This verification needs a reviewer’s decision.

When there is no card, the lines are followed by your next step. After a decision, the decision record states the same reasons in the past tense.

A verification the platform parked after a processing error shows a notice above the review list. The notice says what happened and what you can do next, the status badge reads Verification errored, and the page does not say that nothing needs your review.

The workspace reviewer that you embed in your own product shows the same lines and the same notice. It words the rule lines for the organization that runs the verification, for example: A rule set by the verifying organization sent this verification to review.

The API returns the same reasons as review.causes, with the same sentences as the console. See Review reasons.

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 matches.
• 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.

How the document arrived

Separately from the images, the identity checks for the run state a Document source: Camera capture when the applicant photographed the document during the verification, or Uploaded photo when they supplied an existing photo of it. It is stated once, on the identity checks, and the exported report carries the same row. A verification that recorded no source shows no row rather than a guess.

Read it as context, not as a verdict. An uploaded document runs the same validations as a photographed one and can pass automatically, so Uploaded photo is not a finding and does not by itself mean anything went wrong. What it tells you is that the image was not taken during the verification, which is worth weighing when you are already deciding a borderline case. Upload is offered only on workflow templates that turned it on; see Document upload.

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.