Tech Stack Success: Being the best of Monzo, with what you got

Matej Pfajfar recently published a thought-provoking article titled ‘Monzo CTO Matej Pfajfar looks into why owning your own tech stack sets you up for success.’.

The ideas in the article resonate a lot with my own thinking and the principles we built Plumery. I am sharing my reflection and perspective and hope my readers find this valuable.

Resilience, Scalability, Extensibility, Security and Cost-Effectiveness are the central pillars of the argument in the original article by Matej. I couldn't agree more that these aspects, among a few other quality characteristics, are the most critical when building and operating a bank or any financial service.

The issues of Resilience, Scalability and Security are so axiomatically correct that they barely need discussion. A bank that fails regularly or isn’t secure will not be a bank for very long - it’s as simple as that.

What I think is worthy of exploring a bit deeper are the conclusions on:

• Extensibility 
• Cost-Effectiveness

One of the key messages in the article is that the technology and the organisation's practices should enable the ever-increasing pace of change in customer expectations and the understanding of what good looks like.

Organisations shouldn't be limited by the old legacy technology that wasn't designed for change. New ways of working, embracing 100 or more daily releases, is a new norm.

The question is whether switching from all the tech provided by vendors to everything built in-house is the right answer or whether that is the correct answer for all and at all times.

The decision of whether to build or buy is slightly more nuanced and depends a lot on the individual context of each organisation.

The stage of the business is also critical. Often, companies are faced with the necessity to make pragmatic decisions when they don’t have the luxury of having an 80-strong world-class engineering team on day one.

Internal teams that might need to deliver a transformation proof-of-concept or a neobank that, in the current ‘challenging’ capital-raising environment, need to find ways to achieve excellent outcomes without ticking the ‘bespoke’ box from top to bottom.

While Matej rightfully points out that legacy technologies are not built for change, today, there is a good number of providers that are built specifically to enable banks to focus on what is most important and differentiating (typically, closer to the end-customer, see Wardley Map above), same time, taking away the 'burden' of building and maintaining what's well defined and the same across the industry.

What are the alternative ways to achieve the level of control Matej talks about? To ensure extensibility and cost-effectiveness from the outset when means are limited?

Cost Effectiveness

Building your own solution takes time, money and expertise - lots of it. Most businesses have only so much money and must be very selective about what they build and maintain themselves. As a business, our guiding philosophy at Plumery is to.

‘Buy for parity, build for competitive advantage’

Simply put, if a business is trying to launch an entire bank or even a single proposition and spends all of its money reinventing the wheel, leaving no money left for differentiation. The outcome is unlikely to be good.

Regardless of size, every single bank must have a clear vision of what product capabilities it needs to be differentiated - what will be your secret sauce? And, as the counterbalance to this, what are the features you need to deliver to get to market parity?

Banks should want to find the fastest, cheapest possible way to acquire and maintain those ‘parity’ features. Often, this will mean taking something ‘off the shelf’. Only, as long as it doesn’t compromise quality and your ability to differentiate yourself where it matters the most.

Continuous Evolution

Monzo Bank is one of the leading examples of how tech-forward practices meet century-old industries. Today, it is no longer enough to release an excellent mobile application and keep it running without change for even a quarter. The stream of improvements has to be continuous.

Banks like Monzo release changes to their critical infrastructure 100 times a day. Yet, most traditional banks are still following what is perceived as a low-risk practice of releasing changes once a quarter or every six months. In reality, it does the opposite - as suggested by numerous studies, including the famous DORA, accumulating changes and releasing less often increases risks significantly and worsens the overall customer experience.

Having the technical infrastructure and the practices that enable Continuous Evolution while meeting high reliability and security standards is crucial for today's digital-first or only business.

Sound engineering isn’t building once and forever

We have explored the importance of being strategic about what to 'buy' and what to 'build'. I have also mentioned the criticality of designing your organisation and practices to foster continuous evolution. One more important aspect is that the architecture of your platform needs to support the ever-changing reality of the world.

Evolutionary Architecture emphasises an adaptable and resilient approach to system design, anticipating and embracing change over time. Using this mindset, it's essential to recognise that starting with a vendor product doesn't bind you to it indefinitely.

Often, initiating with a set of off-the-shelf software and transitioning to an in-house solution later can be a wise strategy. The key lies in ensuring that the foundational architecture is adaptable. This way, when the moment arises to replace one technology component with another, the transition is seamless....

Last week, we saw in the news that Monese was moving away from Thought Machine’s core. This is probably simply down to a change in the business's requirements, resources and ambitions - what was right then is no longer right for the company.

Matej was upfront about how Monzo “make good use of off-the-shelf technology where appropriate”.  What is ‘appropriate’ will vary hugely from bank to bank, depending on their circumstances, limitations, and skills.

Monzo initially used a third-party provider for its FPS (Faster Payments) processing but brought the service in-house in 2019. For whatever reason, they determined that strategic control of this component became important from now on. Every bank of FI will need to make these decisions across their stack based on their unique strategy and goals.

Most neobanks banks use third-party KYC providers because it’s specialised and non-differentiating. None of the banks we worked with have decided to build this in-house. I believe there are good reasons for that. Monzo is not an exception here.

As we can see, even technologically advanced digital banks like Monzo (or should we say a technologically advanced company with a banking license?) will use third parties extensively.

Copying what works for one doesn't always lead to successful outcomes for the other—context matters.

Monzo is unquestionably an example of in-house engineering done right. However, I have seen far too many financial companies worldwide bite off more than they can chew to start and regret it. A presentation by the Monzo team back in 2020 talked about how they maintain their library of 1600 microservices. Managing this will be no small task, and for a large number of organisations - unachievable.

Many of the points that Matej raised are the reasons we created Plumery. To bridge the gap between the control a ‘build’ approach offers and the practicality of leveraging standard capabilities off-the-shelf.

The Monzo team is a fantastic example of combining state-of-the-art engineering with digital banking expertise. We hope to democratise some of what makes them great and bring it to the masses for the benefit of financial services across the world.