Design a Credit Card System: Authorization, Fraud, Bureau Reports, Limit Increases
Capital OneSoftware Engineer · Technical Screen
Last updated
A system design question for a credit card platform covering customer login, real-time payment authorization with fraud checks, monthly credit bureau reporting, a spending overview, and instant credit limit increase decisions. It tests laying out entities, services and read and write paths before choosing deep dives.
Design the back end of a credit card system for a card issuer. The system must support:
- Login. Customers sign in to the issuer's website and mobile app.
- Payment authorization with a fraud check. When a cardholder pays at a merchant, the card network sends an authorization request, and the system must approve or decline it in real time after checking for fraud.
- Monthly credit bureau reporting. Every month, report each account to the credit bureaus.
- Spending overview. Customers can see their spending: what they bought, where, when, and how much in total.
- Real-time credit limit increases. A customer can request a higher credit limit and get a decision immediately.
The system is large, and an interview slot does not leave time to design every part in depth. Lay out the core entities, the services and the main read and write paths first, then deep dive into one or two areas. It is reasonable to ask the interviewer which area they want to explore.
Constraints and Clarifications
- No scale numbers are given. Ask for them, or state your own assumptions and size the design from them.
- The card network connection and the bureaus' file formats are external interfaces; you do not design them.
Clarifying Questions
- How many cardholders, and what peak authorization rate, should the design handle?
- What is the latency budget for an authorization decision, and what should happen if the fraud check cannot answer in time?
- How fresh must the spending overview be, and does it include pending authorizations or only posted transactions?
- For a credit limit increase, is the decision fully automated, and what data may it use: internal history only, or a new credit bureau inquiry?
- Which area matters most to you for a deep dive?
Hints
Hint 1
Breadth first: Before any deep dive, list the core entities and the services that own them, and trace one write path (a card swipe) and one read path (the spending overview) end to end.
Hint 2
Different clocks: The five features run on very different time scales, from milliseconds to once a month. Let that decide which parts are synchronous and which run as batch or background work.
Follow-up questions
- How do you keep available credit correct when two authorizations on the same account arrive at the same moment?
- An authorization was approved, but the network never sent the matching settlement. What happens to the hold?
- A bug sent wrong balances to the bureaus last month. How do you detect it and send corrections?
- How would you roll out a new fraud model without risking a spike in declined legitimate payments?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.