AML

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

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.

1. 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. 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 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.
5. View completed customer AML checks to see the results of completed AML checks that are associated with a particular customer.

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.

The following are all AML check status values.

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.

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.

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

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.

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. Use the noMatchDetails field for additional codes that explain which criteria did not match or which search conditions were applied. For other statuses, these fields are empty.

The noMatchReason values are:

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.

This section describes AML features and how to use them.

To review, accept, and reject customer AML checks, see Manage AML. To view completed AML checks that are associated with a particular customer, see View completed customer AML checks.

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

AML sanctions, 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.

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.

• US OFAC
• UN sanctions
• EU sanctions
• US CIA
• Wikidata
• Proprietary

The following check types are performed during an AML check. If you would like to add another type of AML check, contact Rebilly.

• Politically Exposed Person (PEP)
• Sanctions
• State-Owned Enterprises
• Adverse Media

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.

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.

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

If you would like to activate continuous AML monitoring, contact Rebilly.