Skip to main content

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.
Didit AML screening report screenshot with sanctions, PEP and adverse media hits

Where it appears in API responses

On the session decision endpoint, AML screening is returned as the plural array aml_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).
Standalone AML and business sessions return the same per-record shape. The fields below mirror the canonical schema on the Data models page.

Schema

See AML Screening in the Data Models reference for the canonical schema. Top-level fields:

Per-hit fields

Every entry in hits[] 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

When is_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.