The State of Digital Banking

The biggest banks in the world exist for tens and hundreds of years. They were started well before “software took over the world”. They specialize in banking, and not consumer facing software.

However, just like the most successful journalism and commerce companies are now software companies, so do banks that want to succeed in the modern world need to be.

In the following episode of Software Engineering Daily, we get to know Monzo, who are trying to do just that: be a software company that specializes in banking. This affords them significant advantages over older banks, but also sets an interesting set of challenges.
The episode’s guest is Richard Dingwall, an engineer at Monzo. He explains why this is a good time to start a digital bank, and discusses a lot of Monzo’s engineering endeavours.

Modern digital banking

A few factors cause this to be a great time to build a digital bank. The first is a regulatory reason: new UK regulations instituted by the PRA, (Prudential Regulation Authority – overseeing banks in UK), now allow new banks to start in a “sandbox” mode, with only a limited number of customers.

The second has many faces and is often discussed in SE Daily podcasts. It is the emergence of cloud computing, which allows companies like Monzo to develop reliable IT infrastructure at very low costs, as well as recruit an abundance of engineers who are proficient with cloud computing. Richard describes this available talent: “We call them sort of children of the cloud. There are young engineers here at Monzo who’ve never worked in businesses which have had physical servers on premise or anything. They’ve always worked in Amazon or Google’s cloud.”

Moreover, modern digital banks can attempt novel approaches to make money. Older banks use a profit engine called “interest margin,” which is basically the spread between interest by the bank is paid by customers on loans minus the interest paid out by the bank to customers for deposits.

Monzo’s approach to profit is aligning the customer and the banks’ incentives: they offer a free bank account, and earn money from the central UK bank’s interest rate on that money. They also try to identify high spends their customers have for different products, and offer them a cheaper option, while charging a portion of the savings. A recent relevant episode on modern banking is this one: Build a Bank: Nubank with Edward Wible.

Richard describes the tortuous path a transaction makes from merchant point to the customer’s bank, which can be summarized in the following diagram:

How long should such a complex transaction take? A complex transaction should take very little time, according to Richard, “All of that needs to happen in, I think, 9 seconds, which kind of sounds like quite astronomically high amount of time, but actually we find in – I think that’s a requirement that we find in practice and it really happen in about one second otherwise we see transactions get canceled.”

Monzo’s tech stack – some interesting parts

Kubernetes deployments

Monzo has recently moved to using a Kubernetes deployment. Not only that, but they did so with zero down time. Richard describes how they accomplished this: “So on the migration, we basically cloned the bank. We were running two Monzos, if you like. We used Terraform to bring up a new production environment running Kubernetes alongside the old one….  Then we just switched traffic over. I think we’ve actually done that more than once since when we’ve done things like Kubernetes upgrades as well.”Monzo has been very happy with their Kubernetes experience. They testify to a 75% decrease in spend, but more than that, Kubernetes allowed much more freedom and ease of use for their engineers on their infrastructure.

CassandraDB – high availability, with some consistency added on top

Monzo uses CassandraDB, a distributed, masterless key-value database. Cassandra gives high availability, and allows to set its consistency level – by assigning a parameter the administrator can determine how many nodes are notified of an operation before it is considered done. However, that is not enough for some classic banking needs. When a customer transfers money to another account, he can’t have it be ‘eventually consistent.’ That is why Monzo uses a second layer for consisting these transactions. They use etcd, for acquiring locks across these distributed database nodes. So whenever a certain resource needs to be locked for a granular transactions, all locks are for the resource are acquired prior to the operation.

Microservice Architecture

Richard describes Monzo’s microservice architecture in a very down to earth and clear manner: “at Monzo we use micro-service architecture. Instead of running maybe a handful of very large kind of monolithic service processes, which dispatched things using function calls within one process, we compose systems out of a lot of smaller components, which all run as individual processes and then talk to each other”, he explains.

Inter-services communication is separated into two main use cases: synchronous communication is used when a customer needs feedback on an operation. For example an attempt to transfer money, where the customer expects to be informed of success or failure. This communication is performed with json format over the HTTP protocol. They refrain from using GRPC protocol at the moment due to how widespread and common json over HTTP is. Another company that migrated to microservice architecture is shopify. They tell more about this on this episode.

Asynchronous communication happens for tasks that are not of interest to the end consumer: for example transferring the new event to a data science engine. This communication is performed by queueing a message on Kafka queue, which every relevant service that needs the data listens to.

The two modes of communications are depicted in the following diagram: the critical transactions service is notified synchronously, while the rest are informed asynchronously.

Monzo uses a service mesh to orchestrate inter-service communication. The service mesh they use is called LinkerD, and it helps them resolve destination addresses of other services, handles retries, and more. To learn more about service meshes, listen to “Service Mesh with William Morgan“.

Wrap it up

This episode with Richard was a great combination of a very modern and useful product, with a detailed technical deep dive, explained in a clear and concise fashion. In recent years software took over some classic industries, such as journalism, commerce, and more, and one of its future disruption targets is banking. To do that, software companies will need to dive deep into the technical banking world, just like Monzo did.