Information Systems in Banking
What this domain tests
This domain checks whether you understand how a bank's application landscape is assembled and how customer-facing channels reach the core. Expect questions on core banking solution (CBS) architecture, customer information file (CIF), product processors, general ledger interfaces, end-of-day (EOD) processing and channel integration.
Core rules and concepts
- A CBS is the system of record for deposits, loans and customer balances. It is usually centralised, with a single database, application servers and channel adapters; branch, ATM, internet, mobile and API traffic should not write directly to the database.
- Customer, account and product masters are maintained in the CBS; delivery channels are presentation and origination layers. Channel services need authentication, limits, idempotency and reconciliation back to CBS.
- EOD/BOD cycles, interest accrual, standing instructions and GL postings are batch-driven; real-time payments need 24x7 availability, so many banks run continuous processing or a separate payment engine.
- Interfaces use ISO 8583 for card/ATM switching and ISO 20022 messages for many newer payment flows; middleware handles transformation, queues and retries.
Worked example
A bank adds a UPI channel. The correct design is: UPI app → API gateway → UPI switch/adapter → CBS API for debit/credit and balance check. The adapter validates the virtual payment address, applies velocity and limit checks, uses a unique transaction reference for idempotency, and posts a shadow entry if CBS is unavailable; reconciliation matches the NPCI settlement file to CBS postings. The wrong answer is to let the mobile app connect directly to the CBS database or to assume EOD will fix unmatched entries.
Traps that cost marks
- Treating CBS as synonymous with the payment switch.
- Assuming a disaster recovery site is always an active-active channel.
- Ignoring reconciliation and cut-off times for 24x7 payments.