{"id":50,"date":"2026-01-24T01:03:16","date_gmt":"2026-01-23T23:03:16","guid":{"rendered":"http:\/\/localhost\/demo\/?p=50"},"modified":"2026-01-25T22:44:49","modified_gmt":"2026-01-25T20:44:49","slug":"excited-news-about-arrival-fashion","status":"publish","type":"post","link":"https:\/\/smebanking.agency\/platform\/excited-news-about-arrival-fashion\/","title":{"rendered":"Monzo\u2019s machine learning stack"},"content":{"rendered":"
<\/div>\n

Machine learning, popularly referred to as Artificial Intelligence, <\/em>is a method of using data to teach computers how to do things. Inside of a bank there are lots of areas that benefit from machine learning, ranging from preventing financial crime, building a more efficient and delightful customer service and much, muchmore.<\/p>\n\n\n\n

In previous posts, I\u2019ve given an overview of the machine learning team (in 2020<\/u><\/a> and 2021<\/u><\/a>) and explained some of the areas we were focusing on. This post is about our platform and tools. Behind the scenes, we\u2019ve spent several years refining our approach to building impactful machine learning systems, and a core part of that is having the right tools in place to make our development experience fast and safe.<\/p>\n\n\n\n

Our early principles<\/h2>\n\n\n\n

There are lots of different ways that companies build up their machine learning systems. Some companies like Netflix<\/a> and Uber<\/a> have also blogged about their approaches. Several years ago, a small group of us had a discussion about what core principles we were going to use as we started to think about our approach to model deployment. <\/p>\n\n\n\n

    \n
  1. Autonomy<\/strong>. We decided early on that we want to empower Machine Learning people to work end-to-end. That included deploying their own models into production, rather than requiring a handover to a backend engineer to complete that final step. Our view was that this would speed us up and lead people to think about the end-use of a model while it was being designed.<\/li>\n\n\n\n
  2. Flexibility. <\/strong>We decided that we didn\u2019t want to constrain our capabilities to specific frameworks or types of machine learning, so that people could pick the right tool for the job. We imagined a future where we would be working on a variety of problems with different types of data, and we wanted our early efforts to keep as many doors open as possible.<\/li>\n\n\n\n
  3. Reuse over rebuild. <\/strong>Years ago, Monzo already had a strong foundation for a microservice-based production stack<\/a>, and a budding data stack which has evolved considerably since then<\/a>. We decided we did not want to build an isolated and independent stack for machine learning; instead, we opted to reuse the existing infrastructure and tooling where possible and focus our efforts on the delta between what existed and what we wanted to achieve.<\/li>\n<\/ol>\n\n\n\n

    Over the intervening years, a lot of these early decisions have held, and we have benefitted from new features in our production and data stacks. Today, everyone who works in machine learning is embedded into five squads working across four different areas of the company, but we\u2019re all using the same platform and tooling to work on a wide variety of different problems.<\/p>\n\n\n\n

    Monzo\u2019s machine-learning stack<\/h2>\n\n\n\n

    Here is what our\u00a0entire<\/em>\u00a0machine-learning stack looks like today:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The following sections give a brief overview of each part of this image.<\/p>\n\n\n\n

    We use Notebooks for prototyping<\/strong><\/h3>\n\n\n\n

    Notebooks are web-based, interactive compute tools. At Monzo, we encourage people to use Google Colab notebooks<\/u><\/a> in a similar way that engineers use whiteboarding tools. They help us do rapid exploration and prototyping, and to get a sense of what could<\/em> work. The main difference with machine learning is that we need some data to be able to do that.<\/p>\n\n\n\n

    We’ve used notebooks to explore the viability of several ideas and to quickly gauge whether it\u2019s worth investing more time into them. We explicitly don\u2019t take notebooks any further than this; when ideas mature, we move them out of notebooks into our codebase.<\/p>\n\n\n\n

    We have a monorepo of Python jobs, libraries and command-line tools<\/strong><\/h3>\n\n\n\n

    Training a machine learning model entails two big steps: preparing a dataset, and then using that data to train a model.<\/p>\n\n\n\n

    We split these out into two separate jobs, so that we decouple how a dataset is created from how the model is trained. This enables us to experiment with how models are trained without changing how the datasets are created.<\/p>\n\n\n\n

    All our jobs are committed and peer-reviewed before being merged into our shared monorepo on GitHub. We write them in Python, and create them using a base cookiecutter<\/u><\/a> template.<\/p>\n\n\n\n