Building Real-Time Spend Controls for Capital One Virtual Debit Cards

You are a product manager at Capital One, where customers can create virtual debit cards. What technical components would the bank need so that customers can put spending limits on those cards, and how would the pieces work together when someone pays with one? ```hint Follow one purchase Trace a single card payment from the merchant to the bank's approve-or-decline answer and back, then ask where the limit has to be checked and what must stay accurate after the purchase settles. ``` ### Clarifying Questions - Who sets the limits: only the cardholder, the bank's risk rules as well, or an administrator such as a parent or business owner setting limits on someone else's card? - Which limit types are in scope: per-purchase caps, daily or monthly totals, a lifetime cap, locking a card to one merchant, or blocking merchant categories? - Should a limit change apply to the very next purchase, and what happens to purchases already approved but not yet settled? - Does the virtual card draw on the same checking account and balance as the customer's physical debit card? ### What a Strong Answer Covers - Placing the limit check inside the real-time authorization decision, and explaining why an after-the-fact alert is not enough - A data model for cards, limit rules and per-window spend totals, with concurrency handled so simultaneous purchases cannot overspend - Keeping totals correct through reversals, refunds, settlement differences, holds that never settle and transactions that bypass authorization - Latency within the card network's time budget, high availability, a stated fail-open or fail-closed policy, and observability - The customer experience, security of limit changes, and how a PM would scope, launch and measure the feature ### Follow-up Questions - If the limit service cannot be reached during an authorization, should the bank approve or decline, and should the answer differ by card? - A hotel authorizes an estimated amount at check-in and settles a different amount at checkout. How should the running total handle it? - How would the design change for a business that issues many virtual cards to employees under one shared budget? - Suppose the feature is narrowed to a single per-transaction limit: no one purchase on the virtual card may exceed an amount the customer sets. Which components could you drop, and which edge cases still need handling?