How should I practice Banking System, Part 4: Merging and Balance History?

Start by reading the full statement, solve the visible examples, then compare the pattern against related Anthropic online assessment problems in FastPrep.

Is Banking System, Part 4: Merging and Balance History associated with Anthropic?

FastPrep tags this as a Anthropic coding interview or online assessment practice problem when the problem catalog has that company context.

Problem · Design

Banking System, Part 4: Merging and Balance History

Learn this problem

● HardAnthropicOA

Problem statement

Banking System series

Continue the cumulative banking system from Parts 1 through 3. The system now merges accounts and answers historical balance queries.

Operation Format

Each input row contains an operation name followed by string arguments. Return one result row per operation. Scalar and null results use a one-element row; TOP_SPENDERS returns its list directly. Scheduled payments are processed before every input operation exactly as in Part 3.

Level 4 Operations

["MERGE_ACCOUNTS", timestamp, account_id_1, account_id_2]: Merge Account 2 into Account 1. Return false if the IDs are equal or either active account does not exist; otherwise return true.
On a successful merge, add Account 2's balance and outgoing total to Account 1.
Move every pending payment owned by Account 2 to Account 1. It can then be canceled using Account 1's ID.
Remove Account 2 from the active system after the merge.
["GET_BALANCE", timestamp, account_id, time_at]: Return that ID's balance immediately after all operations and scheduled-payment activity at time_at. Return null if the account did not exist at that time.

Conservative History Scope

The history rules below are the only merge-history behavior judged in this part:

Before a merge, each account ID has its own balance history.
At the merge timestamp, Account 1's balance becomes the combined balance and Account 2 stops existing.
Account 2's balance before the merge remains queryable using Account 2 and an earlier time_at.
From the merge timestamp onward, Account 1's history reflects the combined account.

No additional behavior from the unavailable remainder of the source is assumed.

Function

bankingSystemLevel4(operations: String[][]) → String[][]

Examples

Example 1

operations = [["CREATE_ACCOUNT","1","primary"],["CREATE_ACCOUNT","2","secondary"],["DEPOSIT","3","primary","100"],["DEPOSIT","4","secondary","200"],["SCHEDULE_PAYMENT","5","secondary","50","10"],["TRANSFER","6","secondary","primary","20"],["MERGE_ACCOUNTS","7","primary","secondary"],["TOP_SPENDERS","8","1"],["CANCEL_PAYMENT","9","primary","payment1"],["DEPOSIT","10","secondary","1"],["GET_BALANCE","11","primary","7"],["GET_BALANCE","12","secondary","6"],["GET_BALANCE","13","secondary","7"]]return = [["true"],["true"],["100"],["200"],["payment1"],["180"],["true"],["primary(20)"],["true"],["null"],["300"],["180"],["null"]]

The merge combines balances 120 + 180 = 300, outgoing totals, and the pending payment. Secondary existed with balance 180 at timestamp 6, but no longer exists at timestamp 7.

Example 2

operations = [["CREATE_ACCOUNT","1","a"],["CREATE_ACCOUNT","2","b"],["DEPOSIT","3","a","50"],["DEPOSIT","4","b","100"],["SCHEDULE_PAYMENT","5","b","70","5"],["MERGE_ACCOUNTS","6","a","b"],["DEPOSIT","10","a","10"],["GET_BALANCE","11","a","10"],["TOP_SPENDERS","12","1"],["CANCEL_PAYMENT","13","a","payment1"]]return = [["true"],["true"],["50"],["100"],["payment1"],["true"],["90"],["90"],["a(70)"],["false"]]

The pending payment moves from B to A during the merge. It executes before the timestamp-10 deposit, reducing the combined balance from 150 to 80; the deposit then raises it to 90.

Constraints

1 <= time_at <= timestamp <= 10^9
All input-operation timestamps are unique and strictly increasing.
Amounts, delays, and ranking limits are positive integers.
All numeric results and scheduled execution timestamps fit in a signed 64-bit integer.
Every operation has exactly the arguments defined in Parts 1 through 4.