Overview
AML screening emits a small set of warning tags on thewarnings[] array of each entry in aml_screenings[]. The two tags below are the only AML warnings Didit produces — everything else you see on a hit is encoded in the hit’s own fields (risk_view, match_score, risk_score, sanction_matches[], …) rather than as a warning. Both workflow sessions and the standalone AML API emit POSSIBLE_MATCH_FOUND the same way.
The status returned on the AML record (Approved, In Review, Declined) is derived from the aggregate score and your thresholds — the warnings tag the same conditions so you can react to them programmatically. See AML risk score for how thresholds map to status.
Warnings produced
| Risk | Cause | log_type | Affects status | Recommended remediation |
|---|---|---|---|---|
POSSIBLE_MATCH_FOUND | The aggregate score is non-zero and above the aml_score_approve_threshold (default 80) — at least one possible-match hit crosses your risk band. (The standalone AML API also emits it when the score exactly equals the threshold.) | warning; escalates to error when the score also exceeds the aml_score_review_threshold (default 100). | In Review when the score is above the approve threshold; Declined when it is above the review threshold. | Review each hit in hits[]. Use the AML hit-status endpoint to mark hits Confirmed Match, False Positive, or Inconclusive. Hit updates fire a data.updated webhook but do not recompute the AML status — set the final status via the AML status endpoint or console review. |
COULD_NOT_PERFORM_AML_SCREENING | The KYC record is missing one or more of full_name, date_of_birth, or issuing_state. No billable screening call is made. | warning | Forces In Review. | Populate the missing fields on the KYC record. AML re-runs automatically once all three are present — the stale warning log is removed and no manual retrigger is needed. |
feature: "AML" and follow the standard warning object shape.
Configurable settings
Per-workflow-node AML controls (also accepted as options on the standalone AML API):aml_score_approve_threshold— default80. A non-zero score above it producesPOSSIBLE_MATCH_FOUNDand routes the AML check toIn Review. Scores at or below it do not produce the warning in session workflows, regardless of hit count.aml_score_review_threshold— default100. A score above it auto-declines the AML check (with the default of100this never triggers until you lower it).aml_match_score_threshold— default93. Per-hit classification: hits withmatch_scorebelow it start asFalse Positiveand are excluded from the aggregate score; at or above it they start asUnreviewed.- Match-score weights —
aml_name_weight/aml_dob_weight/aml_country_weight, defaults60/25/15(must sum to 100). See AML match score. - Ongoing monitoring — when enabled, AML re-screens the subject as datasets change and re-emits the report plus a
status.updated(status changed) ordata.updated(hits changed) webhook.
When
COULD_NOT_PERFORM_AML_SCREENING fires, the AML check sits at In Review until the missing identity fields are supplied. Once Didit has the full name, date of birth, and issuing state, AML re-runs automatically and the warning clears — there is no manual retrigger.Examples
POSSIBLE_MATCH_FOUND (score above approve threshold)
COULD_NOT_PERFORM_AML_SCREENING (missing KYC fields)
Related
- AML report — full response shape, hit fields, status semantics
- AML risk score — how the aggregate score is calculated
- AML match score — per-hit confidence
- Continuous AML monitoring — monitoring lifecycle
- Data models — AML screening — canonical schema, including the Warning object