> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frankieone.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Interpreting AML Screening Results
A detailed guide to understanding the results of an AML check, from the high-level summary down to the details of each watchlist match.
## 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 the `workflowResult` object.
The examples in this guide refer to a workflow execution response where a PEP match was found. Click to expand and see the full structure.
```json theme={null}
{
"requestId": "01HN9XHZN6MGXM9JXG50K59Q85",
"workflowResult": {
"workflowExecutionId": "wfe_01J...",
"workflowExecutionState": "COMPLETED",
"status": "REVIEW",
"result": "REVIEW",
"riskAssessment": {
"riskLevel": "HIGH",
"riskScore": 100,
"riskFactors": [
{ "factor": "is_pep", "value": "true", "score": 100 }
]
},
"issues": [
{
"category": "AML",
"issue": "PEP",
"severity": "WARNING"
}
],
"workflowStepResults": [
{
"stepName": "AML",
"result": "HIT",
"summary": {
"totalHits": 1,
"totalUnresolved": 1,
"numUnresolvedPEP": 1
},
"processResults": [
{
"processResultId": "pro_01J...",
"result": "HIT",
"class": "AML",
"supplementaryData": {
"type": "AML",
"matchData": { "name": "John Doe" },
"pepData": [
{
"level": "2",
"position": "Former Member of Parliament",
"countryCode": "AUS"
}
]
},
"manualStatus": "UNRESOLVED"
}
]
}
]
}
}
```
***
## Part 1: The Overall Outcome (Final Verdict)
Always start by checking the top-level fields of the `workflowResult` object. These give you the final, authoritative outcome.
| Field | Importance | Description |
| :--------------------------- | :--------- | :---------------------------------------------------------------------------------------------------------------------- |
| **`status`** | ‼️ | The conclusive recommendation (e.g., `PASS`, `FAIL`, `REVIEW`). **Base your primary business logic on this value.** |
| **`workflowExecutionState`** | ‼️ | Confirms the workflow's technical status. **Must be `COMPLETED`**. |
| **`issues`** | ⚠️ | An array of problems that require manual review. If `status` is `REVIEW`, this array contains the specific reasons why. |
| **`riskAssessment`** | ⚠️ | The final risk profile of the entity, including the `riskLevel` and `riskScore`. |
In the example, the `status` is `REVIEW`, which is directly caused by the `issues` array containing a `PEP` issue.
### Understanding AML Issues
When the AML step finds a potential match, it generates an `issue` object. This is what typically drives the overall workflow `status` to `REVIEW`.
| Category | Issue | Severity | Trigger Condition |
| :------- | :---------- | :-------- | :---------------------------------------------------------- |
| `AML` | `PEP` | `WARNING` | At least one valid Process Result contains `pepData`. |
| `AML` | `SANCTIONS` | `WARNING` | At least one valid Process Result contains `sanctionData`. |
| `AML` | `MEDIA` | `WARNING` | At least one valid Process Result contains `mediaData`. |
| `AML` | `WATCHLIST` | `WARNING` | At least one valid Process Result contains `watchlistData`. |
***
## 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.
| Key Field | Description |
| :------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`result`** | The most important field for the step. A `result` of **`HIT`** means at least one potential match was found and requires review. A `result` of **`CLEAR`** means no matches were found. |
| **`summary`** | An aggregated summary of the screening results, broken down by match type. |
| **`processResults`** | An array containing the detailed evidence for each individual watchlist match. |
### The AML Summary Object
The `summary` object gives you a quick, quantitative overview of the screening results.
```json theme={null}
"summary": {
"stepName": "AML",
"totalHits": 12,
"totalFalsePositives": 0,
"totalTruePositives": 0,
"totalUnresolved": 12,
"numUnresolvedPEP": 1,
"numUnresolvedSanction": 1,
"numUnresolvedWatchlist": 10,
"numUnresolvedAdverseMedia": 0,
"providerSummaries": [...]
}
```
This summary immediately tells you the scale and severity of the results. For example, `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 a `HIT`, 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 the **`supplementaryData`** object. This is where you will find the details of the matched entity.
| `supplementaryData` Field | Description |
| :------------------------ | :------------------------------------------------------------------------------------------------------------------ |
| **`matchData`** | Core information about the matched profile (name, date of birth, countries of association). |
| **`pepData`** | If the match is a Politically Exposed Person, this array contains details about their position, level, and country. |
| **`sanctionData`** | If the match is on a Sanctions list, this array contains details about the sanction, its source, and the reason. |
| **`watchlistData`** | This array contains details for matches on other regulatory or law enforcement watchlists. |
| **`mediaData`** | If the match is from Adverse Media, this array provides snippets and links to relevant news articles. |
| **`referenceDocs`** | An array of URLs to source documents for further evidence. |
This example shows a `processResult` for a `HIT` where the individual was matched against a PEP list. The `pepData` array is populated with the specific details of the political exposure.
```json theme={null}
{
"processResultId": "pro_01J...",
"result": "HIT",
"class": "AML",
"supplementaryData": {
"type": "AML",
"matchData": { "name": "John Citizen" },
"pepData": [
{
"level": "2",
"position": "Former Member of Parliament",
"countryCode": "AUS",
"listingStart": "2010-01-01"
}
]
},
"manualStatus": "UNRESOLVED"
}
```
***
## Part 4: Next Steps - Classifying Hits and Re-evaluating
After your compliance team reviews the evidence in the `processResults`, 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](/docs/anti-money-laundering)**.
### Re-running the Workflow
Once all hits have been classified, you **must re-run the workflow** for the entity. This is a critical step for two reasons:
1. **To Update the `status`**: The overall `workflowResult.status` will only change from `REVIEW` to `PASS` or `CLEAR` after the workflow is executed again and the AML step confirms that no unresolved hits remain.
2. **To Clear `issues`**: The re-execution will cause the AML step to re-evaluate the issues. If all PROs that previously caused a `PEP` issue are now classified as `FALSE_POSITIVE`, the issue will be cleared from the workflow result.
This re-evaluation ensures your entity's compliance status is officially updated and your audit trail is accurate.