Core banking systems do not make for splashy ad campaigns.
Often described as legacy technology, these are mission-critical applications that process daily transactions, account updates, and more. Banks attract customers with promises of convenience and financial safekeeping—but it’s the core systems that do the heavy work.
These core systems also tend to present barriers when bank executives look to modernize.
With so much buzz these days around transformation in banking, it helps to remember how core systems became the stuff of C-suite discord. In this piece, I offer a look back in order to look forward at how banks can successfully modernize their most essential applications.
The earliest core banking systems appeared in the 1980s, moving banks out of the centuries-old practice of handwritten journals and ledgers.
Banks needed the ability to manage large volumes of transactions quickly, reliably, and efficiently. The first-generation core banking systems 1 thus evolved, offering centralization, speed, scale, and reliability. Written in COBOL, Assembler, PL/I, and JCL languages, these systems were monolithic, with close coupling of underlying interdependent business modules such as customers, transactions, and products.
These applications only supported batch processing and posting happened at the end of the day. Intraday balances could be made available through workarounds like memo posting. In such applications, business logic and data access logic were strongly intertwined, 2 and separating the two became challenging.
In the late 1980s and early 1990s, the second-generation core banking systems expanded the market to regional and smaller banks. The new core systems introduced less costly N-tier architectures that supported real-time processing and allowed for separating front-end business logic from the mid-tier business logic and the data access logic.
These applications were typically product-centric in architecture; products were easier to build and configure, and multiple integration methodologies were adopted. As the applications were simpler and more parameter-driven by design, banks could deploy new products, features, and pricing in a shorter time to market. 3
The rise of the Internet in the 1990s fueled the growth of front-office tellers, branch banking, and online banking applications. Investment in core banking applications slowed down considerably, and integration challenges between the front-end and core systems quickly surfaced.
To overcome such constraints, banks built or bought service-oriented and message-driven middleware applications that allowed for easier and loosely coupled integration between front- and back-end applications. Industry frameworks such as IFX, FIX, and FpML attempted to provide standardization and interoperability across institutions.
In the 2010s, the banks accelerated their adoption of digital banking with cloud technologies. REST APIs and JSON became popular technologies for data interchange and integration.
With the growing number of FinTechs offering niche and point solutions that enhance customer experience, banks felt the pressure to partner with the FinTechs and allow integration. API and cloud became the force that pushed for further changes to the first and second-generation core banking systems.
Traditional banks customized their legacy cores to the extent that cap currency, the practice of maintaining software in its most up-to-date version, is no longer practical. Sensing a new opportunity, platform vendors began re-designing their platforms for the cloud through a combination of new architectural patterns and refactoring from the second-generation core banking platforms. 4
Most of these third-generation core apps are built as microservices. Containerized, they can run on one or more public cloud environments, and are designed to offer real-time transaction processing. Their microservice-driven architecture decouples business capabilities such as customer and account management, transaction processing, statements, and reporting.
APIs are naturally the preferred method of integration for these new cores, and most vendors also offer their own packaged API-gateway applications that provide pre-integrations with in-house and some third-party applications to support the wide array of banking services such as customer onboarding, customer servicing, money movement, card management, and other ancillary services. 5
These recent advancements in core banking systems allow for rapid innovations that allow banks to experiment with newer application stacks and migration patterns.
Several new core banking vendors have entered the market in the past few years. They offer the next generation of core applications that have many design similarities to the third-generation cores, with a few notable differences. The next-generation cores are truly cloud native and have been built from the ground up using microservices without any refactored code. 6
Some of these applications use cutting-edge programming languages such as Golang and RUST and adopt newer databases such as PostgreSQL. Further, such apps are offered as a set of “headless” APIs that allow for flexible integration choices without attempting to lock the bank down to a few vendors. Such design patterns make the cores “composable” by opening up the architectural canvas and offering the banks the flexibility to try them out in parallel to their existing cores without having to completely migrate off the old cores. 7
A few vendors offer niche point solutions such as product, pricing, and billing engines, and customer servicing applications built for the cloud. While these applications may not replace a core banking system in its entirety, they are meant to work in partnership with other cloud-based cores and can become an essential part of the composable core ecosystem. 8
These recent advancements in core banking systems allow for rapid innovations that allow banks to experiment with newer application stacks and migration patterns.
Older-generation core systems were designed to handle large transaction volumes efficiently and very reliably. Although new-age systems are agile, flexible, and offer numerous business benefits, they still fall behind their older counterparts in this aspect. This is the primary reason why legacy cores have been so sticky. In the past, core banking modernization was a high-risk, high-cost initiative where a big-bang replacement was the only choice.
Today, multiple paths to core modernization exist that optimize risk, cost, and effort. Banks can follow a modernization approach that is iterative and steadily progressive. A few example pathways include:
Whichever pathway banks choose to adopt, core banking modernization must not be treated as just another technology transformation exercise. Operating model changes—particularly business process re-engineering and workforce change management—must complement technology changes.
The evolution of core banking systems articulates why and how these systems were designed and built to meet the business needs of the past. As business needs evolve, an understanding of their evolution provides us with a trajectory and guidelines on how to change these systems. By learning from past errors, we can identify new opportunities for future innovation.
Niloy Sengupta is Financial Services Consulting Partner at Kyndryl
1 Examples of first-generation core banking systems in the US: Systematics (FIS), Hogan (DXC), and Trisyn
2 Example: The use of process control data in Hogan
3 There are many examples: Profile (FIS), DNA and Premier (Fiserv), Silverlake, CoreDirector, CIF 20/20 (Jack Henry), Bancs (TCS), Finacle (Infosys), Flexcube (Oracle), and T24 (Temenos)
4 They do not have any refactored code from the past. This has allowed some innovation such as the use as next-generation programming languages like GoLang in Finxact.
5 FIS introduced the Modern Banking Platform (MBP), and Temenos transformed T24 into Transact. Fiserv, Jack Henry, Infosys, TCS, Oracle, and Finastra all of them developed cloud versions of their popular core applications.
6 Two different pathways around such integration are visible. The likes of FIS, Fiserv, and Oracle pre-integrate apps from their product portfolio, trying to lock in their customers to their own ecosystems as much as possible. On the other hand, TCS, Infosys, Temenos, and others offer a marketplace approach where several third-party apps are certified to be interoperable with their cores through APIs.
7 These core vendors also have a large marketplace of third-party apps that are certified for interoperability and conform to open banking industry frameworks such as ISO 20022 and BIAN.
8 Some of these applications are product, pricing, and billing engines as offered by Zafin, SunTec, or Oracle RMB. Customer service and onboarding applications such as Savana also are part of this category.