We Addressed Our Anti-Money Laundering Duties With Scrum
And transformed from problem child to best in class on AML
And transformed from problem child to best in class
There aren’t that many articles that tell a true story of how Scrum helped to bring value. This is why I decided to write this article. It is a tad long and may not have many twists and turns. But it is an account of how we succeeded to solve one of our major problems. I hope you enjoy it and it may be of help.
My company is a financial institution facilitating online payments. Daily we process millions of them. It is critical to be able to prove our payment processing is secure and we prevent criminal misuse of our product. A financial institution that isn’t secure or doesn’t take cybercrime seriously has no reason to exist.
You may know financial regulators have created compliance rules protecting customers, investors, the economy and society from financial crime, market manipulation, ethical threats, and systemic risk. These rules range from protecting personal data to preventing malicious practices.
One of the big topics these days is online money laundering:
“Money laundering is the illegal process of concealing the origins of money obtained illegally by passing it through a complex sequence of banking transfers or commercial transactions. The overall scheme of this process returns the “clean” money to the launderer in an obscure and indirect way.” — Oxford English Dictionary
The digital age comes with all kinds of opportunities for people with bad intentions. This is also true for money laundering. It’s a big responsibility of the financial institutions to fight this. They are in a rat race with the people with criminal intent. The possibilities to conduct online fraud are growing each day and companies have to respond every time.
When a financial institution fails to comply with the rules, the regulators can pose hefty penalties. But apart from the financial pain, there may be criminal charges (in case of proven lack of compliance) and reputational damage.
Currently one of the major banks in the Netherlands, ABN-AMRO, is in the news because of its failure to enforce Anti Money Laundering (AML) policies. The bank received a fine of 480 million euro. 3 former directors of the bank are identified as suspect, possibly facing prosecution. The reputational damage for the bank is perhaps even bigger than the fine.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fbb7d0c1c-1ef8-49f0-b52d-af77485713a1_800x533.jpeg)
The call for action
After this brief explanation of Anti Money Laundering, let’s return to my company. A few years back, we were in a pickle. The Dutch regulator had informed us we needed to step up. Our AML measures were insufficient. We weren’t doing very well and the regulator wasn’t happy. It demanded quick improvements.
We were far from the only institution with this problem, but that was no consolation. We could not afford the fine, let alone the reputational damage.
The potential damage of our money laudering issues was big — we were at risk to be out of business.
You'd think this is such serious stuff that our company would immediately invest in a solid AML solution. But it still took our director of Risk Management blood, sweat and tears to ensure it was addressed immediately.
In many organisations, it’s difficult to get priority for initiatives to minimize damage. Often initiatives that promise additional revenue get the preference. This has always baffled me.
I’ll inform you here and now our director of Risk is one of the heroes of the story. She achieved what many of her peers didn’t. Just google ‘AML fines’ to understand what I mean. Not every company took anti-money laundering seriously.
Off-the-shelf or Do It Yourself
The first thing to address was whether we could buy an off-the-shelf product to solve our issues. But we found major downsides to that:
These were expensive.
They needed to be tailored heavily to connect to our systems.
They weren’t proven solutions.
They didn’t cover all our needs.
Our software developers were convinced they would be able to build it themselves. They knew what was needed to be compliant. Those rules were clear enough. The developers were confident they would be able to do this way cheaper than the off-the-shelf alternative.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ffae5ff04-49d9-4286-ba00-6b759b819f9b_800x376.jpeg)
Starting with the team
The director of Risk had a clear vision: within a year our company needed to be compliant with all AML regulations. This was what she agreed upon with the regulator.
Now it was time to form the team. It just so happened that I was the Scrum Master of the team with the people who had the skills to build the AML solution.
This was a team of 8 people working on a different product. Considering the importance of AML, we made the decision to split the team. Half of the team would work on AML and the other half on the other product. Both teams had all the skills required to create and maintain their products.
The director of Risk was our de facto Product Owner. Someone else had this title, but he was basically helping to manage the Product Backlog and suggesting the best approach to reach the vision. The director of Risk truly owned the AML product. She owned the vision. She was in contact with the regulator, future users of the product and management. On top of that, she was in close contact with the team.
I was the Scrum Master. My job was to help the team to make the most of the Scrum framework, optimising the chances to reach our goals.
The first Sprint Planning
Our kick-off event was a first Sprint Planning that took about 4 hours. Our director of Risk kicked off with the vision, including the due date to accomplish this vision.
AML has many facets. There are all kinds of ways for people with criminal intent to ‘clean’ their money. These all require a different kind of response to be able to detect it. We needed to incorporate all these responses.
On top of that, regulators have sanction lists that include details of those who are put under financial sanction. As an internationally operating company, we need to take into account sanction lists of many countries. They all required different ways of screening and reporting.
To create a total picture of the work at hand, we did a story mapping exercise. First, we identified all the things we needed to realize. Then we discussed the most appropriate order of addressing them.
Our director of Risk pointed out that the first we needed to do was to address the sanctions lists, starting with the Dutch sanction list. After this, we’d needed to focus on the different ways money laundering can take place, defined by detection rules. After two energizing hours, we had created our first Product Backlog in the shape of a Story Board.
Now we discussed what we should achieve in the first Sprint. As determined earlier, we would focus on sanction list screening. There were a lot of technicalities to tackle. All sanction lists had different formats. Also, we work with many payment types. The way we store customer data varies per payment type. This made the work complex.
We decided the most important thing in the first Sprint was to see how we could best tackle the sanction list technicalities. We asked the regulator how the reports should look like and their response was: “show us your report and we will provide feedback”. This meant it would be a discovery. We decided to set the following Sprint Goal:
Create a Proof of Concept of daily sanction list screening and reporting.
The team would aim to have a working product ready in two weeks. We added one Product Backlog Item to the Sprint Backlog. It was simply titled: “Create a working first increment of the sanction list screening application”.
The first Sprint
The team had a clear Sprint Goal and that led to focus and commitment. They had an enormous drive to prove they could build this solution. It took them only a couple of days to have a rudimentary version.
But they constantly bumped into issues. As an example, they had to decide when a name in the payment files matched with the sanction list. But they had many more issues to solve. They needed the rest of the Sprint to have a solid piece of functionality.
Nearing the end of the Sprint, they reluctantly told me they were afraid they wouldn’t be able to make it. That they would fail the first Sprint. I responded this would be alright. The goal, to create a Proof of Concept, was ambitious. And even if they wouldn’t meet the goal, they would have learned a lot. They could share their learnings at the Sprint Review and discuss how to proceed.
Then I argued that even if we would come to the conclusion we couldn’t do this at all, this would be valuable. We could then end our own efforts and buy the off-the-shelf solution.
For some reason, after this, the team had renewed focus. They realized they had drifted from the Sprint Goal. They were adding things on top of the Proof of Concept that didn’t serve the purpose. After a course correction, they managed to have something working in the end.
At the Sprint Review, we had the future internal users of the product and other people in the risk and security area. We didn’t have the option of having representatives of the regulator. But we had the next best thing. Our own Product Owner, the Director of Risk, kept them up-to-date by forwarding the reports and she received feedback from the regulators constantly.
Sometimes you can’t have all your stakeholders at your Sprint Review. This shouldn’t stop you from obtaining their regular feedback that can help to understand how your progress towards the goals and what to do next.
The attendants of the Sprint Review were heavily impressed by what the team managed to pull off. They saw a crude product that did a basic screening and reporting. It didn’t matter it was data from a report they created themselves, avoiding some pitfalls they hadn’t tackled yet. This Proof of Concept existed to show what was possible.
At the end of the Sprint Review, it was clear the team was on the right track. Their next target was enhancing the software to manage the Dutch sanction list, which had the highest priority.
Detailed plan vs constant delivery of value
Meanwhile, our manager had asked the team to size the efforts of all the stories. This was a two-hour exercise that kept the team from working on the Increment. Next, he used the velocity from the first Sprint to plan out the complete initiative. Then he presented it to the regulator. In doing so, he threw the team under the bus.
Instead of being responsible for achieving their goals, which they believe they were capable of, the team now needed to deliver all items according to this overly detailed plan. The manager thought he did a good thing. The regulator needed something to hold on to. But this was not the way.
I had a difficult discussion with my manager and explained to him how he let the team down. His response was that he didn’t like how Scrum is so noncommital. For me, it was clear we were not going to settle it there.
I advised the team to ignore this planning commitment and simply stick to the storyboard. Luckily, our director of Risk was on our side. She was happy with our first Sprint and looked forward to what we could do next.
Next couple of Sprints — Sanction lists
The many struggles the team had and the ingenious ways to resolve them during the first Sprint helped the team with the Dutch report. They still needed the two full weeks to complete it, but they were in control.
Every Sprint the team focused on a different sanction list. They all came with their own challenges. Not only did we have to take into account different languages, but also different writing systems like Cyrillic. There were also technical challenges to resolve.
On top of that, we received requests to adjust the reports. Coming from the regulator, we considered them to be instructions, not requests. There was a constant back and forth of an updated product and feedback from the regulator. The product emerged from the conversation.
Before long we had implemented all the important sanction lists. This was well before we expected to hit this mark. This the moment for me to again argue against the detailed planning. Our manager had to update it on a weekly basis as so many things changed. He made a fool of himself before the regulator with these constant changes.
Luckily we were delivering new Increments of our product every Sprint. The regulator saw that we were actually fulfilling our compliance obligations step by step. This was our saving grace. In the end, the efforts from our manager only resulted in him being dismissed by the regulator as a serious counterpart. They would only listen to our director of Risk.
I managed to shield my team from these politics. We now focused on the next big topic. We needed to look at monitoring our transactions to detect signs of money laundering. This entailed various sets of detection rules.
We decided to order the detection rules according to priority. We would start with an isolated rule, impacting a small number of payments, to learn the mechanics. When everything was OK-ed, we would work on the most heavily used payment type. Similar to the sanction lists, we used the first Sprint to iron out how the functionality could work and then tackle the items on priority.
Sprint after Sprint our product emerged. We kept the stakeholders, including the regulator, in the know by constantly updating our Sprint Backlog and providing additional information showing the percentage of payments we covered with our screening and the quality of the screening.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F124641f7-311a-47f5-a373-51b1890ed716_800x600.jpeg)
Positive changes
Months before the deadline, we were ready. We had covered all requirements from the regulators. They confirmed our compliance with the rules and now began to ask us for additional quality measures. On one hand, this was nice. We didn’t have any immediate threat of fines anymore. On the other hand, we had unexpected extra work.
This changed a lot for us. We were fully compliant with the AML regulations. We could now stop our investments and put the product efforts on maintenance mode. This was risky. Maintenance mode often means a product is being neglected. Before long, the product doesn’t fit the needs any more. In this case, it would mean we’d risk being non-compliant.
Our director of Risk knew this. Armed to her teeth, she brought the case to the investment board. This was the moment to step up, to build upon the success. Our AML policy could become a unique selling point of our product. Because being a trustworthy partner is important. Luckily, she succeeded and we continued to invest in AML.
We made our product vision more ambitious:
“Within a year, our AML practices are a unique selling point of the company while still adhering to the compliance rules of the regulator.”
As an example, we would work on improving the user experience. Up to this point, it was clunky and served its purpose of providing the necessary information. Now we wanted to streamline to review process.
We would also add AML practices to our organizational development standards. Teams that work with the payment stream needed have these rules in the Definition of Done.
From problem child to a success story
When we started our AML endeavour, we were in a bad shape. Sure, we weren’t the only ones. But that didn’t bring any consolation. We had an urgent problem and needed to fix it.
We consciously choose to create this product ourselves with a Scrum Team. The AML product is complex. Even the regulator couldn’t tell us what our reports should look like. For every aspect of the AML product, we started with a proof of concept. We built something rudimentary that did the minimum to show we had a solution to the problem at hand.
From this, the product emerged. Constant feedback from our stakeholders, including the regulator, allowed us to adjust the course to optimize our chances to meet our goals.
Well before the committed date, we signed off on our responsibilities. We were able to do so because we allowed for experimentation and focus on what truly mattered.
We realize AML is a product with many opportunities to create value for our organisation. Above everything, clients look for payment providers providing a stable and secure platform.
Whenever I watch the news and see a report about a major bank’s troubles with AML I can't help but smile a little. Those major companies failed where we succeeded. With Scrum.
Key ingredients of our success
Looking back at our adventure, I can identify a number of things that were key to our success:
We had full support from the director of Risk who acted as the Product Owner.
We addressed the difficult topics that required the highest learning immediately. This allowed us to control our risks.
We showed our stakeholders we worked on the things they found important. Their feedback had an immediate impact on what we did next.
We constantly produced new Increments of our product that had value. We were able to predictably meet additional needs from the stakeholders while also showing how we were moving towards the overall vision.
Detailed plannings had no place in our approach as we were experimenting and learning. Instead, we focused on delivering value after every Sprint. We took one step at a time while being mindful of the overall vision.
If you don’t know exactly how to solve your issues, great a goal to achieve. Start with a vision and define smaller goals to allows yourself to take steps towards the goal. In complex environments, this is the key to success.