By: Niloy Sengupta
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 birth of core banking systems
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 systems1 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.
The second generation of core banking systems
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.