In the last few years I have had the pleasure of working in the very regulated area that is AML (anti-money laundering), CTF (counter-terrorism financing), and sanctions. These areas may sound dry to some, but they are a vital component of keeping a financial institution compliant. Thus, even if it isn’t directly driving revenue, it is nevertheless important, as it ensures the financial institution can remain in business, and avoid significant fines and other penalties.
Although one learns from one’s own mistakes, it is significantly cheaper to learn from those of others. We will thus look at a few examples of fines related to AML, CTF, and sanctions from the last few years. These not only serve as lessons on the consequences of non-compliance, they also offer some broader lessons on building robust products that can sustain the rigor of being in a regulated industry.
Four examples: From the egregious to the error-prone
Example 1: Binance
We will start with a big one: Binance being fined $4.3 billion for a series of AML and sanctions violations. Apart from failing to run proper identification of their customers and allowing illegal transfers, they also carried out actions that were more egregious than merely lack of controls (although controls were indeed lacking). Binance had not only tried to obfuscate where they themselves or their customers were based to avoid having to comply with US regulations, but they had also identified VIP clients whose transfers they would speed up and whom they would inform if their accounts had been frozen. Binance would also inform these customers about who had investigated them. This sort of tipping off is, to put it politely, illegal. Furthermore, many – if not all – of these VIP customers were such that due to the large volumes they were transferring, they should have been subject to greater scrutiny, rather than have their transfers expedited.
Worth noting, the CEO was also sentenced to prison (albeit for only four months).
I won’t go into more detail of the breaches here (the Guardian article does a good job of that), but it is a spectacular example of compliance breaches and fines worthy of their price tag.
Example 2: N26
In 2021 BaFin, the German financial authority, imposed a 4.9 million euro fine on N26 and, perhaps more importantly, a limit on the number of new customers they could onboard to only 50k customers per month. This was later adjusted to 60k, but it was still way below the preceding customer acquisition rate of 170k per month. This limit was in place for over two years, and according to the CEO had cost the company billions due to lost growth. Rubbing some salt in the wound, N26 also received an additional fine of 9.2 million euros in 2024 for late reporting of suspected money laundering activities back in 2022.
According to the statements from BaFin on the matter, they wanted N26 to establish better processes, better monitoring, and shorter backlogs. To paraphrase liberally, it seems that they wanted them to get their house in order, and they were going to impose limits on N26’s growth until they would have processes that would be sufficiently robust to sustain a larger customer base. This example is also a good reminder that regulators have multiple sticks they can wield.
Example 3: Starling Bank
Starling Bank in the UK was fined close to 29 million pounds in 2024, primarily due to lax sanctions controls, but also for onboarding high risk consumers that it had been forbidden from onboarding in 2021. This latter point echoes somewhat the prohibition imposed on N26, although it is a less drastic one. However what is perhaps more interesting is the sanctions component of this case, as it was found that since 2017, Starlink had been screening their customers against only a subset of the required sanctions lists. This is a long time for an error to be around, and it goes to show the importance of thoroughly testing the correct functioning of your product. It is thus not enough to release a new functionality. You need to be able to show on an ongoing basis that everything is working as it should.
Example 4. American Express
In this final example, we take a look at a fine resulting from one specific incident, as opposed to due to more systemic failures. American Express was fined $430,500 for allowing one sanctioned individual to carry out transactions.
It all started with a sanctions alert which was erroneously dismissed despite all signs pointing to a likely true positive and procedures dictating that an additional review was necessary. Then the sanctioned individual’s card was again flagged, and subsequently blocked. This second alert had been raised through the investigation of an associated media alert (i.e. the individual was flagged while carrying on screening against negative mentions in the media). However, the block did not include the correct suspension code, so when the customer called to complain, the suspension was lifted. The AML team caught this mistake, so the account was again suspended, but again with an incorrect suspension code. This allowed the individual to conduct seven additional transactions, before the account was finally closed a week later.
This case was riddled with human error, which was exacerbated by unclear workflows.
There are a few different lessons that can be learned from this. First of all, we see how expensive it can be to allow a single sanctioned individual to make transaction. Furthermore, it highlights the importance of having clear workflows that are easy to follow correctly. Last but by no means least, it demonstrates how important it is to have multiple different systems working in parallel, so when one fails, another one may still succeed. I find this to be the most interesting lesson. In this example we saw how two different screening mechanisms detected the match, and furthermore, how when one team had made a mistake, a different one was there to catch it. These are two examples of robustness being built into the overall system, so when one process fails, another one can make up for it. Had the system been more brittle, any eventual fine would have been much larger. I recommend reading this short post for a primer on robustness, reliability and resilience.
(Sidenote: One could also come to the conclusion that humans are error prone, and they should be removed from the equation, but software is also error prone, so it seems prudent to still keep humans as part of one of the systems involved.)
So what?
There are some general lessons here that extend beyond “comply with the law”. In most of the cases above, there were some of the expected controls in place, but they either did not function very well, or were otherwise flawed. They also serve as examples illustrating how important it is to ensure that your existing controls work the way they should. This means investing in monitoring and testing, and this work can be commensurate in size with the implementation of the controls themselves. You also need to ensure you have clear audit trails, so that you can demonstrate that you are doing what you are supposed to do.
Furthermore, these cases highlight how expensive non-compliance can be. They typically have a high dollar price. Beyond that, the absence of proper controls can also result in restrictions on your growth, be it through limits on the number of high risk customers in Example 3 (Starling), or a more drastic overall limitation as seen in Example 2 (N26). These limits were at least in part imposed due to a lack of confidence on the part of the regulators that the existing controls could handle larger volumes. This points to scalability as an additional key area to invest in.
When it comes to scalability in the AML space, this could be achieved in at least four different ways:
- Decrease false positives, while still ensuring systems catch what they are supposed to;
- Pursue automation where possible, and optimise workflows, thus increasing throughput rate of any cases being worked on;
- Make it easy to add your products and services to your AML systems (e.g. leveraging APIs, configurability based on product type and jurisdiction);
- Build a technically scalable architecture to sustain increases in volumes of customers or transactions.
The above breakdown demonstrates that increased scalability is not only good for calming and keeping regulators at bay, it is also good for the business itself. The efficiency gains from the decreased false positives and automation reduce the costs that are part and parcel of operating in a regulated industry. Making it easy to apply your existing AML and sanctions controls to new products, as well as a scalable architecture are important for enabling growth, as it allows you to increase your product offering more easily across multiple jurisdictions. One can typically achieve economies of scale as the volume of operations increases.
If one were to dig into the examples further, one could extract more lessons from each, but this will have to be a matter for other posts. It is worth mentioning though that clear documentation, proactive and collaborative engagement with regulators, adherence to SLAs, and a clear awareness of and remediation plans for any gaps you may have are all important. We also didn’t discuss this here, but apart from fines and jail time, banking institutions can also lose their banking license if they lack appropriate AML controls.
AML compliance may be the cost of doing business for banks and other financial institutions, but it is also part of their competitive moat, and an antibody against fines. The demands imposed by working in a regulated industry also considerably raise the bar on the reliability of the systems that you are building. Building a shoddy product would not just result in some unhappy customers, but could pose serious risks to the business itself.
We can conclude with one final take-home message: If you want to learn how to build robust and scalable systems, you could do a lot worse than picking the world of AML and sanctions.
Leave a Reply