Why it matters
Every other system in a bank either reads from the core or posts to it. When a payment rail credits a customer, a mobile app shows a balance or a regulator asks for a return, the answer ultimately comes from the core. Its design decides how fast a bank can launch products, how it copes with round-the-clock payments and how risky it is to change anything.
The model explained
A core is a set of modules around one ledger. The customer module holds who the bank’s customers are. The product module holds the rules: interest rates, fees, limits and statement cycles, set up as parameters rather than code, so a new savings product is usually configuration, not a software release. Accounts are instances of those products. Deposits and loans hold the balances and schedules. Every change of money ends as balanced debits and credits in the general ledger.
The modules of a core banking system
Text description
Customer information and product rules feed accounts. Accounts divide into deposits, loans, and charges and interest, all of which post to the general ledger.
- Customer information to Accounts
- Products and pricing rules to Accounts
- Accounts to Deposits
- Accounts to Loans
- Accounts to Charges and interest
- Deposits to General ledger
- Loans to General ledger
- Charges and interest to General ledger
Online and batch
Online processing posts each transaction as it happens and must be fast and correct. Batch processing handles work done for every account at once: accruing interest, applying charges, ageing loans, producing statements and regulatory extracts. The run that closes the business day is end of day (EODEnd of day. The daily batch run in a core banking system that closes the business day: interest accrual, charges, ledger posting and reports.); the run that opens the next is beginning of day (BODBeginning of day. The batch run that opens a new business date in a core banking system after end of day.).
End-of-day and beginning-of-day stages
- Freeze the business date for postingNew transactions go to a stand-in layer or the next date
- Accrue interest and apply charges
- Post to the general ledger and reconcile
- Produce statements and regulatory extracts
- Open the next business date and release held postings
Why a core is hard to scale out
Money needs strong consistency: two withdrawals must never both succeed against a balance that covers only one. Most cores achieve this with a large relational database and transactions, which works well on one very big machine and less well across many. Some accounts are also hot spots. A merchant’s settlement account or a bank’s own clearing account may receive thousands of postings a minute, and each posting must lock the same balance. Adding servers does not help if every request queues behind one row.
Stand-in processing and shadow balances
When the core is busy with batch work, or briefly unavailable, a stand-in layer can keep approving transactions against a shadow copy of each balance, within safe limits. Once the core is back, the stand-in replays what it approved. This keeps payments flowing but means two systems hold a version of the truth for a while, and they must be reconciled afterwards.
How it plays out in Indian banking
Large Indian banks run large commercial platforms. SBI's core banking has run on TCS BaNCS since an implementation that began in 2001; in October 2021 TCS said the partnership was extended for five years.1Tata Consultancy Services. SBI deepens partnership with TCS to drive innovation and enhance customer experience. As of 6 October 2021. Smaller banks often share one. IFTAS's Indian Banking Community Cloud provides core banking and other applications, such as SFMS and mobile banking, as web services.3Reserve Bank of India. Chief Executive Officer (CEO) for Indian Financial Technology and Allied Services (IFTAS). As of 20 September 2022.
The pressure today comes from instant payments. UPIUnified Payments Interface. NPCI's real-time system for paying from a bank account with a UPI ID, QR code or phone number, through apps on a phone. alone averages 791 million a day2Business Standard. UPI sets new record at 24.51 bn transactions in Aug, value at ₹29.82 trn. As of 31 August 2026., and none of that stops for end of day. Banks answer with stand-in layers, shorter batch windows and payment hubs that shield the core. RBIReserve Bank of India. India's central bank. It regulates banks and payment systems, runs RTGS and NEFT, and holds the accounts in which banks settle with one another.’s resilience rules also reach the batch cycle. A DR test must switch over to the DR or alternate site and run it as the primary site long enough to cover at least a full working day, from beginning of day to end of day.4Reserve Bank of India. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (full text). As of 7 November 2023.
Trade-offs
| Choice | You gain | You give up |
|---|---|---|
| One central core | One version of every balance; simpler audit | A single, very important system to protect and scale |
| Parameterised products | New products without code changes | Complex configuration that itself needs testing and control |
| Nightly batch | Efficient bulk processing | A window when the core is not fully available |
| Stand-in processing | Payments keep flowing during batch and outages | Reconciliation work and the risk of approving against a stale balance |
Failure modes
- End of day overruns. Volumes grow until the batch no longer fits its window, delaying the next business day.
- Stand-in drift. The shadow balance and the core disagree, and a customer is allowed to overdraw or is wrongly declined.
- Hot-account contention. A few very busy accounts slow every posting that touches them.
- Configuration errors. A wrongly set product parameter charges or pays interest incorrectly across thousands of accounts at once.
When to use it, and when to avoid it
Every bank needs a system of record, so the question is not whether to have a core but how much to put in it. Keep the core to what only it can do: accounts, balances, the ledger and product rules. Move customer journeys, payment orchestration and analytics outside it, where they can change faster. Avoid putting logic in the core simply because it is the one system that already has the data.
Questions for a design review
- Which work must stay in the core, and which could move to a system that changes faster?
- Does end of day still fit its window at next year’s expected volumes, with margin?
- What happens to payments while the core is in its batch window, and how are stand-in approvals reconciled?
- Which accounts are hot spots, and how is contention on them handled?
- How are product parameter changes reviewed and tested before they reach live accounts?