Internal consistency, KYC and Expectations in Transaction Monitoring

When we think of transaction monitoring (TM), it’s often thought of purely in terms of rules that detect a change in client behaviour.

For example, a client is onboarded and begins trading £500 constantly every month for a year, then they send a payment for £4,500… that’s odd. Or a client sends payments to Spain for a holiday home, then switches to Italy… why the change? Or a client that always got paid their salary each month and then paid their utilities is now paying 30 different individuals each week?!?

We refer to these at Ermi as internal consistency changes. Where the client was always consistent and suddenly changed behaviour. It is odd, so we flag them.

These sorts of rules work well when a client is compromised, or a corporate company is taken over, or becomes criminal but working only with these sorts of rules will miss things. For example, if your client had been criminal ever since you onboarded them, their behaviour would be consistently criminal and these rules won't help.

This means internal consistency can’t be the only type of transaction monitoring; it comes in multiple different types. In this article, we will explain some of the other types so you can explore the different options.

Normal for us

And by us, I mean your firm.

What is the expected normal for your firm and your product? When your founders, CEO or product team set up the product, what was it for and what is the expected usage?

If it is a savings account, you would naturally expect a large number of inbound payments and a small number of withdrawals. If it is a regular saver product, you will see more monthly payments in, while a one-off saver account will have a more up-front lump sum payment and then irregular inbound payments.

For savings, we would expect to see most payments coming in from the named account holder, because that individual is the person choosing to put money aside each month etc. We would not normally expect to see multiple other remitters paying directly into the account. Therefore “normal for us” here would be to see a small number of remitters (< 3 perhaps) put money into savings products. It would be odd for someone to have 10 people pay into that account.

When creating rules for a transaction monitoring system, we need to build rules that define our normal and expected behaviour and then look for outliers from that. These outliers may suggest criminality and use of your product for an unintended purpose; but it may also be a feature of your product you didn’t realise!

To establish these, you should work with your product and marketing teams during the product's rollout to define your expected usage, or with your data teams internally once the product is launched to examine what is normal for your product and then to monitor it accordingly.

Normal for our client base

The next thing to look for are instances where a small number of your clients are outliers from the rest of your client base.

Again using the example of a savings account, if your product is targeted towards clients with a lower income and most of your customers are in that category, we would expect to see moderate savings in the accounts. It would therefore be odd if one client was using your product to save tens of thousands of dollars or pounds.

This is a relatively simple task to look over all the transactions of your client base for a single product, identify the average values and usage, and then set simple thresholds for outliers. This is often not included in transaction monitoring however because rules are typically set at a per client level, not a product level.

It can also be difficult to do if your products aren’t clearly delineated, or if multiple customer segments use the same product. For example, in our savings account example, bank systems may have one “savings” category, which is sold under multiple brands to different users. If a monitoring system does not know that high net worth and normal consumers are under the same broad category - then we would see many flags of higher spend customers.

We need to ensure that systems have enough granularity of information so that monitoring is effective.

Normal for subsets of our client base

This means a group can be the entirety of the product, including all of your clients, as long as they are broadly similar.

If however, your product category is “all holders of a current account with our bank” then it is likely you will need to find some way of narrowing this down using other data you have about your clients, such as industry, income, location, age etc.

You may also want to specifically assign your clients to peer groups or cohorts to allow you to specifically assign thresholds and rules that only apply to that group.

For example, you may assign clients to a domestic payment only group and then flag any international payments, or to an EU cohort and then flag any international payments to Asia. You could also create an industry group called “Newsagents / Cornershops / Bodegas” and assume that the majority of these firms buy their products from a local wholesaler and have limited or no international exposure, or a group called Online E-tailers, with entities that trade only using electronic payments, no cash.

The key to defining these groups is that once created, you need rules that cover their different behaviours and a way for your monitoring system to know which groups and which rules to apply.

Normal for your client - and why that's not just about internal consistency

The JMLSG notes that:

In designing monitoring arrangements, it is important that appropriate account be taken of the frequency, volume and size of transactions with customers, in the context of the assessed customer and product risk.

When you conduct Know Your Customer (KYC) checks on your client, you learn a lot about them. Their income from private clients, their turnover for corporates etc. which allows you to create a profile of expected behaviours. If a client's total income per year is their student loan, then their expected turnover should reflect that. If they have a single supplier overseas, we can also build rules around that.

You can use this information to assign clients to a peer group (retail clients with low, moderate or high income), or to set individual client limits, for example an upper threshold of spend limit which is assigned to the individual client. The downside of this is that your KYC Analysts will need to assign individual client rules, and a lot of monitoring systems don't allow that. The plus side is that many of the modern KYC tools will automatically set up groups like this.

When we operate these rules, we call them client expectation rules and they include elements such as the client's expected spend or volume for the year, currencies and countries. This should be monitored across all currencies, transactions and products.

Summary

Effective transaction monitoring means building rules that do more than just look at averages. It is important to consider not only the change in behaviours of clients, but also what the product is for, how most customers use it, what is expected from the client and how we clients are grouped.

Failure to do this will result in a limited monitoring program and a risk of nefarious activities being missed. It's definitely worth taking a look, at least annually, at all of your rules and considering if you have taken into account the product design, examined your normal product usage for the past year and looked at how your KYC flows into your transaction monitoring platforms so that you achieve the best results.