Banking System with Accepted Transfers, Part 4: Account Merging and Balance History

Implement a simplified banking system through four cumulative levels. The source exposes direct methods; this practice version serializes the same calls as one ordered String[][] queries batch and returns one string per query.

Timestamp and output rules

• Every query starts with an uppercase operation name followed by its arguments. All timestamps are unique integers from 1 through 10^9 and arrive in strictly increasing order.
• Serialize booleans as true or false, numbers in base 10, and conceptual null results as the empty string.
• Before each external query at timestamp t, expire every pending transfer whose acceptance window ended before t. A transfer created at s remains acceptable through s + 86400000 and expires at the beginning of the next millisecond.

Level 1: Accounts, deposits, and payments

• ["CREATE_ACCOUNT", timestamp, accountId] implements createAccount. Create the account with balance zero and return true, or return false when that active ID already exists.
• ["DEPOSIT", timestamp, accountId, amount] implements deposit. Add the positive amount and return the resulting balance, or the empty string when the account does not exist.
• ["PAY", timestamp, accountId, amount] implements pay. Subtract the positive amount and return the resulting balance. Return the empty string when the account is missing or has insufficient funds.

Level 2: Activity ranking

• ["TOP_ACTIVITY", timestamp, n] implements topActivity. Rank active accounts by total transaction value descending and then accountId ascending.
• Total transaction value is the sum of every successful processed amount affecting the account: deposits, payments, and both sides of an accepted transfer. Creating, rejecting, holding, expiring, refunding, or merely initiating a transfer adds no activity.
• Format entries as accountId(total), join them with , , and return at most n entries.

Level 3: Pending transfer acceptance

• ["TRANSFER", timestamp, sourceAccountId, targetAccountId, amount] implements transfer. Hold the amount from the source until the target accepts or the transfer expires. Return the next global ID transferK. Return the empty string, without consuming an ID, when the IDs are equal, either account is missing, or funds are insufficient.
• ["ACCEPT_TRANSFER", timestamp, accountId, transferId] implements acceptTransfer. Return true only when the transfer is still pending and accountId is its current target; credit the target and add the amount to both accounts' transaction totals. Return false for a missing, accepted, canceled, expired, or wrong-target transfer.
• An expired or canceled transfer refunds its held amount to its current source and never changes either transaction total.

Level 4: Account merging and historical balance

• ["MERGE_ACCOUNTS", timestamp, accountId1, accountId2] implements mergeAccounts. Return false when the IDs are equal or either active account is missing; otherwise merge Account 2 into Account 1 and return true.
• Cancel every pending transfer whose source is Account 2 and refund its hold. Also cancel and refund every pending transfer from Account 1 to Account 2. Redirect every other pending transfer targeting Account 2 so that it targets Account 1.
• After those cancellations, add Account 2's balance and transaction total to Account 1. Account 1 keeps its ID; Account 2 is removed.
• ["GET_BALANCE", timestamp, accountId, timeAt] implements getBalance. Return that ID's balance immediately after all activity at timeAt, or after the latest earlier activity when nothing occurred exactly then. Return the empty string if that account generation did not exist at timeAt.
• Before the merge, each ID keeps its own history. At the merge timestamp, Account 1 records the final combined balance and Account 2 stops existing. Account 2 remains queryable only for times before the merge.