Core Banking Radar
Neo Core Banking Systems and their importance for the IT Architecture of the future
In cooperation with the Business Engineering Institute St. Gallen (BEI), the Core Banking Radar of Swisscom has been monitoring the system support of banks since 2017 and analysing the most relevant systems for the Swiss market using a comprehensive assessment model. In relation to this, 13 core banking systems have already been thoroughly examined and documented.
Text: Christine Popp, BEI, Images: Wendy Buck, Zense GmbH,
Switzerland's banking landscape is currently comprised of 243 banks (source: Statista, 2022), almost all of which run a core banking system from a well-known manufacturer. The systems cover the needs of an entire bank and have different focal points from a functional and architectural perspective. A few, such as the two big banks, have their own core banking system.
Various trends, such as the increased level of networking towards ecosystems and embedded banking, will shape the bank of the future. To provide services along the entire "customer journey" (the process customers go through), banks must also face core IT challenges that are constantly changing. The continuous anticipation of change requires forward-looking flexibility and steady investment in the banking architecture.
This article looks at system support for banks and what it will look like in future in an increasingly connected world.
Trend: Networking in Banking
Mr and Mrs Schweizer are increasingly uncertain about their pension provision and mention this during an appointment with the bank. The customer advisor goes into the possibilities of a life insurance policy and explains its conditions if one of them were to become disabled. They sign the contract directly in the bank.
This is what a customer journey in "pension provision" could look like.
Against the backdrop of increasing uncertainties, consumers are also demanding an overall view of their financial security in the digital world. Initiatives such as the Swiss Pension Cockpit, which provides an overall view of the three pension pillars, are already addressing this.
In addition to this, the use of IoT, and therefore the networking of physical goods, is gaining importance in services for consumers. In the grocery shop they want to pay with their smartwatch, their car insurance company grants a discount based on the driving behaviour measured by smartphone, or the train distance they have travelled is debited directly from their bank account. Which providers are behind this, and the fact that it requires networking via various interfaces, does not matter to the large majority of customers. The main thing for them is that it is convenient and fast.
The traditional customer journey no longer looks at a customer's relationship with the bank alone, but instead at event-driven interactions with the clientele. Banks try to generate additional customer value through their positioning in ecosystems, for example, by offering insurance based on specific situations. For example, in a "holiday" customer journey, it would be conceivable to offer Mrs Schweizer travel insurance with immediate protection when she logs into e-banking from abroad. This of courses requires the processing of external data (e.g. the location) to a certain extent. This also means the relevance of analytics, machine learning and artificial intelligence (AI) is also increasing. And this in turn also means awareness of and know-how in data management is increasing in the financial industry.
Against the background of developments such as embedded banking and open banking, banks are increasingly dependent on networking with other industries. And the expansion of partnerships in the ecosystem goes hand in hand not only with the expansion of digital communication channels, but also with the promotion of integration capabilities via APIs etc. and high technical standardisation. At the same time, individualisation in the customer journey is a driver for microservices from a system architecture perspective.
There are many requirements that a bank's future IT systems must meet, and four areas of change will significantly influence the banking IT architectures of the future:
- FinTechs, which used to provide supplementary features (e.g. personal finance management), are now an integral part of banking and have become an indispensable part of banking architectures (see also Swisscom FinTech Map).
- Digitisation produces a constant field of tension between individualisation and standardisation. Individual consumer needs must be addressed and fulfilled in the digitised world using standardised applications.
- Here we can also see an increasing decoupling of front and back-office functions. While back-office functionalities still have long life cycles (15-30 years), front-office functionalities now have completely variable life cycles, which can range from a few months to several years.
- The traditionally centralised organisation of banks, which organises the interaction with the clientele, is being replaced by (at least in part) decentralised forms of organisation. This is being supported in particular by technologies such as blockchain, which enable the mapping of cross-company, decentralised structures. Another example is the inclusion of the "crowd" when conducting tests or forming opinions.
During the implementation of these developments, the orientation of banking IT is a driving force and a distinctive feature, which must be continuously transformed while taking its own strategic orientation and pending regulation into consideration. In the future we can expect IT architectures that increase agility, accelerate the adaptation of emerging technologies, increase the availability of interfaces and support modularity and openness.
Challenges for System Support in Banks
The IT landscapes of the future will focus on interaction with the customer. Under the aspect of service provision in the ecosystem, it is necessary to define what future system support should look like. To structure the challenges ahead, a differentiation can be made between the three areas of customer management, service management, and system management.
- Customer Management
If end customers are served along the customer journey, the bank will either bundle services itself within the scope of customer management by integrating external services (providing it with an overall view of the advisory service / customer interaction), or it will embed its services within the customer journey of other providers (see Illustration 1).
To do this, the bank must decide in which ecosystems it wants to operate and which customer journeys it wants to support, which services it can offer itself and which services it can efficiently outsource. Most banks, for example, want to offer advisory services themselves, and will increasingly integrate the services of partners here in addition to their own.
Three challenge levels: customer management, service management, system management
- Service Management
When organising services for end customers, a business and a technical perspective of the integration with partners is required.
The business integration needs to map all services that the bank offers to its customers in a nomenclature that is uniform across all partners. Based on the customer journey, needs are translated into services and bundled, for example, in a catalogue. This is independent of whether the services are provided by the bank itself or, as in the example of insurance, are included via partners. What's more, the product information must be available at all the partners involved, as this is the only way to coordinate which provider take over which steps if, for example, a disability occurs in relation to a life insurance policy sold by the bank.
This is, from an architectural perspective, a driver for redundant data storage on the part of the bank and the insurance company and, as with the integration of publicly available data into the services, requires a high level of expertise in data management.
The technical integration must provide all information for the clientele across all channels and make the interaction traceable via monitoring while handling the transactions made, whether for services from the bank itself (e.g. purchase of a share) or from the partner (e.g. change of a life insurance policy). All data needed for the preparation of evaluations and analyses and for regulatory reporting, in particular, must be kept in an archive or data hub.
This in turn requires a strong integration platform, which is also organised via open APIs. Based on this, service management must have clear organisational as well as technical agreements (e.g. SLAs) between the players. This is the only way to efficiently organise the distributed and (in part) also complex service provision and to react quickly in the event of problems. The overarching requirement in service delivery to the end customer is a shared understanding of governance in the ecosystem.
- System Management
Within the context of system management, serving the end customers in the ecosystem increasingly requires the integration of FinTechs or other providers in addition to the operation of a core banking system and associated, integrated peripheral systems. This raises the question for the bank and the providers of core banking systems as to whether and to what extent functionality should be mapped in the core or purchased via partners. The bank's core banking system with its booking engine certainly covers all services offered by the bank that trigger a transaction. In future, however, the overall view of customer-side transactions will be in the service layer.
Efficient collaboration in the ecosystem can only be organised through (open) release-proof APIs. The future design of the architectural building blocks and the flexible operation in the ecosystem will, however, necessitate an open system, which is not yet the case at most banks in Switzerland. Adjustments to make data from the core freely available and to store it are time-consuming activities, which often lead to further cost-associated complexity in mature system landscapes.
Building Blocks for the IT Architecture of the Future
In the future bank system architecture, it will be possible to differentiate between the three levels of customer management, service management and system management for upcoming challenges, in line with the structure that was chosen. These will be supplemented with architectural building blocks for the IT architecture of the future.
Building blocks for the system architecture of the future on three levels
- Architecture building blocks in customer management include all front-end systems, the so-called data hub, which manages data from all sources and systems and allows analytics to be performed on all of the data. In many cases, comprehensive data management is still in its infancy.
- Architecture modules in service management include the service integration layery, which deals with the logic of how to work with partners, and the API layer, which allows the bank to obtain information from a wide range of applications via APIs. However, the utilisation of open interfaces, in the sense of open banking, is still not widespread in Switzerland.
- Architectural building blocks in system management include the actual core banking system or its booking engine, which handles all customer-side transactions, as well as (often) closely integrated implementation systems (e.g. for credit ratings, SNB reporting or portfolio management) and partners such as FinTechs or insurance companies with various levels of integration depth.
Not least due to the increased focus on customer interaction, it is becoming apparent that in future the front-end of the banking architecture will have to map services not only of the bank itself, but also of its partners in the network. This means that it must handle a much broader range of services in the service layer than those mapped within its own core banking system. At the same time, there is a trend for banks to increasingly downsize the back end, which is in part driven by the increasing pressure of cross-company standardisation.
The three basic strategies (as described in an earlier article) entail different potentials and risks.
Simplified overview of the architecture based on three basic strategies
Strategy Core (Best of Suite):
To the greatest extent possible, the bank obtains all functionalities via the core banking system. This means that the bank also has the front-end systems and the API layer covered by the core banking system.
Because of this, the bank relies to a large extent on its core banking system provider, and it should therefore seek a close partnership for further developments with this provider. The integration of additional services in the ecosystem along the customer journey, such as insurance, should be mapped in cooperation with the system manufacturer.
Front-to-Back strategy:
Customer interaction is increasingly being covered by other systems of the bank. Often, the foundation for this is laid with a dedicated integration platform. While the bank continues to rely on the core banking system for back-end functionalities, services are becoming increasingly decoupled from the core. Often the CRM system, which is itself a front-end solution, processes the data. Former CRM systems are increasingly developing into platforms that go far beyond the traditional core banking system with the associated core banking processes.
Modular (Best of Breed):
Depending on a bank's requirements, the functionalities are put together in a modular form via various providers. This requires a high level of integration expertise and technological knowledge, which must be maintained and kept up to date in the bank.
For banks with a modular strategy, the service integration layer and the API layer in particular should be formed or developed. In the future, neo-systems, which support the best-of-breed strategy with a lean, high-performance core, will probably also be considered as booking engines in the modular strategy.
Emerging neo-core banking systems are developing continuously, gaining market share and are now also being used by well-known big players such as N26. New platform-orientated approaches with high levels of standardisation and flexible data management combined with modular, service-orientated architectures characterise these systems. With the greenfield setup, pure SaaS offerings, for example, can be implemented much more consistently. At the same time, there is limited functionality compared to known core banking systems, which are dependent on embedding in the ecosystem of other systems. The following comments characterise systems that are relevant to Switzerland from this perspective.
Overview of key neo-core banking systems with an interest in the Swiss market
In contrast to conventional systems, neo-core banking systems offer greater architectural flexibility, but fewer things from a single source. All neo-systems are (sometimes exclusively) cloud enabled, based on microservices, and tend to require extensive IT know-how in the bank.
In terms of basic functionality, the neo-systems are similar, with comprehensive coverage of the core (customer-side transaction booking), payments and initial credit functionalities, such as mortgages and loans, all of which are important for the retail sector. Two systems also cover functionalities for corporate customers, such as capital loans. The securities part has so far only been implemented in one neo-system. Except for one system, which is Swiss in origin, the neo-core banking systems have not yet been Helvetized. Swiss-specific functions, such as the QR invoice or regulatory directives for calculating affordability when granting mortgages, still must be developed or mapped via peripheral systems. The neo-core banking systems deliberately refrain from maintaining the general ledger, as payroll accounting, for example, is not seen as an area of their expertise. The user interface for end customers (e-Banking, mobile banking) should also be provided via partners for all neo-systems.
In terms of basic functional coverage, the neo-systems are similar
Despite coverage that is generally similar, each system has some differentiation as well as an individual approach.
Mambu from Berlin is a cloud-only software-as-a-service (SaaS) system, which focuses on the booking engine as well as financing services and deposits. High levels of standardisation also enable Mambu to be scaled internationally. This means that, according to the motto "configuration over customisation", all banks basically have an identical version with the possibility of configuring products for themselves specifically.
Mambu obtains external data flexibly or integrates the bank's peripheral systems via the API architecture. Data is at the core of Mambu, including a configurable data model for storing and connecting structured and unstructured data. To process data, Mambu recommends streaming it into a data warehouse or data lake.
The Mambu Marketplace helps banks build their own ecosystems and assemble their own, specific best-of-breed solutions. The required country-specific cooperation with partner companies needs a high level of integration expertise (on the part of the bank or with the help of Mambu's network of system integrators). However, more than 160 reference installations prove that this is not an insurmountable hurdle. The ability to (putting it figuratively) purchase a ready-to-move-into house with keys (URL that can be started immediately with API integration points), means Mambu fills a need in the market.
SolitX is a transaction system from the Swiss company Ariadne Business Analytics that focuses entirely on transaction processing and combines this with customised financial products.
It is based on the ACTUS algorithmic standard for smart contracts, which is used for more than 99% of the world's financial contracts. After the bank-specific configuration of these smart contracts, SolitX basically enables the functionality of the entire core as well as accounting and Helvetized banking products to be covered.
In addition to the payments area, SolitX has also already been used extensively for mapping investment products and, most recently, financing services.
Ariadne's clientele includes, for example, the Swiss development company of a platform that allows the rapid development of an app for services such as microfinance or peer-to-peer lending. Settlement of the corresponding financial products runs via SolitX.
A technical API layer and a DLT (blockchain) adapter are available for integration with peripheral systems.
Tuum from Estonia aims to cover a bank's functionalities as completely as possible. In doing so, it tries to map missing functions with as few additional partners as possible while, at the same time, keeping the platform as open as possible so that other systems can be connected if necessary. Tuum therefore combines the advantages of a modular strategy with the core strategy (best-of-suite solution).
Tuum, which runs on the cloud or on-site as required, groups its services into independent modules (e.g. core module with accounts and transactions, card module, ...etc), each with its own database, and allows these modules to be decoupled and connected to other core systems. Most of Tuum's customers therefore start with individual modules and then, step by step, add other capabilities, if needed.
Predefined products, such as the electronic recording of customer signatures, require little programming knowledge, but rather the adjustment of bank processes to Tuum’s standard. In addition to retail business, Tuum also supports corporate business, above all in capital loans. In addition, Tuum allows non-bank industries to use its functionalities in the form of "embedded banking use cases" along the customer journey, and it already has several non-bank customers from various industries.
Vault Platform from the UK-headquartered banking technology company Thought Machine, made up of Vault Core and Vault Payments, is based on the fundamental principle of using the latest technologies for high performance and configurability. The core functionalities are transaction booking, account management and product development (Vault Core) and, since this summer, card and payment processing (Vault Payments). In Vault Core, each financial product is represented via Smart Contracts, which allow the rapid introduction of new products (programmed using Python or from the product library) and customisation to meet the individual needs of the end customers. The architecture of this system is based on microservices that are as granular as possible, each with its own database.
The idea behind Vault Core is to connect functionalities and services as needed via open interfaces. To be lean, Vault does not offer general ledger accounting. Instead, the sub-ledger – as a "single source of truth" – transfers transactions of all bank-related products in real time via the general ledger to the bank's data warehouse.
The Vault Platform leaves all possibilities open for the architectural developments of banks in the future and can be connected to existing systems by banks with a good level of tech expertise.
Leveris was an integrative platform with a modular and scalable architecture that focused on real-time data analysis and use. It mixed microservices, open API and data lakes with traditional approaches such as Oracle and PLSQL technologies. In July 2021, Leveris announced that it would cease operations. The reasons given included a slowdown in the investment market due to Covid-19 and the failure of a significant financing deal.
The following overview compares selected core characteristics of the active neo-banking systems that were reviewed.
Characteristics of the neo-core banking systems studied to date within the core banking radar
The market dynamics for neo-core systems are exceptionally high. The Core Banking Radar is following this development from a Swiss perspective and has already contacted other manufacturers such as 10X or SaaScada.
For banks as well as manufacturers of core banking systems, the cooperation and use of such agile and, due to the reduced complexity, more cost-effective platforms can sooner or later represent a worthwhile alternative for the transformation and further development of their own system landscapes. This applies to each of the basic strategies for further development (cf. above) and basically avoids a "Big Bang" that ties up extensive resources over a longer period.
Conclusion
Digitalisation, embedded banking and open finance require banks to increasingly collaborate with partners in a system-related manner. Banks also increasingly need to get involved in ecosystems to offer customers services along their individual customer journeys based on their specific needs. To do this, banks add services from other partners' ecosystems to their own or position themselves in other ecosystems with selected services of their own.
This places new system requirements on banks and manufacturers. The future system architecture of banks can be described using architectural building blocks on three levels: customer management, service management, and system management.
The characteristics of the building blocks vary depending on the strategic orientation of the system support. Neo-core banking systems can also play a role in the implementation of their respective strategies. The neo-core banking systems have different characteristics and a modern architecture, and they are developing rapidly.
However, a switch to the neo-core banking systems is only likely to be an issue in the medium to long term. There has not yet been a successful and extensive implementation of a neo-core banking system in Switzerland. What's more, the outlay for the required Helvetization still needs providing. The table below shows the strikingly different characteristics of neo-core banking systems and established core banking systems. The main focal point is certainly the focused cover of the neo-core banking system functions as opposed to the established core banking systems.
Differences between neo and established core banking systems
Banks basically have two options for the further development their system architectures:
- They work with their core banking system manufacturers for the provision of architectural building blocks to open the systems to third parties (core strategy), because even established core banking system manufacturers have to deal with networking and cooperation issues.
- Within the described architecture building blocks, they also seek cooperation with neo-core banking systems and, once a certain size is reached, use the capabilities for a good integration layer to open the systems (front-to-back and modular strategy).
With both options, it is worthwhile keeping track of changes and gaining experience with partnerships and cross-organisational service management. In addition to this, it is advisable to systematically formulate sub-strategies on data management, analytics and AI in order to deal with the increasing levels of data redundancy.
One of the following Core Banking Radar articles will deal with the derivation of viable transformation scenarios, moving forward towards the architecture of the future (in terms of resources, money, time).
More on the topic:
