# AML

This topic describes Rebilly Anti-Money Laundering (AML) features.

KYC and AML features are available as add-ons to your Rebilly account.
To activate, [contact Rebilly](/support/).
The KYC and AML features may be used together or separately.

Anti-Money Laundering (AML) checks are automated processes that scan customer information against AML lists as each new customer or lead is added, or when their information is changed.
When customer information matches data in an AML list, a hit is returned.
Completed AML checks contain one or multiple AML hits, where each hit is a record returned from the check.

You must manually verify these checks and mark them as a false positive or confirm that the customer has failed the AML check.

## How AML works

1. [Configure AML confidence level settings](/docs/settings/aml#configure-aml-confidence-level-settings).
For each scenario, set the degree of confidence to assign when a matching country, mismatching country, or no country is detected.
2. [Configure match priority settings for AML sources](/docs/settings/aml#configure-aml-match-priority-settings).
For each source, set the priority level for when very strong, strong, medium, and weak matches of customer information are found.
3. Automated AML checks scan customer information against Rebilly AML sources as each new customer or lead is added, or when their information is changed.
4. [Manually review AML checks](/docs/data-tables/manage-aml#review-customer-aml-checks) to confirm result matches or mark false positives.
A known false positive is suppressed from future alerts for a 1-year period.
For more information, see [Review customer AML checks](/docs/data-tables/manage-aml#review-customer-aml-checks).
5. [View completed customer AML checks](/docs/data-tables/manage-customer-compliance#view-completed-customer-aml-checks) to see the results of completed AML checks that are associated with a particular customer.


## AML check lifecycle

This section describes how an AML check moves from automated detection to a final outcome, and how those outcomes are displayed in the Rebilly UI.

### AML check status

The following are all AML check status values.

| Status  | Description |
|  --- | --- |
| `pending-review` | At least one possible AML hit was detected.
The AML check must be manually reviewed. |
| `in-review` | A reviewer opens the AML check, and the review is in progress.
For more information, see [Review AML checks](#review-aml-checks). |
| `no-match` | No possible AML match was detected for the customer data, or AML hits did not meet the configured rules.
For more information, see [No-match reasons](#no-match-reasons). |
| `confirmed-match` | A reviewer marks the AML hits as a confirmed match.
From a review perspective, the customer failed the AML check.
For more information, see [Review AML checks](#review-aml-checks). |
| `false-positive` | A reviewer marks the AML hits as a false positive.
From a review perspective, the customer passed the AML check.
For more information, see [Review AML checks](#review-aml-checks). |


AML checks with `pending-review` or `in-review` status are displayed in the **AML unreviewed customers** and **AML customer in review** segments.
For more information, see [Manage AML](/docs/data-tables/manage-aml).

### AML hits detected

This flow applies when the automated AML check detects one or more AML hits and a manual review is required to confirm the match or mark as a false positive.


```mermaid
%%{init: {"flowchart": {"htmlLabels": false}}}%%
graph LR;
    A(1 AML check completes) --> |Hits need review| B(2 pending-review)
    B --> |Reviewer opens the check| C(3 in-review)
    C --> |Reviewer confirms match| D(4 confirmed-match)
    C --> |Reviewer marks false positive| E(5 false-positive)
```

1. A customer or lead is created or updated, or a purchase or recurring event triggers an AML check.
2. The automated AML check is performed using configured AML lists and match rules.
For more information, see [Configure AML confidence level settings](/docs/settings/aml#configure-aml-confidence-level-settings) and [Configure AML match priority settings](/docs/settings/aml#configure-aml-match-priority-settings).
3. If AML hits are detected, the AML check is assigned the `pending-review` status and is displayed in the **AML unreviewed customers** or **AML customer in review** segments.
For more information, see [Review customer AML checks](/docs/data-tables/manage-aml#review-customer-aml-checks) and [Manage AML](/docs/data-tables/manage-aml).
4. When a reviewer opens the AML check, the status moves to `in-review` until the review is finished.
5. The reviewer confirms that the AML hits are a match by pressing **Confirm match**, or marks them as false positive by pressing **False positive**.


### No AML hits detected

This flow applies when the automated AML check detects no AML hits.
No manual review is required because there are no hits for a human reviewer to confirm or mark as a false positive.
From a review perspective, the customer passed the AML check.

The AML check is assigned the `no-match` status, receives an empty hit list, and a `noMatchReason` value of `no_hits_found`.
This value means that the AML check did not detect a possible match based on your AML configuration.

If the `noMatchReason` value is `internal_system_error`, the AML check failed for internal technical reasons.
Investigate the error and re-run the AML check.
Do not rely on this outcome for policy decisions.
For more information, see [No-match reasons](#no-match-reasons).


```mermaid
%%{init: {"flowchart": {"htmlLabels": false}}}%%
graph LR;
    A(1 AML check completes) --> |No AML hits| B(2 no-match)
```

#### No-match reasons

When an AML check has the `no-match` status, use the `noMatchReason` field to determine why no AML match was detected for the customer data:

| Reason  | Meaning |
|  --- | --- |
| `no_hits_found` | AML check returned no list entries that matched the customer. |
| `mismatched_hits` | AML hits were discarded because they did not match the configured AML confidence and matching rules.
For example, a country mismatch between the customer and the list entry. |
| `hits_are_below_relevance_score_threshold` | Possible AML hits were found but scored below the relevance threshold, so they are not treated as matches for review. |
| `internal_system_error` | AML check failed because of an internal system error, and the check completed without a match. |


### Inherited AML check outcome

Inheritance applies when a new AML check has the same AML hits as an earlier AML check that is already reviewed and is not in `pending-review` or `no-match` status.
The new check then skips `pending-review` and `in-review` and receives the earlier `confirmed-match` or `false-positive` status of the earlier AML check.
For more information, see [AML check inheritance](#aml-check-inheritance).

## Features

This section describes AML features and how to use them.

### Review AML checks

To review, accept, and reject customer AML checks, see [Manage AML](/docs/data-tables/manage-aml).
To view completed AML checks that are associated with a particular customer, see [View completed customer AML checks](/docs/data-tables/manage-customer-compliance#view-completed-customer-aml-checks).

### AML settings

To configure the level of confidence for customer Anti-Money Laundering (AML) check scenarios, see [AML confidence level settings](/docs/settings/aml#configure-aml-confidence-level-settings).
To configure match priority levels settings for Anti-Money Laundering (AML) sources, see [AML match priority settings](/docs/settings/aml#configure-aml-match-priority-settings).

### AML lists

AML sanctions, [Politically Exposed Person (PEP)](/docs/glossary#politically-exposed-person-pep) lists, and adverse media lists are used to check customer-provided information against lists published by governments and proprietary lists compiled by Rebilly.

#### List sources

The following AML list sources are assessed during an AML check.
These lists are updated daily.
If you would like to add another list, [contact Rebilly](https://www.rebilly.com/support/).

- [US OFAC](/docs/glossary#office-of-foreign-assets-control-ofac)
- UN sanctions
- EU sanctions
- US CIA
- Wikidata
- Proprietary


### Types of AML checks

The following check types are performed during an AML check.
If you would like to add another type of AML check, [contact Rebilly](https://www.rebilly.com/support/).

- [Politically Exposed Person (PEP)](/docs/glossary#politically-exposed-person-pep)
- Sanctions
- State-Owned Enterprises
- Adverse Media


### Fuzzy matching

Rebilly uses fuzzy matching algorithms including: partial match, double metaphone for name-based fuzzy searching, sounds-like (Soundex algorithm), and typos (Levenshtein algorithm) to identify possible matches.
Rebilly also uses a combination of other tactics, including custom relevancy and matching algorithms, to increase accuracy and confidence as much as possible.

### AML check inheritance

When an AML check returns one or more hits, the result of an earlier check may be used instead of creating a new pending review.
This reuse is called AML check inheritance or propagation.

Inheritance reuses only the status of the earlier check, such as `confirmed-match` or `false-positive`.

The new check still records current hits and links to the source check.

Inheritance occurs only when the current check produces the exact same set of AML hits as an earlier check that has already been reviewed and is not `pending-review` or `no-match`.
The reason recorded on the new check specifies why the earlier result was reused.
To view AML inherited matches reports, see [AML inherited matches reports](/docs/reports/aml-reports#view-inherited-matches-reports).

#### Reasons for inheritance

- **Customer data exactly matched a previous check on the same customer:** The same customer already had an AML check with the same hits, and that check was already reviewed.
The result of the earlier check is reused so the same hits do not need to be reviewed again.
- **Customer identity exactly matched a check on another customer:** The customer is treated as the same natural person as another customer, for example, the same person record in Rebilly.
The other customer has an AML check with the same hits that was already reviewed.
The result is reused for the current customer.
- **Customer primary phone number exactly matched a check on another customer:** The customer shares the same primary phone number on the primary address as another customer.
The other customer has an AML check with the same hits that was already reviewed.
The result is reused for the current customer.
- **Customer data exactly matched a previous check on the same customer vs related-customer propagation:** For a given check, the result is inherited either from the same customer’s previous check or from a related customer’s check, but not both.
When both are available, the result from the same customer’s previous check is used.


### Activate continuous monitoring

If you would like to activate continuous AML monitoring, [contact Rebilly](https://www.rebilly.com/support/).