Core banking: when jobs are on the line, it’s go-lives that count
TL;DR: Replacement of core banking systems is inevitable. Banking is a 24/7 real-time activity yet banks are running on systems that pre-date the internet. The current replacement options are either pre-cloud systems with rich functionality or cloud-based systems with limited functionality; and neither is easy to implement. As a cloud-native system, with rich functionality and fast, predictable implementations, Tuum solves for these trade-offs and, for most banks, it’s an ideal choice.
Ex-China and ex-US, we estimate that around 175 banks replace their core banking systems each year. That equates to an annual replacement rate of 2.3% — or, expressed differently, the average core banking system is 43 years old! To put this into perspective, over the life of a single core banking system, a bank could expect to see 6 CEOs, 7 CIOs and 4 financial crises.
Core replacement is inevitable
This has to change. If the average core banking system is 43 years old, it predates the internet.
The internet has revolutionized banking as it has revolutionized most industries. It has dematerialised its means of exchange (coins, cheques) and its physical distribution points (branches, ATMs), reimagined its forms (standard products) and expanded its actors (formerly banks only), turning it into a set of microservices that are being moulded according to individual needs, seamlessly embedded into our everyday activities, and manufactured and distributed by an ecosystem of players.
Against this profound change in the nature of banking, it is self-evident that COBOL-written, monolithic and batch-based core banking systems cannot keep up. There are three fundamental (and insuperable) challenges.
Scalability (and cost of ownership). Core banking systems were built for in-branch transactions during working hours vs. a world of much higher velocity 24/7 digital payments and an explosion of interactions vs transactions.
Adaptability. Core banking systems were built for a time when banks controlled the value chain, pushing standard products to a mass consumer. This contrasts with the situation now, where distributors have to intimately understand their customers, who in turn expect solutions to be personalised to their needs.
Openness: core banking systems were built assuming the same bank would control the end to end process of creating and selling its own products through its own channels. Today, banking services are becoming increasingly dynamic, sourced from multiple manufacturers, rearranged into composite forms, and distributed seamlessly through the most convenient channels (embedded into the buyer journey).
To address these challenges, banks will need to move to systems that:
- can automatically scale to meet growing volumes of transaction and enquires (from customers and the third-parties they allow to access their information);
- can be deployed natively on the public cloud, to underpin this level of scalability, but also to ensure the lowest cost per transaction;
- can be orchestrated successfully within an ecosystem of systems, offering an event-driven framework for integration, as well as many pre-integrated applications for essential services such as KYC; an extensive set of APIs for interaction; and a consolidated database with an extensible data schema allowing easy, fast (near real-time) and comprehensive querying of data by other systems; and,
- provide a rich set of microservices to allow the functionality of the systems to be composed into different use cases with the best security and maintainability.
Hollowing-out the core doesn’t obviate the need for a core
Like many others, we have advocated for putting orchestration systems between distribution channels and core banking systems.
Our rationale, which we set in detail in this blog, is that an intelligent orchestration platform is needed that binds together systems of interaction (the application front-end and user interfaces) with systems of record (the back-end ledgers) to ensure scalability and to facilitate open banking and AI.
Without an orchestration platform, more logic needs to be put either into distribution channels, which doesn’t make sense since these tend to be presentation layers which change frequently (and are increasingly non-bank, embedded channels) or into the systems of record, which doesn't make sense since these systems won’t scale up to meet the number of interactions and because delivering the right user experience requires understanding information from multiple systems of record. As such, an orchestration platform is needed, which mashes together cached information from multiple underlying systems into a decisioning engine which can serve up the right offers and content, from an ecosystem of partners, into the right distribution at the right time.
Since an orchestration platform takes away much of the load for product arrangement and origination, as well as customer interactions, from the core banking system, it could be argued that core banking replacement becomes less urgent.
However, having an orchestration system as part of a modern enterprise architecture does not necessarily make core replacement less urgent, but it does change the desired attributes of the core system. In other words, the critical decision is not whether to replace, but what core system characteristics are needed.
A modern core system needs broad banking functionality, not vertical functionality, and it needs to work at the highest scalability with the lowest cost per transaction.
Many of the legacy core systems have vertical functions that are made redundant in this new enterprise IT set-up, like CRM or origination capabilities. Moreover, because these same cores are monolithic in structure (i.e. don’t have components that can be deployed independently of each other), the bank pays for functionality it doesn’t need and, worse, this redundant functionality adds to the system footprint and IT processing costs.
Conversely, cloud-native providers are more focused, but can’t support broad use cases. Their microservices-based architectures are highly scalable, secure and inexpensive to run. They also haven’t built redundant or specialised vertical functions which are better handled by app store partners. However, they haven’t created that much banking functionality either, making them unsuitable for complex or universal bank use cases.
Multiple cores may be necessary, but multiple brands should be avoided
Many people make the case for a multi-core strategy. The idea is that banks would operate multiple core systems which would be synced through an orchestration system. This would allow banks to gradually replace existing systems and, while they might end up with multiple cores, this is still a much less fragmented IT estate than at present and reduces the risks of attempting to consolidate too many existing applications at once.
This may be desirable, especially for the largest and most complex banks. However, we would rather expect multiple cores to be only necessary in different segments of a universal bank, such as retail, private and corporate — especially as the orchestration systems seem (for now) to be segmentally-focused. Instead, we suspect this multi-core strategy is used to expediently cover up lack of functional breadth, i.e. what a bank really wants is to orchestrate multiple use cases from the same core.
A lot of people also make the case for introducing multiple brands. The rationale here is that rather than attempting to unpick the legacy spaghetti mess of existing systems, existing banks should create new banks — with new IT systems, new processes, new people and a new brand. This allows them to build from scratch with no legacy technology.
As before, there are cases where this makes sense. However, we would argue that the prism through which to judge this decision is a strategic one, not an IT one. That is to say, where a bank wants to launch a new strategy, such as a new business model (say banking-as-a-service), it can make sense to launch a new business (and brand) and in that case it definitely makes sense to buy a new core banking system. However, it does not make sense in our view to launch a new brand just as a build and migrate strategy for a bank to move its existing customers onto a new technology platform. We have modelled this out for traditional banks and, at best, it leads to long-term duplication of costs and, at worst, it risks creating a kind of bad bank with customers it can’t move and branches it can’t close.
Replacement should be possible, and should be the default
The dirty secret of the core banking market industry is that it is very difficult and costly to replace existing systems — and many newer vendors don’t have the functional breadth to do it. So, we end up in a situation where the industry pushes banks to start new banks, rather than to fix their existing businesses where they have built up sustainable competitive advantages — namely, a trusted brand, a sizeable customer base and a large balance sheet.
But what if core replacement were straightforward and predictable? What if CTOs didn’t desperately try to extend the life of COBOL systems in the hope that they can make core replacement their successors’ problem?
This should be possible and, if it were, it would be the default option for banks, who would loosen the innovation straitjacket imposed by legacy systems, and be able to embrace digitization rather than view it as an existential threat.
Introducing Tuum, reimagining core banking
Tuum is a hidden gem. A new company, most of whose success to date has been in the Nordics, Tuum is not yet a generally well-known brand, but we think that is about to change.
Started in 2019 in Estonia, Tuum is one of the newest core banking systems on the market. It is built on a cloud-native and microservices architecture, making it highly scalable with very low processing costs. However, this in itself wouldn’t make it differentiated. Instead, Tuum’s secret sauce lies in the fact that it liberates banks from the normal constraints they face with core banking systems. Tuum enables banks to replace systems across multiple business lines with a single platform; it allows banks to orchestrate precisely new businesses and business models; and, it offers fast, predictable implementations.
More than core
Despite being one of the newest kids on the block, the Tuum platform is functionally rich. Before starting Tuum, the founding team worked at Icefire (sold out to checkout.com) where they spent years building systems for banks. This gave them deep tech and domain knowledge and enabled them to build out functionality quickly.
The result is a system that already covers much more than core. In addition to all the modules you would expect in a core system — accounts, loan management, limits, fees, etc — the Tuum system also offers extensive payment and card functionality. For instance, the payment platform not only covers payment initiation, processing and settlement with native ISO20022 messaging, but also offers payment aggregation — smart processing and routing across multiple payment processors — and a reconciliation engine.
The Tuum system therefore allows clients to support a broad range of use cases from a single system, as well as manage progress migrations onto a single, multi-tenanted instance of the system. For example, Ferratum uses Tuum to support current, deposit and savings accounts, lending, BNPL, payments and credit cards, while a large tier 2 bank is in the process of migrating one retail business line after another onto its Tuum platform (a single core sitting under a single orchestration platform).
Smart migrations
Not only functionally rich, the Tuum platform is also straightforward to implement even — critically — when it is implemented to replace legacy systems. The average implementation time is 7 months. In the three and a quarter years to March 2023, Tuum sold its system to 15 financial institutions. 12 are live and the three in implementation were all signed within the last 9 months. Further, Tuum supports on-premise migrations, migrations to private clouds as well as, most commonly, migrations to the public cloud.
Fast integrations happen under all conditions. As the Ferratum case shows, fast implementations happen with large scope. Moreover, fast implementations hold even with large customer numbers. LHV UK, which processes 7% of European faster payments, migrated over 5m customer accounts onto the Tuum platform in less than 2 months.
The key to these predictable “smart migrations” owes to combination of progressive renovation using a single core; a configuration-first approach; data migration tools and migration APIs; extensive documentation; and enterprise-grade capabilities.
Business builder
Once live and availing of broad functionality, Tuum customers then have access to rich set of fine-grained controls to build new businesses exactly to their requirements.
Core banking replacement is a means to end. No bank CEO or CTO wakes up in the morning with a burning desire to replace their core banking system. The decision is typically forced upon them by technology obsolescence risks, and success is normally gauged in terms of improving the “run the bank” costs and other productivity measures. However, the real prize of core banking replacement should come in its capacity to set banks free to capitalize on digitization — to innovate freely in response to changing customer and market conditions, quickly launching new business and business models to generate new revenue streams. One such opportunity is to launch Banking-as-a-Service, a whole new field of business.
In its ability to help banks to precisely configure and orchestrate new business lines, the Tuum platform seems unrivalled. Take BaaS as an example. Having worked on many projects, we have seen first-hand the limits imposed on BaaS providers by their core banking systems in terms of being able to offer different setups to different customers running on the same system. Normally, every request for a variation to the standard requires months of development work. Tuum, in contrast, offers an extensive range of fine-grained parameters to allow banks to precisely set up their new businesses, with each tenant having full control over products, pricing and limits, underpinned by a highly flexible account structure, with hierarchies of shared and individual account properties.
A clear gap in the market
Not all banks will necessarily want to choose Tuum. Mambu has built a formidable franchise with fintech firms. Thought Machine, whose smart contract concept allows banks to extend its platform to meet their specialised needs, is a popular choice, especially with tier 1 banks (and especially for greenfield projects). Temenos will, for the foreseeable future, be the premier choice for multi-country roll-outs and in certain segments, like private banking.
But core banking is a $12bn market, big enough for all of these vendors to co-exist successfully. And for the 4,500 tier 2 to 4 banks operating in retail and commercial banking, who don’t have the budget to build a highly complex bespoke system nor have the appetite to launch a challenger bank version of themselves, Tuum looks like a great fit. It will slash their maintenance budget and processing costs, enable them to renovate their business model and unlock new revenue streams. And it will do so with a predictable time and risk to value.
It is this last point which should resonate most because it is the fear of a failed project which stops most banks from acting today. For, ultimately, no matter how many new name logos a core banking vendor may tout, when jobs are on the line, it is go-lives that really matter.
