The Google AML AI API is an engineering and analytical pipeline designed to assess anti-money laundering risk in retail and commercial banking. If you're unfamiliar with the Google AML AI, it might be worth reading our introductory article.
Alongside the operational and risk benefits of deploying a robust and effective AML model, Google’s extensive experience of operating machine learning and AI for decades has embedded MLops and devops capabilities which can be transformative for your ability to rapidly react to new and emergent risks.
Often these capabilities are less obvious and are deceptively hard to get right. They are absolutely critical for your ability to reliably maintain a model in production as a core control - and with the Google AML AI this work has already been done for you.
Put simply, a well designed operational AI system like the Google AML AI allows for:
- Reliable model lineage
- Frequent model retraining
- Rapid iteration and experimentation with new data
- Consistent backtesting with measurable outcomes.
In this article we'll explore some of the advantages Google AML AI brings from its transformative approach and why you should build your systems and processes to take advantage of these capabilities, and how you might go about it.
Benefits for Risk and Operational Teams
Lower false positives - AML AI learns from the outcomes of investigations. Feedback puts investigations at the heart of AML AI learning technology, and more rapid feedback leads to higher quality alerts. Frequently retraining the model keeps false positives rates lower and helps the model learn from emerging threats.
New risks - Intelligence from staff reports, FIUs, fraud systems, law-enforcement and other “out-of-aml” systems makes it easier for the model to detect new and emergent risks across your business. Through regular retraining and investigation the model learns from these risks in a fraction of time it would take to mobilize a team to write and test a set of rules in a traditional system and at a consistent cost.
Black Swan Events - Covid-19 changed customer behaviours across the world and new threats, e.g. PPE fraud and government support schemes introduced never before seen typologies. AML AI was developed during covid and showed a remarkable ability to detect these risks as they emerged as the model was retrained.
Stable Alert Volumes - Operational teams can have confidence they won’t be flooded with new alerts when a new model is put live due to the continual testing a model goes through throughout the development process, not just at the end of a deployment cycle. Operational volumes become more consistent and predictable because the model remains at peak performance and backtests can better predict alert volumes and align to business outcomes.
Benefits for Technology and Analytics Teams
Model lineage - We’ve seen other models at major banks fail model governance processes because there was uncertainty about the specific model used to produce an operational sample, or the specific model governed. Months of effort was wasted because there was uncertainty around the model configuration that was used to produce the version proposed for production. AML AI strongly links a model across training data to input data and subsequent prediction runs.
Development velocity - The tools and techniques to rapidly retrain allow both IT and analytics teams to develop on the same, consistent model platform. This greatly improves time to production, because everyone is working off the same model. There is no “re-coding” scenario where the analytics team hand-over code to IT and lose visibility.
Rapid iteration - New ideas and training data can be rapidly tested and discarded or accepted in days, as judged by their ability to move accepted business metrics in the right direction. With metrics being automatically calculated during training and backtest, the entire team has far better visibility over how model updates are expected to perform in production.
Reproducibility - a well-engineered model can be consistently reproduced, since the model is the result of a combination of data, code and configuration. Model issues can be more easily resolved by analytics and IT teams because multiple iterations can be trained and tested in development to isolate issues.
How do you align your own processes and technology?
Like any cloud platform, Google AML AI provides robust capabilities around which you can build your processes and provides a basis for building a complete end to end system.
It is completely feasible to execute the Google AML AI as a once-off experiment with difficult to re-run manual processes - manually specified data, ad-hoc evaluation techniques. This might be fine for an initial test, but it negates many of the advantages above if used for the long turn.
Even in a proof of concept, the ability to rapidly rebuild and for full model lineage for any later governance procedures is hugely valuable and allows for rapid iteration.
Groundtruth AI has extensive experience with Google AML AI from proof of concept to operating and retraining it in production and can help you to build for long term success in compliance with your model governance and IT rules.
The model pipeline
In order to make the best of use of the AML AI and fully gain the advantages above, you need to be able to run the processes you execute around the Google AML AI to fully leverage its ml-ops and dev-ops capabilities. To do this, we introduce the model pipeline. The model pipeline is an automated sequence of all the steps required to retrain and backtest a model, eliminating as many manual procedures as possible, and it is able to run major components of the process completely autonomously. Done correctly, the model pipeline:
- Carries out any curation of training data with verification and testing.
- Builds any PSD/customer analytics (features) required with verification and testing.
- Executes the AML AI to train and backtest a model
- Maintains and records inputs and outputs for governance purposes
- Applies previously selected model thresholds
- Produces technical metrics and projected business metrics that the whole team, including senior risk stewards, recognize.
- Makes a record of all the associated inputs and outputs in a way which establishes a clear lineage with the data, code and models used.
What’s important here is that you don’t need to do everything at once - a pragmatic approach is important. A model pipeline with a subset of the list above can unlock huge benefits for your team and organisation, and allow you to iterate confidently and quickly.
Model Governance
Internal model governance requirements will often require scrutiny of a single instance of a trained model. This creates a great deal of work each time a model is retrained with new data since the entire process much be repeated. If you can, we'd recommend governing the the process for producing a particular model instance instead - updating only the data going into the model and none of the associated configuration or code. Changes to the configuration and code can be governed in detail. This should allow for a much faster process of governing a retrained model. Pre-agreed tests are run and a lightweight process ensures the test results for each model produced meet standards.
An imperfect analogy might be useful here. Consider a factory (the model pipeline) producing widgets, with a well-established testing procedure which all widgets must pass. Each widget is produced to the same specification, with only the raw materials (the data) differing. An end-to-end production process is governed in detail, including a rigorous certification procedure any widget must pass before it is released. Contrast this to a situation in which each each widget must be governed individually in a bespoke fashion. This process results in it taking longer to release each widget, and the governance process risks becoming inconsistent between each widget.
We believe that governing the processes around training, retraining and testing unlocks a host of benefits - but we are very aware that this isn't always possible for a variety of reasons including regulatory expectations and internal policy. In these situations it may be worth considering a blended approach instead.
In future, we will explore the topic and challenges of model governance more deeply.
Deploying to production
Iterating and testing rapidly doesn’t mean you must lose the controls you already have. The bank will always own the risk and decide what and when to put a model into production, but it can proceed with the certainty of exactly what was governed and approved while maintaining the ability to react as quickly as possible.
About Groundtruth AI
At Groundtruth AI we have extensive experience of building and deploying model pipelines in real-world FIs with technology and governance requirements, particularly in AML. Our founders led product, technology and analytics teams deploying and maintaining the Google AML AI deployment currently at HSBC. We can help in your journey with the pre-built solution accelerators, systems integration and domain specialist consulting to deploy the AML AI.