Thought Piece // Financial Service

Core Banking System selection remains a difficult trade-off decision

Thought Piece // Financial Service

Core Banking System selection remains a difficult trade-off decision

Our 3 Key Take-away's

Two types of vendors are successfully competing in the still growing core banking software market. Established providers offer comprehensive out-of-the-box capabilities and have modernised their platforms into modular, integrable, cloud-enabled solutions, while newer providers use cloud-native, microservices-based architectures that emphasise flexibility and agility, but offer fewer features and require third-party integration for a broader range of functionality.

Selecting core banking software demands balancing five key trade-offs: out-of-the-box functionality vs. modernity and highly flexible architecture; cloud, hybrid, or on-premise deployment; single- vs. multi-vendor strategies; transformation approach; and licensing, operational, development costs and internal skill availability for the chosen approach.

Banks should select based on their long-term strategy, determining which areas need differentiating features and flexibility, which can rely on standard functions and have a lower change rate.

1.           Core Banking Market Overview

The market for core banking projects is still large and growing. Different market analysis indicate CAGR between 12%-17% globally until 2032/2033 whilst the European growth rates are around 7%-8% , elevating the current global market size up to  20 billion to 50 billion by 2030 On the one hand, there are still many incumbent banks that are running on older technology stacks and are now reaching their architectural and technological limits in terms of their ability to adapt to new market needs and fulfilling the expectations of their customers. On the other hand, there is still great potential for ”non-traditional” financial service providers that require core banking systems.

The provider market for core banking systems (CBS) is roughly divided into three segments:

      I.        Traditional CBS providers (founded before 2010) who have driven technological modernisation forward in recent years, so that they can currently offer an architecturally and technologically solid platform with a wide range of functions. As sales figures remain high, these manufacturers have sufficient resources and capital to continue working on the modernisation of their platforms. Examples are (not a comprehensive list):

Fig. 1:     Examples of traditional CBS provider with comprehensive technological modernization


     II.        New CBS providers (founded after 2010) have developed banking solutions based on current architecture paradigms in recent years. However, these are mostly functionally focussed on individual products and customer segments (like consumer banking). They offer partially excellent solutions with outstanding features in these areas. In general, the functional scope is limited compared to the traditional CBS providers which have the longer trajectory of amending features to their platforms. Examples are (not a comprehensive list):

Fig. 2: Examples of new CBS provider


    III.        Traditional CBS providers that have not carried out a comprehensive technological modernisation yet and remain active in niche markets (regional, customer segments, products) up to today. While they are still offering a wide range of functions, their architectures fall behind actual market standards in terms of modularisation, integration capabilities, cloud utilisation and flexibility regarding changing market requirements Examples are (not a comprehensive list):

Fig. 3: Examples of traditional CBS provider without a comprehensive technological modernization yet


Additionally, many leading neobanks, e.g. Revolut, Monzo, TradeRepublic, with excellent banking product offerings in their specific market segment have built their own platforms, which are not available as tech products).

Based on our 20+ years of CBS market observations we strongly believe the provider market going forward will see a convergence of “Traditional CBS providers with modernized technology basis” and “New CBS providers based on state-of-the art technology basis”.

Traditional CBS providers with modernized technology basis

Traditional providers (such as Temenos, Oracle, Finacle, Intellect Design Arena, ...) originally developed their solutions around the turn of the millennium. Solutions that are essentially based on relational databases and application servers. These established solutions, with their functionally comprehensive but typically monolithic architectures, became a bottleneck in the further development of bank architectures in the mid-2010s - with an excessively slow rate of change and high integration costs, etc.

Due to their history and widespread use in the market, the traditional providers offer extensive out-of-the-box functionalities that cover a wide range of banking products from retail to commercial banking. In addition to standard products in the retail business (current accounts, cards, payments, consumer loans and mortgages), the core banking systems are also able to support complex products in corporate banking, such as syndicated loans, extensive collateral and asset management and project financing out-of-the-box. They also support all customer segments - from private customers, SMEs up to large corporates, including their complex authorisation structures. The offering is complemented by additional support functionalities such as risk management and document management, which are not part of the narrower functional core banking scope but are nevertheless required to operate a bank.

In recent years, these providers have worked intensively on modularising their former monolithic cores and expanding integration options. Comprehensive APIs are provided to better integrate the core banking systems with surrounding IT-systems. Events generated by the core to support event-driven approaches. Integration into streaming infrastructures such as Kafka is also becoming a common capability of the platforms.  This enables feeding of modern data and analytics platforms and other IT systems with real-time data from the core. At the same time, the classic ETL batch-oriented methods are often still available.

Alongside the integration capabilities improvements through APIs, we see a strong push towards better modularisation of the former monolithic architectures. To achieve this objective the philosophy is shifting towards a "clean core" approach: adaptations and extensions of the standard are no longer implemented within the core (as custom code), but in external systems integrated via APIs, events or streaming. In consequence the core banking processes remain largely standard and unchanged. Differentiating and often changing processes for the bank (e.g. customer onboarding or product origination processes) are therefore implemented outside the core in modernised architecture frameworks.

In addition to modularisation the established providers have developed further platforms based on micro-services for modern customer frontend realizations and state-of-the-art customer-related processes (e.g., onboarding, origination).

Technologically, the core components continue to be based on relational databases and application servers. With the spread of virtual and cloud environments, the components have been containerised so that they can be operated in cloud environments or on-premise depending on the IT strategy of the bank or sometimes on regulatory requirements to be fulfilled. However, some of the components, e.g. the database, are still quite large. Its rather cloud enabled than cloud native. Operation in containerised environments makes use of the scaling and high availability mechanisms of the container infrastructure and modern database software. Most vendors now also offer SaaS solutions for their products in specific markets. For new functions, many established providers are increasingly favouring the option of offering these either primarily or exclusively as cloud solutions.

New CBS providers based on state-of-the art technology basis

The new providers' platforms (Mambu, 10xBanking, Tuum and ThoughtMachine, Innus etc.) are based on modern technologies and architectural principles from the outset. They all pursue an API-first approach, utilise cloud-native, event-driven architectures and build on microservices and composable architectures. Overall, this architectural approach aims to further decouple individual - much smaller - components and make it easier to expand, update or replace individual function modules. In addition, the finely granular components can be operated and scaled more precisely in virtualised or cloud environments. Overall, this approach promises to enable a more flexible and agile response to changing conditions.

From a functional perspective, the newer providers’ platforms grew out of a retail consumer banking focus or other specialized areas, which means their feature sets remain limited compared to those of traditional providers. Typically, they include product configuration, customer administration, account management, payments and the issuance of debit and credit cards. The functions are sometimes augmented by innovative features that established providers have yet to adopt. With the growth of the new providers, they are gradually expanding their feature scope –step-by-step together with their customers. Creating market trajectory is therefore of upmost importance for the new CBS providers to establish themselves for a successful future positioning in the market. The new providers generally deliver a lean core - and in most cases only that. Other functions such as the implementation of user interfaces, customer facing processes (onboarding and KYC, origination), risk management, compliance reporting and payment transaction integration must either be created by the bank itself or can be obtained and integrated from other providers. This enables the development of unique solutions that are specifically tailored for the respective optimized user experience.

Originally designed for cloud environments, these solutions are fully cloud-native and are therefore provided as either Software as a Service (SaaS) or Platform as a Service (PaaS). They are typically cloud-agnostic and compatible with major hyperscalers such as AWS, Google Cloud, and Microsoft Azure. Some providers also support operation on the OpenShift stack or Kubernetes, which enables on-premise installations. The exact operations models depend on the provider.

The market has sorted itself out for traditional providers throughout the last 20+ years. Providers that have comprehensively modernised their platforms continue to have high sales figures. Others, with less extensive modernization stay in their niches or leave the market through acquisitions by larger players which then transition the customer base into their core product.

The new providers – most of them founded after 2010 – each has yet a limited customer base. They are all usually externally financed by the incubators of large banks or Venture Capitalists. When the organic growth of the core banking market slows down, a consolidation of the new providers is to be expected over the next few years.

CBS Provider

Founding Year

Key Investors

Key Clients


2011

CommerzVentures, Kizoo, Point Nine,
Bessemer Venture s, TCV, EQT, Tiger Global

N26, Raiffeisen, Banco Estado,
ABN Amro

2014

ING, JP Morgan Chase,
Standard Chartered, Lloyds Banking

Lloyds, Standard Chartered, SEB

2016

BlackRock, JO Morgan
Chase, Olyver Wyman, CPP

Chase, Westpac, Old Mutual

2016

Visa, Amazon, Softbank, Accel

BTG Pactual, Citi Nicaragua,
Dynamoney

2019

CommerzVentures,
Portage Ventures, Citi Ventures

LHV, CrediNord

Fig. 4: New CBS providers (not comprehensive)


Overall, we can conclude that the CBS provider market remains fragmented with many players globally, regionally and also very locally positioning their offerings. Within this fragmented environment the new players are capturing market share but with an overall growing volume we also see the traditional vendors are evolving their products, but they are not in general replaced by the newer providers. Both segments of the provider market have specific challenges to address in order to be well positioned for the future especially as a vendor consolidation must be expected at some point in time.


2.           Bank’s challenges for selection of the right core banking systems

Determining the right strategy for the introduction or replacement and further development of a software platform for a bank remains a complex task with decisions – meaning difficult trade-offs.

There are essentially five trade-offs to consider:

Functional width and depth compared with modern technology, flexibility and agility

Generally traditional providers offer extensive functions based on solid technology with good flexibility and cloud scalability, while new vendors excel with their modern composable architecture paradigm, cloud-nativeness, flexibility and agility.

New CBS Providers

Traditional CBS Providers

Lean core with focussed functionalities
depending on the vendors origin
(e.g. consumer banking)

Extensive range of out-of-the-box
functionalities available in core banking
and surrounding capabilities

For functions outside the lean core
either solutions of other provides need
to be integrated or they need to be built
by the bank itself

Functionality is often available as module
in the CBS or offered as separate solution
built with modern architecture principles
(e.g. for experience management)

Composable architecture with finer
grained microservices

Modularised core. Compared to the new
vendors the modules are defined in larger
coarse-grained segments

Cloud native, highly flexible and
agile deployment options with
excellent scalability

Containerized, cloud ready solution with
partially large containers, but good flexibility
and scalability

Excellent integration capabilities using
APIs, events, streaming etc.

Good to excellent integration capabilities
using APIs, events, streaming etc.

Fig. 5: Functional and architectural trade-offs between new and traditional CBS provider


However, the line is blurring. With growing market penetration (and time) the new vendors offer a broader set of functional modules while traditional vendors enhance their integration capabilities allowing for easier integration of specialised platforms (e.g. experience management platforms).

Fundamentally the trade-off between “Functional richness out-of-the box” versus “Maximized flexibility through composable architectures” can only be clearly decided if banks explicitly clarified their own differentiating factors in the market.

The following graphic shows an example of the comparison between three CBS manufacturers in a real project

Fig. 6: Example evaluation of core banking system


Operational Model: Cloud (SaaS, PaaS, IaaS), on-premise or hybrid operations

The options which are offered by the various providers for deployment and operations are different, depending on the provider:

New CBS providers

Traditional CBS providers

Develop their core banking modules "in the cloud
for the cloud"

Offer virtualised and containerised
environments

Usually run in the cloud environments of the
hyperscalers (AWS, GCP, Azure)

Support on-premise and cloud deployments
under bank responsibility

Mainly offer them as SaaS or PaaS solutions

Only some vendors offer SaaS options in
selected markets.

Only some vendors offer on-premise operations
(via OpenShift or Kubernetes), however the
operational model for on-premise installations
are very specific for the individual vendors


Fig. 7: Deployment and operations comparison of new and traditional CBS provider


Since the solutions options are different for cloud or on premise installations banks need to assess early which operational models are feasible regarding the following key aspects: regulatory constraints, IT strategy principles, in-house available talent, further general risk perspectives for operating the IT core of the bank.

Vendor landscape: One major Vendor vs. Multiple Vendors

Beside the technical integration aspects discussed above, the overall vendor landscape necessary to cover a required scope of functionality must be considered by the bank’s decision makers:

The new CBS providers often offer a focussed "lean and standardized core" with very good integration options, but no more than that. Additional functionalities required in the bank must therefore be purchased from additional providers or created by the bank itself followed by an integration effort under the bank’s responsibility. In this case, a larger number of vendors / solutions need to be managed on a permanent basis with technical, operational governance and cost management aspects.

On the other hand, the established vendors offer a wider range of functionalities out of the box by themselves, reducing the number of vendors to be managed, but results in a greater vendor lock-in.

 Transformation approach: Transforming an existing CBS or add a Sidecar

Banks which already have a core banking system must decide to either replace the current core banking system or to introduce a new banking system for a new product offering (as a sidecar).

A complete migration of an existing core banking solution to a new core banking system is usually a complex and cumbersome process with high effort on business and IT-side. A major effort in a core banking transformation to assess all current processes in the actual system, compare them to the standard functionality offered by the new system and define the changes. The second high effort task is the migration including long running contracts and long-lasting transaction histories. Also sometime require to setup functions which are only used by old existing contracts.

All these aspects and more must be considered due to the nature of the banking business: is a complex domain in which numerous capabilities from the customer interface to initiation and service processes, transactional postings and reporting must be transitioned consistently from an old IT environment to a new system landscape.

In a sidecar approach the new core banking system is introduced for a new product offering or for targeting new customer segments via new channels or expanding into further regions/ countries. The new offering will be processed in the new system, whilst the existing business (customers, products etc.) are still served in the existing core banking solution. With proceeding time existing products or customer segments might be migrated step by step to the new solution. This approach has significant less effort for the initial setup of the new system but need to operate two banking systems in parallel for a decent amount of time. Typically, the downstream risk management and reporting needs require an integration of data from the different CBS environments which can quickly become challenging and costly for the daily banking operations.

Third option is to refocus a bank’s existing core banking system to a clean core and move differentiating functionality in dedicated (specialized) modules outside the core. This effort starts with the enhancement of the integration capabilities of the existing core banking system, ideally as an upgrade by the system provider and carve our existing functionality step by step. Once the core is “cleaned” it might be a more suitable starting point for a full replacement with a new solution.

Frequently experiences showed that for existing banks with grown IT landscapes based on “rather old” core banking solutions the path into a modern landscape including a new CBS is the more decisive trade-off than the selection of the future CBS product.

Licenses models and costs

The costs incurred for the implementation, licensing and operation of the core banking solution is certainly an important factor in the selection of a core banking system and the neighbouring systems.

The favoured commercial model is increasingly establishing itself based on subscriptions composed of an annual fixed base fee plus usage-based fee (per account, per transaction, pre volume or value processed, etc.). Thus, cost must be negotiated carefully based on the assumption regarding actual and expected volumes. It is always the aim to find a smart balance between flexibility, sharing the benefits/ risks, stability in future costs, etc. Some established traditional providers continue to offer models with a perpetual licence, supplemented by separate maintenance costs.

In our experience, license and implementation costs do generally not depend on whether a traditional or a new provider is preferred. Rather, the costs depend on the specific offers for the respective scope of the core banking implementation or transformation. TCO comparisons based on well-defined business scenarios for a duration of 5 years incl. sensitivity simulations prepare a transparent and structured view on the expected cost associated with the core banking system. Putting this into perspective with the expected revenues generated from the banking products processed within the platform ensures clarity regarding the relevance of the cost aspect compared to the other trade-offs described before.

The following illustration shows the cost comparison for the core banking selection for a greenfield set up of a new bank. Absolut numbers are arbitrary, relations between numbers reflect the actual cost indications. Numbers include the cost directly related to the CBS, no additional project cost, nor cost for substantial add-ons.

Fig. 8: Comparison of cost indications for a core banking project


3.           Recommendations for banks selecting a core banking system

The selection of a core banking system is a strategic decision that will characterise the bank's capabilities in the market for > 5 years.

Strategic selection

A comprehensive definition of the strategic direction for the coming years (> 5) is therefore necessary

  • Determining in which areas (products - structure and conditions -, customer segments, user experience, data-driven, etc.) the bank wants to differentiate from others and in which parts not.

  • Analysing the required flexibility and agility for the various business domains. What are the areas in which the bank needs to react quickly and flexibly to external changes in the future and the areas in which slow change is sufficient.

  • Definition of the operating model for the new banking platform, in particular which parts (functional and technical) can be sourced externally, and which parts should be developed by the bank itself. This includes an assessment where individual best in class solutions are required for the business model and in which areas good standard functionalities are sufficient. 

  • Clarification of the regulatory and internal framework conditions regarding cloud usage.

Selection of core banking software

  • Clarify whether the bank prefers a comprehensive, ready-to-use solution that is less flexible and not at the forefront of technology, or whether the bank wants to work with a highly flexible, composable architecture in which missing functions must be developed internally or integrated by third-party providers.

  • Verify that the software to can be developed and operated in the desired/required operating model (SaaS, PaaS, cloud under own responsibility or on-premise)?

  • Ensure that sufficient resources are available on the business and IT side for the areas that require the bank to develop specific functionalities in the areas in which the selected core banking software does not offer sufficient support. This includes all relevant business and IT skills.

Transformation path

Regarding the transformation path, i.e. in particular the question of whether the existing core banking system can remain in place in parts (sidecar) or must be completely replaced, the following topics should be analysed

  • What integration options does the existing core banking system offer in a modern architecture aligned with current paradigms (APIs, events, streaming, etc.)?

  • Can sub-functions be removed from the existing core banking system and redeveloped externally (with new technologies and platforms) in a customised way? In this way, the core banking system is gradually returned to a "clean core" without having to migrate it.

  • Can new differentiating functions be integrated into an existing core banking system with the existing options?

  • Does the remainder offer enough functions to continue operating for a while, so that a gradual migration is possible?


4.           Conclusion

In conclusion, selecting and implementing a new core banking system is not a one-size-fits-all endeavour. Each financial institution must define its unique market strategy, decide which functional areas require the highest degree of flexibility, and assess the operational model that best fits its regulatory and organizational requirements. Whether opting for a comprehensive yet less flexible solution or pursuing a lean, modern architecture requiring more internal and external integrations, the goal remains to strike the right balance between functionality, technology, and cost. By setting clear priorities and developing a carefully phased transformation path, banks can ensure that their chosen solution supports both current needs and future ambitions.

About the author(s)

Senior Expert Advisor

Dr. Carsten Wedekind

PhD in atmospheric physics with 30+ years of expertise in IT architectures and engineering solutions; special focus on financial services and manufacturing industries. Former professional work at SAP, CORE and EPAM.

Senior Expert Advisor

Dr. Carsten Wedekind

PhD in atmospheric physics with 30+ years of expertise in IT architectures and engineering solutions; special focus on financial services and manufacturing industries. Former professional work at SAP, CORE and EPAM.

Managing Partner

Christian Böhning

25+ years of experience in top-management consulting for IT strategies, enterprise architectures, and organizational enablement; special focus on the financial services industry. Former professional work at SAP, McKinsey and CORE (Founder and CEO).

Managing Partner

Christian Böhning

25+ years of experience in top-management consulting for IT strategies, enterprise architectures, and organizational enablement; special focus on the financial services industry. Former professional work at SAP, McKinsey and CORE (Founder and CEO).

Meet Amaranth

Is increasing tech complexity an issue?

Let's discuss how we can help your organization navigate complexity and achieve lasting success.

Meet Amaranth

Is increasing tech complexity an issue?

Let's discuss how we can help your organization navigate complexity and achieve lasting success.

Sign up for emails on Amaranth quarterly articles

Never miss an update. We'll email you when new articles are published.

Sign up for emails on Amaranth quarterly articles

Sign up for emails on Amaranth quarterly articles