Banking System with Transfers, Top Spenders, Delayed Payments, and Account Merging

Design a Bank class that simulates a financial system supporting account creation, cash deposits, transfers, a leaderboard of top spenders, scheduling and canceling deferred payments, merging accounts, and balance inquiries. Before executing any operation that receives a timestamp, all pending deferred payments whose execution time is less than or equal to that timestamp must be processed.

Core Concepts

• Every account is identified by a unique string accountId.
• Account balances are never allowed to go negative. Any transaction that would cause an overdraft is rejected.
• Spending is defined exclusively as money leaving an account:
  • It includes outgoing transfer amounts and successfully debited deferred payments.
  • It does not include deposits, incoming transfers, or failed deferred payments.

Deferred Payment Processing (global rule)

• A deferred payment has a planned executeTime (set to timestamp + delay when scheduled).
• When an operation is called with a new timestamp, the system must:
  1. Execute every deferred payment whose executeTime is ≤ timestamp (i.e., payments due now or earlier).
  2. If multiple payments share the same executeTime, process them in the order they were created (FIFO).
• Execution behavior for each payment:
  • If the owner account’s balance is sufficient, deduct the amount, add it to the account’s spending, and mark the payment as processed.
  • If insufficient, the payment fails: no balance change, no spending added, still marked as processed.
  • Once processed (success or failure), a payment is never executed again.

---

API Methods

1. createAccount(accountId: str) -> bool

Create a new account with a zero balance and zero spending. Return True if the account was created; return False if an account with that ID already exists.

2. deposit(timestamp: int, accountId: str, amount: int) -> int | None

First, process all due deferred payments (see global rule). If the account exists, add amount to its balance and return the new balance. Otherwise return None.

3. transfer(timestamp: int, fromId: str, toId: str, amount: int) -> int | None

First, process due deferred payments. A successful transfer requires:

• Both accounts exist,
• fromId and toId are different,
• fromId has a balance ≥ amount. If all conditions hold, debit fromId, credit toId, add amount to the spending of fromId, and return the remaining balance of fromId. On any failure condition, return None.

4. topSpenders(timestamp: int, k: int) -> list[str]

First, process due deferred payments. Compute the k accounts with the highest spending. If fewer than k accounts exist, return all of them. Sort the result by spending descending; ties are broken by accountId ascending (lexicographic order). Each entry must be formatted as "accountId(spending)".

5. schedulePayment(timestamp: int, accountId: str, amount: int, delay: int) -> str | None

First, process due deferred payments. If the account exists, create a new deferred payment with executeTime = timestamp + delay. Return a unique identifier string such as "payment1", "payment2", … (the actual implementation must return globally unique IDs across all calls). If the account does not exist, return None.

6. cancelPayment(timestamp: int, accountId: str, paymentId: str) -> bool

First, process due deferred payments. The cancellation succeeds only if paymentId refers to an existing payment that belongs to accountId and that has not yet been processed or canceled. Return True on success, False otherwise.

7. mergeAccounts(timestamp: int, targetId: str, sourceId: str) -> bool

First, process due deferred payments. The merge is allowed when both accounts exist and targetId != sourceId. The effect:

• targetId’s balance is increased by the balance of sourceId.
• targetId’s spending is increased by the spending of sourceId.
• All unprocessed deferred payments belonging to sourceId are reassigned to targetId.
• The sourceId account is permanently deleted. Return True if the merge succeeded, False otherwise.

8. getBalance(timestamp: int, accountId: str) -> int | None

First, process due deferred payments. Return the current balance of the account if it exists; otherwise None.

---

Example 1 (basic flow, no deferred payments)

Input:
createAccount "acc1"
createAccount "acc2"
deposit 1 "acc1" 500
deposit 2 "acc2" 200
transfer 3 "acc1" "acc2" 150
topSpenders 4 2
getBalance 5 "acc1"
getBalance 6 "acc2"

Output:
true
true
500
200
350
["acc1(150)", "acc2(0)"]
350
350

Explanation: After the transfer, acc1 spent 150 and has balance 350; acc2 has 350 and spent 0. The top spenders are returned in the required format.

Example 2 (deferred payment execution)

Input:
createAccount "userA"
deposit 10 "userA" 1000
schedulePayment 10 "userA" 200 5
getBalance 12 "userA"
deposit 15 "userA" 0
topSpenders 15 1
getBalance 16 "userA"

Output:
true
1000
"payment1"
1000
800
["userA(200)"]
800

Explanation: payment1 is due at time 15. The deposit at time 15 first processes it – balance drops to 800, spending becomes 200. The subsequent topSpenders reflects that spending.

Example 3 (account merging and payment cancellation)

Input:
createAccount "accA"
createAccount "accB"
deposit 1 "accA" 600
deposit 1 "accB" 400
schedulePayment 1 "accB" 100 10
mergeAccounts 2 "accA" "accB"
cancelPayment 3 "accA" "payment1"
deposit 12 "accA" 0
getBalance 12 "accA"

Output:
true
true
600
400
"payment1"
true
true
1000
1000

Explanation: After merging, accA owns the 1000 total balance and the deferred payment. The cancellation is valid. At time 12, no payment is due, so deposit with amount 0 simply returns the current balance.

---

Constraints

• 1 <= total number of API calls <= 10^5
• 1 <= length of accountId <= 20; at most 10^5 distinct accounts exist at any time
• 0 <= timestamp, amount, delay <= 10^9
• All input values are valid (non‑negative amounts and delays, non‑empty strings, etc.)
• A solution with O(log n)‑amortized time per operation (e.g., using a priority queue for payments) is expected.