Banking System with Pending Transfer Acceptance

Implement a simplified banking system. The assessment is cumulative: after unlocking a new level, every operation from the current and previous levels remains available.

Query and Output Rules

• Each query calls exactly one operation and includes a stringified millisecond timestamp.
• Timestamps are unique, lie between 1 and 10^9, and appear in strictly increasing order.
• Return one string result for every query, in input order.
• Return the empty string when an operation has no successful scalar result, exactly as specified below.

Multipart Series

• Part 1: Accounts and Payments
• Part 2: Activity Ranking
• Part 3: Pending Transfer Acceptance
• Part 4: Account Merging and Balance History

Level 1: Accounts and Payments

The banking system should support creating new accounts, depositing money, and withdrawing or paying money from accounts.

• CREATE_ACCOUNT <timestamp> <accountId> creates a new account with the given accountId if it does not already exist. Return "true" if the account is created and "false" if it already exists.
• DEPOSIT <timestamp> <accountId> <amount> deposits amount into the account. Return the account balance after processing the query, or the empty string if the account does not exist.
• PAY <timestamp> <accountId> <amount> withdraws amount from the account. Return the account balance after processing the query. Return the empty string if the account does not exist or has insufficient funds.

Level 2: Activity Ranking

The banking system should support ranking accounts by the total value of their transactions.

• TOP_ACTIVITY <timestamp> <n> returns the top n accounts with the highest total transaction value, sorted by total value descending and then by accountId alphabetically ascending.
• Return one string in the format "<accountId1>(<transactionsValue1>), ..., <accountIdN>(<transactionsValueN>)".
• Total transaction value is the sum of every processed amount for an account, regardless of how it changes the balance: deposits, payments, and each side of a successfully accepted transfer count.
• If fewer than n accounts exist, return all active accounts in the same format.

Level 3: Pending Transfer Acceptance

The banking system should allow transfers to be scheduled and their status to be resolved by the target account.

• TRANSFER <timestamp> <sourceAccountId> <targetAccountId> <amount> initiates a transfer. Withdraw amount from the source immediately and hold it until the target accepts the transfer or it expires. Refund the held money to the source when it expires.
• Return the empty string when the source equals the target, either account is absent, or the source has insufficient funds.
• A transfer expires after 24 * 60 * 60 * 1000 = 86400000 milliseconds. It expires at the beginning of the next millisecond after that period, so acceptance at the exact expiration timestamp is still valid.
• A valid transfer returns the next global ID: "transfer1", "transfer2", and so on. Failed transfers do not consume an ID.
• The source and target transaction histories are updated only after acceptance. A successfully accepted transfer contributes its amount to the total transaction value of both accounts.
• ACCEPT_TRANSFER <timestamp> <accountId> <transferId> accepts a pending transfer. Return "true" on success. Return "false" if the transfer does not exist, was already accepted, expired, or accountId is not its target.