Banking Transfers, Account Merges, and Historical Balances

Implement a banking system that processes an ordered batch of operations. It supports basic accounts, settled transaction activity, pending transfers, account merging, and historical balances. Return one string per operation.

Time and result rules

• Each row begins with an operation name and an integer millisecond timestamp. Timestamps are strictly increasing.
• Return lowercase true or false for boolean results, base-10 strings for numbers, and the empty string for an unavailable numeric or transfer-ID result.
• A transfer created at time s can be accepted through s + 86400000. It expires at s + 86400001. Before any operation at time t, process every expiry at or before t, recording its refund at the expiry time.
• Rejected operations leave state unchanged, apart from expiries that must already have been processed.

Basic accounts and activity

• ["CREATE_ACCOUNT", t, id]: create an active account with balance and activity zero. Return true, or false if that ID is already active. A removed ID may be created again as a fresh account; older history remains queryable.
• ["DEPOSIT", t, id, amount]: credit a positive amount and return the balance, or the empty string for a missing account.
• ["PAY", t, id, amount]: debit a positive amount and return the balance, or the empty string for a missing account or insufficient funds.
• ["TOP_ACTIVITY", t, n]: return up to n active accounts ordered by settled transaction total descending, then ID lexicographically ascending. Format each entry as id(total), joined with , . Return the empty string if there are no active accounts.
• Settled activity counts deposits, successful payments, and the amount on both sides of an accepted transfer. A hold, refund, expiry, or merge adds no new transaction activity.

Pending transfers

• ["TRANSFER", t, source, target, amount]: immediately subtract and hold the positive amount from the source. Return the next global ID transfer1, transfer2, and so on. Reject with the empty string if either account is missing, the IDs are equal, or the source has insufficient funds. Only successful initiations consume an ID.
• ["ACCEPT_TRANSFER", t, id, transferId]: return true only if the transfer is pending and id is its current target. Credit that target, settle the hold, and add the amount to both accounts' activity totals. Otherwise return false.
• Pending money is unsettled; it contributes to neither account's settled activity until acceptance. An expiry or cancellation refunds the hold to its source without changing activity.

Account merges

["MERGE_ACCOUNTS", t, first, second] merges the second account into the first. Return false if either account is missing or the IDs are equal. Otherwise perform these steps and return true:

1. Cancel and refund every pending transfer whose source is the second account.
2. Cancel and refund every pending transfer from the first account to the second account.
3. Redirect every other pending transfer targeting the second account to the first account. Other pending transfers remain unchanged.
4. Add the second account's resulting balance and settled activity total to the first account, then remove the second account.

Historical balances

["GET_BALANCE", t, id, timeAt] returns that ID's balance after all activity at timeAt, or after the latest earlier activity if no event occurred exactly then. Return the empty string if the ID did not exist at that time.

• Before a merge, each account retains its separate history. At the merge timestamp, the surviving account has the combined balance and the removed account stops existing.
• A removed account remains queryable for times when it existed. A later recreation does not rewrite that history; it starts a new existence interval with zero balance and activity.
• When expiry and an external operation share a timestamp, historical balance at that timestamp includes both, with expiry processed first.