Banking System, Part 3: Scheduled Payments
Reported by candidates from Anthropic's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Anthropic reported this one in July 2026, and the trap is in the scale, not the logic. Timestamps go up to 10^9, so you can't tick a clock forward one unit at a time and fire payments as you go. This is Part 3 of a cumulative banking system, so it builds on accounts, deposits, transfers and TOP_SPENDERS from the earlier parts. If your Part 1 and 2 code is sloppy, this part exposes it fast. The pattern is design with a priority queue underneath. If you blank mid-assessment, StealthCoder runs invisibly on your screen as a safety net, but the idea below is short enough to carry in your head.
The problem
Banking System series Part 1: Accounts and Transfers Part 2: Top Spenders Part 3: Scheduled Payments Part 4: Merging and Balance History Continue the cumulative banking system from Parts 1 and 2. The system now supports scheduling and canceling payments. Operation Format Each input row contains an operation name followed by string arguments. Return one result row per operation. Scalar and null results use a one-element row; TOP_SPENDERS returns its list directly. Scheduled Payment Processing Before processing an input operation at timestamp t, execute every pending payment whose scheduled time is at most t. A payment scheduled for the same timestamp as another operation executes first. Payments with the same execution timestamp are processed in creation order. If the account has insufficient funds at execution time, the payment is skipped. A successful payment reduces the balance and adds its amount to the account's outgoing total for TOP_SPENDERS. Level 3 Operations ["SCHEDULE_PAYMENT", timestamp, account_id, amount, delay]: Schedule a payment for timestamp + delay. Successful schedules receive globally unique IDs payment1, payment2, and so on. Return the ID, or null if the account does not exist. ["CANCEL_PAYMENT", timestamp, account_id, payment_id]: Cancel a pending payment. Return true on success. Return false if the payment does not exist, is no longer pending, or belongs to a different account. Because due payments execute first, canceling a payment at its execution timestamp is too late. Function bankingSystemLevel3(operations: String[][]) → String[][] Examples Example 1 operations = [["CREATE_ACCOUNT","1","account1"],["CREATE_ACCOUNT","2","account2"],["DEPOSIT","3","account1","2000"],["DEPOSIT","4","account2","3000"],["SCHEDULE_PAYMENT","5","account1","50","10"],["SCHEDULE_PAYMENT","6","account2","1000","5"],["SCHEDULE_PAYMENT","7","account1","3000","7"],["DEPOSIT","11","account2","5"],["CANCEL_PAYMENT","12","account2","payment1"],["CANCEL_PAYMENT","13","account1","payment1"],["DEPOSIT","14","account1","5"],["DEPOSIT","15","account1","5"]] return = [["true"],["true"],["2000"],["3000"],["payment1"],["payment2"],["payment3"],["2005"],["false"],["true"],["2005"],["2010"]] payment2 executes before the deposit at timestamp 11. payment1 is canceled by its owner. payment3 is skipped at timestamp 14 because Account 1 cannot cover 3000. Example 2 operations = [["CREATE_ACCOUNT","1","a"],["DEPOSIT","2","a","100"],["SCHEDULE_PAYMENT","3","a","80","7"],["SCHEDULE_PAYMENT","4","a","30","6"],["CANCEL_PAYMENT","10","a","payment2"],["DEPOSIT","11","a","1"],["TOP_SPENDERS","12","1"]] return = [["true"],["100"],["payment1"],["payment2"],["false"],["21"],["a(80)"]] Both payments are due at timestamp 10. payment1 executes first and leaves 20; payment2 is then skipped. The cancellation is processed afterward and returns false. Constraints 1 <= timestamp <= 10^9 All input-operation timestamps are unique and strictly increasing. Amounts, delays, and ranking limits are positive integers. All numeric results and scheduled execution timestamps fit in a signed 64-bit integer. Every operation has exactly the arguments defined in Parts 1 through 3.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick: never simulate time. Keep pending payments in a min-heap keyed by (execution time, creation sequence). Before every incoming operation at timestamp t, pop while the heap top has time <= t and run it. Because input timestamps strictly increase, you only drain lazily, once per operation. Each payment is pushed and popped once, so total cost is O(n log n). Cancel works by a map from payment ID to a record with an owner, an amount and a status (pending, done, canceled). Don't remove from the heap. Mark it canceled and skip it when popped. Pitfalls: draining after the operation instead of before, which breaks the same-timestamp rule. Counting skipped payments toward outgoing totals. Forgetting the owner check on cancel. Assigning payment IDs for failed schedules on missing accounts. Example 2 tests the drain-first ordering directly. StealthCoder is your hedge if the heap ordering slips under pressure.
StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.
You can drill Banking System, Part 3: Scheduled Payments 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. If you're reading this with an OA window open, you're who this was built for.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Anthropic's OA.
Anthropic reuses patterns across OAs. If you're reading this with an OA window open, you're who this was built for. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Banking System, Part 3: Scheduled Payments FAQ
What's the core trick in Banking System Part 3?+
Lazy execution with a min-heap. Before each operation at timestamp t, pop and run every payment due at or before t. Order by execution time, then creation order. You never loop over time values, which matters because timestamps reach 10^9.
Why can't I just simulate every timestamp?+
Timestamps go up to 10^9 and scheduled times can be larger, so stepping one unit at a time is far too slow. Input operations are strictly increasing, so you only need to process due payments at those moments, once per operation.
How do I handle cancellation with a heap?+
Don't delete from the heap. Store each payment in a map by ID with a status field. On cancel, check existence, owner and pending status, then mark it canceled. When the heap pops a canceled payment, skip it. Cancel at the execution timestamp returns false because due payments run first.
What edge cases did the examples highlight?+
Two payments due at the same timestamp run in creation order, and the second is skipped if funds run out. A cancel arriving at or after the due time returns false. A skipped payment doesn't add to the TOP_SPENDERS outgoing total. Payment IDs only increment on successful schedules.
How do I prepare for this in 48 hours?+
Make sure your Parts 1 and 2 code is clean, since this is cumulative. Then write the heap drain step as a helper called at the top of every operation. Test both examples by hand, especially the same-timestamp ordering and the late cancel.