# Design an online banking system: system design interview question

> Financial views over an existing core, with strict account access, stable transaction history, and durable card controls.

Source: https://sysround.com/questions/design-online-banking-system
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design an online banking platform where customers view balances and transaction history, and freeze or unfreeze their debit cards. Integrate with the bank's existing core systems and provide secure access. Transfers and bill payments are outside the scope."

## What to clarify first

- Customers and requests
- Accounts and history
- Core interfaces and capacity
- Financial source contract
- Financial truth and latency
- Availability and durability
- Card servicing
- Identity and access limits
- Ownership source contract
- Deployment, audit, and exclusions

## Scope of a strong answer

Core requirements:

- Provide secure access to accounts that the customer owns.
- Show posted balances, available balances, and transaction history.
- Let customers freeze and unfreeze their debit cards.
- Show financial freshness and the confirmed status of card changes.

Usually out of scope:

- Build the core ledger or payment processor.
- Transfer money or pay bills.
- Open accounts or issue loans.
- Handle disputes or fraud investigations.
- Build an identity provider.

## What interviewers probe

### Balance accuracy and freshness

The core sends related financial changes in separate fragments. The service must distinguish a complete view from a quiet account or a delayed source.

### Card controls

A remote timeout can hide success. The platform must preserve accepted commands through zone failure and prevent conflicting changes from reaching the core in the wrong order.

### Access to accounts

The platform must stop access soon after ownership removal. Concurrent recovery must not restore access from older source data.

### Account history

Seven years of history requires much more storage than current balances. New posted entries and mutable pending entries need different page rules.

## Common mistakes

- Builds a new ledger instead of treating the existing core as the financial authority.
- Calls the core for every balance read without checking its latency or capacity.
- Assumes account versions prove complete delivery or freshness for idle accounts.
- Loads ownership snapshots over newer permissions without an exact replay position.
- Acknowledges card commands before synchronous replication across zones.
- Serves stale financial views after ownership evidence expires.

## The bar by level

- **Senior:** Defines complete financial publication and stable history pages. Designs durable card commands across zone failure. Enforces ownership expiry and uses snapshot replay during recovery.
- **Staff+:** Validates snapshot cuts, source completeness, and trusted progress. Prevents ownership rollback during recovery. Defines recovery beyond command protection periods and quantifies ownership safety's availability cost.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=online-banking


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.
