AML Screening (enhanced)

This article covers the enhanced AML Screening solution.

If you are using the previous PEP & Sanctions solution, contact your Solutions Engineer to upgrade to the enhanced solution.

Compared to the legacy solution, the enhanced AML Screening offers more customization options regarding which lists to screen against, how strictly names are matched and how results are filtered.

These solutions can be used to meet and comply with Know-Your-Customer (KYC) and Anti-Money Laundering (AML) requirements. The enhanced solution allows more customization regarding:

• which lists to screen against,

• how strictly names are matched,

• how results are filtered.

It is available via API, web flow, and native SDKs.

*The solution can use two webhooks:

• decision webhook when the solution is used with the document or document+selfie identity verification (IDV) solution

• watchlist-screening webhook when the solution is used as standalone.

Contact your solutions engineer for info and configuration.

Prerequisites

• You have an integration set up with Veriff

• You have the PEP & Sanctions feature configured by your Solutions Engineer

• You have webhook(s) configured to get responses from Veriff (see the Webhooks section for info)

• You can also opt in to use optional adverse media checks and ongoing monitoring solution

End-user data sources

The “end-user data sources” refer to different origins from which the end-user’s information can be collected for database verification. There are two data sources: initData and document data.

InitData

This is data that you provide when creating a verification session, i.e. the parameters you specify in the POST /sessions request.

Parameters that can be sent via initData are:

• first name (required) in verification.person.firstName

• last name (required) in verification.person.lastName

• date of birth (optional) in verification.person.dateOfBirth

• end-user’s country (optional) in verification.document.country

Date of birth and country info is used as part of screening data sent to do person search.

Document data

This is data that is extracted from the end-user’s document. Includes information like names, date of birth, country data etc.

Flow overview

The flow is a bit different, depending on whether you are using an IDV or non-IDV integration for the checks.

Using an IDV integration

This means that it is possible to run the identity verification checks related to document or document+selfie, and the PEP and Sanctions, Adverse Media and Ongoing Monitoring checks.

End-user’s data can be sent via both Veriff end-user flow and the API endpoints.

1. Once the IDV integration is set up, generate a verification session using the regular POST /sessions[↗] endpoint

2. After the end-user’s data has been passed and the session has been verified:

   1. The identity verification results are sent via decision webhook,

   2. The AML result will be sent in the Watchlist-screening webhook

      1. Veriff will send a new webhook if the ongoing monitoring reveals that the status of a verified person has changed

3. You can:

   1. Query the results of AML checks from GET /sessions/{sessionId}/watchlist-screening[↗] endpoint

   2. Query the results of IDV checks from GET sessions/{sessionId}/decision[↗] endpoint

   3. Or view them in the Veriff Customer Portal

Using a non-IDV integration

This means that it is possible to run only the PEP and Sanctions, Adverse Media and Ongoing Monitoring checks. End-user’s data can be sent only via the API endpoints.

1. Create a new session using the API keys and the baseURL of the integration you are (see the API Documentation and reference[↗] how to find these). Include the following fields in the request:

   1. Ensure you send mandatory verification.person.firstName

   2. Ensure you send mandatory verification.person.lastName

   3. You can also send optional verification.person.dateOfBirth

   4. You can also send optional verification.document.country

POST {baseURL}/v1/sessions
Type: object
Headers:
       X-AUTH-CLIENT: string (required) = API key
       Content-Type: application/json

curl -X POST \
  --url '/v1/sessions/' \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: API-KEY' \
  -d '{
    "verification": {
        "person": {
            "firstName": "Eva",
            "lastName": "Nováková",
            "dateOfBirth": "1980-02-21"
        },
        "country": {
            "document": "PL"
        }
    }
}'

2. Change the status of the session to submitted using the PATCH /sessions/{sessionId}[↗] endpoint.

   • This endpoint requires endpoint level authentication via x-hmac-signature header. See HMAC Authentication and Endpoint Security article for general info about signature creation.

3. Receive the results from Veriff via Watchlist-screening webhook, query the results from GET /sessions/{sessionId}/watchlist-screening[↗] endpoint, or view them in the Veriff Customer Portal

   1. If you have set up the decision webhook, it will return session info, for example decision time, attempt id, and session status; but as no IDV checks were made, most of the fields will be null

Screening configuration

The screening parameters (which lists to check, match sensitivity, country filters, and other options) are configured on Veriff's side. The table below describes the available options.

To enable or adjust any of them, contact your Solutions Engineer.

You can see which configuration was applied to a specific check in the searchTerm object returned in the watchlist-screening webhook.

lists categories and category descriptions

About matchStatus field

The matchStatus field is the primary outcome indicator of the AML/PEP screening itself. It directly answers 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 is independent from the session decision (approved/declined), which is driven by IDV checks.

The confidence in the matchStatus is higher when combined with IDV, because the screening data was extracted from a verified document. In standalone mode, the accuracy of the screening depends on the quality of the data you input.

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.

Possible session outcomes

Session approved + matchStatus: 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 + matchStatus: possible_match

The end-user’s identity is verified (the document and selfie are genuine), but they were found on one or more 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 the hit is a true match or a false positive (e.g., common name coincidence).

• Apply your own risk-based decision depending on your regulation and requirements (decline the end-user, apply enhanced due diligence, or escalate).

Find decision and/or session related info

You can get the data from three sources:

• Receive the webhook. The webhook is different, depending wether you are using the AML solution with or without an IDV integration

• Poll the results via GET /sessions/{sessionId}/watchlist-screening[↗] API endpoint

• View the session in Veriff Customer Portal > All Verifications > session > Webhooks tab

Webhook payload

API call response payload

You can use the GET /sessions/{sessionId}/watchlist-screening[↗] endpoint, which contains the same data as the watchlist-screening webhook.

Veriff Customer Portal

You can find the verification session related info, including the decision, in the Veriff Customer Portal, under the Verifications tab.

Status and reason codes

For an approved session, see the verification.code and verification.status parameters.

If the session was declined or resubmission_requested, you can find additional information by checking the verification.status, verification.code, verification.reason and verification.reasonCode data objects.

For more info about the codes you are seeing, refer to:

• Verification session status codes (table)

• Verification session decision codes (table)

• Granular reason codes (table)

Disabling ongoing monitoring for a specific end-user

It is possible to use the API to disable the ongoing monitoring feature for a specific end-user. For the API requests, the end-user is identified by the sessionId.

Steps

1. If unsure if the feature is enabled for them, check the monitorStatus parameter in GET sessionId/watchlist-screening response payload.

2. If the monitorStatus is enabled or empty, you can set it to disabled using the PATCH sessionId/watchlist-screening endpoint.

3. If you wish to re-enable ongoing monitoring for an end-user, contact your Solutions Engineer

Additional info

→ Log in to your Veriff account to see the PEP, Sanctions, Watchlists, and Adverse Media & Information checks[↗] article in Veriff Knowledge Base for more information about the Anti-Money Laundering solutions

→ Log in to your Veriff account to see What is PEP?[↗] article in Veriff Knowledge Base for more detailed insight into Politically Exposed Persons

Changelog