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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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. To understand the broader reviewer surface, see Manually review a verification. To track verification status from the API, see Track verification status.