top of page

Money Laundering — A Zero Sum Game

Anti-Money Laundering (AML) & Counter-Terrorism Financing (CTF) are big focuses for banks in 2020
Anti-Money Laundering (AML) & Counter-Terrorism Financing (CTF) are big focuses for banks in 2020

Here in Australia, Westpac Bank were recently exposed for facilitating billions of dollars of transactions to suspicious bank accounts abroad implicated in everything from Child Exploitation to Terrorism. Westpac weren’t adequately scrutinising thousands of very small transactions that were going to smaller banks that were flagged as ‘risky’ by the regulator. In Westpac’s case, there is already talk that the fine is going to reach into billions of dollars.

This reminded me of an episode of one of my favourite TV shows — “Suits”. In this episode, the two main characters (Mike and Harvey) need to call on the expertise of their rival Louis to help them with a case involving an employee who they suspect of embezzling money. The difficulty they encounter is that even though they know exactly how much money has been stolen from their client’s account in a single transaction ($152,375,242.18), they can’t seem to link this amount to any of the deposits in offshore Swiss bank accounts that the suspect has made.

The breakthrough comes when Louis uses his knowledge of financial crime to explain that even if there were no deposits that were made into the offshore accounts with that exact amount, if they could find some group of deposits that added up to exactly that amount, that would be enough to link the stolen transaction to the deposits. Here's the dialogue:

Louis: “Every person who embezzles money, they do it in their own way, but the one thing they all have in common, is they never put all their eggs in one basket. So we are going to be looking at a combination of accounts.”

Mike: “But how do we figure out which accounts?”

Louis: “Because the deposits in those accounts will all add up to the same exact amount of money that was lost from Stable Shelter’s account. When the account was drained, the money had to go somewhere, it’s a simple law of mathematics.”

In this case, the crook has done the following:

  1. Made a big one-off transaction out of his company’s account into some intermediary bank account (say, in Panama).

  2. Then he’s broken up that amount into many smaller transactions that arrive into some Swiss account(s) of his choosing offshore.

In academia, the problem our lawyers are trying to solve is referred to as the “Subset-sum problem” since the objective is to find some subset of a set of numbers that sums to some other value (e.g. the stolen amount).

However, the scenario in this episode is pretty simple (that’s showbiz!).. If the crook were more shrewd, he could have broken up the transaction amounts at both ends of the process (both taking, and depositing the money) so they are harder to link together. Doing so would have also had the added benefit that the smaller transaction outflows would have been more likely to fly under the radar. Or, the crook could have concealed his theft among many innocuous transactions, so that our lawyers didn’t know which transaction was the thievery and which were harmless, and instead they just suspected that any one of the outgoing transactions could be a theft.

How could our team of lawyers establish a link between the outgoing transaction amounts (leaving the company) and the transaction amounts arriving in the offshore banks they suspect of receiving the stolen money?

Let’s pretend that we have a suspicion that there is some link between two accounts. The first account (say — a Westpac Transaction account) has outflows in column “Outflow” below, and the second account (say — an offshore bank account suspected of financing terrorism) has inflows marked in column “Inflow” below (over a three week period):

Now the goal for the bank is to find any subset of transactions in the “Outflow” column, that adds up exactly to any subset of transactions in the “Inflow” column. If they could do that, they could uncover a suspicious link between the transactions, stop the dodgy activity, and potentially avoid a multi-billion dollar fine (bonuses all around! Yay!). Unfortunately that’s a much harder task, and it’s not something the bank would find an answer to with some light Googling..

Last year, I had to solve exactly this problem for one of Australia’s largest private wealth management businesses. Even though in this case the business knew exactly which accounts were linked together, there were still hundreds (and in some cases thousands) of transactions on both the outflow and inflow side of the ledger they had to try to link together, with transaction volumes reaching towards tens of millions of dollars.

I was able to solve this problem by drawing on elements from operations research that were operationalised for many thousands of transactions. I’ve since published a free version of this code and deployed it as a light application using the python library “dash”, the free optimisation package “mip” and solver “cbc” here (deployed onto a Heroku app server):

Once the app has booted up, the user can delete the source and sink values and paste in their own values, then hit “Run” to try to identify the matching transactions. In this case, the transactions flagged as ‘Match’ balance exactly (sum to the same number exactly) within the inflows and outflows. E.g. in this case we have identified that one of these outgoing transactions adds to exactly the same number as five incoming transactions in the offshore account we suspect of financing terrorism. Armed with this knowledge, the bank might consider scrutinising the transactions on this account more thoroughly or conducting a full investigation.

We can also specify a ‘match tolerance’ that will allow for matching transactions on both sides of the ledger to within some threshold, i.e. they don’t exactly balance, but balance to within 0.1 dollars.

A limited public use calculator is available here (up to 25 transactions on either side).

The underlying algorithm I developed to identify the matches scales easily to many thousands of transactions on both sides of the transaction ledger and runs in seconds (when deployed with a commercial Optimisation solver like Gurobi). If you find yourself needing to analyse more transactions or multiple accounts, please get in touch :).


Recent Posts

See All
bottom of page