Skip to main content

PEPs, AML & Adverse Media checks

Availability

Available in SDK v1.0+

The PEP, AML & Adverse Media checks capability screens the user against compliance and risk databases. It's typically used in regulated industries (financial services, fintech, gaming, and others) where onboarding checks are a legal or regulatory requirement.

This capability relies on data collected in earlier steps (for example, a name and date of birth from a Scan ID step) to perform the lookup.

Checked categories​

Politically Exposed Persons (PEP)​

A Politically Exposed Person is someone who holds or has held a prominent public position (for example, a head of state, senior government official, senior military officer, or a close family member or associate of such a person). PEPs are considered higher-risk for potential involvement in corruption or bribery. Checking for PEP status is required by anti-money laundering regulations in many jurisdictions.

Anti-Money Laundering (AML)​

The AML check screens the user against sanctions lists and watchlists maintained by governments and international bodies (such as OFAC, the EU, and the UN). A match may indicate that the user is subject to financial sanctions, or is otherwise a prohibited or restricted party.

Adverse Media​

The Adverse Media check looks for negative news coverage associated with the user (for example, reporting related to financial crime, fraud, corruption, or other serious misconduct). This check complements the structured PEP and AML lists with signals from unstructured sources.

Relevancy score and rules​

Each category returns a relevancy score that reflects how confident the system is that the match is genuine and significant. A common source of false positives is name similarity; many people share names with individuals on watchlists. The relevancy score accounts for this by weighing how many identifying details align beyond the name alone.

For each category, you can configure a threshold:

  • If the relevancy score exceeds the threshold, the step can result in Rejected or Manual review

The scores from this capability can also feed into the Trust score capability if it's present later in the workflow.

Continuous watchlist monitoring​

Continuous watchlist monitoring (CWM) automatically re-screens your accepted users against compliance watchlists on an ongoing basis. Instead of a one-time check at onboarding, CWM runs periodic searches so you are notified if a user's status changes after they have been accepted—for example, if they are added to a sanctions list or their adverse media score changes.

CWM only creates a monitor for users whose final workflow result is Accepted. If a user is rejected during the workflow and you later manually change their status to Accepted, a monitor will still be created at that point.

There is a minimum delay of 5 minutes between publishing a workflow and monitors firing for that workflow.

How monitoring works​

CWM searches the same compliance databases as the one-time check, using the data collected during the user's workflow: first name and last name, supplemented by date of birth, document number, and country where available.

It returns a relevancy score for each category (AML, adverse media, PEP) using the same thresholds you configured for the capability.

We recommend setting thresholds at 90% or higher for each category.

Managing monitors​

In your organization, open the Activity tab and find Monitored profiles.

You can stop monitoring a specific user profile from there by finding the profile and disabling their monitor.

If a user goes through the same workflow again, and workflow settings are unchanged, the existing monitor is kept as-is.

If the workflow settings have changed (for example, different lists or thresholds), the old monitor is deleted and a new one is created with the updated configuration.

Webhooks​

You can set up a webhook to get updates if at any point a user's score changes.

At the specified cadence (monthly, weekly), the user is re-checked. If their compliance score has changed, you receive a webhook.

A notification is sent for any score change, not only when a user crosses a threshold.

Webhook payload​

{
    "AmlScore": 1,
    "EventType": "cwm.user.flagged",
    "NmScore": 1,
    "OrganizationId": "66d99fa9e7c185dfd4072f8c",
    "PepScore": 1,
    "UserId": "abcd-1234",
    "UserProfileId": "6a039ek301c4c60d84722b13"
}
  • AmlScore: AML and sanctions relevancy score (0–100)
  • EventType: always cwm_user_flagged for CWM events
  • NmScore: adverse media relevancy score (0–100)
  • OrganizationId: your organization's ID
  • PepScore: PEP relevancy score (0–100)
  • UserID: the user identifier from the consent object
  • UserProfileId: the ID of the user profile

API​

You can manage and inspect monitors programmatically via the Agent API.

Regions

Code examples here use the eu region. Use the appropriate region for your deployment.

Retrieve all monitors for your organization:

GET /agent/api/v1/organization/{organizationId}/monitor
curl --url "https://api.eu.platform.microblink.com/agent/api/v1/organization/{organizationId}/monitor" --user "$CLIENT_ID:$CLIENT_SECRET"

Retrieve a specific monitor by its ID:

GET /agent/api/v1/organization/{organizationId}/monitor/{monitorId}
curl --url "https://api.eu.platform.microblink.com/agent/api/v1/organization/{organizationId}/monitor/{monitorId}" --user "$CLIENT_ID:$CLIENT_SECRET"
Last updated on