10 Sample AML Compliance Rules 

10 Sample AML Compliance Rules 
Image source: https://wallpaperaccess.com/machine-learning-4k

Money laundering schemes are difficult to detect. The goal of compliance teams at fintechs, banks, platforms, and payment processors is to find these abnormal patterns in the sea of transaction data generated every day. This creates a critical balancing act where rules must catch all of the bad activity without being so broad they generate overwhelming false positives.

When establishing a compliance program, one of the most important steps is establishing the initial set of rules. Over time, this ruleset will grow as new schemes are detected and corresponding rules are created. But that first set of rules is critical for quickly launching a compliance program and setting your team up for future success.

Creating rules can be a real challenge as every business situation has different risk factors and appropriate thresholds. However, there are some basic rule structures that every compliance team should consider deploying to cover the most common schemes.

Below are 10 universal anti-money laundering (AML) rules provided by Beam’s data science team that compliance departments should consider running against all of their transactions. These rules are intended as an entry point for anyone looking to establish a compliance program including fintechs, payment platforms, challenger banks, and marketplaces.  

These sample AML rules represent some of the powerful rules available for immediate deployment in the Beam AML compliance platform.

1. Structuring over time

This rule detects an excessive proportion of transactions just shy of a reporting or internal threshold. In the example below, the threshold is $10,000, and we are looking for a pattern where transactions for the party largely fall between $9,000 and $10,000 over a 60-day period.

Sample Expression:
(PARTY_PAY_OUT_NUMBER_OF_TRANSACTION_AMOUNTS_BETWEEN_9000_AND_10000_LAST_60_DAYS + PARTY_PAY_IN_NUMBER_OF_TRANSACTION_AMOUNTS_BETWEEN_9000_AND_10000_LAST_60_DAYS) / (PARTY_PAY_OUT_NUMBER_OF_TRANSACTIONS_LAST_60_DAYS + PARTY_PAY_IN_NUMBER_OF_TRANSACTIONS_LAST_60_DAYS) > .1

2. Profile change before large transaction

This rule identifies a situation when a customer makes a profile change to personally identifiable information (PII) shortly before making a large transaction (in this example, a transaction greater than $750). This can indicate account takeover or potential “layering” activity to obscure the path of the funds.

Sample Expression:
PARTY_DAYS_SINCE_LAST_MODIFIED_PII  < 2 && AMOUNT_VALUE > 750

3. Abnormally high volume of transactions

This rule identifies parties with abnormally high pay-out transaction volumes. A rule like this is appropriate for a peer-to-peer payment network with the capability of withdrawal of funds to an external account. In this simple example, the threshold is coded at 300 transactions over 30 days; both variables would be set for your business model.

Sample Expression:
PARTY_PAY_OUT_NUMBER_OF_TRANSACTIONS_LAST_30_DAYS > 300

4. Anomalous increase in overall transaction volume

This rule identifies a significant increase in the value of a party's outgoing transactions when compared to their recent average. It looks for parties with recent activity where the party's transaction value is substantially higher than the 7-day moving average. The rule filters out parties that have existed for a short amount of time, parties with a low balance, and low outgoing transaction value over the relevant time window.

Sample Expression:
(PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_7_DAYS) / (PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_14_DAYS - PARTY_PAY_OUT_NUMBER_OF_ALL_TRANSACTIONS_LAST_7_DAYS) > 2 && PARTY_INSIGHT_BALANCE_VALUE > 5000 && ((new Date() - PARTY_SOURCE_CREATED)/(60*60*24*1000)) > 60 && PARTY_NUMBER_OF_ALL_TRANSACTIONS_LAST_14_DAYS > 10

5. Self-pay by IP address

This rule identifies transfers between parties with the same IP address.

Sample Expression:
PARTY_GEO_CODE_IP_ADDRESS == REFERENCE_PARTY_GEO_CODE_IP_ADDRESS

6. Excessive flow-through activity

This rule identifies parties where the total value of credits is similar to the total value of debits over a short time frame. In this example, the rule is coded to cover 7 days. A rule like this is appropriate for a service that generally offerers collection of funds where you would not expect to see comparable spend activity (for example, a marketplace for goods and services).

Sample Expression:
PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS > .9 * PARTY_PAY_OUT_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS && PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS < 1.1 * PARTY_PAY_OUT_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS && PARTY_PAY_IN_VALUE_OF_TOTAL_AMOUNT_TRANSACTIONS_LAST_7_DAYS > 30000

7. Suspicious user spend behavior

This rule identifies transactions that highly deviate from the party's standard spend behavior. This may indicate an account takeover or externally influenced transaction. It includes a lower limit of $500, which you may want to modify to avoid the creation of excessive false positives.

Sample Expression:
((TOTAL_PRICE_VALUE - BUYER_AVG_VALUE_OF_TOTAL_PRICE_USD_TRANSACTIONS_LAST_60_DAYS) / BUYER_STDDEV_VALUE_OF_TOTAL_PRICE_USD_TRANSACTIONS_LAST_60_DAYS) > 1.5 && TOTAL_PRICE_VALUE > 500

8. Low buyer diversity

This rule is best suited for a platform where you generally see many buyers (senders) interacting with a single seller (recipient). It identifies merchants that only receive payments from a small number of buyers (in this example, fewer than 10). This rule only fires for accounts older than the set threshold to validate low diversity over time and permit some time for merchants to ramp up their interaction.

Sample Expression:
SELLER_ACCOUNT_AGE_DAYS > 90 && SELLER_NUMBER_OF_UNIQUE_BUYERS <= 10

9. Low seller to buyer messaging

This rule, like #8 above, is well suited to a platform that permits a buyer/seller relationship. It’s most useful for platforms that track the frequency of communication between buyers and sellers on the service. It identifies merchants with high earnings but very few messages sent, which could indicate collusion or money laundering rather than conventional commercial activity. This rule triggers based on an adjustable percentage threshold of messages sent per USD earned.

Sample Expression:
(SELLER_NUMBER_OF_MESSAGES_SENT / SELLER_TOTAL_EARNINGS_VALUE) < .013 && SELLER_NUMBER_OF_MESSAGES_SENT > 10

10. High transaction count from new users

This rule, like #8 and #9 above, is well suited to a platform that permits a buyer/seller relationship. It identifies merchants with a high percentage of their activity coming from new accounts, a potential red flag for money laundering or conventional fraud.  

Sample Expression:
(SERVICE_NUMBER_OF_BUYERS_USER_CREATED_LAST_30_DAYS / SERVICE_NUMBER_OF_BUYERS) > .5

Want to quickly deploy these rules and launch your compliance program?

Beam’s software was designed by compliance experts to provide an intuitive, highly accurate, and easy-to-use dashboard that streamlines transaction monitoring and case review. We help fintechs, banks, broker-dealers, entities using blockchain, and other regulated financial groups who need to comply with anti-money laundering (AML), know-your-customer (KYC), and suspicious activity reporting (SAR) regulatory requirements. Request a demo to see how Beam can solve your compliance challenges.

Title image source: https://wallpaperaccess.com/machine-learning-4k