No but seriously, how do we design a rule

In part 2 of this series we discussed how to design rules for your Transaction Monitoring system.

We focused on risk assessments and how they help you develop appropriate rules for your business. This time we promise we will talk about actually designing the rules.

Language is important

So first, let's talk about Months. It's important to understand and define all of your terms when talking to your systems developer. They will build whatever you ask for, exactly as you ask for it.

Months are not great because they are inconsistent. The word “Month” is used loosely. When you say month do you mean, 30 days, 31 days, 28 days? A Calendar month? A Synodic Lunar Month? (We suggest you don't try to use the last one…)

When designing rules, the first thing to do is to choose your language and choose it carefully.

When you say Client, what do you mean? Are the clients in any groups such as Individuals as Individuals or Corporates? Are there any words you use that may not automatically make sense to someone else. For example, the wire transfer regs specify payer and payee, by some may internally refer to these as client and beneficiary. Third and fourth party are concepts that only really exist in correspondent banking, so don't assume everyone knows them.

A glossary of terms, or codex, is a useful place to start when developing a tool from scratch or writing rules with a third party.

The choice of language

Secondly, it is essential to ensure the right language is used to define and describe rules. This should be agreed between you and the developer up front, to avoid any confusion later.

Ermi uses Gherkin. This is a plain-text language with a simple structure. It is designed to be easy for non-programmers to learn, yet also structured enough to allow concise description of test scenarios and examples to illustrate business rules in most real-world domains

By way of an example:

This rule clearly:

• Defines that the rule is only for clients who have traded in the last 90 days and have traded within the period we are screening. This stops any accounts with no recent activity from flagging.
• Only applies to individual clients, not corporates
• Flags any client who traded more than 3 (i.e., 4) currencies.

So, if a client trades and has used multiple currencies (4) then their account will be flagged.

The concept behind this rule is that most individual clients will trade in their home currency (GBP or another home currency for where the firm is based). If they are an expatriate or a migrant, they may be sending money home for example, or to an overseas property. In addition, it allows for USD, which is a universal currency, used often enough that it is added to avoid false positives. Therefore, someone trading in 4 currencies is likely to be worth reviewing.

This intention behind the rule and what are you trying to achieve can also be a useful thing to tell a developer. Rather than just passing them a solution or rule providing context is helpful when it comes to problem solving.

Note that the wording of this rule example does not specify exactly which currencies a client can use, merely any 3 currencies. A more specific rule would be needed to flag specific currencies.

<, >, or equals to?

Another area to be careful of here, is <, > and equals to. The rule above says “more than 3” - which means 4.

Less than 3 could be 0, 1 or 2. If we say 3, it means EXACTLY 3, not 2, not 4.

This might seem obvious to you, but care needs to be taken because if you write a rule that says, “less than 10,000”, and another rule that says “more than 10,000” - then there’s no rule for exactly 10,000.

In the rule above, the client could happily send transactions in GBP, Euro and USD, but the moment they begin to trade in Yen, the client will flag.

Another important thing to clarify is “what is flagging?” Is it the client, or the transaction? This can become especially important if you have a live monitoring platform with a hard stop, as flagging the client could block all their future activity, while flagging a transaction will just stop a single payment from going. It might also be good to clarify what a Transaction means! Does this mean an FX conversion, or a payment… or both?

Ermi isn’t a live tool, but it's important to consider this as it will also prevent you from having to clear huge amounts of false positives or missing something important.

What data do I actually have?

As obvious as it might sound, you can only write rules on data you have in the system. If your TM system doesn’t know if your client is a corporate or an individual, you can't write a rule that differentiates between these groups. Similarly, if your TM system does know that your client is a PEP, then it can use this data to do more accurate analysis of payments to higher risk corruption countries, for example.

Our file format can be found on Github but, be careful. Just because your monitoring provider CAN take in this data, which doesn't mean your developers or internal systems have access to that data, or that it can be shared with your provider. Reading the provider’s API spec might give you a false sense of security that anything is possible.

Ermi can also run with just 9 pieces of data, but the more data she has the more she will find and the more rules that become available. For example, “payerCreatedAt” unlocks rules that flag newer clients with stricter thresholds. This can be useful to detect mule or fraudulent accounts, which are opened and then rapidly abused before they can be detected and shut down.

What thresholds should I set?

Other than a few very specific regulatory limits in the USA and Canada, both for $10,000, there are very few specific thresholds set by regulators. This is because what is considered to be suspicious will vary hugely by your product, client base and risk profiles. See our last blog!

On this basis, you need to set limits and thresholds that are unusual for your product and client base, or even individual clients.

For example, if you have two individual clients with different incomes, or who have had differing levels of Customer Due Diligence carried out - you may wish to allow them to transact to different levels. For example, up to £250 before carrying out your Standard Due Diligence. In Ermi, this is set using the “payerPastYearExpectedTotal” and allows you to choose a specific USD amount that a client can send in a single year. Similarly, a daily threshold can be set using “payerDailyTotalThreshold” but this requires you set an acceptable spend on a per client basis.

If you don't have access to per client levels such as this, then a wider and generally acceptable threshold needs to be set, based upon your product, risk profiles etc. If you are a service offering prepaid cards for low-income families, a £100,000 threshold for rules is likely to land you in regulatory hot water.

Another option is to set graded rule levels. A yellow, orange or red (Note, not green… if it was green it passed!) or a numbered scoring system allows you to prioritise the hits you get.

For example, in our rule above we could add the following additional AND line at the end:

This indicates that 4 currencies is a minor review, likely to be a false positive but worth a look still. However:

If the client continues to pay out in multiple currencies, this may increase to an orange alert, or even higher as the activity becomes increasingly concerning.

Red flags would therefore be prioritised as the most unusual activity and clearly a backlog of such alerts should be cleared as quickly as possible. Whereas orange or yellow alerts may be processed later.

Graded rules can also have different monetary thresholds or be based upon the risk of the country being paid. Just be careful when setting such rules that you do not have a 'greater than', 'less than' or 'Equal to' error!

So, now we have an agreed set of language, some basic understanding of rules and the ways we can reduce false positives. If you'd like any help setting these up, please get in touch