Overview
AML screening cross-references the verified subject’s identity against global sanctions, PEP, watchlist, and adverse-media datasets. Each hit returns the matched entity, the dataset(s) that produced the match, two scores —match_score (identity confidence) and risk_score (entity risk) — and a structured breakdown by source (pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[]). The aggregate score is the highest risk_score among hits that are not marked False Positive.
The same shape is returned by AML screening on user (KYC) sessions, business (KYB) sessions, and the standalone AML API.

Where it appears in API responses
On the session decision endpoint, AML screening is returned as the plural arrayaml_screenings[]. Every entry corresponds to one AML execution in the workflow (an AML check that runs twice produces two entries with different node_id values).
Schema
See AML Screening in the Data Models reference for the canonical schema. Top-level fields:Per-hit fields
Every entry inhits[] has the following fields (subset shown). Match-source arrays — pep_matches[], sanction_matches[], warning_matches[], adverse_media_matches[] — are populated only for the dataset(s) the hit belongs to.
Hits classified as
False Positive (because match_score fell below the match-score threshold, or because a reviewer marked them) remain in hits[] for auditability. They are excluded only from the aggregate score calculation.Ongoing monitoring
Whenis_ongoing_monitoring_enabled is true, Didit re-screens the subject continuously and re-emits the AML report any time a hit is added, removed, or changes. Re-screens that change the AML status fire a status.updated webhook; re-screens that only change hit data fire data.updated. The monitoring window runs from the last_aml_bill_date for 365 days; next_ongoing_monitoring_bill_date exposes when the next annual renewal hits. See Continuous AML monitoring for the full lifecycle.
Status values
The thresholds are configurable per workflow node — see AML risk score. Custom status rules combine with the derived status using
Declined > In Review > Approved precedence; reviewers can also override the AML status from the console or the AML status endpoint.
Examples
Approved — no hits
In Review — PEP + adverse media hit
All names, URLs, and articles below are fictional.Related
- AML warnings — every warning code AML can emit
- AML risk score and AML match score — how the two scores are calculated
- Continuous AML monitoring — enabling and consuming monitoring events
- Watchlist database — datasets covered
- Data models — AML screening — canonical schema
- Webhooks —
status.updatedfires when AML changes the session status; hit review-status changes and monitoring data refreshes firedata.updated