Progressive Banking System with Cashback

Implement a progressive banking system. All operations have a timestamp parameter — a stringified timestamp in milliseconds. All timestamps are unique, lie in the range from 1 to 10^9, and are supplied in strictly increasing order.

Before every operation at timestamp t, process every cashback whose due time is at most t. A cashback due exactly at t is credited before that operation.

Level 1

Initially, the banking system does not contain any accounts. Support account creation, deposits, and transfers between two different accounts:

• createAccount(timestamp, accountId) creates a new account with the given identifier if it does not already exist. It returns true when the account is created and false when an active account with accountId already exists.
• deposit(timestamp, accountId, amount) deposits the given amount into the specified account and returns its resulting balance. It returns null when the account does not exist.
• transfer(timestamp, sourceAccountId, targetAccountId, amount) transfers the given amount from the source account to the target account and returns the resulting source balance. It returns null when either account is missing, the identifiers are equal, or the source has insufficient funds.

Level 2

topSpenders(timestamp, n) returns up to n active accounts with the highest total outgoing transactions. Outgoing transactions include successful transfers out and successful payments. Sort by outgoing total in descending order, then by accountId in ascending lexicographic order. Format every entry as accountId(totalOutgoing). If fewer than n accounts exist, return all of them. Cashback never counts as outgoing activity.

Level 3

• pay(timestamp, accountId, amount) withdraws the amount when the account exists and has sufficient funds. A successful payment contributes to outgoing activity, returns the next global identifier paymentK, and schedules floor(amount * 2 / 100) cashback for timestamp + 86400000. A failed payment returns null and does not consume an identifier.
• getPaymentStatus(timestamp, accountId, payment) returns IN_PROGRESS before that payment's cashback is processed and CASHBACK_RECEIVED afterward. It returns null when the account or payment does not exist, or when the payment belongs to a different current account lineage.

Level 4

• mergeAccounts(timestamp, accountId1, accountId2) merges accountId2 into accountId1. It returns false if the identifiers are equal or either active account is missing; otherwise it returns true.
• The survivor receives the absorbed balance and outgoing total. Pending cashback follows the survivor, old payments from the absorbed account become queryable through the survivor, and accountId2 is removed. A removed identifier may later be created as a new, independent account.
• getBalance(timestamp, accountId, timeAt) returns the account balance immediately after all activity at timeAt, or after the latest earlier activity when nothing happened exactly then. It returns null if accountId is not active at the query timestamp or if that surviving account did not yet exist at timeAt.
• After a merge, the survivor inherits the absorbed account's balance history. For a historical time when both lineages existed, the survivor's historical balance is their sum; internal transfers between the two lineages cancel naturally.

FastPrep Batch Interface

Implement processBankingQueries(queries). Each row contains an uppercase operation name followed by the arguments shown below. Return one string per query in the same order.

• Use CREATE_ACCOUNT, DEPOSIT, TRANSFER, TOP_SPENDERS, PAY, GET_PAYMENT_STATUS, MERGE_ACCOUNTS, and GET_BALANCE.
• Serialize booleans as true or false, numbers in base 10, and every conceptual null as the empty string.
• Serialize TOP_SPENDERS by joining its formatted entries with commas and no spaces.