Bank Requests with Delayed Cashback
Reported by candidates from Ramp's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Ramp OA reported in December 2025 hides its trap in one sentence: cashback due at the same timestamp as a request lands first. Miss that and your balances drift by a few units, or you reject a withdrawal that should pass. It's a simulation problem with a queue of scheduled credits, nothing exotic, but the ordering rules are where candidates lose points. If you blank on the cashback timing mid-assessment, StealthCoder is the invisible safety net that reads the problem and hands you a working solution. Know the rules cold and this is 20 minutes of work.
The problem
You are given the initial balances of several bank accounts and a sequence of timestamped requests. Process the requests in order and return the resulting balances. Account holder IDs are the 1-based positions of their accounts in balances. Request format Every request is a lowercase space-delimited string in one of these forms: deposit timestamp holderId amount: add amount to the selected account. withdraw timestamp holderId amount: remove amount from the selected account and schedule a cashback equal to floor(amount * 2 / 100). Cashback processing A scheduled cashback is credited exactly 86400 seconds after its successful withdrawal. Before processing an external request at timestamp t, apply every cashback whose due timestamp is at most t. Therefore, a cashback due at the same timestamp as a deposit or withdrawal is applied first. After the last external request is processed, ignore every cashback whose due timestamp is later than that request. Invalid requests A request is invalid when its holderId is outside 1..balances.length, or when a withdrawal exceeds the account's available balance after all cashback due at that timestamp has been applied. Result If every request is valid, return the final balances. Otherwise, stop at the first invalid request and return a one-element array containing the negative 1-based index of that request. Function processBankRequests(balances: long[], requests: String[]) → long[] Examples Example 1 balances = [1000,500] requests = ["withdraw 100 1 200","deposit 200 2 300","withdraw 86500 1 500"] return = [304,800] The first withdrawal leaves account 1 at 800 and schedules cashback 4 for timestamp 86500. The deposit raises account 2 to 800. At timestamp 86500, cashback is applied first, so account 1 becomes 804 before the withdrawal leaves it at 304. The new cashback is due after the last request and is ignored. Example 2 balances = [100] requests = ["withdraw 10 1 100","withdraw 86410 1 3"] return = [-2] The first withdrawal schedules cashback 2. That cashback is credited before request 2 at the same timestamp, but the balance is still only 2. Withdrawing 3 is invalid, so the result is [-2]. Example 3 balances = [200,300] requests = ["deposit 5 3 10"] return = [-1] There are only two accounts, so holder ID 3 makes the first request invalid. Constraints 1 <= balances.length <= 200000 1 <= requests.length <= 200000 0 <= balances[i] <= 10^9 Every request has exactly four space-delimited tokens and uses deposit or withdraw. Every request amount is in 1..10^9. Request timestamps are nonnegative and strictly increasing. Every intermediate balance fits in a signed 64-bit integer.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Since timestamps strictly increase, every cashback is due at its withdrawal time plus 86400, so due times are also strictly increasing. That means a plain FIFO queue works. No heap needed. Before each request at time t, pop while the front's due time is at most t and credit that account. Then validate holderId, then check the withdrawal against the balance after credits. The pitfalls: using less-than instead of less-or-equal for due times, validating the balance before applying cashback, and scheduling cashback for a withdrawal that failed. Also use 64-bit math and integer floor of amount * 2 / 100. After the last request, don't flush the queue. Return the negative 1-based index on the first invalid request. StealthCoder is your hedge on the live OA if the ordering logic slips under pressure, but the whole thing is one loop and one queue.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Bank Requests with Delayed Cashback cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Ramp's OA.
Ramp reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Bank Requests with Delayed Cashback FAQ
What's the trick in the Ramp bank requests problem?+
Apply all cashback due at or before the request timestamp before you validate or process that request. Same-timestamp cashback goes first. A FIFO queue of (dueTime, holder, amount) handles it, because due times arrive in increasing order.
Do I need a priority queue for the cashbacks?+
No. Request timestamps are strictly increasing and every cashback is exactly 86400 seconds later, so due times are already sorted. A plain queue or a pointer into an array is enough and keeps it O(n).
What edge cases break a naive solution?+
Cashback due exactly at the request time, a withdrawal that only succeeds because of that cashback, an invalid holderId like 3 with two accounts, and failed withdrawals that must not schedule cashback. Also don't apply cashback after the final request.
How hard is this really?+
Easy to medium. There's no clever algorithm, just careful simulation with 200000 requests. The difficulty is reading the rules precisely. Parse each request string, use 64-bit integers, and test against the three examples.
How do I prepare in 48 hours for this kind of OA?+
Write this one from scratch twice, then do a few simulation problems with queues and ordered events. Practice parsing space-delimited strings and returning early on the first failure. Focus on rule ordering, not new algorithms.