> ## 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.

# AML Screening & Monitoring

> Learn how FrankieOne's AML solution helps you screen against global watchlists, manage risk, and maintain ongoing compliance.

## What is AML Screening?

Anti-Money Laundering (AML) screening is a critical compliance process for identifying individuals and organizations with connections to financial crime. It involves checking customer data against global watchlists to detect risks related to money laundering, terrorism financing, sanctions violations, and political exposure.

FrankieOne's solution streamlines this process, from initial real-time screening at onboarding to continuous, automated monitoring throughout the customer lifecycle.

***

## How AML Screening Works

Our AML capabilities are integrated directly into the FrankieOne workflow engine.

<Steps>
  <Step title="1. Create an Entity">
    First, you [/create](/api-reference/organizations/create-an-organization-entity) an `organization` entity with an `organizationToken` recorded from a lookup of the organization or you can use and `entityId` of an existing entity on which a data-fetch workflow like `ownership` or `profile` has been run using the [/execute](/api-reference/organization-workflows/execute-a-workflow-with-organization-details) endpoint.
  </Step>

  <Step title="2. Execute a Workflow">
    You then execute a workflow that has been configured with an **AML Step**. Our platform takes the entity's details and screens them against our connected data sources.
  </Step>

  <Step title="3. Receive Actionable Results">
    The workflow returns a clear result for the AML step—typically **`CLEAR`** or **`HIT`**. A `HIT` generates detailed Process Result Objects (PROs) and `issues` for any potential matches, allowing your team to investigate and classify the results.
  </Step>
</Steps>

***

## What We Screen For

Our AML solution checks against a wide array of global sources to provide a comprehensive risk profile.

* **Politically Exposed Persons (PEPs):** Identify individuals who hold prominent public functions and may present a higher risk for bribery or corruption.
* **Sanctions Lists:** Screen against lists of individuals, entities, and countries subject to economic or trade sanctions by governments and international bodies.
* **Adverse Media:** Scan global news sources for negative information linked to an individual that may indicate an elevated risk.
* **Other Regulatory & Law Enforcement Watchlists:** Check against a wide range of official lists to identify potential bad actors.

### Intelligent Matching

To increase accuracy and reduce false positives, our system uses sophisticated matching logic:

* **Name Matching**: Checks against the entity's full name, as well as known aliases.
* **Contextual Filtering**: Uses the entity's **date of birth**, **nationality**, and **country of residence** to filter out irrelevant matches from the screening results.

***

## Classifying AML Hits

When an AML screening results in a `HIT`, your compliance team needs to review the potential matches and classify them. This is a critical step in managing your AML risk.

You can update the status of one or more AML-related Process Result Objects (PROs) using the update [/results/aml](/api-reference/organization-results/update-the-status-of-aml-process-results) API.

**Request:**

```http theme={null}
PATCH /v2/organizations/{entityId}/results/aml
```

**Request Body:**

```json theme={null}
{
  "processResults": [
    "pro_01J285FC7DH5G113KF109RJHSD",
    "pro_01J285FC6MDNE7SZPVS8D3GC7S"
  ],
  "manualStatus": "FALSE_POSITIVE",
  "comment": {
    "text": "Reviewed by compliance officer. Matches are for a different individual with a similar name."
  }
}
```

### Manual Status Options (`manualStatus`)

When classifying a hit, you can set one of the following statuses:

| Status                 | Description                                                                                                           |
| :--------------------- | :-------------------------------------------------------------------------------------------------------------------- |
| `FALSE_POSITIVE`       | The match is not the same person you are onboarding.                                                                  |
| `TRUE_POSITIVE`        | The match is the same person, but a final decision has not been made. The hit remains unresolved.                     |
| `TRUE_POSITIVE_ACCEPT` | The match is the same person, and your organization has decided to accept the risk and proceed with the relationship. |
| `TRUE_POSITIVE_REJECT` | The match is the same person, and your organization has decided to reject the relationship.                           |
| `UNKNOWN`              | It is unclear if the match is the same person. The hit remains unresolved.                                            |
| `UNKNOWN_ACCEPT`       | It is unclear if the match is the same person, but your organization has decided to accept the risk.                  |
| `UNKNOWN_REJECT`       | It is unclear if the match is the same person, and your organization has decided to reject the relationship.          |

### Updating the Workflow Result After Classification

After classifying hits, the workflow needs to be updated so the entity's compliance status reflects the classifications. For example, a workflow that initially resulted in a `REVIEW` status due to unresolved hits may change to `PASS` if all hits are classified as `FALSE_POSITIVE`.

There are two ways to do this:

#### Re-evaluate the Workflow

Call the **evaluate** endpoint. This re-runs the decision and risk assessment steps using existing check results. It does **not** trigger new calls to external AML providers, so there is no additional provider cost.

```http theme={null}
POST /v2/organizations/{entityId}/serviceprofiles/{serviceName}/workflows/{workflowName}/evaluate
```

#### Re-run the Workflow

Call the **execute** endpoint to re-run the full workflow. This will contact external providers again (e.g., run a new AML search), which incurs additional cost and resets the aging window.

```http theme={null}
POST /v2/organizations/{entityId}/serviceprofiles/{serviceName}/workflows/{workflowName}/execute
```

<Callout icon="triangle-exclamation" color="#FFCA16" iconType="regular">
  Use `/evaluate` when only the decision needs updating based on changed classifications — it is faster, cheaper, and does not call external providers. Use `/execute` if the entity's underlying data has changed and fresh provider results are needed, or if existing check results have expired beyond the aging window.
</Callout>

***

## Additional Resources

* [Interpreting Workflow Results](/docs/kyb/interpreting-workflows-v2)
* [Handling AML Results](/docs/kyb/anti-money-laundering-results)