Jost Hoppermann – Like many banks, TSB has been working on digital transformation for some time.
Suresh Viswanathan – For the last 2-3 years we’ve been on a transformation journey from what’s primarily been an analogue company to a digital and data driven company.
During this journey, the first crucial thing we considered is the case for urgency.
Everyone today would say that digital and being data driven is fundamental for any retail business, not just a bank. But what drives the case for urgency is the more important question. Would you need to do it in 5 years or 2 and what drives you to do that program without losing customers and colleagues on that journey? That is primary question.
While there are many ways of creating urgency in an organization, COVID was a big agent for change. You cannot imagine what the proportion of analogue and digital was back in 2020. This was because we were running the company that way and didn’t have all the instrumentation and the telemetry to even find out. So COVID helped us to set the urgency as a key determinant as to why should pick up pace.
The rest of the factors are what you’d hear from everyone – Having a very systematic way of making sure that the customer journey is great at the point of experience, all the teams are getting around the table, whether to follow an agile methodology or not, etc. I’m not a big fan of methodologies or frameworks but rather the outcome of these methodologies. So, for me, that was the big imperative for change.
The second one in the context of TSB was that this company that had the worst press in history in the UK for how to do an IT migration back in 2018.
These two were the most important reasons as to why it was necessary to transform the company from being an example of how not to do things to becoming one that is comparable to peer groups and hopefully outperform them.
Jost Hoppermann – You did mention the need for urgency, and this is something many banks discovered during the early days of COVID for a wide variety of reasons; primarily because they needed ways to digitally access and engage with their customers. At the same time, some banks found it hard to do all this with their existing core solutions.
This brings me to a slightly different view on what you were saying. Because earlier on I believe, you wanted to continue working with your existing core solutions.
Was the plan to modernize the core with digital layers to provide agility and more banking capabilities quicker or was it something completely different that you had in mind? How did you plan to move forward with your core banking solutions?
Suresh Viswanathan – To answer your question, I would start by defining the core a little bit. For example, if you take a retail bank, its core is a credit card, debit card, current accounts, savings account, mortgages, and loans.
What’s very interesting about TSB is that there are different platforms that provide each of these product services for our customers. For example, here, the mortgage platform is different from the card platform, and so on. The way we have implemented functionality for our customers is by joining up these platforms in real time rather than having it all in a ‘Bank in a box’ solution because by then, we had already seen the pros and the cons of different architectures. So that’s the TSB architecture.
What that means for us is that because we are a financial services company, we benefit from a single highway. So, when we decided to connect our various channels such as branch, voice, web, mobile, and APIs to the core platforms, we went with microservices.
So, we’re not concerned about how we are connected to the back ends. That layer doesn’t change and is cloud ready. However, if in the future, we find the need to change the core platform, we can detach and reattach a new core platform for any of our products. Also, because we have adopted a microservices approach, it becomes easy to integrate new products into our ecosystem.
It’s also important to remember that a lot of lending products have a shelf life. If you take an average loan in the UK, people pay it back in about 16-18 months. An average mortgage reprises every three years, and so on.
We also observed that no matter how complex these migrations might have been in the past, they have reached a state where customer risk is decreasing. So, when you use the combination of using a new platform that runs in parallel to an old one, it results in a very safe migration without any big bang stuff.
So architecturally, we are ready and right now we don’t have plans to replace the core platform. What we’re trying to do is be increasingly relevant to our customers.
Currently, we are almost done with our featured capabilities. We have some last mile activities to catch up on digital which will be completed in the first two quarters of 2022.
When we ask ourselves, how can we be more relevant to our customers beyond traditional banking? Can we give them a better experience when they want to insure themselves or buy things? The answer is a marketplace driven approach. This is what we will focus on from the second half of 2022.
Hence, we’re not camping on core. We’re camping on front end and personal experiences.
Jost Hoppermann – Marketplace is something we have been noticing as soon there is a foundation to deliver these digital services. At the time you mentioned microservices. I’d don’t want to drill down into the topic too much but early upon I learnt that you are working with multiple cloud providers like AWS and a couple of additional providers in the field. This is something many banks are asking themselves or don’t know to move forward. What are your experiences with this kind of multi-cloud environment? What have you learnt? What would you do differently today?
Suresh Viswanathan – It has been a journey for us. The first thing we learnt when we worked with cloud service providers is to not try and be too innovative and inventive in terms of how we attach ourselves to the cloud.
We spend a lot of time, energy, and cost inventing standard landing zones for TSB and figuring out why they won’t work for us. Hence, I’d say that a little bit of control in architectural innovation helps when you go the cloud.
The second thing is the trade-off between how you use proprietary cloud functionality versus how you use generic stuff and there is a trade-off that needs to be made. What we’ve always tried to remember here is that if there is a queue of 100 customers that an AWS needs to bring up when they go down it’s unlikely that we’re number one on the list. And in that case, it makes no sense to for us to use them exclusively as a provider.
So that’s the philosophy behind our approach and once you’ve made that philosophical leap of faith, it comes down to how you actually implement it. Therefore, part of what we’re doing from an implementation point of view is to ensure that we’re not locked into proprietary tools. Philosophically, what we try to say is – anything that’s cloud ready, run it on the cloud. Don’t try to run it on premise and then try and take it on the cloud. All our allocation, monitoring, and management platforms, all now run on the cloud without us spending time and energy managing them on premise.
Then, when you look inside out, what you find is that for a lot of organizations, heavy payload is around running access technologies that allows people to connect from their device into the mothership safe and secure. That takes about 40% of our physical footprint. So, when we try to take that technology into the cloud, the front door is there. Then it’s relatively easy to drag rest of the components through.
The second thing is that the microservices architecture that we have is fully deployable across multiple clouds. And one of the things we’ve learnt about banking after being in the game for many years is that for 90-95% of the time, customers are ‘reading stuff’ like what’s my balance, what’s my transactions, where is my chequebook? And 5% of the time, they’re doing what we call ‘write transactions’ like make a payment, add a beneficiary.
Hence, the whole model of resilience on the cloud is architected through that lens with the understanding that 95% of the time your customers are reading stuff. It is very easy to have a read-only repository and you don’t have to worry about how you will beat the physics in keeping yourself concurrent across clouds. Because once a customer is in one cloud, they are in one cloud, and we have a very simple architecture that we are working called the ‘writes’ which we will hopefully implement sometime in the second half of this year to give ourselves true resilience across the clouds.
Very simplistically, in the old world, we all used to run ourselves out of two data centres, but we can’t do the same thing in the cloud. But of course, there is cost of ingress, cost of regress, etc. There is a whole host of commerciality we need to work through in making sure that the operational independence that we aspire for, connects well with the commercial reality.
Jost Hoppermann – I guess this is certainly something that many banks are left to consider particularly those who are not yet on the cloud journey as you are today. That said, let me move back to something you mentioned earlier on focussing on customer experiences and you spoke about the need for a foundation in real-time. At the same point, experiences certainly also need the right software to deliver them – the digital front end because to meet certain needs a solid foundation ought to be around. This is what Forrester calls a digital banking engagement platform – A bit of software sitting on the core for example. Maybe on a microservices layer that helps banks to deliver these experiences. How does TSB work with these digital banking engagement platforms? Did you build them, did you buy them, or did you compose them from a variety of sources?
Suresh Viswanathan – If you believe the theory that we are about to rapidly expand the things we put in front of our customers, we must be very thoughtful. For example, when we look at the world of art, there is a cost involved and an experience that is very different versus the cost of just reproducing stuff. And both have their place.
And the way we are thinking about is that there are probably 5-10 payments that customers to 90% of the time on the TSB app and there about 150 things they might do sporadically, and we can’t have the same strategy to deliver both.
There is one which I would call the scale build and the other what I call the handicraft build. The handicraft is something you can achieve if you get the right number of people to do it. But if we must think about scale, you need a platform.
Therefore, we decided to work with i-exceed and their Appzillon platform. Because once you standardize how should things look and feel in your app where the user cannot spot the difference between the two, then you want your developers to focus on the experience through the content and not the experience through the beautification of the real estate the user sees.
So that’s what we’re tried to do by adopting a tool-based approach.
This approach also gives us insulation. For example, if we wanted to change our name and wanted to do something about how we want the experience to reflect for our customers, in theory you can almost do it with the touch of a button other than the handicraft method where you’d go screen by screen to change customer experience.
Also, with industries consolidating and engaging with merger and acquisition transactions, you must be ready for all of those and what you don’t want to do is be stuck in the long list of small things to do. You want to do the small list of big things and get a tool to do the long list of small things.
Jost Hoppermann – In summary, you’ve gone for an off the shelf apps in those areas where you need plenty of capabilities to standardize recognition factors so that your customers find that the apps are very similar from an experience and UI perspective. Then in selected areas where you feel you need differentiation or need additional capabilities, you build stuff with your own teams.
How do you work with this approach? Is it about using the same engagement infrastructure that you used for the official apps, or do you use something different like a technology stack for your custom build apps?
Suresh Viswanathan – The framework is the same in terms of the customer experience, design standards, library etc. The decision on what are we are going to use for our teams to build versus what is it that you get the tool to build, is something we are evolving towards.
Do we know based on our telemetry where customers spend most of their time? What do they do when they log on? In that sense, what we want to make sure is, for example, if I need to notify customers or give them a marketing call, all of that is in the handicraft model. But if it’s fulfilment then I don’t really need too much of a handicraft model. It’s like I have decided to buy two of this.
Then it’s much easier to say – go execute your fulfilment structure. That’s as evolved we are at this stage and over time, if required, we’d add more in the handicraft model.
One of the other things the tools does for us is suddenly opens the possibility of who can actually build on these tools? The history was that you needed to be a software developer to build screens and develop user experience. But those software developers also need a host of tools for injection of business content. But when you have a tool and business content, then you have given them a standardized framework. When the theory is that these guys can build most of what they think customers need and our lifecycle can become a lot faster that what it is today.
Jost Hoppermann – So basically, you are sticking with your core and putting additional microservices layers on top to create a flexible foundation to add new capabilities at a later point of time. On top of the microservices, you have an engagement infrastructure that you use for off the shelf and home-grown apps and consequentially, it results in a very layered digital architecture. All this opens up your capabilities to bring in more extraordinary capabilities if you decide to do so at a later point in time to work in banking application ecosystems.
Your approach is interesting and to phrase it mildly, I’m sure it will certainly help a couple of people in banks to move forward. So, we talked about your digital transformation journey from a couple of different perspectives, but we haven’t talked too much about what will come next. What are your broad level plans for 2023 and beyond that?
Suresh Viswanathan – There are quite a few things but to start with, we are very clear about customer experience. We are still a couple of quarters worth of work away to say that we are at par with the industry and see where are we beginning to outperform?
Secondly, we chose the right conversational banking platform to connect to our mobile app. This implies that the long list of small things is sorted out and you don’t have to lose your customers in terms of discoverability.
Then we have the marketplace lining up in early 2021 which broadens what we can offer to our customers. Once we have that in place, we’ll be working towards how can we join it all up to make it a full experience?
For example, I can have a payroll platform and an accounting platform on the cloud which my customers can go and buy. But that’s not the problem they’re trying to solve. They’re trying to solve the problem of paying their people and packing their invoices. So, the only way I can make it a full experience is by joining it up in the cloud.
Lastly, an idea we want to pick up in 2023 is to help the economy grow. One of the fundamental reasons why we banks exist is to help the economy grow – We can take money from people who have more or it and give it those who need to expand. However, in a digital world, we haven’t yet connected people in a way that they can help each other and expand the economy.
But yes, delivering retail experiences to our customers broader than banking is our goal over the next 3-4 years.
To know more about Appzillon, get in touch with us: