Starling Bank CIO: “You have to design the software for failure”

The chief information officer role could not be more crucial than it is now. A role that simultaneously requires the robust upkeep of mission critical IT systems as well as constantly searching out the most innovative technology.

For John Mountain, CIO at challenger bank Starling, the way incumbent IT departments operate is vastly different to challenger banks, both in operation and culture.

“Challenger bankers are seen as laid back but we all work phenomenally hard and enjoy it; we’re not casual with it,” he says. “We’re probably the cheerful end of the industry.”

                       

                              John Mountain, CIO of Starling Bank

How did you come to be CIO of Starling Bank?

I’ve come on a slightly unusual route to the role of technology executive in that I have vast experience of programming and systems delivery. It’s more common to join a management consultancy and then take a senior role in the business side of the traditional banking structure than the IT side.

I approached the idea of working for a challenger bank after advice received over a couple of beers back in 2015. I confess, I didn’t know a lot about the challenger banks back then, but when I started looking into them and I came to a shortlist of four banks that looked realistic to work at: Atom, Tandem, Mondo (now Monzo) and Starling.

The first three all had technology that they’d either built or bought, but Starling was the exception and I could start from scratch. What really made my decision was reading a quote in an article from Anne Boden [CEO] that read ‘the only way to build a modern bank is not to have an IT department’. That one sentence made my decision.

I originally joined to do the big groundfloor delivery system job, to bootstrap a core banking platform for the mobile app, lead the build and report into the executives. But in late 2016, Anne promoted me to the executive team.  

In that respect, I’m relatively unusual in that I’m running technology at a bank and have fifteen years experience of coding.

It’s certainly the way fintech is going and the banks will have to follow.

Why do you make a distinction? At what point does fintech simply become banking?

Well it is. 30 years ago, the banks were fintech businesses and yet at some point of being technology leaders – banks were the leading adopters of computing – and then stopped for no apparent reason.

In the 1980s, when they were pioneering technology by employing smart people, building systems, running payment infrastructure and, fast forward 20 years to 2010, they can’t run even an IT department and everything innovative is being done by vendors.

So I would say they were the original fintechs.

There’s some weird risk aversion that caused the great pause in between. My role as CIO at Starling is to ensure that, as we go from 100 to a 1,000 people, we don’t turn into the thing we’re currently replacing by being small and agile.

It seems to me that nowadays you can be very successful in banking IT if you never make a mistake. But there’s almost no reward for success, only for avoiding error. The incumbent banks somehow set up this culture where being successful is all about not screwing up and in the IT context, the way to do that, is to do nothing.

Incumbent risk functions see their role as taking no risk. But surely it’s the top of the risk function to work out how much risk you can take. I read Chris Spark’s interview (CRO of challenger, Atom Bank) on bobsguide, and his take was interesting on the matter.

Certainly, within the technology function there’s no upside to changing things or turning things off or moving the dial a bit, but there’s definitely a downside in your career if you’re the guy standing there when a TSB style crisis happens.

Talk us through Starling’s core banking platform.

First and foremost, our core banking platform was built entirely in-house whereas a lot of firms buy and customise a vendor platform.

We started in late 2015 with two engineers and now have sixty. That will continue to be the strategy to employ our own engineers and develop our own product. Peeling back the covers, the core banking platform consists of 25 different applications which all talk to each other in different ways.

Each component furthers a specific functional purpose; we have one application cluster running cards, another running the ledger, one devoted to payment processing and so on.

These independent applications running as clusters run in the AWS cloud. We rely on different Amazon regions and within those regions Amazon has availability zones which you can liken to data centres. If you like, we’re always on in multiple zones and cities which is a very resilient model in terms of uptime.

Plugged into that is the mobile app, as well as the public API infrastructure and payment services. That’s something that’s not associated with Starling, we have corporates plugging into our payments infrastructure.

It was interesting talking to the regulator back in 2015 where there was a breakthrough moment where they were prepared to countenance a public cloud hosted bank, to which they’d previously not been open.

It’s been a cooperative process between Starling and the regulators on the subject. I like to think Starling has helped move the national understanding to make this possible. There were some brilliant audit questions back in the early days, my favourite being – ‘who has the keys to the server room?’ – well, there isn’t a server room and when I commission server rooms in AWS, I don’t even know where they are.

There were a few tricky meetings to say the least but crucially we wanted to convey that this was an overall lower risk model hosting on AWS rather than all in the basement.

---

What aspect are you particularly proud of?

I’m most proud of the release cycle at Starling. This is tied up with how the applications are developed. We release upgrades for all the different clusters to our core platform daily if not more frequently with no impact to our users.

In order to do this, you have to design the software for failure. By no means did we come up with the idea; the foundational work was done by the guys at Netflix who open sourced a lot of software around the concept of injected failure.

We’ve built the entire platform from the groundfloor to expect things to go wrong. If there are two related applications, we programme each application to react independently should the other go down. The benefit of that is impact free upgrades.

An example of this might be when we switch off old servers. Many of our services use old and new servers and we turn the old servers off when we’re confident the new servers are up to speed.

It’s not a graceful switch off either and the system doesn’t care and continues on. You can effectively turn the server off arbitrarily during the day and the system rectifies itself. If I went into our AWS infrastructure right now and turned off our bank statement services, firstly customers wouldn’t be affected and secondly, the system would identify the loss and reinstate it.

This principle of coping with failure isn’t just about stability, but we also have a delivery cadence; it’s something I have to protect. Internally, one of our differentiators will be the speed with which we can iterate our platform.

The speed with which we can add products and functionalities is good but the most important aspect of my role in the next few years will be keeping that cadence going.

We use a piece of Netflix technology called Chaos Monkey. You run it in production and it goes around finding bits of your infrastructure and killing them. It’ll turn off servers at random or overload databases so that they run out of hard drive; it simulates failure at a much higher rate than you know it’ll occur naturally. It’s an IT inoculation of sorts.

We recently published an article looking at the relationship between challenger banks and tech giants, and particularly what challengers can learn from the tech giants’ work in digital identity.

The tech giants must be looking to get into financial services, but I find it very hard to conceive of a tech giant doing very detailed KYC and the reverse is more likely to happen.

Rather than using your social media account to log into financial services it’s far more likely to use your banking identity to log into other non-financial services. We have strong anti-impersonation, KYC established identities, something the tech giants can leverage.

We’re only just getting started too with our core services. The fun part is asking where we go from here. The future of Starling is going to involve a lot of integrated services, not to be foisted onto customers. Rather customers have greater control over their data and money with access to a suite of financial services; that currently doesn’t exist within banking in the UK.

It’s been happening for years on the internet using one account to log into other services, and that’s what Starling wants to do with its current account, among other things, to save customers time and money.

We’re also looking to get into insurance. The current insurance climate is quite frankly a pain and particularly the services that you only consume annually – home insurance, car insurance etc – they’re never going to get an app onto your phone but they can be a tile in the marketplace. We’d even be able to take out the identity checks and form filling.

How do you avoid an IT crisis?

Have people in the executive team who have strong software experience.

We fundamentally don’t want to see organisations fail. There’s two kinds of failure, catastrophic failure which nobody wants to see and organised failure where customers migrate away in an orderly fashion.

I don’t have an inside account so can’t comment directly on TSB, but what I can say is that the Starling executive team as well as the board have all come from technology backgrounds and specifically software and systems delivery. On the executive team, Anne Boden has experience delivering systems as does Steve Newson (technology director) and other non-IT members who have backgrounds in tech companies in Megan Caywood (chief platform officer) and Ben Chisell (product director).

You have technology credentials throughout the executive team who are used to dealing with these issues. With the board it’s not like they get their information from one point, but rather we can have quite a detailed and multi-perspective discussion on an issue.

What do you look out for when looking for new technology partners?

We have a strong opinion on this, we don’t want to run anyone else’s software. We write our own code and run it. We use vendors for lots of bits and pieces on a SaaS (software as a service) model, but if we’re using their software it’s because they’ve built it, they’re operating it and we just consume the service.

I can’t imagine myself going and buying a piece of software, installing it and managing the upgrades; that’s a very outdated model.

You want people who run a continuous model rather than a project based one. A healthy system is a model with a 12 month roadmap with weekly rollouts of upgrades. An unhealthy system would be a model that was launched two years ago and hasn’t changed since, I’d be uncomfortable with a project based model; if something goes wrong with no one to maintain that system it’s very difficult to rectify compared to a continuously updated model.

Would those vendors necessarily be newer fintechs?

Not at all. We use a mixture of new and old. There are plenty of established fintechs out there that know how to do technology, it’s not just new fintechs around Shoreditch. There are incumbent banks, particularly investment banks, who’ve been around for hundreds of years who know how to do technology very well.

There are also startups who don’t know how to do tech.

What motto would you share with aspiring CIOs that’s helped you throughout your career?

I’m going to steal one from my boss and I apologise for being sycophantic.

Anne Boden has said a couple of times “It’s often easier to do it than talk about it”. That reflects how we approach delivery. You can spend years figuring out how to solve a problem theoretically but learn so much more when you actually start it.

• Read more under:
• BankingTech
• Digital Banking