100,000 Foot View of Core-Banking Systems
K.S. Bhaskar
Core-banking systems (CBS) are the legal systems of record for account balances and transactions. For custodians with fiduciary responsibility for their customers’ money, CBS are the most mission-critical applications for commercial banks.
At a high level, there are two types of core-banking systems: batch and real-time.
Batch systems are process-centric, centered around an end-of-day (EOD) process that updates account balances from one day to the next.1 Since transactions can arrive at any time, incoming transactions are placed in a memo file; credits and debits update account balances during EOD processing. This complicates processing logic, since if a debit transaction (e.g., an ATM withdrawal) is received during the day, the previous EOD balance and entries in the memo file must be reviewed to determine if there are sufficient funds in the account, and if there are, another memo must be posted to be processed at EOD. In batch systems, each transaction can be processed multiple times.
Real-time systems are customer-centric. A database has the current balance for each account. When a transaction arrives, it is processed forthwith, and the account balance updated. An incoming debit transaction only needs to be validated against the account balance – there is no memo file to review. Each transaction is processed just once and the account balance in the database is always current. Real-time systems have an additional advantage for financial institutions: since the account balance is always current, there is virtually no need to reconcile discrepancies.2
Batch systems originated on mainframes in the 1960s, with each part of the EOD processing involving the mounting of tapes and the movement of data from one tape to the next. Those days are of course long gone, and data now resides in databases, while batch processes move data within and between databases. Owing to their ability to process large numbers of accounts (accessing data sequentially is more IO efficient than random access), batch systems traditionally ran on expensive mainframes, and were used by the large financial institutions that could afford them. Since there is not necessarily a single point of truth for transactions and balances, banks that use batch systems must also retain staff to reconcile differences.
Real-time systems originated on minicomputers in the 1980s. Owing to their then limited ability to process data, real-time systems were more commonly used by smaller financial institutions. Apart from random access, real-time systems impose an additional constraint on databases: since a transaction is processed just once, straight through to a customer account, databases must support robust Atomic, Consistent, Isolated, and Durable (ACID) transactions and applications must use them correctly.3 Apart from using more affordable minicomputers, not needing staff to reconcile discrepancies was of course attractive to smaller institutions.
In the late 1990s and early 2000s, the massive scalability of the GT.M key-value database coupled with faster new-generation computers such as the DEC Alpha AXP OpenVMS, and UNIX servers from IBM, HP, and Sun, allowed the Profile real-time CBS to break out of its original savings-bank niche, and scale up to the needs of large financial institutions. The database’s ability to provide business continuity in the face of unplanned and planned events, and robust single points of truth for financial data on more affordable servers, delivered scalability with reduced capital, operating, and staff cost, facilitating its segue into global financial institutions.
Today, batch systems are legacy applications, and no financial institution would start implementing a new batch CBS. Yet legacy systems remain, because the cost to a bank of replacing a working CBS is large: replacing a CBS involves reorganizing business workflows to align them with those of the CBS. This also brings up a difference between banks in the United States and countries such as Thailand. Large banks in the US have grown by buying other banks. In such cases, it is often easier to retain the CBS of an acquired bank, implementing a front end application that provides customers with the illusion of a single bank, than to replace the acquired CBS. Large banks in countries like Thailand have grown organically, and thus process tens of millions of accounts on a single system vs. the millions of accounts that a large US bank may process on a single system.
YottaDB is a downstream derivative of GT.M. While staying upward compatible with GT.M, YottaDB adds language independence, better performance, and support for energy efficient ARM CPUs. Placid (Thailand) Ltd. took advantage of the benefits offered by YottaDB to build a greenfield real-time CBS (see Go+YottaDB – A Perfect Platform for Fintech).
Contact us to build your next mission-critical fintech application, or to migrate an existing application to YottaDB.
Footnotes
1 Without getting too much into the weeds, note that the balance in an account may not be a single number: there can be an available balance, a collected balance, etc.
2 Real-time systems also have EOD processes. For example, interest is usually computed on a daily basis. The important distinction is that financial transactions go straight through to customer accounts.
3 Vendor’s secret ‘fix’ made critical app unusable during business hours is an example of what can go wrong if an application uses the less than robust transactions implemented by a database. YottaDB’s transactions are more robust than those of that database.
Credits
- Palazzo Salimbeni houses the main offices of Banca Monte dei Paschi di Siena. Established in 1472, it claims to be the world’s oldest surviving bank. Photo originally by Ray in Manilla used under CC by 2.0.
- Picture of US Continental Congress eight dollar bill is in the public domain.
Published on January 04, 2026