The incumbent core banking systems: Erstwhile Challengers facing technological obsolescence?
When the first core banking systems gained traction about 25 years ago, they were challengers themselves. Core banking functionality had until then be regarded as – literally – a core capability of a bank’s own IT shop. Specific external solutions – product- or functionality-centric e.g. for lending, payments or bad debt management – had been around for a while and found their way into an increasingly complex bank IT architecture. When the likes of Avaloq, Temenos, Sopra, Finastra/Misys et alt. started rolling out their comprehensive solutions, they challenged the established conventional wisdom of bank IT. And they started out small – gradually adding customers, functionality, and track record. A quarter of a century later, these once-upon-a-time attackers can be considered established – but not yet standard. In fact, the majority of the global banks work without an external core banking system. But as most solutions are in their third decade of existence, the established providers may also face some sort of technological obsolescence. Some ageing becomes visible once you scratch beneath a varnish of recently added digitalization manicure. Where some critics see established core banking systems as “dead men walking” –others -with technology evergreens like Microsoft DOS/Windows or Oracle databases in mind – discern eternal youth.
The natural replacement cycle of core banking systems is probably somewhere in the 30-year-range – so increasingly, not just banks operating their inhouse-developed legacy solutions will need to consider what’s available, but the first generation of banks that moved to a core banking system will review what they have.
So while there is still a lot of core banking market space to be covered, a next wave of challengers has joined the race. Will they catch up? Or even sprint past the established providers? It will depend on how banks will choose between them – and their legacy solutions. How should banks decide?
The promise of the challenger solutions
The challenger solutions – from the likes of Mambu, 10X, fivedegrees, Finxact, etc. – promise in essence three things: More flexibility; faster deployment and lower cost – without compromising functionality or performance.
These promises foot on 4 key features or premises:
- Core Engine Focus: The challengers do neither pretend nor intend to be a “soup-to-nuts” turnkey solution. Rather, they focus on core functionalities and leave it to the banks to finish the solution by adding a wide range of further third-party functionalities of their own choice. Strategically and tactically, this makes a lot of sense – but it also limits the scope of the solution.
- Openness (through API’s, open data dictionary, etc.): Driven by their core engine focus, it is only natural that the challenger solutions embed openness as a key tenet of their architecture. In a banking world where regulators increasingly force openness (see PSD2) in some areas, and customers demand it in others, the times of a closed or semi-open system may well be over. But openness also means that interfacing with other solutions will be required. The value of integrated solutions is a single data model that does not require interfacing – and the expensive maintenance that comes with this. The smaller the scope of the solution, the more effort will be required to make the different parts collaborate with each other.
- Cloud-native solution: The challenger solutions can be deployed in a cloud environment. This could be a significant benefit for banks, as the infrastructure requirements and cost as well as implementation effort should be lower than in conventional, dedicated bank data center set-ups – particularly if it is in a public cloud. Additional mileage could come from truly deploying a single source code which would require only small configuration and parametrization for each bank. However, it is not clear how ready banks are to rely fully on public clouds – IT security concerns seem to linger. Furthermore, it will be a challenge for the challengers to maintain a single source code particularly as functionality and client diversity increases. The established players have been trying this without smashing success over the past three decades.
- SaaS-deployment ability: Software as a Service (SaaS) would allow banks to be much more flexible in the use of the software (turn-on/turn-off) and variabilize the cost. However, a genuine SaaS model is only feasible in a public cloud set-up. Furthermore, the software should be truly architected as a portfolio of services. Barring these two prerequisites, SaaS is just a billing model – not a deployment model. In other words: Yes, you can rent only the penthouse, but we have to build all floors below this onto your lot as well.
Can Incumbents step up to the challenge?
These four challenger key features could also be realized by the established core banking system providers. One can already observe their tendency to more openness coupled with a refocus on core functionality. The cloud aspiration and SaaS are also being pursued by some, but appear to be complex and expensive – but by no means not impossible – to realize for established providers and their existing client base.
Like with any new solution, the core banking system challengers can start with a clean sheet of paper – or rather blank screen – and with the latest technology. Retrofitting the core banking solutions of the established providers will be a more difficult task. It is also unclear how excited their existing customer base will be to move to a different model. Thus, strategically, the established core banking system providers may be forced to pursue a two-thronged approach: Maintaining and evolving their “legacy solution” to keep their installed base happy while creating a parallel solution that mimics the challengers’ approach. Not all established providers might have the financial or human resources to pursue both.
A checklist to help guide banks’ choice
It is a tricky situation for banks to decide which horse to bet on. As always, the right choice will depend on the specific requirements and “pain points” of a bank. We suggest a simple check list to help banks organize their initial thinking. We have also added our hypothesis of how well incumbents and challenger solutions perform against the seven checklist criteria. It should be viewed more as an educated initial guess that needs to be assessed in more detail in each specific case. But it might serve as a good starting point
- Functionality: Established solutions tend to have richer functionality which has been honed and expanded based on a sizeable number of customers for two decades or longer. Challengers will naturally need time to reach the same level of functionality – but may eventually catch up.
- Performance: Non-functional requirements like latency, peak and average transaction volumes, concurrent users, scalability, etc. are important metrics for users. There is no general rule – but beware that modern technology does not by itself mean modern performance. For the established solutions, there will typically be more reference points for specific performance metrics. Furthermore, in a deployed context, banks will have more levers to pull to optimize performance. In a pure cloud-solution, the performance levers must be solved mostly on the provider side -if their engineering is great, that’s a clear advantage. If it isn’t, then there is little one can do about it.
- Connectivity: Established solutions already provide a lot of connectivity and may even have standard adapters with popular other solutions, e.g. taxation, regulatory reporting, market data feeds and others. Challenger solutions tend to be more radical and more modern in their approach. But banks need to beware that moving from connectivity to actual connection requires work and effort. Flexibility has a price.
- Agility: What agility actually is, and how agile established players and challengers actually are is difficult to measure. The rule of thumb is that more complex systems are less agile as interdependencies and underlying construction principles need to be honored. In order to test for agility, banks should specify a number of “agile” use cases and compare the approach and solutions of the different providers.
- Implementation: CIO’s are wary of the risk and cost involved in implementing new solutions. While public cloud-based solutions should have an advantage since they do not require a separate infrastructure set-up, it is not clear that challenger solutions have a general and intrinsic implementation advantage over established players. It is not only the core banking system itself that determines the timeline, cost and risk of the implementation project. Many bank-specific choices and parameters will influence them as well. The state of the system to be replaced, the scope of the new core banking solution and required integration with other inhouse or third-party solutions all have direct implications on the implementation effort.
- Total Cost of Ownership (ToC): This notion should cover all cost aspects over the lifetime of the solution– including acquisition of the software (licences), project cost, as well as operations and maintenance cost. In practice, it is very difficult to come up with the ToC. A good approximation would already be a 10-year modelling, comparing the status quo with an established and challenger solution each to be implemented. A priori, it is not possible to say whether established solutions have higher cost of ownership than challenger solutions. We would also expect that the challenger and the incumbent solution will hardly be an “apples-to-apples” comparison – the intrinsic trade-offs between them go beyond measurability on the cost side.
- Strategic Viability of Provider: A decision for a new core banking system is typically a long-term commitment, both for the bank and the provider. Bank CIOs will want to have comfort that the chosen provider will not only be around for the next two to three decades, but will continue maintaining and enhancing its product. It is impossible to predict how established or challenger providers will fare in the future. But bank CIO’s will need to have a perspective at the time of decision making on the following points: (1) Is the installed client based of the provider relevant and growing? (2) Does the provider systematically involve its clients in shaping the product roadmap? (3) Is the ownership of the company expected to be stable? (4) Is the financial performance of the provider satisfactory? (5) Is there a sizeable pool of experts and consultants which can be relied upon to provide coverage and capacity for this solution?
Our general assessment along the above dimensions comes up with a very high-level view – which leaves a number of white spots to be filled with regards to the challengers:
Should I stay or should I go?
Challenger providers of core banking systems promise to overcome some of the perceived weaknesses of established core banking systems. Providers of the latter, on the other hand, point to what they regard as proven, stable and reliable solutions. While both incumbent and challenger providers beat the marketing drum, the rational bank CIO will diligently examine these claims and assess them rigorously. In the long run, one might expect a convergence between the two camps as their approaches are not that dissimilar. It will be interesting to see who will be faster: The challengers in generating the functionality and reliability of the established solutions, or the incumbents injecting more agility and connectivity into their platforms. The jury is out – and will be for a while.