What to Expect in the Commonwealth Bank System Design Interview

Expect a design conversation about the systems Commonwealth Bank actually runs, not an abstract puzzle. The bank, which uses the name CommBank in public, hires engineers for payments, fraud, and data platforms. Published interview guides and candidate reports name two question types most often: design a payment processing system, and design a real time fraud detection system.

Senior candidates also report a long discussion of their current architecture with architects. These questions add banking constraints: every movement of money must be correct, traceable, and permitted by regulation. For mid level roles, interviewers usually ask design questions inside a technical interview rather than in a separate round.

Why the Questions Look Like This

CommBank moved its core banking platform onto AWS, and the published AWS case study reports that about 40 percent of Australia's payments depend on it. The same case study reports more than 70 million transactions a day, with about 26 million core banking events streamed into the bank's data platform.

Australia also has near real time payments. CommBank's own PayID page states that payments after the first one to a payee should arrive in under a minute. A design built on overnight batch runs therefore does not match how the bank now works.

The Question Types

Payment processing from the app to settlement. Design the path from a customer pressing send to money arriving at another bank. The hard parts are idempotency, ordering, and failure, where idempotency means the same request can arrive twice while the money moves only once.

Real time fraud and scam checks. CommBank has released features that check a payment while it happens, so expect questions about scoring a payment within a few hundred milliseconds. NameCheck tells a customer whether the account name and the account details they typed appear to match. CallerCheck triggers a message in the app, so a customer can check a caller who claims to be from the bank.

Data platforms and event streaming. Data roles report questions about very large transaction tables, partitioning, indexing, and disaster recovery. Partitioning means splitting one table across many smaller stores so that each query reads less.

Personalization and real time decisioning. Published reports describe a Customer Engagement Engine that decides in real time what each customer sees across the bank's channels. Machine learning models produce those decisions, so expect questions about serving a model inside a single request.

A Walkthrough: Design a Payment Transfer System

Step 1: requirements (about 5 minutes). Customers send money to accounts at other banks at any hour of the day. Money must never be sent twice and never be lost, and the transfer should finish in under a minute with a fraud check inside that time.

Step 2: the request path. The mobile app calls a payments service through a gateway. Each request includes an idempotency key, so a retry after a timeout cannot create a second payment. Validate the account, the daily limits, and the balance first.

Step 3: the ledger. The ledger is the record of every credit and debit for an account, and each transfer writes a double entry record: one debit row and one credit row inside a single transaction. The two rows must sum to zero, so a half written transfer is impossible. Treat the ledger as append only, and calculate balances from it rather than editing a stored total.

Step 4: fraud and name checks. Score the payment before release, using features computed from recent account activity. Keep a strict time budget, and define the behavior when the model is slow: allow, hold, or ask the customer.

Step 5: settlement and reconciliation. Send the payment to the clearing network, then wait for its confirmation. Store each state change as an event, so the current state can be rebuilt after a crash. Reconciliation means comparing your own records against the network's file and resolving every difference.

Step 6: failure and scale. Queue payments when a downstream system is unavailable, and tell the customer what state the payment is in. Shard the ledger by account, and keep the busiest accounts on their own shards. Give the recovery plan too: how long a region failure takes to repair, and how much data could be lost.

What the Interviewer Grades

Requirements first, then one clear diagram, then trade offs with reasons. State the numbers out loud: expected payments per second, the size of the ledger after twelve months, and each call's time budget. Name the failure you fear most, then describe the defense against it.

Candidates report interviewers who are senior engineers and architects, so expect follow up questions on security and compliance. When you do not know the answer to a follow up question, say so plainly rather than guessing.

Common Mistakes in This Round

• Ignoring the correctness of money. A design that cannot prove why every balance is right fails, however well it scales.
• Treating fraud as a later feature. Fraud and scam checks belong in the payment path here, not in a separate project.
• Forgetting the audit record. Regulators and internal reviewers must see who did what, and when.
• Designing for overnight batch runs. Batch processing does not fit a bank whose payments clear in seconds.
• Skipping the cost to the customer. A wrongly blocked payment harms a real person, so name that trade off yourself.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, replication, and sharding, which every answer above uses.
• Study the harder cases. Advanced System Design Interview, Volume II goes deeper on consistency and failure recovery, which banking questions reward.
• Rehearse the six steps. Practice the payment walkthrough out loud in under 40 minutes.
• Learn the order of the rounds. The Commonwealth Bank interview process lists every stage, and how long it takes to hear back covers the wait afterwards.
• Prepare the motivation answer too. How to answer why Commonwealth Bank uses the same product research.