Default rules & some examples

Unlike many other transaction monitoring systems, Ermi comes with some default rules out of the box.

These rules can be tuned to your requirements and thresholds, or to use your own country risk rankings. However, the default rules are being used as examples here to help explain rules design.

What is context?

When we talk about context, we mean: “What are we trying to achieve with this rule?” Our last blog explained how this can be useful for developers, but it can also be useful later on when explaining your process to auditors and regulators. It's a bit like getting points on a math exam for showing your working!

We give you the context of our rules to help explain our logic but also because this context can be used to write these rules into other systems if you're using someone else. It’s okay, we don’t mind. Our priority is to have less money laundering and bad things in the world.

Not everything has to be a rule

One of the things our clients have found most useful is just “management information”. No hardcore analytics, simply a list every week of their biggest clients.

All this rule does, is to look back over the past 30 days, convert all transactions into a single currency (in this case USD), and total up all the transactions. It then generates a list of the top 10 individual clients, and shows them to the MLRO.

For clarity - PayerID in Ermi refers to the Unique ID given to a client, like an account number. This allows us to know which client conducted transactions etc.

This means that the MLRO can identify who the biggest clients are on a rolling basis. This helps with audits, in case asked for a list of your largest clients by a regulator. It also helps ensure you always know where your firm is making money.

Any huge outliers in this data can also be spotted. For example if the top client is spending £100K+ and the rest of your clients are typically spending < £1,000, clearly this is “A bit odd”

Ermi has 4 iterations of this rule; Largest corporate in the screening period; largest Individual screening period; largest single transaction by an individual and largest single transaction by a corporate.

These pages have been very useful for clients, simply because they did not have a base or home currency value in their transaction systems.

Geographies

Much of the regulation, in the UK and EU at least, concentrates on the risks of geography. This means rules are needed to identify transactions to or from high-risk countries.

It is important to note firstly that this is not the same as payments to sanctioned countries. Sanctions are often strict liability offenses, meaning you simply must not pay certain countries. Post event monitoring of these transactions is not acceptable; your systems need to block and reject payments to these locations.

Instead, this refers to countries that are considered to be high risk for money laundering. For example, because they have failed a FATF mutual evaluation or because other factors like corruption indicate that they pose a risk.

Popular guides for this include the Know Your Country risk index, or the Basel Risk Index.

Both of these have a well-defined methodology for how these scores are calculated.

There are no specific levels of what constitutes a suspicious payment to these locations. So we need to choose some thresholds, noting of course that a Red, Amber, Yellow set of thresholds may be possible, but also, that our countries represent different levels of risk.

Ermi, for example, has ranked all countries on a scale of 1-10. Where countries greater than 8 have high risk, greater than 6 are medium risk and 5 or below are low risk.

This rule for example:

This is a strict rule, which flags any transaction made by a corporate client to a high-risk country.

While:

This rule sets an allowed threshold for a medium risk country, for an individual client. This allows a client to send a payment up to 20,000 without flagging, but payments over this level will flag.

If you have multiple country risk lists, for example the UK’s 3ZE list, or the FATF list etc, then you will need multiple rules.

You may also need to consider corridors. For example, a payment from the UK to Columbia may be acceptable (The UK imports orchids from Columbia frequently!). Whereas a US based client paying to Columbia, from Miami, might be considered risky owing to this being a popular cocaine trafficking route.

In this case a rule such as this might be needed, which defines a UK based payer and only flags if the client is in the UK:

Unusual Spends

Unusual Spends are where a client exceeds their usual spend. If someone typically pays for an overseas mortgage and some utilities for a house in Spain - £1000 a month, but suddenly increases their spend to £20,000, this is clearly a little odd.

However, unusual spends are subject to a lot of false positives. This is for a number of reasons:

• Individuals and corporations will have different variations in their spending. Individuals will typically have a reliable stable income and so their spending will be consistent, whereas business spending will vary more depending on seasons and expenditures.
• Average spends and permitted multiples can cause some oddities. A client with an average spend of £500, with a permitted variance of 2x, would flag as soon as they spent £1,100. This same permitted variance for a client whose average transaction value is £1m, would be allowed to spend £2m before they flag, clearly this creates a lot more scope for the larger client to misbehave
• Higher risk clients should be flagged at an earlier stage, with a lower permitted multiple reflecting their risks.
• Unusual spend rules are usually very simple, if client spends 2x average, flag. This is too simplistic.

The solution is to combine these factors - client risk, ATV (Average Transaction Value), a red amber yellow flag system and permitted variable - in a 4 dimensional table which one vendor described to me as: “A nightmare of coding”.

This table shows some examples, where the ratio varies depending on the ATV & payer risk for individuals.

This table shows some examples for corporate payers:

This means that if the clients is an individual, low risk client, and their ATV is between the lower bound and higher bound, say £4,500, they will be allowed to trade up to 3x their normal average before we flag them, with a yellow alert.

If the same client is a medium risk client, they will only be allowed to trade up to 2.7x their average before they flag.

A high-risk client is only allowed to trade up to 2.4 of their average.

This reflects that higher risk customers are monitored more closely with tighter thresholds, reflecting the enhanced control you need to have over higher risk clients.

Expectations versus reality

Another indicator of your client being involved in risky activity is if they perform vastly more transactions or a vastly higher volume than you carried out KYC for.

For example, if during KYC, you approved them to trade up to $10,000 with your firm, but they instead trade $100,000, this is clearly a problem.

On a smaller scale, also look at daily transaction levels. For this to work, a limit needs to be set for the client. In Ermi we can set this threshold per client, or across our whole client base.

In this rule, each client has a set daily level and if a client of any kind trades above this threshold, then it will be flagged. The amount in this case is set in the payerDailyTotalThreshold column.

Ermi also has payerPastYearExpectedTotal which allows you to set an annual expected volume, or the reverse of this - payerPastNinetyDaysMinumumTransactionValue which allows you to set a minimum spend which can be used to flag fraudulent accounts which have only conducted test transactions.

Conclusion

There are likely to be more rules that you need, with multiple iterations of each of the rules for different groups and client types.

You may also need to consider how rules apply to different product types, or whether clients located in different countries need different rules based upon your regulators requirements. You may, based on this, end up with a large number of duplicate rules that look the same to create overlaps and different risk profiles, depending upon how your chosen transaction monitoring tool works.

Finally it is worth considering if external datasets, other than country risk lists, can be used to add value to your monitoring systems, for example monitoring certain addresses associated with higher risks, e.g. addresses where there are lots of companies listed.

The core thing at the end of setting your rules, is to ensure that you have a list of all of the active rules that can be applied to your transactions so that you provide them when asked by a regulator or auditor.