You are given a list of transaction records as strings. Each record has the format: ``` account_id,timestamp,currency,amount ``` - `account_id`: string identifier - `timestamp`: integer (not guaranteed sorted) - `currency`: string like `USD`, `EUR` - `amount`: integer (can be positive for credit or negative for debit) Maintain balances **per (account_id, currency)**. ## Part 1 — Final balances Process all transactions and return the final balance for each `(account_id, currency)`. - Exclude entries whose final balance is exactly `0`. - Output can be in any order (unless you choose to sort). ## Part 2 — Reject transactions that would go negative Now process transactions in **increasing `timestamp` order** (tie-breaker can be input order). A transaction is **rejected** if applying it would make that account’s balance for that `currency` fall below `0`. - Rejected transactions have no effect. - Return final non-zero balances as in Part 1. ## Part 3 — Use a platform account for insufficient funds Add support for a special “platform” account that can cover shortfalls. You are given `platform_account_id` as a parameter. Processing is still in **timestamp order**. For a debit transaction (negative `amount`) on account `A` in currency `C`: 1. If `A` has enough balance in `C`, apply it normally. 2. Otherwise, attempt to cover the shortfall using the **platform account’s balance in the same currency `C`**: - Deduct all remaining funds from `A` (bringing it to `0`). - Deduct the remaining required amount from the platform account. 3. If the platform account also lacks sufficient funds in `C`, **reject** the transaction (no balances change). Credits (positive `amount`) always apply. Return final non-zero balances for all accounts (including the platform account if non-zero). ### Constraints (you may assume) - Up to ~10^5 transactions - `timestamp` fits in 64-bit integer - `amount` fits in 64-bit signed integer