The Incremental Approach to Successfully Automating an AML Program

I've been with Jade ThirdEye for over 12 years, helping numerous clients implement and maintain their software smoothly and successfully. Throughout my career, my ideas and approaches have evolved, and in this blog, I want to share the methodologies I currently use. While I'll be discussing these in the context of our software, many of the concepts are applicable to any project—and even to other facets of life. 

For instance, I recently applied some of these ideas during a cycling trip along the Munda Biddi trail in Western Australia with my wife, Chris. Beyond talking about AML, I also enjoy discussing cycling. I believe that sharing stories and analogies can make these theories more memorable. So, you'll hear more about my cycling trip further along in this blog.

In software development, we always aim to deliver incrementally, focusing on what’s needed to go live and what can be added afterward. When automating an AML program, I naturally adopt this mindset. However, I find that many clients prefer to have everything live at once.

This blog is about the benefits of taking an incremental approach to projects, which I hope will inspire you for future projects. I'll start with some theory to explain the concepts, then explore how they can be applied to automating an AML program—or embarking on a cycling adventure.

Incremental and Iterative

Incremental describes the approach of getting one thing done, then moving onto the next and so on. In Jade ThirdEye terms, this means gradually making more of the software live until you have reached your goal.

Iterative means learning from the first increment and using that knowledge to enhance future increments or to improve the first increment.

At the start of any project you may think that you know everything, but you don’t know what you don’t know. Taking an incremental and iterative approach helps you improve your understanding of the problem and achieve a better outcome.

You may have heard the term “inspect and adapt” or a “feedback loop”. The process is that you complete the first increment, then review what you have done and work out how to make the next increment more successful.

I used the incremental and iterative approach on our cycling trip. It was a 24-day trip where we had to take our tent and food with us with chances to resupply every few days. Rather than trying to plan the 24 days, we took it in stages. We planned our food up to the first town after four days and didn’t look further ahead. After those four days we realised we were slower than we thought we would be and we needed to eat more than we expected. So we were able to plan the next four days better and made sure we took more food and especially the kind of food we fancied eating.

Then we broke it down into even smaller increments and each day we worked out where we need to get to that night. Each morning our goal was to cycle two hours, then stop and cook up morning tea. Life’s a lot simpler when you just must look ahead to the next meal rather than the end goal in 24 days’ time.

Limiting the Scope

At the start of any software project it’s common to write down all the things that the software needs to do. People think of everything because they know that adding something in later is usually harder than getting it in scope at the beginning.

It’s better to think of the things that you really need or “must have”. You may have heard of the Moscow rating: categorising tasks or features into must have, should have, could have, or won’t have.

If you start by concentrating on the must haves, you put yourself in a better position to decide whether those should haves get worked on or they get relegated to could haves or won’t haves.

I have worked on several projects where we delivered all the requirements, only to find that many of them were not used or were not what the client intended when they wrote the requirements. In the meantime, there were change requests to add things that were not originally thought of. This approach just wastes everyone’s time doing things that aren’t wanted and makes the software harder to support because it is more complex than it needs to be. It’s better to complete that first increment and then move on from there with the knowledge you have gained so far.

When we set off on our cycling trip, we didn’t really know what gear we would need. Such as, how much warm gear or wet weather gear to take, whether we could get water along the way or had to carry it—so what should we do? One approach is to take everything you think you might need. That’s the must have, should have, could have approach. But then our bikes would be too heavy, so we packed the must haves and a few should haves and made sure the must haves included a credit card in case we learnt that we needed something we hadn’t taken.

Working Sequentially

Let’s say that you have two tasks to do, each of which will take you 10 days effort. If you work on both at the same time, you will get them finished and usable in 20 days. If you work on one then the other, you will get the first finished and usable in 10 days and the second 10 days later. That means that you have got use from the first task 10 days earlier. 
But it’s not that simple. You will have heard of task switching – doing one task for a while, then switching to the other for a while, then back again and so forth. Switching between tasks takes time as you need to get set up for the other task or get your brain back into the other task. When you are multi-tasking, that is effectively what you are doing. You are not doing both at the same time, your brain is switching between tasks.

What this means is that task switching takes time, so the two tasks in parallel approach will take longer than 20 days. The sequential approach will get both tasks competed before the parallel approach and one task will get completed in less than half the time.

I don’t think there is such a good analogy for our cycling trip, although I know that as we travelled together I was slower than Chris so we took longer than if she had gone alone. Luckily we are a good team and she kept waiting for me to catch up.

Planning Ahead

I am an advocate for an incremental and iterative approach to get one thing done and then move onto the next, but that doesn’t mean that you don’t plan ahead. You should have a high-level view of your end goal and the things that you need to do to get there. You should also be thinking about the next increment before you start it. Get a good idea of what you will be doing in the increment, but before you start, review what you have learned from the first increment and factor that into your work for the second increment.

You’ve probably heard this quote from Eisenhower “plans are worthless but planning is everything”. He knew that you needed an overall strategy and a high-level plan to get to your goal, but the detailed plans of how to get there were worthless as they are liable to change as circumstances change.

During our bike trip, we spent some time looking through the whole trip to decide that we should allow ourselves 24 days. Working back we decided on our goal for the first four days and planned for those four days alone. Without the foresight that we needed 24 days, we could easily have taken it too easy at the start and struggled later to catch up, or failed to reach the end.

Small Wins Improve Morale

Everyone likes it when you get a win or something goes well. In terms of implementing software, the real milestone to celebrate is when something goes live and provides a benefit to the users.

Whereas the go-live-with-everything approach only has one deliverable that is worth celebrating, the incremental approach has many. That’s not just milestones in the project but actual benefits that you have made available to your team. Morale is important, so pay attention to keeping your team winning.

When we split our cycling trip down into increments, we made sure we celebrated every few days when we reached our goal. That kept us feeling positive about our progress instead of continually looking for the finish line.

MVP (Minimum Viable Product)

A term that we use to define what to go live with initially is MVP or minimal viable product.

• Minimum means the smallest thing possible
• Viable means a thing that has a clear use or benefit
• Product means the thing we are talking about

Combining these, an MVP is the smallest thing that you can create that is useful to your users. It is ideally a stepping stone towards your end goal. This might be a completed feature or it might be something that is useful and also increases your learning so that you can make better informed decisions about the rest of the project.

When we are thinking about software, it’s a feature that has some use when you make it live.

Software usually has many features. Each of these features could be useful on its own, so an MVP could be one of them rather than all of them or an MVP could be part of one of these features.

Working towards an MVP enables you to get an early benefit from your program. Rather than waiting until everything is finished before you go live, get something small live and start to receive the benefits.

I want to be clear about what MVP means as it can get misinterpreted or perhaps deliberately abused. What is doesn’t mean is the least you can get away with before you move on to a new project. What it does mean is the least that you can deliver that is useful on the path towards an even more useful outcome.

On our bike trip our MVP was to get to the first town in four days. This was the type of MVP that was a step towards our goal and also provided us with learnings. We learned a lot that helped us to adjust our approach and made reaching our destination more certain. Our biggest learning was that we needed some easier days to recover and we needed to carry more food or we would run out of steam before the end.

Risk Mitigation

Breaking a project down and frequently delivering small increments to the users reduces the overall risk of the project going off the rails. With small increments you can spot issues and adjust to compensate for them quickly throughout the project.

Whilst cycling through Australia, one of the risks is encounters with snakes. As I’ve already mentioned my wife was faster than me. As the person in front is more likely to be the one that encounters a snake my slow speed was a good risk mitigation strategy. I only saw one snake on the whole trip and that was one of the few occasions that I was in front.

Implementing an AML Solution

Our software has three components: the processing of alerts and cases off the back of transaction monitoring, reporting to AUSTRAC for SMRs, TTRs, IFTI-Es and IFTI-DRAS, and customer screening against a watchlist for PEPs and sanctions.

How can we break down software implementation into increments, and what do we mean by an MVP?

Customer Screening

The key to getting a good output from software is to get the inputs right. In this case it’s information about customers, their accounts and transactions.

Screening customers for PEPs and sanctions against a watchlist only needs data about customers and in fact only needs a subset of all the information that you might hold about a customer.

Getting that subset of data sorted is a simpler step than getting all data sorted at the same time.

Customer data is constantly changing. You continually sign-up new customers or there are updates to existing customers. These updates need to be run through the screening process as soon as they occur, or maybe once a day. This is more complex than screening the original fixed state of all your customers, which you could look at that as a second step.

You may not want to go live without being able to screen updates. If so, your MVP is after you have got the updates working, but you can get to that MVP incrementally. Do the bulk customer screening first, then move on to screening updates.

Monitoring Customer Data

What about transaction monitoring? Transaction monitoring is a bit of a misnomer because it really means monitoring all the behaviour of your customers not just transactions. Nevertheless, I’ll go with that term.

Whilst you are loading customer data you can look at transaction monitoring rules that only look at customers. Analysing customer data might not lead to submitting an SMR as readily as analysing transaction data, but it’s often an early indicator that a customer may be high risk.

Let’s say we decide to go live with customer screening plus transaction monitoring for customer data. Do we need to get all the customer data rules running?

If you can get them all created and tested without delaying the go live of the rest of the system, then maybe go for it. However remember that doing two things in parallel delays them both, so be careful what you think you can achieve. Otherwise, concentrate on the customer screening or just get some rules running.

The whole AML regime takes a risk-based approach, so use a risk-based approach to decide which rules to go live with first. You might decide that identifying high-risk customers is the priority. Alternatively, you might decide that your data is not as good as it should be which exposes you to missing things you shouldn’t, so create rules to help with data quality. They are your risks so you should decide what to do first. The message here is to get your priority clear and work on that priority first.

Monitoring Transactional Data

Getting transaction monitoring going to pick up suspicious transactional activity is much harder. To start with, there is a lot more data to wrangle into shape to get good outputs. Then there are probably a lot more rules that you want to set up to address your risks.

Getting any rule set up, tested and thresholds tuned is not a quick task, especially when you want to run it over data each day to check that it works correctly before committing it to live.

When a rule does go live you need to keep a close eye on it for a while to make sure it is working as expected or needs tuning.

This leads me to suggest to my clients that they should start with a small subset of their rules, get them working smoothly, then incrementally add more rules.

I had one client that wanted to go live with over 40 rules. They tested them on test data and did some testing on live data. But when they made the whole lot live on the same day they got flooded with unexpected results. Live data has lots of idiosyncrasies that test data doesn’t, so you should expect it to throw up situations you were not expecting. That client had so many things to look at that they didn’t know which way to turn and spent the next few weeks trying to get things back on track.

If you have that many rules, break them into several increments and deliver the highest priority rules first—your minimum viable rule set.

It's not just getting the rules to give you the outputs or alerts that you expect to see. The next step is what to do with those alerts. Each rule will lead you to looking at the customer’s data in a different way. Your team needs to understand what each alert is showing, what they need to do to decide about whether the alert is suspicious or not, whether the alert needs to be escalated into a case for further investigation and how to record their decisions. That also takes time to become familiar with. Once again, starting with a small set of rules makes the task much simpler.

Reporting to AUSTRAC

Once you have alerts that you find suspicious you will need to report them to AUSTRAC. We automate that process taking client data into the format AUSTRAC mandate and sending it to AUSTRAC Online. That process is straightforward once you have good data in the system. However, AUSTRAC require you to go through a testing process with them so that they are comfortable that you can submit quality SMRs. This process typically takes several weeks, so how does that fit with the incremental approach?

You may decide to go live without SMR automation. You can submit SMRs by logging into AUSTRAC online, so automation isn’t a must have to go live.

However, if automation of SMRs is your priority objective, you should rethink the approach to get that done earlier than some other parts of the solution.

Continuous Improvement

So now you have gone live in increments, and you have achieved the outcomes that you wanted, now what?

Nothing stands still in our world: your business changes, regulations change, criminals develop new typologies, your IT systems change. All these things mean that you need to keep reviewing your solution to ensure it is detecting the things that you have identified in your risk assessment and is not giving you too many unnecessary false positives.

If you identify several changes, think how you will approach them. I like to follow the same process as the main project even though the scale is smaller. Take one rule at a time, address its weakness, test it, make it live and check it’s working well. Then move on to the next rule.

Key Takeaways

To summarise, the key takeaway is to consider how you can deliver useful benefits to your users incrementally throughout a project, rather than in one big delivery at the end.

Like all successful projects, this one had a happy ending. We completed our bike ride a day ahead of schedule, feeling a real sense of achievement. We followed our initial high-level plan, adjusting as needed, but most importantly, we enjoyed ourselves and celebrated our small successes along the way.