AML Rule builder… how to up your game!

Are you a rule builder (or scenario developer or rule developer)? If yes, then you should be proud of yourself as you are one of the most important pieces of the puzzle in any FI’s fight against criminals. If your are not one of these gems you may or may not have heard about them…Think about it this way. Automated rules developed by rule builders lead to generating correct signals (finding needle in a haystack), helping in identifying customers who might expose your FI to a money laundering risks. Sometimes rule developers can get so deep into the “how” part that they may miss the bigger picture. In this article I would like to address how to up your game! Even if you are not a rule developer, depending your role in the AML/CFT space, this article will share insights which you can complement with your expertise and help your rule builder team.

Involve the investigators

This is one of the mistakes I have seen happen too often. Rule builders are mostly facing testing teams to get validation of the developed rules. I have, on the other hand, advocated active participation of investigators in the rule development process and not just towards the end for sign-off. In most cases rule specifications are outcome of some great ideas, which are just ideas. It’s OK to develop per specifications, however with active feedback from investigators, you can fine-tune these requirements to meet the real life needs! After all you want to catch criminals so better fine-tune the idea rather than complain about false positives later. If your organization does not promote such culture, try explaining this as a necessary step. You will be surprised by the positive impact it can bring. I can imagine some rule builders sit at the vendor side and it may not be possible to meet investigators. Still FI’s should find a way to collaborate with vendors in this key area as it will help them in the long run.

Time-bound feedback

Sometimes you can get carried away with great insights from your investigators. You need to time-bound the feedback cycle. It’s important to listen to feedback and give another try and re-write your rule and try again. However you need to box it otherwise you will get carried away in getting the perfect rule, which never exists in the AML space. In my other post comparing Fraud to AML, I have argued that AML space is too grey as there is no definite method to confirm money laundering. This is the reason you can never claim to get the perfect result, leading you to a never ending feedback loop. The best way is to move on, get your code live and after a specific time, get real-life feedback from your investigators and improvise. So be pro-active even after you rule is live. It’s an always evolving process.

This brings me to an important point. Keep on learning as much as possible. Just because you are developing technical rules, does not mean you should be far away from the content. I strongly believe that your role is not just of a technician and develop code, but far greater than that. Unless you understand the nitty-gritty world of money laundering, you will not be able to develop better rules. Always have the curiosity running inside you, why do money launderers do what they do and how… Trust me, after a while coding will become secondary.

The bigger picture

Being a rule developer, you will probably be a technology enthusiast and know the best tips and tricks for covering the “how” part. However spend a bit of extra time on the “why” part too. You may be given a specification to implement but always try to dig deeper in finding out why this rule is important in the first place. It may change your perspective in implementing the rule altogether. Let me give an example. Let’s say you are asked to develop a pass-through rule which looks for rapid movement of incoming vs. outgoing funds. On digging deeper, this rule is supposed to help investigators find out unknown countries popping up in the customer’s profile and movement of funds through these countries. Such information will help you in developing a much smarter and targeted rule. Try to think like a criminal and find out how best you can address the challenge.

Add as much meaningful info as possible

You may develop one of the smartest rules, reducing the false positives by 90% but if your alerts do not make sense to an investigator (without referring to the rule specification over and over again), this rule has failed its purpose. You have used all the available data points to come up with an alert. Now try adding a brief story line (using all these data points) and display it to the investigator. He/She should be able to, in an instant, identify why this alert is important (or may be not). Such a small change will take you a long way in easing the life of investigators. Hence think like an investigator and try to find out what you would like to see and just do it.

Common mistake - deviation

This can be something very controversial which I will suggest here. There is over enthusiasms in using AI/Machine Learning etc. in detecting the odd ones out. Several algorithms are used to detect this “deviation”. However try thinking like a smart criminal. It’s not always about deviation. Don’t underestimate what you will find out exploring just consistency. A customer showing too consistent behavior is as odd as the ones who deviate significantly.

Audit trail

I know this is obvious. No matter how good the rule is, a regulatory visit will dig deeper into your audit trail. This is one of the most important things to be mindful about. Who did the change, what was the change, when was the change performed and all related information is a must have in this domain. It not only helps you back-track any unintentional change, but most importantly brings transparency. Such pieces of information gives confidence to your organization while facing regulators. If your tool does not have audit trail feature (which will be odd in the first place), try to add an extra procedural layer for audit. You can thank me later 😉.

Data is your playground

Last but not least, you have access to all the possible FI data you could have (if not, try getting access!). Give yourself the opportunity to mine this data and identify patterns which you think can sound suspicious. It ties back to the “keep evolving” tip I gave earlier. You should never limit yourself to just the rule specifications. Investigators will appreciate if you share ad-hoc insights with them, based on your analysis. It can open up new possibilities. Recently I wrote an article on "bad data". Your exploration can help your organization in fixing the so called bad data much before something goes terribly wrong.

All points I have listed above come from the experience I have gained in this space over several years. At some point in my career I was responsible for developing rules/scenarios for AML detection. I have seen almost the full spectrum of AML Transaction Monitoring - Risk assessment to defining TM rules - developing rules - training investigators - reporting SARs. What I have tried here is to summarize this experience, specifically for the rule builders, as it helped me get things right. In my training courses to the rule builders, covering these topics extensively, I have noticed a major positive shift in the thought process. If you are not already thinking on these lines, I will highly recommend you start doing so.