What is transaction monitoring?

Ermi is a transaction monitoring system, what even is that?

At a high level, transaction monitoring is a tool for detecting suspicious or unusual activity in financial transactions, which may be indicative of money laundering or criminal activity.

The requirement to monitor for and detect such activity is a defined requirement appearing in nearly all Anti Money Laundering regulations around the world, including both the UK in (S28(11) Of the MLR’s) and EU (Article 13(d) of the 4th MLD) which defines it as

“(a) scrutiny of transactions undertaken throughout the course of the relationship (including, where necessary, the source of funds) to ensure that the transactions are consistent with the relevant person’s knowledge of the customer, the customer’s business and risk profile;”

In Canadian regulations, Part 5, 123.1(d)

determining whether transactions or activities are consistent with the information obtained about their client, including the risk assessment of the client.

And in the USA, the CDD Rule, which amends the Bank Secrecy act, requires firms to

“conduct ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information”

It appears simple enough then, conduct Customer Due Diligence (CDD) on your clients and then monitor their transactions to make sure they are doing the right thing.

However, the devil is always in the details when it comes to compliance requirements and the JMLSG Guidance for the UK provides us with some extra practical context on what transaction monitoring systems actually do:

"There are many automated transaction monitoring systems available on the market; they use a variety of techniques to detect and report unusual/uncharacteristic activity. The systems available are not designed to detect money laundering or terrorist financing, but are able to detect and report unusual/uncharacteristic behavior by customers, and patterns of behavior that are characteristic of money laundering or terrorist financing, which after analysis may lead to suspicion of money laundering or terrorist financing”

In short, a transaction monitoring tool is not able to say:

"This client appears to be a drug dealer,”

However it can say:

“This client has an unusual transaction pattern, which is outside of the normal”.

So, what exactly does a transaction monitoring system need to work?

• Have access to all the transaction data - to spot outliers, a system needs to be able to see all the transaction data and information.
• Be able to compare and contrast one client’s transactions with another, and a client’s own transactions to their own historical transactions and KYC data
• Operate on a risk sensitive basis
• Have a series of defined rules or alerts that can be configured to spot outliers or unusual transactions
• Be able to explain those outliers and why they have occurred
• Keep a record of the alerts raised.

Frequency, Manual or Automatic?

Transaction monitoring, like most AML controls, is risk based. The level, frequency and rules required are dependent on the risk of your product, but also the volume of transactions and the risks associated with your clients.

A firm with a small number of clients with a large number of manual touch points or face-to-face interactions to place an order can rely upon a manual system, whilst a high traffic system with little or no human intervention will need an automated system.

JMLSG guidance gives us further clarity:

“A monitoring system may be manual or may be automated to the extent that a standard suite of exception reports is produced, or it may be a combination of the two. One or other of these approaches may suit most firms. "In firms where there are major issues of volume, or where there are other factors that make a basic exception report regime inappropriate, a more sophisticated automated system may be necessary. Where manual monitoring is in place, firms should have procedures to manage the risk of manual error’”

It is clear is that if a firm chooses a ‘Manual’ Process - then like any compliance process, this needs to be clearly documented, defined and evidenced to ensure it is actually happening with QA processes and testing.

Real Time or Post Event?

Interestingly the regulations and guidance do not mandate that transaction monitoring systems must be in real time and prevent transactions from being processed which have flagged.

Instead they allow for reviews to be post event. The guidance spends more time concentrating on the effectiveness of the rules (More on rule creation soon!) and the capabilities of the firm to address those results.

From the JMLSG Guidance:

“The effectiveness of a monitoring system, automated or manual, in identifying unusual activity will depend on the quality of the parameters which determine what alerts it makes, and the ability of staff to assess and act as appropriate on these outputs. The needs of each firm will therefore be different, and each system will vary in its capabilities according to the scale, nature and complexity of the business. It is important that the balance is right in setting the level at which an alert is generated; it is not enough to fix it so that the system generates just enough output for the existing staff complement to deal with – but equally, the system should not generate large numbers of unproductive alerts/‘false positives’, which require excessive resources to investigate”

If we look at the 2023 fscom Audit findings report, which details the most common failings they saw across the industry, we see their findings more often concentrate on the number of rules, the manual nature and the backlog and investigation, with a small number of issues relating to the retrospective nature of the process.

This shows that in some cases, depending on your firm's business model and products, retrospective monitoring may not be suitable; however, if properly managed and with the right rules and alerts in place and sufficient resources, there is often no reason not to use retrospective monitoring.

It is also worth considering how retrospective the retrospective is. Monitoring at day end may be appropriate, monthly, or conducting monitoring only during your KYC refresh programme is less likely to be appropriate.

Summary

In short, there is a legal requirement for your firm to have some sort of ongoing analysis of your client's transactional activity in order to detect potential red flags and suspicious activity.

This process can be manual, with sufficient controls in place. Automated monitoring will naturally be easier to prove to your regulator, auditor and banks, it is more likely to meet your obligations and be able to carry out complex analysis of your client transactions. However as the JMLSG notes:

"The implementation of transaction monitoring systems is difficult due to the complexity of the underlying analytics used and their heavy reliance on customer reference data and transaction data” - And so if your systems are disconnected and - but in all cases the rules of the system will need to be risk based and sufficiently robust, based upon the risks of your firm and products.

Finally, once your system has generated alerts, these will need to be reviewed and actioned in a robust fashion with a clearly defined process for accepting or investigating these reviews, and you will need to fully document your system, the rules and how alerts are handled.

Where next?

This article is the first in a series. Read part 2, Getting transaction monitoring rules design right next, or "Follow us on LinkedIn to get updates for future posts.

You may also enjoy Mike's Rant on building a fair package for startups.