The next few years are going to see a large number of transformation and modernization programs for core banking systems. Core banking systems support the bank’s critical banking processes and products, such as personal accounts, cards, loans, etc. and process billions of dollars in financial transactions every single day. These transformations programs will aim to provide financial institutions with the necessary business agility to compete in an increasingly complex market, and a reduction in their high operating costs, through the use of cloud infrastructures and new technologies.

Many financial entities have been developing applications on cloud infrastructures for some time, but very few have actually started to transform their core systems. In this challenging journey, they should consider seriously the differences in the characteristics of the applications that will enable to take advantage of these infrastructures.

To begin with, the new core systems must have a high modularity, which can be defined in three dimensions: structural, operational and development. Traditional core systems do not have these modularity characteristics, being the main cause that has led to the current complexity and lack of maintainability of current systems.

Core banking systems have life cycles of more than 20 years. The new core in the cloud must also have a high durability, because due to the criticality and importance of the processes it supports, financial institutions cannot afford to transform these systems with the frequency that other of their applications change, for example, channel applications or systems of insight. This means that the useful lifespam of the applications is much longer than that of the technologies on which they are going to be developed. The appropriate design patterns must be adopted to avoid that technological obsolescence of the applications happens long before their expected service timelines.

The use of Hexagonal Architecture can clearly help to provide the necessary features for new core systems. In this architecture style, the business logic is isolated from the technological platform and from the rest of the applications with which they interact through integration adapters, ensuring the modularity of the applications and facilitating the evolution of the technical infrastructure on which it builds and deploys.

The applications in the target architecture require high modularity, reflected in different dimensions: structural, operational and development.

Practically all the initiatives to transform core banking systems in financial institutions share two objectives: to improve the time to market in responding to the needs of their businesses; and to gain efficiency, reducing the high maintenance costs of current systems through the adoption of cloud infrastructures, both private and, increasingly, public clouds.

The adoption of these technologies requires highly modular characteristics in the applications, characteristics that we can synthesize in 3 dimensions: structural, operational and development.

Structural Modularity

Structural modularity implies designing the applications around business capabilities and not technologies, with teams specialized in business domains and not technical capabilities. This principle may seem basic to professionals in other industries, but it is not fulfilled in most financial institutions, where organization based on technological solutions predominates, and where the logic of business domains is distributed among all layers with, for example, some teams that work in a mainframe environment, other teams that develop the processes in BPM solutions, other teams that design and expose the APIs, and so on.

This trend has been accentuated in recent years. Instead of evolving core systems, entities have added technological layers on top of it, trying to provide new digital and multi-channel capabilities, and always fearful of touching core applications because of their cost and the risk involved. Actually, banking history does not lack of business continuity failures in systemic financial institution, cause by errors in the maintenance of their core systems.

As a result of this trend, maintenance costs has increased and efficiency in the resolution of incidents and the evolution of applications have been impacted, because where before there was a single team responsible for identifying and solving problems, now there are several that have to coordinate to identify the root-cause of the problems

This system evolution strategy has constrained the huge efforts to adopt Agile or DevOps practices in the search for better agility, when any modification to the business logic requires the intervention and coordination of several team

Operational Modularity

Applications must have minimal dependencies between them at runtime, to ensure availability and performance of their Services.

If we consider a typical financial transaction processed in a core banking system, let’s say a cash disposition with a debit card in an ATM, it is easy to find that there are hundreds of interactions in runtime, between different components of the system, for a single execution of the transaction. If, for example, we consider a core systems implemented in Cobol, as in the case of most first-level financial institutions, the implementation of these interactions between components will generally implemented as COBOL Calls within a monolithic system. When trying to transform this business function to a solution for the cloud, where each of the components will be, for example, a microservice, if the design patterns applied are those same ones used in the design traditional core systems, these COBOL Calls will be transformed in, for example, API Rest, and each one of the invocations will introduce latency tempos, transactional context breaks and availability dependencies that we did not have before.

Given this scenario, it is evident that the way applications are designed must be radically changed, and it is not valid to perpetuate design patterns that were suitable for traditional monolithic systems, but which are not suitable for core application development. Where once there were hundreds of run-time interactions, now we can’t afford a handful of them anymore.

Operational modularity is important not only to provide good performance characteristics, but also for its impact on costs and agility of maintenance and evolution of the applications. In modern applications developed under agile models it is easy to find daily or weekly deployment frequencies; when we look at deployment frequencies in core banking environments, we will find that there are applications with monthly or even quarterly deployment windows. The rationale for these limitations is due to the need to control risks in deployment. The high operational coupling of the applications in a traditional Corebanking system means that modifications in auxiliary components, which are not critical for the business, can affect critical applications and, therefore, must be treated as critical elements; they require extensive testing phases and complex impact analysis for such low business value applications. Good operational modularity eliminates runtime dependencies between critical components and secondary components, significantly reducing costs and times for system maintenance and evolution.

Development Modularity

Components with development modularity have minimal dependencies at the software level, so that changes are deployed without impact on the rest of the components. Most of the core banking systems have a high coupling between their applications. When certain elements are modified and redeployed, they drag programs and components from other applications, forcing extensive impact analysis and regression tests, the same as happened when there´s lack of operational modularity.

This same problem has been reproducing in new developments in the cloud, generally linked to the lack of API versioning policies but, above all, to the use of interfaces through files, reproducing patterns of designs rooted in traditional systems. Dependencies in development are one of the most important causes of the lack of agility and high maintenance costs of these traditional core systems.

A cause of lack of development modularity is the structuring of applications in technological layers, managed by different teams, with different repositories, and that have to coordinate their deployments.

Achieving high maintainability of core systems should be a priority objective in the development of new systems, as maintenance is the most important cost item in any ​​development department of a financial institution.

The life cycle of core banking system applications is much longer than the technology on which they are being built

Core banking systems support the bank’s critical banking processes and products, such as personal accounts, cards, loans, etc.

These systems have life cycles of decades, since the business logic of these products does not change frequently . There are substantial changes around the core, caused by changes in the models of interaction with the client or caused to changes in regulatory compliance requirements, but the processing of the product, as such, does not change significantly

The life of these systems will be much longer than that of the technology on which they are being built.

The evolution of Cloud platforms is rapid and continuous. Today’s solutions, standards and patterns will be completely outmatched within a few years. This would make it necessary to evolve the applications with the changes in the available technologies, but given that the core systems support the critical processes for the bank, any attempt to update the technological platform on which they are developed will meet great resistance due to the risk involved, unless such change is enabled by means of a correct design and by isolating elements of the business logic from the technological platform itself. If this is not achieved, it will pose a serious risk of technological obsolescence for systems and would force financial institutions to support technologies long after they have been overcome, with the high cost that this can entail.

Use of the hexagonal architecture for the development of modular applications and with long life cycles

The hexagonal architecture helps us to develop applications with the modular characteristics required for a good time to market and to achieve expected service lifespan in core applications, avoiding the obsolescence of the technology on which they are built.

The hexagonal architectures is an well-known architectural pattern that produces applications loosely coupled from the technical environment and from other applications, by isolating the data and the business logic of our application from the outside by means of adapters. The adapters provide functional and technical isolation:

  • Functional: the core domain business logic will not depend on external data structures, or domain languages, but rather all input information is transformed into the language of our domain or application. In this way, changes in the data structures of the interfaces with other applications only affect the integration logic and not the business logic of the application.
  • Technique. The business logic must not be linked to the technical platform. Exposing / consuming an API, publishing / subscribing an event, or persisting data, should be implemented with the same logic (same code) whatever the technical services used: Kafka, Oracle, mySQL, MongoDB … This guarantees that technological evolution of the platform will not be limited by the impact they have on the logic of the applications.

For example, a Credit Management application that retrieves information about a customer in the Customer Management application can call a Customer Management Rest API but:

  • The invocation of the Rest API is made from an adapter, so that when in the future the Rest APIs are changed to another standard, the components that implement the application’s logic are not impacted.
  • The Credit Management application incorporates in its logic structures or data elements of the client application, but transforms it into its own internal language. In this way, if the client application is replaced or transformed in the future, we avoid impact on the business logic of the loan application

The implementation of the isolation patterns has an additional cost to developments with direct interfaces with external services. The question is, is this extra cost worth it? If we consider applications of limited use and short life cycles, possibly not, but in applications called to service critical processes, which are going to have high useful life cycles, and that process hundreds or billions of dollars in financial transactions, that cost seems more than justified