The Hong Kong Monetary Authority has published a report entitled 'AML/CFT RegTech: Case Studies and Insights' which outlines the ways in which regulatory technology make banks more effective in fighting money laundering, with end-to-end approaches and real-life examples.

The report, made by Deloitte, contains case studies and insights gleaned from banks which taken on such IT as network analysis and robotic process automation (RPA).

This is the first time that the HKMA has shared comprehensive and practical, hands-on experience from banks that have already used AML RegTech. The case studies show the importance of early and continuing "stakeholder buy-in"; interdisciplinary adoption teams; fora in which to share views and experience; and being able to track and measure success.

The report looks at one Hong Kong subsidiary of a global retail bank that operates in many markets in the Asia-Pacific zone. In 2020 it established an internal task force to look at AML RegTech, chaired by its money-laundering reporting officer (MLRO), and spot opportunities.

One option - an increasingly popular one - was to use non-traditional data elements such as IP addresses to spot networks of relationshiops between customers. The subsidiary had never used network analysis or IP addresses before, but the group had. These attempts had not been successful, however. The subsidiary therefore proceeded cautiously (with a "use-case-driven" approach) and in tandem with Hong Kong's financial intelligence unit or FIU.

Working from insights that it had gleaned from trends in suspicious transaction reports (STRs) which the bank had sent off over the years, the subsidiary concentrated on a group of 50 or so customers in the Asia-Pacific region. The "network ontology" that it set up included name, address, etc., transactional data and, most interestingly, data about the customers' digital footprints, which included information (date, time, location) about their attempts to log into their online bank accounts.

Two months later, after much effort spent asking data owners to explain the purpose of their enquiries, the taskforce 'visualised' the data and looked for patterns and relationships. These included undisclosed clusters of relationships involving multiple customers with the same IP addresses, email addresses that tried to log into online bank accounts at the same time as each other, and many attempts to log into a single bank account from many jurisdictions that occurred in a short time.

At the end of a year of using analysing networks with the help of non-traditional data, the bank learnt three lessons.

First, it appreciated the practical problems that beset anyone who wants to run a RegTech experiment or proof-of-concept exercise. It is important to talk to (and receive approval from) internal people such as data owners. It takes time and effort to make sure that the data is complete and of the right quality - in RegTech, as in any other part of IT, the old US adage holds true: "garbage in, garbage out." It is vital as well to limit the ambitions of the exercise at the outset and avoid "mission creep."

Second, network analysis (or 'analytics,' as Deloitte calls it) and the use of non-traditional data are more useful for intelligence-led investigations than for passive monitoring. They are good for enquiries but less good for generating alerts.

Third, and perhaps most important, the taskforce (and indeed other staff) learnt a great deal about thinking creatively during the process.

Many other banks appear in the study, all anonymous.

Low-tech innovation

Many banks are finding that the best uses of AML RegTech are not necessarily the most sophisticated and ther report mentions this. Today, many of the questions asked by an analyst during the course of an investigation can be answered by pairing said analyst with the right data and a colleague who can translate the question into a data query using open-source programming languages such as Python or SQL.

Take, for example, an incident such as the Panama Papers in 2016. In the immediate days and weeks after the papers hit the headlines, MLROs wanted to know if there had been any suspicious activity on the part of their customers in the weeks just beforehand. Using open-source analysis software in Python, such as 'pandas,' along with visualisation libraries such as 'Matplotlib,' an analyst could go through transactional data to group the original dataset and see summed transaction values across the defined period. In other words, he could go through thousands of rows of transactional data and calculate daily transaction values, then he could plot the results visually on pandas using Matplotlib.  

Rights of representation

An FIU spotted a group of suspicious clients where parties held "rights of representation" (e.g. authorised signatories and power of attorney, both very common in private banking) in many relationships between clients and banks, despite not being beneficial owners. By upgrading its data infrastructure, one bank's financial-crime risk-focused data-analysis team performed a "look across" exercise to see if this type of pattern existed in other groups of clients. It spotted some other suspicious groups of clients and told the FIU. The MLRO then designed fresh controls and introduced them to every part of the bank.