Banking Pending Transfer Acceptance
Reported by candidates from Anthropic's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Anthropic OA reported in July 2026 looks like a banking problem, but it's really a hash map plus a lazy expiry sweep. Every operation first refunds stale pending transfers, then does its own thing. If you're taking this in the next day or two, that ordering is the whole game. StealthCoder is the safety net if you blank on the live OA, running invisibly and screen-share-resistant. But the logic here is small enough to hold in your head once you see the shape.
The problem
Implement a banking system that reserves outgoing transfers until the recipient accepts them. Operation Format Each row in operations contains an operation name followed by string arguments. Timestamps are strictly increasing. Return one row for every operation. Scalar results use one-element rows; TOP_ACTIVITY returns its ranked list directly. Before processing an operation at timestamp t, expire every unaccepted transfer whose expiration timestamp is strictly less than t and refund its reserved amount to the sender. Basic Operations ["CREATE_ACCOUNT", timestamp, account_id]: create a unique account with balance zero. Return true or false. ["DEPOSIT", timestamp, account_id, amount]: add funds and return the new balance, or null if the account does not exist. ["PAY", timestamp, account_id, amount]: withdraw funds and return the new balance. Return null for a missing account or insufficient funds. ["TOP_ACTIVITY", timestamp, n]: rank up to n accounts by total processed amount descending, then account ID ascending. Format entries as account_id(total). Deposits, successful payments, and both sides of accepted transfers count; merely creating or expiring a transfer does not. Pending Transfers ["TRANSFER", timestamp, source_id, target_id, amount]: validate two different existing accounts and sufficient source funds. Reserve the amount immediately and return a globally increasing ID transfer1, transfer2, and so on. Return null on failure. A transfer's expiration timestamp is timestamp + 86400000. It may still be accepted at that exact timestamp; a later operation expires it. ["ACCEPT_TRANSFER", timestamp, account_id, transfer_id]: return true only when account_id is the intended recipient and the transfer is still pending. Credit the recipient, finalize the reserved debit, and add the amount to both accounts' activity totals. Otherwise return false. Function bankingPendingTransferAcceptance(operations: String[][]) → String[][] Examples Example 1 operations = [["CREATE_ACCOUNT","1","alice"],["CREATE_ACCOUNT","2","bob"],["DEPOSIT","3","alice","500"],["TRANSFER","4","alice","bob","200"],["TOP_ACTIVITY","5","2"],["ACCEPT_TRANSFER","6","bob","transfer1"],["TOP_ACTIVITY","7","2"]] return = [["true"],["true"],["500"],["transfer1"],["alice(500)","bob(0)"],["true"],["alice(700)","bob(200)"]] The transfer reserves 200 but does not affect activity until Bob accepts it. Acceptance then records 200 for both participants. Example 2 operations = [["CREATE_ACCOUNT","1","a"],["CREATE_ACCOUNT","2","b"],["DEPOSIT","3","a","100"],["TRANSFER","10","a","b","70"],["ACCEPT_TRANSFER","86400011","b","transfer1"],["PAY","86400012","a","20"]] return = [["true"],["true"],["100"],["transfer1"],["false"],["80"]] The acceptance occurs one millisecond after the expiration timestamp, so the transfer is refunded before the failed acceptance. Account A can then pay 20 from its restored balance of 100.
Reported by candidates. Source: FastPrep
Pattern and pitfall
What it reduces to: accounts in a hash map (balance, activity total), transfers in a second map (source, target, amount, expiry, status), and a counter for transfer IDs. Before every operation at timestamp t, expire every pending transfer with expiry strictly less than t and refund the source. Since timestamps strictly increase, a min-heap or an insertion-ordered queue of pending transfers makes the sweep cheap. Pitfalls: expiry is inclusive, so acceptance at exactly t+86400000 works. Reserved funds leave the balance immediately, so PAY sees the reduced balance. Activity counts only on accept, for both sides. TOP_ACTIVITY sorts by total descending, then ID ascending, and includes zero-activity accounts, like bob(0). Run the sweep first, even for failing operations. If you freeze live, StealthCoder is the hedge, but write the sweep function first and everything else hangs off it.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Banking Pending Transfer Acceptance 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. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Anthropic's OA.
Anthropic reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Banking Pending Transfer Acceptance FAQ
What's the trick in the Anthropic Banking Pending Transfer Acceptance problem?+
Run an expiry sweep at the top of every operation, before anything else. Expire transfers whose expiry is strictly less than the current timestamp and refund the source. Almost every wrong answer comes from skipping the sweep on some operation type or getting the boundary off by one.
How hard is this OA really?+
It's more careful than hard. No fancy algorithm, just hash maps, a sort, and a handful of rules. Candidates lose points on edge cases: boundary expiry, activity only counting on accept, and null returns. Read the examples closely and you're most of the way there.
Does the exact expiration timestamp count as expired?+
No. A transfer can still be accepted at timestamp + 86400000. It expires only when a later operation arrives with a larger timestamp. Example 2 shows this: acceptance one millisecond past the expiry returns false and the sender is refunded.
How should TOP_ACTIVITY be sorted and formatted?+
Sort by total processed amount descending, then account ID ascending. Return up to n entries formatted as account_id(total), such as alice(700). Include accounts with zero activity. Deposits, successful pays, and both sides of accepted transfers add to the total. Creating or expiring a transfer adds nothing.
How do I prepare for this in 48 hours?+
Write a small simulator yourself. Build the accounts map, the transfers map, and the sweep function. Then trace both examples by hand against your code. Test a failed transfer, a wrong recipient accepting, double acceptance, and a refund restoring balance. That covers nearly every rule in the spec.