Process Transactions and Compute Balances

You are given a list of financial transactions in CSV-like rows:

account_name, timestamp, currency, amount

• account_name is a string ID.
• timestamp is an integer (not guaranteed to be sorted).
• currency is a string like "usd" .
• amount is an integer (positive = credit, negative = debit).

Assume all arithmetic is integer. Unless otherwise stated, process transactions in increasing timestamp order (stable tie-breaker by input order).

Part 1 — Final non-zero balances

Compute each account’s final balance (you may assume all rows are the same currency, or treat balances independently per (account_name, currency)—state your assumption). Output all accounts with non-zero final balance.

Example Input:

account_name, timestamp, currency, amount
acct_123,1,usd,1000
acct_123,2,usd,500
acct_321,3,usd,400
acct_321,4,usd,-400

Output:

• acct_123 has balance 1500
• acct_321 is omitted (balance 0 )

Part 2 — Reject debits that would overdraw

Process transactions in time order while maintaining balances.

A transaction is rejected if applying it would make the account’s balance negative (i.e., balance + amount < 0). Rejected transactions:

• must be appended to rejected_transactions in the order encountered,
• must not affect any balances.

At the end, output:

1. rejected_transactions (full original rows for rejected ones), and
2. all accounts with non-zero final balance.

Example Input:

account_name, timestamp, currency, amount
acct_123,1,usd,1000
acct_123,2,usd,500
acct_321,3,usd,400
acct_321,4,usd,-500

Output:

• Non-zero balances: acct_123 = 1500 , acct_321 = 400
• rejected_transactions = ["acct_321,4,usd,-500"]

Part 3(a) — Platform reserve can cover negatives

You are also given a special platform_id account.

Process transactions in time order with the following rule:

• For any non-platform account, if applying a transaction would make its balance negative, the account may borrow from the platform just enough to bring its balance back to 0 .
  • This borrowing reduces the platform’s balance accordingly.
  • Track the platform’s outstanding loans (e.g., per account) so that when an account later receives credits, it repays its debt before increasing its own positive balance (state and apply a consistent repayment rule).
• If the platform does not have enough available balance to cover the needed borrowing at that moment, then the transaction is rejected (and does not change balances or debts).

Output three things:

1. max_reserve : the maximum total outstanding amount borrowed from the platform at any time (peak platform exposure),
2. rejected_transactions ,
3. all accounts with non-zero final balance (including the platform if non-zero).

Example (platform_id = acct_123) Input:

account_name, timestamp, currency, amount
acct_123,1,usd,1000
acct_321,3,usd,400
acct_321,4,usd,-500

Explanation: acct_321 would go to -100, so it borrows 100 from the platform to return to 0.

Output:

• max_reserve = 100
• rejected_transactions = []
• Non-zero balances include acct_123 = 900 (and acct_321 omitted if it ends at 0 )

Constraints (you may assume)

• Up to ~200k transactions.
• Need an efficient solution (typically O(n log n) due to sorting, or O(n) if already sorted).