MediumArrayHash TableDesignSimulationUpdated Sep 2026

2043. Simple Bank System

Asked at Capital One

Difficulty

Medium

Time

O(1) per operation

Space

O(n)

Pattern

Array

Companies

1

Problem

Design a class that simulates a bank with n accounts. Account numbers run from 1 to n, but the starting balances are given in a 0-indexed array balance, where account i + 1 starts with balance[i] dollars.

Implement three operations. deposit(account, money) adds money to one account. withdraw(account, money) removes money from one account. transfer(account1, account2, money) moves money from one account to another. Each method returns true if it succeeded and false if it did not.

A transaction is valid only when both rules hold: every account number mentioned is between 1 and n, and the account that gives money (the one in withdraw, or account1 in transfer) holds at least money. If a transaction is not valid, return false and change nothing — no balance may move. Deposits have no balance rule, only the account-number rule.

Accounts are 1-indexed, the array is 0-indexed

balance1010020503001234index 0 holds account 1's money, index 2 holds account3's moneycheck account numbers existcheck enough balanceupdate balances, return trueEvery operation follows the same order: validatefirst, then change state.
Account number a always maps to array slot a - 1, so account 1 is at index 0.

Constraints

  • ●n == balance.length
  • ●1 <= n, account, account1, account2 <= 10^5
  • ●0 <= balance[i], money <= 10^12
  • ●At most 10^4 calls will be made to each function transfer, deposit, withdraw

Examples

Example 1
Input["Bank", "withdraw", "transfer", "deposit", "transfer", "withdraw"] [[[10, 100, 20, 50, 30]], [3, 10], [5, 1, 20], [5, 20], [3, 4, 15], [10, 50]]
Output[null, true, true, true, false, false]
WhyAccount 3 starts at 20, so taking out 10 works and leaves 10. Account 5 holds 30, so sending 20 to account 1 works: account 5 drops to 10 and account 1 rises to 30. Depositing 20 into account 5 works, giving it 30. Then account 3 only has 10, so transferring 15 fails. Finally account 10 does not exi
Example 2
Input["Bank", "deposit", "withdraw", "transfer"] [[[0, 0]], [1, 5], [2, 3], [1, 2, 5]]
Output[null, true, true, false]
WhyDepositing 5 into account 1 works, so it holds 5. Withdrawing 3 from account 2 works even though it started at 0, because after the deposit account 2 still has 0 — wait, it has 0, so this fails. Actually account 2 has 0, so the withdraw returns false. Then account 1 has 5, so transferring 5 out woul

Asked At

1 companies
CompanyDifficulty
Capital OneMediumView all Capital One questions →

How to Think About It

1

Store balances in an array. Account numbers are 1-indexed, so account a lives at index a - 1.

2

Write one helper, valid(a), that checks 1 <= a <= n. Every operation starts by validating its account numbers.

3

For withdraw and transfer, check the balance before changing anything — a failed operation must leave all balances untouched.

4

Balances and amounts go up to 10^12, so use 64-bit integers in C++/Java.

5

Follow-up discussion: concurrency (locking the two accounts in a transfer in a consistent order to avoid deadlock).

Optimal Approach

State: bal (array of balances), n.

transfer(a, b, m): valid if both accounts exist and bal[a] >= m; then bal[a] -= m, bal[b] += m.
deposit(a, m): valid if a exists; bal[a] += m.
withdraw(a, m): valid if a exists and bal[a] >= m; bal[a] -= m.
Each returns whether it succeeded.

Time: O(1) per operation. Space: O(n).

One helper plus three small methods

balance1010020503001234transfer(5, 1, 20): account 5 has 30 >= 20, so it isallowedbalance3010020501001234After the transfer: account 5 lost 20, account 1gained 20valid(a) = 1 <= a <= nwithdraw/transfer: also need bal[a-1] >= moneyfailed call → return false, touch nothing
A single valid(a) check keeps all three methods short and consistent.
ComplexityTime O(1) per operationSpace O(n)Each call only checks a couple of indices and updates at most two array cells; the O(n) space is the balance array itself.

What Trips People Up in Real Interviews

1

Forgetting the 1-indexed account numbers.

2

Partially applying a transfer (debiting before checking the destination exists).

3

Using 32-bit integers for balances up to 10^12.

4

Not validating the account in deposit — deposits into nonexistent accounts must fail.

Solution Code

O(1) per operation time
class Bank:
    def __init__(self, balance):
        self.bal = balance
        self.n = len(balance)

    def _ok(self, a):
        return 1 <= a <= self.n

    def transfer(self, account1, account2, money):
        if not (self._ok(account1) and self._ok(account2)) or self.bal[account1 - 1] < money:
            return False
        self.bal[account1 - 1] -= money
        self.bal[account2 - 1] += money
        return True

    def deposit(self, account, money):
        if not self._ok(account):
            return False
        self.bal[account - 1] += money
        return True

    def withdraw(self, account, money):
        if not self._ok(account) or self.bal[account - 1] < money:
            return False
        self.bal[account - 1] -= money
        return True

Pro at DSA?

Test your skills with a real FAANG-style mock interview.

Start a Mock Interview →

Frequently Asked Questions

What is the Simple Bank System problem?

Simple Bank System asks you to implement transfer, deposit, and withdraw on an array of account balances, returning false for any invalid transaction (a nonexistent account or insufficient funds). It is a design warm-up about validation order and 1-indexed accounts.

How do you solve Simple Bank System?

The optimal approach runs in O(1) per operation time and O(n) space. Scroll up to "Optimal Approach" for the step-by-step walkthrough, diagrams, and code in Python, C++ and Java.

What companies ask Simple Bank System?

Simple Bank System is asked at Capital One. It is a medium difficulty problem.

What are common mistakes on Simple Bank System?
  • Forgetting the 1-indexed account numbers.
  • Partially applying a transfer (debiting before checking the destination exists).
  • Using 32-bit integers for balances up to `10^12`.
  • Not validating the account in `deposit` — deposits into nonexistent accounts must fail.