When you’re a “challenger bank”—a new online bank with no physical branches—the success of your entire business is determined by the quality of the digital customer experience you deliver.

That’s why Tori Wieldt and I were so excited to welcome Paul Clark, CTO of UK-based Tandem Bank to the New Relic Modern Software Podcast. Paul—whose background is in streaming TV, not financial services—brings a fresh, digital perspective to a traditionally slow-moving industry.

Whether or not you’re in the financial industry, you’ll definitely want to hear his insights on why big banks don’t embrace modern technology, why “DevOps teams” don’t make sense, and why artificial intelligence is critical but blockchain is a distraction. And don’t miss his explanation of how New Relic helps Tandem figure out what “good” performance looks like.

You can listen to Episode 25 right here, or download all the episodes automatically by subscribing to the New Relic Modern Software Podcast on iTunes, or wherever you get your podcasts. Read on below for a full transcript of our conversation, edited for clarity:

New Relic was the host of the attached forum presented in the embedded podcast. However, the content and views expressed are those of the participants and do not necessarily reflect the views of New Relic. By hosting the podcast, New Relic does not necessarily adopt, guarantee, approve or endorse the information, views or products referenced therein.

Fredric Paul: This podcast is international, so we were wondering, Paul, can you bring everyone up to speed on Tandem Bank and the concept of a challenger bank? We love that phrase, but it’s not a common one here in the United States.

Paul Clark: It’s a kind of modern bank. It’s only been in existence for a couple of years now. The reason why a bank such as Tandem and other challenger banks in the UK have come into existence is because there’s a perceived monopoly in the market.

There are a number of incumbent banks that all the customers deal with, and there is a perception that customers aren’t getting the best deal. So the people who regulate banks in the UK have decided to introduce a new process by which you become a bank.

It’s called the Prudential Regulation Authority Option B, which allows people like us to be a bank without necessarily having all the regular policies and processes in place. It’s a gauging process that allows us to build our technology and customers and raise funds—and at the same time it goes through a series of gates which eventually led to us becoming a full-fledged bank with a banking license.

We’ve been on that journey for a couple of years. We became a bank in March of this year, and we’ve opened our doors to customers.

Fredric: So where did the phrase come from? I do love the phrase.

Paul: They’re challenger banks because they’re challenging the incumbent.

Fredric: If this is a new concept, what’s your background? How did you end up at Tandem?

Paul: Well, I’m perfectly placed to be working in banking. I spent the last 15 years working in television.

Tori Wieldt: I get it. No, I don’t.

Paul: I came from a background of building TV-on-demand platforms for broadcasters in the UK. So I worked at ITV, I worked at Channel 4, and I worked at the BBC. The BBC has a very modern approach to software development, as do all of those companies. And it’s completely different to how banks do it. Whereas a television company will have like 10, 20 people in a team cranking out code every week, delivering value to customers in small increments, the banks employ hundreds or thousands of people and get nothing out of it.

Tori: A release every two years whether you need it or not, right?

Paul: Exactly. Regular as clockwork, every two years.

What I bring is not an expertise in the banking domain per se. I’ve now been with Tandem for two years, and I like to think I’m getting pretty good at understanding the mechanics of a bank. But what I brought at the beginning was a different way to build software, a different way to test software, a different way to deploy software, a different way to think about how we could deliver value to the customer and know that the customer was getting the value that we had hoped they would get. And what we would do if they weren’t, or what we would do if they were and how we could improve that.

We build software in a lean, agile way because we believe that software and technology is a strategic differentiator. We can’t really compete with the banks on staff; they’ve got more money than us. We can’t compete with them on brand recognition; they’ve got better brand recognition than us. We can’t compete with them on numbers of customers; they have more customers than us.

We can compete with them on technology. The ability to execute technology well is cheaper now than it’s ever been, so if we can leverage that, it provides us with a strategic differentiator.

My background: television, building large TV-on-demand platforms, mass market, millions of customers, fast changing, releasing software every day. Taking that and bringing it to the banking world so that we can ‘”challenge” existing banks and disrupt the UK banking market.

Fredric: What’s your position on the application of modern software techniques like Agile and cloud and DevOps to the financial services industry? Is there any structural reason that those things can’t be used in that area or is it just hidebound tradition?

Paul: It’s hidebound tradition. There’s absolutely no reason why these things can’t be used.

The Financial Conduct Authority in the UK provides us with guidance on how we think about technology and how we should think about the suppliers that we use.

Back in 2015, the Financial Conduct Authority said, “Look, it’s okay to use the cloud, with certain caveats. We definitely have a higher bar than when I was working in the TV industry because we have certain requirements around the right to audit and the right to visit premises. But the cloud providers, all of them—we use Amazon Web Services and a bit of Microsoft Azure—have made provisions for that. They understand the FCA’s requirements and they meet it. They give us what we need to satisfy the regulator.

I worked in an incumbent bank briefly. I left. It was pretty much a waste of my time working there because the things that you would want to do as a modern software development company they didn’t want to do because, “That’s not how we do things here, Paul.” It’s really just inertia.

In these very large institutions you’ve got a guy, let’s call him Dave, and he’s in charge of the data center. Dave’s got 2,000 people running these data centers for him. You say, “Hey Dave, we could probably get that down to like 200 people and move it all into the cloud.” Dave’s probably not gonna be that pleased.

Fredric: It may be good for the company; it’s not so good for Dave.

Paul: People have built their careers in these legacy banks doing things in one way. They’ve been doing it for 20 years. They’ve got five years to go before they retire. Why would they want to change? Where’s the drive for them to change? People say that the big banks are hamstrung by their technology. I would argue they’re more hamstrung by their cultures.

Fredric: Your approach changes a lot of issues for a bank. Since you don’t have physical branches, your apps and your mobile app are your branches. How does that change how you deal with the digital customer experience? Does it change the effort that you put into it and the processes that you use to optimize that?

Paul: Yeah, totally. We don’t have physical branches but we have millions of branches—people’s mobile devices. More and more that’s how people want to interact with us.

People spend most of their time in other people’s apps, so your app has to be as good as other people’s. There’s an expectation. If those other people’s apps are Uber or Facebook or Instagram or whatever your favorite apps are, then that’s the level of sophistication, of smoothness, of customer experience that your customers expect. And when they don’t get that, when they jar up against it, it’s very easy to drop one app and move to another.

Banking is no different. We have the ability in the UK for people to change banks very easily. It’s called the Current Account Switch Service. It’s part of the government legislation. Within 48 hours of requesting a switch, you can switch to your new bank.

It’s becoming easier and easier for customers to just switch banks, so your app has to be good. It has to provide a wonderful customer experience. It has to have low friction and high security. It has to provide the features and functionality that your customers want. And it has to provide them in a compelling way.

The old way of delivering software—pre-Agile, pre-lean, pre-DevOps—where you’ve got your release once every other year whether you need it or not—it’s just not good enough. You can’t keep up with the pace of innovation. You can’t fix bugs. You can’t deliver new features quickly enough. Your customers will leave.

So we don’t cast ourselves as a bank with a digital experience. We cast ourselves as a digital bank. There’s a big difference. We are digital first. Everything we do, we ask ourselves the question, “How does this manifest itself into a digital experience for the customer that is beautiful? Which they will want to use?”

Banks look at themselves as a bank and will give people some digital tools. Those digital tools are actually there to save the bank money because they don’t want you going into branches and speaking to people or phoning them up because that costs money. We have completely turned that on its head. We are a digital bank. Everything we do is led by digital because our branches are in everybody’s pocket.

Tori: So how do you know you’re doing that well? What metrics do you use?

Paul: There’s a multitude of monitoring through the stack. All the way from customer interaction through Mixpanel to gather data about what features the customers are using and build funnels to understand how they are progressing through the journeys that we’ve created for them. To understanding how the app is performing from a systems point of view on the device that it’s running. For that we use New Relic.

We use New Relic all the way down through the stack. Backend services that support the app, through the middle tier, the microservices that we build, the queues that we have, all are getting monitored using New Relic, down to the infrastructure. So we have New Relic Infrastructure agents running in the cloud, that tell us how our infrastructure is getting on. Are we running out of disk space? Is the CPU running hot?

All that’s then hooked up into a series of alerts that are pumped out into HipChat. If we get fatal alerts, then that triggers into PagerDuty. PagerDuty then sends out emails and phones up engineers, making sure that things get fixed.

On the Mixpanel side of things, we have all of our journeys mapped out. We have real-time data coming out of that. Throughout the office, we have our journeys up on big screens so we can see how those things are getting on.

On top of that, we bring in customers into the office every week. We ask the customers, “What do you think of this new feature? Can we do it differently?” Or they look at existing features that may not be performing as well as we thought they would, and we ask them what they think of those features, what can we do differently?

We try and use the fact we are a digital bank to get all the metrics and data out so we can rapidly analyze it and then create better solutions that better serve customers’ needs. We focus on how do we create customer value in the smallest possible increments? How do we tighten up those feedback loops between having an idea, putting it in customers’ hands, seeing it working, and changing it for the better?

Tori: Let’s take a look at your engineering practices. How often do you update your mobile app, and how quickly can you make a change?

Paul: The backend teams are developing API-enabled microservices, and most of those teams are releasing every day, a few times a day. From committing a code change to putting a build into production, probably in the region of 20-30 minutes.

On the mobile side of things, we don’t want customers updating their apps all the time—draining their battery or using all their data —so we release only about every two weeks. Internally, we’re releasing it three or four times in that period

Fredric: So you could do more of those if you wanted to, but you’ve decided that that’s the right rhythm for customers.

Paul: The thing is, you have to build software in a way that allows you to push out change as often as you want. Because if you push out a change and something goes wrong and you can only push out a change every three months, guess when you’re going to fix the problem? In three months’ time.

If you build software to push out changes all the time, you can choose when to release it. If I choose to release it fortnightly, but I can actually do it in an hour, should something go wrong, I can fix it in an hour. That’s how we think about creating software and how we think about doing releases. We create software so that we can deploy all the time, and then we choose how often we wish to deploy.

Tori: So tell me, do you have QA teams? Do you have SREs? How DevOps-y is your organization?

Paul: We don’t have QA teams. We have engineers. We don’t have developers and testers. We have engineers. And we expect engineers to write quality code. And that includes demonstrating the quality of the code through automated testing.

We do support the engineers with test devs, software development engineers who test. These people are responsible for helping develop the framework, thinking about what framework and tools we should be using.

The hard part is making sure that the test artifacts support the test automation. If you’re originating a credit card or savings account, you use lots of systems working together to determine whether or not you have a credit card, which APR they would get.

Recreating that data so that you can run that test over and over is quite complicated. So we hand that task off to the test devs and say, “Can you please go away and work out how to create the test artifacts that are required to support the testing?”

If you want to release agile, lean code as often as you like, you need massive amounts of automation and that automation runs all the way through the stacks. So you say, “Do you have DevOps people?” We don’t have DevOps people because DevOps aren’t people. DevOps is practice.

When we talk about DevOps, what we’re really talking about is automation. How much automation do you have? Well, the answer is simple. Just automate everything. Automate your infrastructure. Automate your build. Automate your testing. Automate your deployment. Automate your monitoring. Automate your logging. Automate your alerting. Automate everything. Automate all the things.

We follow DevOps practices. The closest thing we have to a DevOps team person is the platform engineers. We have specific roles in the team. Platform engineers are responsible for automating the infrastructure, automating the build pipeline, automating the monitoring, logging, and alerting. And again—T-shaped people—the developers are involved in that as well, but the platform engineers are the experts.

Fredric: Got it. How does New Relic play into all of that?

Paul: We use it end to end, from front to back. We use all the products from New Relic, more or less. The one thing we don’t use is New Relic Synthetics. We use pretty much everything else—front to back—and it’s a key tool for us.

It gives us a single place to go to see the state and the health of our systems all the way from top to bottom. And then it plays a crucial role in setting thresholds of what we think “good” looks like. When that threshold is breached, we can alert somebody.

We have a very complex state of interacting microservices, of asynchronous messaging, CQRS, and it’s all synced. We need to know when things aren’t working as they’re supposed to work. But at the same time, if we were to spend all our time looking at our systems to make sure they’re all working okay, we wouldn’t be doing anything else.

With New Relic, we automate the process of monitoring our state and we automate the process of it telling us when something goes outside the norm. It’s not perfect, there is no perfect. Not often, but things do get missed. Things happen that we’re not aware of. Part of our wash out procedures—when we have incidents—is to understand whether the monitoring was sufficient and if it wasn’t, enhance it.

We also use New Relic for our journey dashboards. A lot of the time we take people through a multi-stage process. We want to see them go from applying on the website, to being credit checked, to being KYC [know your customer, making sure we know who they are].

When we know that they are traversing multiple steps in the journey and those steps are driven by different services, we can automate the journey monitoring and see whether people are falling out at particular places.

If we see them falling out at particular places, we can get the product team and say, “Hey, people seem to be falling out here. You should go and have a look in the more detailed logs in Mixpanel.” We can say, “Well, why is that happening there? Is there an issue with that service?” Again, that’s all up on big screens around the office, constantly cycling through different dashboards, the underlying microservices, state of the underlying systems. There’s a visual reminder of how the system is, but it’s also connected into HipChat, so if something does go wrong, you see alerts in there immediately.

Fredric: What’s the next step beyond creating a fast, easy-to-use, highly available mobile banking app? Where does a challenger bank like Tandem get competitive advantage after that?

Paul: That’s a really great question. We’re a digital bank, but we don’t want to be your “bank.” We want to be the service that helps you understand money better. By helping you understand where you can save, how to spend better, what product to have at one point for the thing you’re trying to do—that helps you not get stressed by money.

Tori: Oh, if I can figure that one out …

Fredric: If you’ve got that, I’ll sign up across the pond.

Paul: Money stresses people out. Mainly because people like to spend money, but people don’t like to spend time with money. They can’t be asked to sit down with their spreadsheets and calculate their bills coming and going. If you think about it, it’s nuts! Why should they?

Your bank has all of your data. And really, if you take that data and apply some machine learning to it, do some analytics, you can begin to understand how people interact with money and help them do that better so they’ll have more of it and they’ll worry about it less.

At Tandem, we want to take that data—we are building machine-learning models to understand how people interact with money—and then help them have the right products at the right point at the right price. For instance, say you want to go on holiday? We can detect that you’re probably going on holiday because we can see that you’ve booked a villa or you’ve booked a flight or something like that. We can intervene in a friendly, helpful way and say, “We think you’re about to go on holiday. Can we help you do that better?”

We can also see that you had a bad credit card and that if you use that credit card when you go abroad, you’ll get charged fees. So we can offer you a better credit card. We can help you save for that holiday. When you come back, we can help you repay anything that you’ve spent on that holiday.

It’s not about being a better bank, it’s about being a better help for you when you spend your money. The reason we have a banking license is so we can provide you with really good products, but what we want to do at Tandem is not to be a better bank. We want to be a better friend in your pocket that’s looking out for you, making sure you’re not having to worry about money because we’re worrying about it for you.

Tori: So, Paul, I want to ask you about blockchain.

Paul: There are some areas where blockchain is absolutely a no-brainer. When you’ve got multiple companies that want to interact with one another in a way that doesn’t require a central authority, blockchain is absolutely perfect. Settlements between organizations is a really good example.

However, if you’re within a single institution like Tandem, then blockchain doesn’t make a lot of sense because there are no distributions, no distributed ledger. So we don’t see any immediate use cases for blockchain in Tandem, but we will continue to explore it. We’ve thought about it; we might go back, but right now we’ve got other fish to fry.

Fredric: If I’ve got this right, you’re bullish on AI and machine learning and still unsure on the ultimate value of blockchain.

Paul: I think that’s a fair summary. AI and ML, there’s a clear link between having someone’s data, finding interesting patterns in that data, and helping them understand their spending so they can spend better or save better. Blockchain has less of a link between technology and customer value. We could go into blockchain tomorrow for blockchain’s sake and a lot of people would go, “Oh, that’s great.”

Tori:  Hashtag. Buzzword, yeah.

Paul: Blockchain. Yeah, buzzword: tick. Yeah, valuation goes up: tick. But right now we believe that there are other things that we could do that would deliver more value.

 

If you like what you hear, be sure to subscribe to the New Relic Modern Software Podcast on iTunesSoundCloud, or Stitcher.

Note: The intro music for the Modern Software Podcast is courtesy of Audionautix.

fredric@newrelic.com'

Fredric Paul (aka The Freditor) is Editor in Chief for New Relic. He's an award-winning writer, editor, and content strategist who has held senior editorial positions at ReadWrite, AllBusiness.com, InformationWeek, CNET, Electronic Entertainment, PC World, and PC|Computing. His writing has appeared in MIT Technology Review, Omni, Conde Nast Traveler, and Newsweek, among other places. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!