How to Read an AML Result
When you execute a workflow containing an AML step, the API response provides a rich set of data to help you understand the outcome. This guide provides a structured, “top-down” walkthrough of how to parse theworkflowResult object.
View Full API Response Example
View Full API Response Example
The examples in this guide refer to a workflow execution response where Adverse Media matches were found. Click to expand and see the full structure.
Part 1: The Overall Outcome (Final Verdict)
Always start by checking the top-level fields of theworkflowResult object. These give you the final, authoritative outcome.
In the example, the
status is REVIEW, which is directly caused by the issues array containing a MEDIA issue.
Understanding AML Issues
When the AML step finds a potential match, it generates anissue object. This is what typically drives the overall workflow status to REVIEW.
Part 2: The AML Step Result (workflowStepResults)
Next, drill down into the workflowStepResults array and find the object where stepName is AML. This object contains the specific results of the screening.
The AML Summary Object
Thesummary object gives you a quick, quantitative overview of the screening results.
numUnresolvedSanction highlights if a high-risk sanctions match is present and needs immediate attention.
Part 3: The Process Results (The Raw Evidence)
When an AML step returns aHIT, the processResults array will contain one or more Process Result Objects (PROs), each with class: "AML". Each PRO represents a single potential match from a watchlist and contains all the data you need for your investigation.
Anatomy of an AML PRO
The most critical part of an AML PRO is thesupplementaryData object. This is where you will find the details of the matched entity.
Example: A Adverse Media Match PRO
Example: A Adverse Media Match PRO
This example shows a
processResult for a HIT where the organization has adverse media hits. The mediaData array is populated with the specific details of the adverse media matches.Part 4: Next Steps - Classifying Hits and Re-evaluating
After your compliance team reviews the evidence in theprocessResults, they must classify each hit (e.g., as a FALSE_POSITIVE). This is done by updating the manualStatus of each PRO.
For a detailed guide on how to perform this action via the API, please see our AML Screening & Monitoring Documentation.
Updating the Workflow Result
Once all hits have been classified, the workflow needs to be reevaluated so the entity’s risk and workflow status reflect the classifications. This is critical for two reasons:- To Update the
status: The overallworkflowResult.statuswill only change fromREVIEWtoPASSorCLEARafter the workflow is re-evaluated or re-run and the AML step confirms that no unresolved hits remain. - To Clear
issues: The AML step will reassess the issues. If all PROs that previously caused aMEDIAissue are now classified asFALSE_POSITIVE, the issue will be cleared from the workflow result.
Re-evaluate the Workflow
Call the evaluate endpoint. This re-runs the decision and risk assessment steps using existing check results, without triggering new calls to external providers. This ensures the entity’s risk and workflow status are updated and the audit trail is accurate.Re-run the Workflow
Call the execute endpoint to re-run the full workflow. Unless existing results are within the aging window, this will contact external providers again (e.g., run a new AML search), which incurs additional cost and resets the aging window.Use
/evaluate when only the decision needs updating based on changed classifications — it is faster, cheaper, and does not call external providers. It re-assesses risk using the entity’s existing check results, but does not refresh them. Use /execute when the entity’s underlying data has changed, or when you need fresh provider results because existing checks have expired beyond the aging window.