AML Screening
AML screening checks a subject against official sanctions lists, politically exposed persons (PEP) and other risk domains. Every risk domain is screened by default; you can narrow the scope.
The full endpoint contract lives on its own page: Sanctions Screening API. This page covers the two decisions you make when calling it — scope (risk domains or mode) and threshold.
Choosing a mode
You set the scope in one of two ways:
riskDomains— pick the risk domains to screen one by one (sanctions,pep,rca,wanted,regulatory,debarment,ownership,vessel,securities). What each one means: Risk domains.mode— pick a preset set of risk domains (below).
Send neither and every risk domain is screened. Send both and their intersection is screened; an empty intersection is refused with sanction.screening.scope_invalid (400).
screenedRiskDomains in the response records it.| Mode | Risk domains screened | When |
|---|---|---|
sanctions_only | sanctions, wanted, regulatory, debarment | When sanctions screening is your only obligation |
sanctions_pep | + pep, rca | When you also carry a PEP obligation (most financial institutions) |
full_risk | Every risk domain — the same as sending no mode | Broad scope / high-risk customer segment |
Setting the threshold
threshold (0–1) is the minimum similarity score a match needs before it is returned to you.
| Threshold | Effect |
|---|---|
High (e.g. 0.95) | Fewer hits, less review load — but a higher chance of missing one |
Low (e.g. 0.70) | Many hits, many false positives — your review team drowns |
Lowering the threshold is not "safer". A pile of hits nobody can work through shows up in an audit as unreviewed alerts — a worse picture than never raising them. Set the threshold to the volume your team can genuinely close.
The way to cut false positives without touching the threshold is to send more disambiguators: dateOfBirth, identifiers (national/tax id), country. They do not change the score, they improve match precision.
Risk domains
Every match reports which risk domain it came from via riskDomains — sanctions, pep, rca, wanted and so on. The same name can appear in several; split your decision by domain:
sanctions— usually a hard blockpep·rca— not a block, a trigger for enhanced due diligence- other domains — down to your policy
Do not wire a PEP match to an automatic block. Being a PEP is not a crime; the obligation is to monitor the relationship more closely. An automatic block loses legitimate customers and does not match the regulatory expectation either.
Onboarding screening ≠ ongoing monitoring
A one-off screening is a snapshot of that moment. The lists change daily; a customer who is clear today can be listed tomorrow.
POST /api/v1/sanction/monitoring/register # register a subject
GET /api/v1/sanction/monitoring/alerts # new match alertsThe register call also takes the monitoring frequency and scope:
| Field | Notes |
|---|---|
externalCustomerId | Your own customer id |
subjectType | Person or organization |
frequency | DAILY · WEEKLY · MONTHLY (defaults to DAILY) |
riskDomainScope | Which risk domains to monitor against (empty = every risk domain) |
Screening at onboarding and not registering for monitoring is the most common gap in a compliance programme: the file closes because the customer was clear on day one, and the later listing goes unnoticed. They are two separate obligations.
Related
- Sanctions Screening API — endpoint contracts and authentication
- Adverse Media Screening — off-list reputational risk; a separate endpoint from name screening
- Screening History — the audit trail