Getting transaction monitoring rules design right

As a business founder or an MLRO looking to set up and tune your transaction monitoring system, it is often hard to know what rules you need to detect suspicious transactions, catch criminals and meet your regulatory obligations.

These days, AI is all to often seen as the solution. The suggestion is that you can just let the world’s most cutting-edge technology step in and do the legwork for you to solve all of your problems.

There is an issue here though. AI systems can require billions of pieces of data to effectively train them. So, what happens if you are a new company with no existing transactions or transaction monitoring system.

What are you going to train AI with?

It is important to bear in mind that as part of your submission to the FCA, you need to tell them what rules you have - before you have the data needed to train your AI. Maybe then we need to rethink letting AI decide our fates.

Fortunately, transaction monitoring rule design isn't all that complex. You just need a lot of context about your systems, the services you offer, who you offer it to, what the financial crime risks are and how a criminal might use your systems for nefarious purposes; then you build rules to detect activities that are outliers to this.

For those you in the UK - The Money Laundering regulations at S18 (For those in the EU, Article 8 of Directive 2015/849) require that the MLRO or founder conduct these assessments already:

Risk assessment by relevant persons

18.—(1) A relevant person must take appropriate steps to identify and assess the risks of money laundering and terrorist financing to which its business is subject.

(2) In carrying out the risk assessment required under paragraph (1), a relevant person must take into account—

(a) information made available to them by the supervisory authority under regulations 17 (9) and 47, and

(b) risk factors including factors relating to—

(i) its customers;

(ii) the countries or geographic areas in which it operates;

(iii) its products or services;

(iv) its transactions; and

(v) its delivery channels.

So, let's look through these assessments and consider how this can help create a ruleset for your transaction monitoring system.

Customers

Customer risk in this context is not about trying to assess a customer on a Low, Medium and High-risk basis for your AML Risk scoring. It is trying to assess whether your individual customer attributes create any specific risks that you can monitor, or expected behaviours to monitor against.

For example, let’s consider the expectations of a client based upon the KYC (Source of funds, source of wealth, age and location) which we obtained when we onboarded the client.

For example, a client who is:

• An individual, overseas student staying in the UK.
• With a student loan
• A monthly income a from their parents
• Living in student accommodation
• Using our Foreign Exchange product

Then:

• You might only expect a limited number of senders to this account, likely from the student’s parents or their own account.
• The inbound volumes through this account would be relatively low in terms of total volume and number of currencies used.
• The lifespan of this account is likely to be 3-4 years before the student goes home, not 10 years.
• The student’s outbound payments are likely to be University fees, rent, and groceries, not hundreds of outbound payments in multiple currencies.
• Rules for this client type should take into account the expected use case of this group and monitor for any oddities based on this - for example:
• The total number of senders who pay into the clients account should be low
• The total number of currencies used by the client should be limited to 1 or 2 (Their home currency and the currency of the country where their university is)
• The total volume of all transactions for this client would be moderate each year, as international student fees are high.
• The account should not still be in use after 4 years unless your client has been through KYC again to change their profile.

This means a ruleset needs to be created that is specific to this cohort or base of clients.

Having a single set of Transaction Monitoring (TM) rules that cover both corporate and individual client base, or trying to monitor student clients in the same way as international pensions clients with the same rules clearly wont work and it will result in a lot of false positives.

This also means some sort of marker, or method for identifying and running these different rules is needed. How the capabilities of the product impact the rule also needs to be considered - more on this below.

Countries and geographies

For countries we need to consider the location of the client as well as where they are sending payments to. This is because what is considered a high risk country from the UK might be different to what is considered high risk by European Standards. We may therefore need to have different country risk lists, driven by client location.

We also need to consider that some countries have a list of defined high risk third countries that require Enhanced Due Diligence (EDD) on all transactions. This means we might find that a very strict approach is needed, with a rule that flags every transaction involving these countries.

Geographies are smaller than whole countries. If for example you operate in a country that borders a higher risk or prohibited country, then there is a risk that funds are going to be sent to the lower risk bordering country and then cross into other countries.

Smaller geographies may also be useful as a way to consider the expected income and spend of your client. If you have someone living in a hugely deprived area with an average income of less than £15,000, but spending £100,000 a year - this might be an indicator of a risk.

We also need to be realistic about the client base. If your core product is sending transactions to Afghanistan, because your client base is primarily Afghani expats… then flagging every transaction to Afghanistan may not be useful and a specific threshold based on expected use may be more appropriate.

When building rules, we need to consider the geographies we might be paying, what the product is intended to be used for and how we monitor transactions to those riskier countries.

This may result in us applying specific rules to certain client groups or setting expectations for corporate and individual clients that reflect a normal use for those countries.

Products and services

Understanding the AML or Counter Terrorist Financing (CTF) risk of your products is core to building a control framework to detect money laundering.

If your product has zero risk of money laundering (quite the achievement!) then your monitoring can be correspondingly light, whereas if your product has loose controls or has attractive features such as anonymity and limited KYC, then clearly this will require more in-depth monitoring.

Where offering multiple products, then it is important to consider the different levels of monitoring which will need to take place for each product.

Ask yourself, what it is about your product, the specific features that make it attractive to criminals? Does it allow payment to locations that pose a specific risk, or is there a route to anonymity which criminals may want to exploit, Or does the product allow multiple third parties to easily send funds to it. Or has very limited due diligence been carried out which allows impersonation?

Monitoring rules should recognise all of risks. If you have a higher risk product, your monitoring of the products should be more stringent and have tighter thresholds. If the product favours anonymous, monitoring should flag when the Simplified Due Diligence (SDD) threshold is reached.

You also need to consider the practicalities of your product in monitoring transactions. If our product offers a Foreign Exchange service, it is essential to consider how transactions will be compared against each other in a single currency and ensure the rules are effective.

The MLRO should be able to clearly show how the product risk assessments have fed into the rules of the monitoring tool.

Transactions

Transaction risk seems like it should be considered in the most depth, given the subject matter. However, it is clear from the above that elements other than just the risk of the transaction must be considered when designing your monitoring approach.

The expected usage of the product, expected average transaction size and client risks also need to be fed into the overall assessment of the transaction. For example:

• If the product is designed to target younger users, such as pocket money accounts, then we would expect transaction limits to be low.
• If the product is designed as a limited access savings account, we would expect a low volume of transactions.
• If the client base has a range of risks and we have a range of products, then we should have different transaction levels and thresholds by product.

Once the overall risk has been considered, then transaction values and frequency, as well as the method of settlement and timing of the transactions, should be considered in terms of the risks posed and the type of monitoring needed.

For example, if multiple transactions appear to be structured to avoid reporting thresholds, or to breach limits on the account, these should be flagged.

Similarly, if there is a possibility for multiple transactions by multiple clients to be paid to the same beneficiary (Structuring) then the risks of this should also be taken into account.

Rules in this space would therefore typically look for:

• Transactions that are outliers from your Average Transaction Value (ATV) or the expected usage of the product
• Transactions that are outliers from the normal usage of the product by clients, e.g. multiple times higher than the clients own ATV
• Transactions that are to the same beneficiary account by multiple clients on the same day/week/months etc.
• Rules that consider inbound, as well as outbound transactions, such as ratio rules which monitor the number of pay ins versus payouts

More advanced transaction rules can also “score” a transaction - taking into account a range of factors, such as the total value, location of the client and the clients AML risk and ATV. Such scoring methodologies should be well documented and clearly defined.

Delivery Channels

Delivery channel risk will vary depending on whether you allow multiple methods of engagement with the client and how that interaction looks.

If you have an inbound calls process, a face-to-face process, or a callback process which allows you to engage with clients and ask them additional questions during the process of booking or arranging a transaction, this might allow you to reduce the level of monitoring needed.

However, if you do rely on such a process, then you need to consider how much interaction and what checks, If any, take place during this interaction. Are front office staff trained? And is there a process to ask additional questions for larger transactions? Or where the transaction is to a higher risk country? If staff are merely doing data entry or order processing, then this might not provide you any extra comfort and your transaction monitoring process should not get easier based upon this.

Similarly, whilst JMLSG Guidance now states that non face-to-face does not ALWAYS imply high risk, you should consider how good your online platform is at asking additional questions or gathering additional documentation. If you have a default process for getting documents over a certain value, this may mitigate your risks. If you treat all transaction bookings in the same way, then this wont help mitigate or reduce the level of monitoring needed.

Some considerations in this area then are:

• How much Customer Due Diligence / Enhanced Due Diligence was done by your team when booking the trade?
• Have you ever met the client and verified their ID and Business?
• Are there any limits or thresholds in place in your systems to require more due diligence for certain deal sizes or routes?

Monitoring can then reflect this based upon the the delivery channel or any controls used.

Summary

Admittedly we haven't given the exact details of any rules here, but once you have carried out this exercise, you will have met both your regulatory obligations under S18, and hopefully identified some of the gaps or risks in your product and services, which you can then fill with appropriate monitoring.

The next core step is to consider how much data you can actually pragmatically get to a transaction monitoring provider. This may seem counterintuitive, but it is a practical approach to the problem.

There is little benefit in trying to write 30 transaction monitoring rules that consider the clients age, or AML risk score… if this data is in a CRM and not stored in a system that can be accessed by your transaction system or shared with a transaction monitoring provider.

This data can then be mapped to, and used to write rules, which mitigate the above risks. We dive into that further, in part 3.