Credit Card Authorization, Limits and Reporting

0) Problem Restatement

Design the card issuer's system (asked at Capital One) that supports:

• Application login (for the customer app),
• Payment authorization with fraud detection: when a card is swiped, approve or decline in real time,
• Credit limit decisions: don't approve beyond available credit,
• a view of spending for the user,
• Monthly credit bureau reporting (sending account data to Experian, Equifax and TransUnion).

1) How a Card Payment Works (simple version)

1. The customer pays at a merchant. The merchant's bank (the acquirer) sends an authorization request through the card network (Visa/Mastercard) to the issuer (us).
2. We must reply approve or decline within a strict time limit (the network gives about 1–2 seconds in total, and our budget is maybe ~100–200 ms).
3. If approved, we place a hold on available credit. The transaction is pending.
4. Later (usually within days), the merchant captures/settles. The transaction becomes posted and moves into the statement balance.

2) Architecture

flowchart LR
    NET["Card network"] --> GW["Authorization gateway - ISO 8583"]
    GW --> AUTH["Authorization engine"]
    AUTH --> ACC[("Account + available credit - in-memory, replicated")]
    AUTH --> FR["Fraud scoring - model + rules"]
    AUTH --> RULES["Card controls - lock, limits, MCC blocks"]
    AUTH -->|"decision"| GW
    AUTH --> K[("Auth events")]
    K --> LED[("Ledger - pending holds")]
    NET -->|"clearing files"| SET["Settlement processing"]
    SET --> LED
    LED --> APP["Customer app - spending view"]
    LED --> BUR["Monthly bureau reporting job"]
    BUR --> CB["Credit bureaus"]

3) The Authorization Engine (fast path)

Order of checks (fail fast, all in memory where possible):

1. Parse and dedupe: networks retry, so keep a short-term record of processed request IDs (network reference numbers) and return the same answer for duplicates.
2. Card status: active, not locked, not reported lost, and the expiry, CVV and PIN checks passed.
3. Controls: merchant category blocks (e.g., gambling), international transactions allowed, per-transaction limits set by the user.
4. Available credit: credit_limit - (posted balance + pending holds) >= amount. The account state is kept in a fast, strongly consistent store (in-memory with replication), because many auths for one account can arrive together, so update it atomically (compare-and-set).
5. Fraud score: a model using features such as distance from usual locations, merchant risk, velocity (number of transactions in the last minutes) and device signals, plus rules. High risk → decline, or approve and send the customer a "was this you?" alert.
6. Decide: place the hold, publish an event, respond.

4) Pending vs Posted and the Ledger

• Approved auths create pending holds in the ledger. Settlement files from the network turn them into posted transactions (sometimes with a different final amount, e.g., a tip), and release the holds.
• Holds that never settle expire after N days.
• The customer app shows both: "Pending: $54.20 at Coffee Co." and posted history.

5) Monthly Credit Bureau Reporting

• A batch job at each statement cycle builds the standard report format (Metro 2 in the US) for every account: balance, credit limit, payment status, days past due.
• It must be accurate and auditable: use the ledger's statement snapshots, validate the file, keep copies, and have a disputes process to correct errors.

6) Reliability

• Active-active across regions: account state replicated synchronously within a region and carefully across regions (or each account homed to a region with failover).
• Stand-in processing: if our system is unreachable, the network can approve small transactions on our behalf using pre-agreed rules. We reconcile them afterwards.
• Idempotency everywhere (retries from networks are normal).

7) Wrap-Up

Receive authorization requests from the network, deduplicate them, and run fail-fast checks in memory (card status, user controls, available credit including pending holds, fraud score with rules fallback) within a tight latency budget, then place a hold and respond. Record holds in a ledger that settlement files turn into posted transactions, show pending vs posted to customers, generate audited monthly credit bureau reports from statement snapshots, and rely on active-active deployment plus network stand-in for availability.