AML Screening

These solutions can be used to meet and comply with Know-Your-Customer (KYC) and Anti-Monely Laundering (AML) requirements.

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

Contact your solutions engineer for info and configuration.

Prerequisites

  • You have an integration set up with Veriff

  • You have the PEP & Sanctions checks 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


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 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 using for the AML solution (see the API Documentation and reference[↗] how to find these). Include the following fields in the request:

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

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

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

Click to see the minimum request payload sample needed to start a session

1.1 Include the API URL and mandatory headers

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

1.2 Add the following data into the minimum payload

  • verification: object Verification object

    • person: object

      • firstName: string*

      • lastName: string*

      • dateOfBirth: string

*Required parameter

Request payload sample

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"
        }
    }
}'

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

  2. 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

Find decision and/or session related info

Webhook payload

  1. Check the decision webhook for the identity verification results

  2. Check the watchlist-screening webhook for AML checks results

  1. Check the watchlist-screening webhook for AML checks results

  2. If you have set up the decision webhook, you can check it for session info (note that as no IDV checks were made, most of the fields will be null)

API call response payload

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

data.matchStatus shows if the person has a match in any of the listings or databases:

  • possible_match indicates that the person was found. The data.hits array is populated with data about the person

  • no_match indicated the the person was not found. The data.hits array is empty

If you require more data, you can use the relevant sessionId and query the GET sessions/{sessionId}/persons[↗] endpoint to find more detailed info about the match. Look for data in the person.pepSanctionMatches array.

Veriff Customer Portal

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

See Review verification in Veriff Customer Portal about how to view the session info in the Veriff Customer portal


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:


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


Article Versioning

Date

Description

March 20, 2025

“Using a non-IDV section” and “Webhooks payload” section updated with info about  the decision webhook in sessions done with non-IDV integration

March 12, 2025

Documentation published