#35 Thoughts around modernising banks
Framing the different technology decisions that bank's leadership need to think about
Hi all - This is the 35th edition of Frontier Fintech. A big thanks to my regular readers and subscribers. To those who are yet to subscribe, hit the subscribe button below and share with your colleagues and friends. 🚀
This newsletter often acts as my journal where I take notes and share them in public, often thinking about problems that I need to solve. By writing, I both clarify my thinking whilst attracting like minded people to ideate and solve together. It’s been a powerful journey from the beginning given that I’ve made friends along the way who have been so helpful. I think I’m slowly becoming one of the most connected people when it comes to Fintech and banking tech in Africa just by talking about Fintech in public. The power of learning in public has been overwhelming at times and today I continue with the idea of journaling in public.
Right now bank CEO’s have to make major decisions around their technology that may have significant consequences down the line. If the wrong decisions are made, then the bank may lose the ability to compete and serve their clients. What makes this task even more difficult is legacy technology and particularly legacy technology decisions that create an adverse path dependence. It’s hard to unwind some of these decisions because they would have negative P&L consequences despite the fact that they need to be made. Career risk is also at stake, the CTO recommended specific decisions three years ago, but now these decisions no longer make sense.
In high school, when we did dynamic optimisation, we always started with the stated goal then listed the constraints before reaching the optimised outcome. In many banks, it seems that decisions are made backwards, starting with the constraints and then reaching the decision based on the path of least resistance.
The context in which these technology decisions are being made are marked by a number of factors.
A digital world
We live in a digital world where technology defines our lives. This podcast on the Tim Feriss show is a great place to start when contextualising modern life. In it, Balaji, one of the great thinkers of our time talks about how life has changed from 20 years ago. In the early 2000s or late 90s, life was pretty similar to how life was in the 1960s. You would wake up, have breakfast, drive or commute to work whilst reading a newspaper, then you’d get to your office and start work. Whilst at your office, you’d focus fully on work then clock out at 17:00hrs. Thereafter maybe you’d participate in a social event, maybe go to the bar or go to a sports club after which you’d head home and have dinner with your family. The idea is that everything was fragmented into neat time slots dedicated for particular activities. However, if you compare life in say 2005 to life in 2021, things have changed completely. Nowadays, the first thing you do when you wake up is to check your phone. Immediately, you’re socialising, working and maybe even banking first thing in the morning. When you get to work, you’re responding to Whatsapp messages from a family group whilst also communicating with your suppliers or clients on the same platform. Life has converged into a new existence where everything happens simultaneously. It’s an always on, always present blob of time.
The ever present, ever available nature of technology has created similar expectations for banks. Clients expect ever present 24/7/365 availability of banking services. This requires a complete rethink of everything, not just the tech stack but the whole design of the bank. This is why we should always pay attention to neobanks because they were built for the digital world from first principles.
In the past, payments were largely cash based for low value high volume transactions whilst being paper based for high value low volume transactions. Banks were thus built around this reality, a wide branch and ATM network to enable clients to make cash deposits or withdrawals so as to support their daily transactional needs. At the same time, corporate payments were branch based with technology coming in to “digitise” old processes as opposed to making them digital.
In this old payments world, the flow and value of payments was standard and predictable and followed the laws of the industrial economy. In the post-industrial world, payment flows are non-standard and not predictable at the individual bank level. They may eventually become standard and predictable at a macro-level. The technology to support this needs to adjust. Two banks in Kenya, KCB and NCBA have had to shift towards Huawei based platforms for their low value high volume payments.
Both banks were using Temenos and both banks did integrations to M-Pesa for lending and savings. The attendant volumes that came from M-Pesa essentially crashed their Temenos based systems which just weren’t designed for such business. They both migrated towards Huawei platforms that powered both the private cloud and the mobile payments. KCB added Sopra for their lending whilst NCBA partnered with Murong for a microservice based core banking.
It’s a situation faced by many banks with crazy workarounds being implemented to support the systems. For instance, some banks process all their mobile payments on a separate server in real time then post the transactions into their core ledgers during End of Day processes. What this reflects is simply a case of the bank moving into the digital world with legacy technology processes. KCB and NCBA learned the lesson the hard way and made the costly but necessary investments into modernising their payments capabilities.
Regulations and Standards
Market factors are all pressuring banks to change but at the same time, regulatory pressures also abound.
On one hand, regulators are opening up the payments and banking space to traditional non-bank players. This is a trend that is likely to accelerate and converge globally towards a standard fintech regulatory landscape. New licenses such as virtual bank licenses, e-money licenses as well as payments bank licenses like those in India will open up the space to more entrants. In Africa, Nigeria, Ghana and South Africa are all on different trajectories ranging from payment service provider licenses in Nigeria and South Africa with Ghana opening up the space fully to Mobile Money. Kenya opened up the space over 15 years ago by enabling Mobile Money and the results have been impressive with the growth of M-Pesa. Nonetheless, the Central Bank of Kenya is understood to be reviewing the market with a view of enhanced and improved regulatory guidance underpinned by the National Payments System Vision and Strategy - 2025 document.
On the other hand, regulations and market standards are also driving banks to review their technology stack. Some of these include the move towards ISO 20022 for payments which will essentially enable richer message information and power use cases such as reconciliations and more efficient straight through processing. Globally, SWIFTgpi and the move from MT to MX standard expected in November 2022 will also necessitate changes in the bank’s technology.
Banks need to respond to these changes and the response should be strategic and not tactical. The change in market standards such as SWIFT gpi and ISO20022 requires a rethink in the whole customer and payment journey, potentially with payments data becoming the core offering. The introduction of new players will necessitate a rethink of a bank’s role in the financial system. My view is that Fintechs will win the battle of the customer in the long-term and banks should focus on infrastructure and financial primitives as a service. The battle for the customer’s attention is being driven by not only Fintechs but also Big-tech with offerings such as Google Plex. I just don’t think banks have the expertise or tactical agility to win the customer in the long-term.
With the above in mind, banks have both strategic commercial decisions to make which will then shape their technology decisions. In a nutshell, banks have three main options which are well captured by this Deloitte document;
Marketplace Owner - Where banks build out their own propositions including SME banking, consumer banking and maybe corporate propositions whilst offering third parties the capabilities to build their own propositions in partnership with the bank;
Marketplace Partner - Partner with a marketplace provider and rationalise your product offering whilst relinquishing distribution to third party banks;
Pure utility play - offer basic financial primitives such as payments, accounts, KYC/AML capabilities to third parties whilst relinquishing distribution to third parties. A low margin high volume play powered by cheaper liability collection and FX margins;
The above commercial strategies will then impact technology decisions which in my view should focus on;
Core Banking Systems;
Digital distribution frameworks;
Core Banking Platforms
I did an article on core banking platforms 5 months ago that has become the most viewed article on the newsletter. In the article I did a sweeping review of the whole core banking system industry detailing how it got to where it is and why it’s structured the way it is. Additionally, I detailed the different decisions banks have to make when deciding on their core banking platforms. It must have struck a raw nerve across the industry given the number of views it got.
The issue in my view can be distilled into a simple dilemma. On one hand, from a pure technology perspective, it’s clear that lean core platforms such as Thought Machine, Mambu and Vodeno would be the best decision for a modern bank. Nonetheless, these are yet to be battle tested like more traditional players such as Temenos, Finacle, FIS and Oracle. Additionally, the ecosystems of the new vendors particularly in Africa are yet to mature when you consider factors such as implementation partners, hardware vendors and post implementation support.
The middle ground is thus to demand more functionality from your traditional players in terms of APIs, componetisation and containerisation capabilities whilst dumbing them down.
The article I did on “Vodeno and Banking as a Service” and the following answer given was very informative of the benefits of a modern cloud native core banking platform if you want to offer financial services in a digital world.
2. You're a cloud native core banking platform - why is this the right time to be purely cloud native and what advantages do you see accruing to cloud native players like yourselves vis-a-vis the traditional players such as Temenos and Oracle? - The Vodeno Cloud Platform (VCP) operates entirely in the cloud. The fundamental difference with a ‘no legacy’ principle is that we are using the latest development frameworks from the start and do not need to manage previous migration journeys that traditional software houses have to consider. Utilising VCP solutions like smart contracts and real-time data, we are able to build any financial product without the traditional cost burden that is associated with the development of code. This also means we can provide not only real-time insights to our customers but also to all of the down-stream systems, i.e. regulatory reporting outputs, through our ‘curated’ ecosystem of partners. This provides a true account of any customer or business line at any given time. We have one of the best engineering teams in the industry with a mix of talent from both the banking community and best of breed technology players.
This podcast from 11:FS goes further to detail why modern financial technology is being built on completely different principles. Key points from the podcast were around event architecture and the underlying data and reporting advantages.
Review that there are modern API’s for almost every service - for instance, there should be API’s for the whole account journey from creation to dormancy to closure;
Review evidence of the scalability and robustness of these APIs through some sort of automated testing;
Ensure componetisation and containerisation where you can stand up basic functionality whilst acquiring new functionality based on evolving business needs - away from standard bank sales system of the traditional vendors;
Review vendor lock in either from hardware or cloud providers;
Review compatibility with open source platforms such as open source DBs, event architecture as well as API management;
In Africa, Enterprise architecture decisions are nowadays being driven by the regulatory constraints of moving to cloud as well as the costs and resource constraints of cloud architecture in terms of a base of DevOps expertise. From a pure principle perspective, everything should be on cloud. There are few if any technical arguments against cloud deployments.
One issue I always struggle with when thinking about enterprise architecture is the idea of “sizing”. In the old days, when branch based banking was dominant, it was very easy to size your hardware requirements. You could easily calculate the volume of card transactions, expected number of transactions per branch, expected number of SWIFT payments and then project these neatly based on a three to five year growth plan. It all made sense.
However, the internet is based on non-linear growth paths. My newsletter subscriber base has grown on an extremely non-linear path where a mix of exogenous factors such as a famous person sharing the newsletter to his readers or endogenous factors where one of your posts go viral define the growth curve.
If you’re building a bank for the 21st century and offering either Banking as a Service or a pure digital play, you have to be prepared for internet growth. An influencer can in a weekend say something positive about your digital product and you immediately get 200,000 account openings in one weekend. In BaaS you could partner with a major e-commerce player and in one day get 100x your standard payment volumes. The only thing built to handle this is the cloud.
Alternatively, given the regulations around cloud, then maybe the following should guide the thinking;
Moving away from traditional super-machines such as HP and IBM towards smaller more nimble hardware such as Intel or Huawei - I’d actually appreciate input into this;
Reducing maintenance bandwidth by adopting server co-location;
Shifting systems of engagement into the cloud and perfecting the integration of both on-prem and cloud systems;
Modern software-defined architecture from database to storage to networks could enable you to have a private cloud;
Modern tech stacks envision payments capabilities sitting outside of the core platform as opposed to the past where payments were baked into the core system. The rationale for this largely centres around the different customisations that need to be made for different markets as well as the move towards payments capabilities as a differentiating factor particularly given the rise of e-commerce and digital payments.
In the latter, the idea is that a payments hub can enable a bank to design different payment journeys for their customers from end to end. A modern payments hub should also be built around componetisation, containerisation as well as the ability to power both real time transactions as well as older payment formats such as batch and file based payments.
Another core element is message enrichment and the capabilities to provide richer payments data. In the past, payments were largely around ensuring transactions go through. If banks move into the new payments paradigm with this mentality, it may work against them. In the future rich payments data can power new use cases such as improved cash management and forecasting tools for corporate clients.
The vendor ecosystem for payments is evolving with traditional players such as Temenos, Oracle, FIS, ACI and Finacle upgrading their offerings. New entrants include players such as Form3, Currency Cloud and even Amazon Pay.
API Management and the Integration Layer
API’s are the new back-office. This article by Segment gives a very good overview of how API’s are upending the value chain. Essentially, the whole discussion around APIs has to be framed from a commercial perspective. Traditionally, software was an appendage to business and was seen as something that improves the efficiency of traditional businesses. So for instance, you had an order management system which enabled a company to manage their traditional ordering systems more efficiently. As we move towards the digital world, then business logic is defined in the software and the software is the business. Value creation and commercial communication is held together through API’s via a request/response model. The diagram below from Segment gives a good overview. This article by Packy M is also a must read.
Once you internalise and accept this new business model, it becomes clear that API management is a critical pillar for any bank’s future technology strategy. The integration layer essentially abstracts all the underlying complexities of your systems such as core banking platforms, card systems as well as payment systems and presents easy intuitive API’s for both your third party partners as well as internal engineering teams.
Banks can approach this in different ways. Those with big budgets and engineering expertise can take this on and do it internally by building out the integration layer. Alternatively banks can acquire vendor based API layers either from traditional vendors or from new players such as WS02, Kong, Apigee, Axway and Amazon. In this case, it should be open source and cloud based. This partnership needs to go deeper than just API presentation to a partnership with your underlying vendors such as your payments and core banking vendor for long-term API management including retiring APIs, analytics, throttling of traffic and creating new APIs together with the commercial teams.
I did an article on digital banking platforms, you can review this to understand the vendor considerations around this. Digital propositions are hard, many banks in Africa are in the process of creating or launching digital propositions often powered by the likes of Backbase, Temenos Infinity, ODBX, Tagpay or in-built propositions. From my discussions with people in the space, the following are critical to ensure success;
Make sure your architecture can support the platform. Sometimes, digital propositions are built on cloud but then have to communicate with monolithic on-prem systems thus leading to session time-out issues.
Create devops capabilities - when dealing with vendors, they expect specific capabilities from you such as a proper API layer as well as Devops capabilities. There’s no point in having a digital proposition in the modern age and you don’t have full agile capabilities particularly in terms of CI/CD. Agile is not just a buzzword it’s actually a manufacturing process just like Kaizen;
From my experience, be ready for things to break. Recently, the new M-Pesa app was having issues. From my experience, the main issues were around updating balances and confirming payee details for P2P transactions. My wife was adamant when we are paying for Ubers that I use the STK. They’ve recently fixed this issue. I have empathy for the team. They are likely the most talented team in Kenya, but in the digital world, bad things happen. The whole idea behind micro-services and pizza sized teams is that bad things will happen, what you want to ensure is that you can quickly recover and minimise the damage.
Summing it up
The most important decisions will be the strategic decisions from which all the technology decisions flow. I’m actively seeking feedback to the above issues. Particularly;
The best way to design on-prem enterprise architecture;
How to structure long-term vendor based API management for open banking;
Building high throughput payments systems that are robust, reliable and scalable;
Glad to have this chat and you can email me on email@example.com or firstname.lastname@example.org
As always thanks for reading and drop the comments below and let’s drive this conversation.
If you want a more detailed conversation on the above, kindly get in touch on email@example.com