Watchlist-screening results

Returns PEP (Politically Exposed Person) and Sanctions screening results for a verification session

When to use this endpoint

• Use this endpoint to retrieve comprehensive PEP and Sanctions screening result, including match details, confidence scores and source database information after a verification session has been completed.

• Common use cases include:

  • Accessing screening results for compliance and AML (Anti-Money Laundering) purposes
  • Investigating potential PEP or sanctions matches flagged during verification
  • Obtaining provider-specific match data including match confidence and source information
  • Conducting enhanced due diligence based on screening results
  • Retrieving ongoing monitoring status for the session

Response data

• The response includes screening results such as match status, search parameters used, and detailed hit information when matches are found.

• Key data returned:

  • reviewStatus: overall review state of all hits (no_match, potential_match, or reviewed)
  • monitorStatus: shows if ongoing monitoring is enabled or disabled for this session
  • searchTerm: shows the exact search parameters used (name, year, lists checked, match threshold)
  • totalHits: number of records matched in PEP and Sanctions databases
  • hits: array of detailed match data including matched names, countries, dates, match types, and related listings
  • matchStatus (deprecated): legacy indicator of whether matches were found (possible_match or no_match); use reviewStatus instead

• If no matches are found in PEP or Sanctions databases, the hits array will be empty and reviewStatus will be no_match.

• For matchTypes, see the data provider's documentation for more detailed info.

About reviewStatus field

• It reflects the overall review state of all hits in the screening result.
• The field has three possible values:
  • no_match: no hits were found in PEP/Sanctions databases
  • reviewed: all hits have been reviewed (each hit has a matchStatus decision) and possible changes have been acknowledged
  • potential_match: one or more hits exist that have not yet been fully reviewed, and/or monitoring changes have not been acknowledged
• Each hit in the hits array includes:
  • id: unique identifier for the hit (use this with the PATCH endpoint to submit reviews)
  • matchStatus: the review decision for that hit (false_positive, potential_match, true_match, inconclusive)
  • riskLevel: risk assessment (low or high), only present when hit matchStatus is true_match
• The hasUnacknowledgedChanges field indicates if ongoing monitoring has produced changes that need acknowledgment.

About matchStatus field (deprecated)

• Deprecated: Use reviewStatus instead.
• The matchStatus field is the legacy outcome indicator of the AML/PEP screening itself. It answered the compliance question "Is this person flagged on any watchlist?"
• The field has two possible values:
  • possible_match: the person was found in one or more listings/databases. The data.hits array is populated with data about the person.
  • no_match: the person was not found. The data.hits array is empty.
• This was independent from the session decision (approved/declined), which is driven by IDV checks.

Possible session outcomes

• Session approved + reviewStatus: no_match

  • This is the ideal outcome. The end-user's identity was verified successfully and they were not found on any PEP/Sanctions/Adverse Media lists. You can proceed with onboarding, no further AML action needed.

• Session approved + reviewStatus: potential_match

  • The end-user's identity is verified (the document and selfie are genuine), but one or more unreviewed hits were found on watchlists. Veriff only flags potential matches, you retain decisioning responsibility. Therefore, you need to perform manual review:
    • Review the hits array to examine the matched listings (source names, URLs, match types, etc.).
    • Determine whether each hit is a true match or a false positive (e.g., common name coincidence).
    • Submit your review decisions via the PATCH endpoint (hit.matchStatus, and optional hit.riskLevel if applicable).
    • If you require more data, you can use the relevant sessionId and query the GET sessions/sessionId/person endpoint to find more detailed info about the match. Look for data in the person.pepSanctionMatches array.

• Session approved + reviewStatus: reviewed

  • All hits have been reviewed, however this status does not tell you what the decision was. Always check the per-hit outcome before proceeding.
  • Apply your own risk-based decision depending on your regulation and requirements (decline the end-user, apply enhanced due diligence, or escalate).
  • See Possible session outcomes section in AML Screening (enhanced) guide for more info.

Screening availability

• Screening timing: Results are typically available within seconds to minutes after session completion, depending on:

  • Session submission and processing time
  • Provider database response times
  • Complexity of search parameters

• Response status codes:

  • 200 = Screening results ready (either matches found or no matches)
  • 202 = Screening still in progress, results not yet available. Wait a few seconds and retry the request.
  • 402 = PEP & Sanctions screening is not enabled for your integration

Implementation notes

• This endpoint requires session-level HMAC signature authentication
• PEP & Sanctions screening must be enabled for your integration to receive results
• The checkType field indicates if this is the initial_result or an updated_result from ongoing monitoring
• Handle both possible_match and no_match scenarios in your implementation
• Always ensure that you use the correct API URL to send requests. See the API URL section for more info
• The order of parameters in the real API response can differ from the order you see in this documentation. This is expected and part of the Backwards compatible changes requirements