A **watchlist** check screens an applicant's identity against a large set of public-record sources. When the watchlist check returns matches, each match becomes a **finding** the reviewer reads on the applicant detail page. Your job is to decide whether each hit is a real match against the applicant in front of you or a false positive.

## What a watchlist check looks for

The watchlist check covers several source categories. The platform maps each source onto a canonical authority and a finding type so the reviewer surface always renders the same vocabulary regardless of which list emitted the hit:

- **Sanctions**: OFAC SDN, OFAC consolidated, EU consolidated, UN consolidated, UK OFSI, Australia DFAT, Canada autonomous sanctions, Switzerland SECO, and other national programs. These map to `findingType: SANCTION`.
- **Politically exposed persons (PEP)**: PEP lists map to `findingType: PEP`.
- **Adverse media**: public reporting that adversely references the applicant. Maps to `findingType: ADVERSE_MEDIA`. Mugshot sources are bucketed here as well; the reviewer reads the rendered evidence rather than treating presence alone as adverse.
- **Enforcement and debarment**: BIS denied-persons, HHS LEIE, SAM debarred, World Bank ineligible, and similar programs. Maps to `findingType: ENFORCEMENT`.
- **Watchlist (law enforcement)**: FBI Wanted, US Marshals, Interpol Red, EU Most Wanted, NCA, and similar. Maps to `findingType: WATCHLIST`.
- **Regulator alerts**: for example UK FCA. Maps to `findingType: REGULATOR_ALERT`.
- **Sex-offender registries**: `findingType: SEX_OFFENDER`.
- **Missing-person registries**: `findingType: MISSING_PERSON`. This is presence data and is rendered with neutral language; selecting it as a decline reason is unusual and the decline modal warns when you do.

A source the platform has not seen before falls through to `CUSTOM_LIST` so the hit still produces a reviewer-visible finding rather than being silently dropped.

## Anatomy of a hit

Each finding in the findings panel carries:

- The **matched authority** (for example `OFAC_SDN`, `PEP_LIST`, `INTERPOL_RED`) and the **finding type** derived from it.
- The **matched person record** from the source: names, aliases, dates of birth, and addresses where the source provides them.
- The **match confidence** the check returned.
- A **source attribution** so you can trace the hit back to the originating list.

The watchlist check applies a `manual_review` cap so a typical verification carries a small handful of findings rather than hundreds. The reviewer-decision surface caps how many findings are returned to the panel initially and pages the rest in on demand.

## Clear a false positive

A false positive is usually a name-only collision (same name, different person). Use the structured fields on the matched record to decide:

- Compare date-of-birth against the applicant's submitted DOB (when your workflow template captures it via `collect_user_info`).
- Compare the matched record's listed countries and addresses against the applicant's address.
- Read the rendered evidence (descriptions, source links) for any context that obviously rules the applicant in or out.

If the evidence rules the applicant out, do not cite the finding when you record the decision. **Approve** the verification through the decision panel; the finding remains attached to the verification for audit, but it does not drive the verdict.

## Confirm a true positive

If the matched record really is your applicant (corroborated by DOB, address, or unambiguous biographical detail), open the decline modal in the decision panel. Cite the finding by selecting it in the findings rollup inside the modal. You must cite at least one finding or one triggered rule before the modal accepts the submission; a notes-only decline is not allowed.

Record any additional context in the notes field. The notes are persisted on the reviewer-decision row and surface in the audit-log entry.

## Escalate

The platform does not have a built-in escalation queue. If a hit needs a second reviewer or a compliance officer's sign-off, leave the verification in `awaiting_review` and route it through your team's own process: Slack, email, an internal ticket. The verification stays in that state until a reviewer presses Approve or Decline.

When you come back to the verification, the surface picks up where you left it: the findings panel is unchanged, the decision panel is unchanged, and the audit-log carries no premature decision row.

## Record the decision

Approving and declining both emit audit-log rows through the HMAC-chained writer. A decline event is `kyc.session.reviewer_declined`; an approve event is `kyc.session.reviewer_approved`. A later override emits `kyc.session.reviewer_decision_changed` as a separate row: the original decision is preserved.

For terminology, see the [Glossary](/glossary). To understand the broader reviewer surface, see [Manually review a verification](/guides/verification/reviewer-manual-review). To track verification status from the API, see [Track verification status](/guides/verification/track-status).