--- title: "AML Screening (enhanced)" slug: "aml-screening-solution" description: "Use the AML Screening solution for customizable compliance with KYC and AML requirements, available via API, web flow, and SDKs." updated: 2026-05-19T11:22:26Z published: 2026-05-19T11:22:26Z --- > ## Documentation Index > Fetch the complete documentation index at: https://devdocs.veriff.com/llms.txt > Use this file to discover all available pages before exploring further. # AML Screening (enhanced) | Available via API | Available via SDK | Needs configuration on Veriff’s side | Needs a separate integration | Needs a separate webhook | | --- | --- | --- | --- | --- | | ✅ | ✅ | ✅ | ✅ | ✅*/❌ | > [!TIP] > **This article** covers the **enhanced AML Screening solution**. > > > > If you are using the [previous PEP & Sanctions solution](/v1/docs/aml-screening), 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](/v1/docs/decision-webhook) when the solution is used with the document or document+selfie identity verification (IDV) solution - [watchlist-screening webhook](/v1/docs/watchlist-screening-webhook) when the solution is used as standalone. > [!NOTE] > 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](/v1/docs/aml-screening-solution#webhook-payload) 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](https://devdocs.veriff.com/apidocs/v1sessions) 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 P****EP 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](https://veriff-dev-documentation.document360.io/apidocs/v1sessions)[↗] 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](/v1/docs/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](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidwatchlist-screening-1)[↗] endpoint 2. Query the results of IDV checks from [GET sessions/{sessionId}/decision](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsiddecision-1)[↗] 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](https://devdocs.veriff.com/apidocs)[↗] 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` **Click to see the **minimum request payload** sample needed to start a session** **1.1 Include the API URL and mandatory headers** ```plaintext 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` - `document`: `object` - `country`: `string` *Required parameter **Request payload sample** ```bash 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"        }    } }' ``` 1. **Change the status** of the session to `submitted` using the [PATCH /sessions/{sessionId}](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsid-2)[↗] endpoint. - This endpoint requires endpoint level authentication via `x-hmac-signature` header. See [HMAC Authentication and Endpoint Security](/v1/docs/hmac-authentication-and-endpoint-security#public-api-v1) article for general info about signature creation. 2. **Receive the results** from Veriff via [Watchlist-screening webhook](/v1/docs/watchlist-screening-webhook), query the results from [GET /sessions/{sessionId}/watchlist-screening](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidwatchlist-screening-1)[↗] 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. > [!NOTE] > 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](/v1/docs/watchlist-screening-webhook). | Option | Description | Parameter inside `searchTerm` object | | --- | --- | --- | | List selection | Which watchlists to screen against, for example: Sanctions, PEP Class 1–4, Adverse Media. See [table below](/v1/docs/aml-screening-solution#lists-categories) for more info about the categories. At least one list must be always selected. | `lists` | | Match threshold | Name match sensitivity on a 0–100 scale, indicates how much variation should be allowed from the end-user's data in the results. Higher values require a closer match before a result is returned. | `matchThreshold` | | Exact match | Requires an exact name match, meaning that the screening will happen on the data as it is. This bypasses name normalisation, e.g., titles are not removed. | `exactMatch` | | Country filter | Filters search results by country, meaning that the results presented in the webhook/API response will only include the hits from the selected countries (ISO 3166-1 Alpha-2 codes). The countries selected here will be merged with the countries present in initData or the document. | `countries` | | Exclude deceased | Filters out deceased individuals from results. | `excludeDeceased` | #### `lists` categories and category descriptions | Value | Description | | --- | --- | | `SANCTIONS` | Global sanctions lists, including OFAC SDN, OFAC Consolidated, European Union, UK (OFSI), United Nations and other national sanction programmes that have regulatory requirements to screen for connected entities. | | `PEP_CLASS_1` | Heads of state Members of the national executive Members of the national legislatures Senior officials of military and law enforcement Senior officials of national agencies Board members of central banks Senior judiciary officials (national level) Top-ranking officials of political parties | | `PEP_CLASS_2` | Board members of International Organisations (HIOs) & International Sports Federations Ambassadors, high commissioners and other top diplomatic positions Members of the regional executive Members of the regional legislatures Senior judiciary officials (regional level) | | `PEP_CLASS_3` | Senior management and board of directors of state-owned businesses and organisations | | `PEP_CLASS_4` | Mayors and members of local, county, city and district assemblies | | `ADVERSE_MEDIA` | Adverse media coverage | | `FITNESS_PROBITY` | Lists of individuals and legal entities which have been disqualified or otherwise restricted from holding certain positions or participating in certain activities such as publicly-funded contracts due to regulatory or code of conduct breaches. | | `WARNINGS` | Lists of individuals, legal entities, issued by relevant law enforcement or regulatory bodies. | --- ## 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](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidperson-1)[↗] 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](/v1/docs/aml-screening-solution#webhook-payload), depending wether you are using the AML solution with or without an IDV integration - Poll the results via [GET /sessions/{sessionId}/watchlist-screening](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidwatchlist-screening-1)[↗] API endpoint - View the session in Veriff Customer Portal > All Verifications > *session* > Webhooks tab ### Webhook payload With IDV integrationNon-IDV integration 1. Check the [decision webhook](/v1/docs/decision-webhook) for the identity verification results 2. Check the [watchlist-screening webhook](/v1/docs/watchlist-screening-webhook) for AML checks results 1. Check the [watchlist-screening webhook](/v1/docs/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](https://veriff-dev-documentation.document360.io/apidocs/v1sessionsidwatchlist-screening-1)[↗] 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. → *See*[*Review verification in Veriff Customer Portal*](/v1/docs/how-to-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: - [Verification session status codes (table)](/v1/docs/verification-session-status-codes-table) - [Verification session decision codes (table)](/v1/docs/verification-session-decision-codes-table) - [Granular reason codes (table)](/v1/docs/granular-reason-codes) --- ## 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](/v1-api/apidocs/v1sessionsidwatchlist-screening-1) response payload. 2. If the `monitorStatus` is enabled or empty, you can set it to `disabled` using the [PATCH sessionId/watchlist-screening](/v1-api/apidocs/v1sessionsidwatchlist-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*](https://help.veriff.com/en/articles/3250236-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?*](https://help.veriff.com/en/articles/3292257-what-is-a-pep)[↗]*article in Veriff Knowledge Base for more detailed insight into Politically Exposed Persons* --- ## Changelog | Date | Description | | --- | --- | | May 19, 2025 | Documentation published | Abbreviation of **Identity Verification**. A **process where the end-user submits the data** required to get verified.Also referred to as the "verification flow". A session during which the end-user is verified. It starts when a session is created, it can contain several attempts (i.e. steps of uploading media, sending additional data etc.) and it ends when a conclusive decision (“approved”, “declined”, “expired”/”abandoned”) is granted. Each verification session receives an unique ID, aka the **session ID**, which can be added to the API URL when making API requests. Veriff customer back-office, a dashboard where you can see your end-users' verification data. Depending on your setup, you may be required to access the environment via station.veriff.com or hub.veriff.com. Always **check your sign-up email** and make sure that you **log in via correct address**.