Core Banking Solution Architecture: CBS Modules Explained (CAIIB ITDB)

Every teller screen, ATM withdrawal, and NEFT credit in an Indian bank ultimately touches one system: the core banking platform. Understanding core banking solution architecture — how CBS modules, the database layer, middleware, external interfaces, and the disaster recovery (DR) site fit together — is a recurring theme in the CAIIB Information Technology and Digital Banking elective, and it is also the mental model every IT and operations officer needs on the job. This article breaks the architecture into its working layers so you can answer both conceptual and scenario-based exam questions with confidence.

🏗️ CBS Modules: The Functional Building Blocks

A core banking solution is not one program — it is a suite of tightly integrated modules, each owning a slice of banking business logic. The customer information module maintains the single customer view (CIF) that every account, loan, and card links back to. The deposits module handles savings, current, and term deposit accounts, including interest accrual and TDS computation. The loans module manages sanction, disbursement, EMI schedules, and NPA classification. A General Ledger (GL) module consolidates every transaction into the bank's books of account, and a parameterisation module lets the bank configure interest rates, charges, and product rules without touching source code.

Two operational modules matter most for exam scenarios: day-begin (BOD) and day-end (EOD) processing. Day-begin opens the business date for transaction posting after validating that the prior day's EOD closed cleanly. Day-end runs interest applications, standing instructions, NPA and provisioning checks, GL reconciliation, and statutory reports, then rolls the system to the next business date. If EOD fails or runs late, day-begin the next morning is held up — a dependency examiners frequently test. For the underlying computing and language concepts these modules sit on, revisit Introduction to Computing.

🗄️ Database and Middleware Layers

Below the modules sits a three-tier architecture: a presentation layer (branch, ATM, internet and mobile front-ends), an application/middleware layer (business logic and integration), and a database layer (the system of record). Most Indian CBS deployments run on a relational database management system holding customer masters, account balances, transaction logs, and audit trails, with real-time replication to a standby node so a single node failure does not stop banking. Database integrity — foreign keys, referential checks, and transaction atomicity (commit/rollback) — is what keeps a debit and its matching credit consistent even if the network drops mid-transaction. Candidates should be comfortable with these fundamentals from Database Management Systems.

The middleware layer is the glue between the CBS core and everything around it. It handles message queuing, transformation, and routing so the core database is never hit directly by external channels — a mobile banking request, for instance, is translated by middleware into the CBS's internal transaction format before it reaches the database. Where a bank runs many point-to-point connections, it typically consolidates them through an integration layer; the pattern and trade-offs are covered separately in our guide on enterprise service bus in banking.

💡 Exam Tip: If a question describes a failure that corrupts one transaction but leaves the rest of the ledger untouched, the concept being tested is database atomicity, not middleware — read the scenario carefully before choosing.

🔌 Interfaces: Channels, APIs, and Payment Switches

The interface layer is where the CBS talks to the outside world. Channel interfaces connect ATMs, POS terminals, internet banking, and mobile apps to the core. Payment interfaces connect to NEFT, RTGS, IMPS, and UPI switches, each with its own message format and settlement cycle, all reconciled back to the GL through the middleware layer. Regulatory and reporting interfaces push data to credit bureaus, the RBI's various reporting platforms, and internal MIS systems. Increasingly, banks also expose CBS functionality through open APIs so that fintech partners and third-party apps can originate transactions without needing a screen-level integration, a pattern candidates should already know from earlier chapters such as Networking Systems.

Every interface point is also a potential single point of failure, so architecture reviews focus on queueing, retry logic, and idempotency — making sure a retried message does not create a duplicate transaction. The RBI's supervisory expectations on IT architecture, resilience, and interface controls for regulated entities are set out on the RBI website, and every bank's IT policy must map back to that framework.

⚠️ Common Mistake: Candidates often assume the CBS database is queried directly by ATMs or mobile apps. In a well-designed architecture, every external channel goes through the middleware/interface layer — direct database access from a channel is a control gap, not the norm.

🌐 Disaster Recovery Site and Business Continuity

Because the CBS is the single point of truth for every account balance, its DR site is not optional. Indian banks typically run a near-synchronous or asynchronous replication link between the primary data centre (PDC) and the disaster recovery site (DRS), located at a sufficient geographic distance to survive a regional disruption. Two numbers define DR readiness: Recovery Point Objective (RPO) — how much data, if any, can be lost — and Recovery Time Objective (RTO) — how quickly banking services must resume after a switchover. Banks are expected to test DR switchovers periodically and to document the results, since a DR site that has never been drilled is a paper control, not a working one.

Day-end batch completion, database replication lag, and network link capacity between PDC and DRS are all architecture decisions that directly affect whether a bank can meet its RPO/RTO targets. This is also where governance overlaps with architecture: policy expectations on IT resilience are covered in our IT governance framework for banks guide, while the data-side view of what gets replicated and reported is explained in data warehousing in banking.

📌 Remember: RPO measures data loss tolerance; RTO measures downtime tolerance. A near-zero RPO needs synchronous replication, which costs more bandwidth than the asynchronous replication typically used for a distant DR site.

🧠 Practice MCQs: Core Banking Solution Architecture

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

📖 Also read: ISO 20022 migration in banking — ISO 20022 Migration in Banking: CAIIB ITDB Guide 2026

❓ Frequently Asked Questions

✅ Conclusion: Study the Layers, Not Just the Terms

CBS architecture questions in CAIIB ITDB rarely ask you to define a term in isolation — they describe a scenario (a failed batch, a channel outage, a DR switchover) and expect you to identify which layer is responsible. Anchor your revision around the five layers covered here — modules, database, middleware, interfaces, and DR site — and cross-reference the foundational chapters on Essentials of Information Technology and Introduction to Software. For the broader elective, browse every article under the Information Technology and Digital Banking elective tag, and once you have revised the risk-side view of resilience, follow it up with our ICAAP process in banks guide. Then lock in the concepts with a full chapter-wise mock test on iibf.store/tests before exam day.