Credit-Card Fraud Detection: Real-Time Decisioning and System Design

You are designing a real-time decisioning system for card-payment authorizations at a large payments company. At authorization time, only a subset of features is available, and you have a hard latency budget. The ground-truth outcome of a transaction (e.g., a chargeback) arrives weeks to months later.

For the accept/decline exercise, assume the following two minimal transaction snippets are available at decision time:

• Transaction A
  • Channel: e-commerce (card-not-present)
  • Amount: $4,200
  • Cardholder home country: UK
  • Merchant country: US (electronics)
  • Local time at cardholder: 03:17
  • Device fingerprint: new to platform
  • IP geolocation: NG (Nigeria), VPN likely
  • Velocity: 5 auth attempts in the last 10 minutes on this card across different merchants
• Transaction B
  • Channel: card-present (EMV chip + PIN)
  • Amount: $18.75
  • Cardholder home country: UK
  • Merchant country: UK (coffee shop)
  • Local time at cardholder: 12:41
  • Device/terminal: known merchant terminal, low dispute history
  • Velocity: consistent with the user's past pattern (daily coffee purchases)

This is an open-ended design problem, to be worked through in four parts:

Constraints & Assumptions

• Latency: The model's contribution to the auth decision must fit within a sub-100ms end-to-end budget; aim for low-tens-of-milliseconds scoring.
• Class imbalance: Confirmed fraud is typically well under 1% of transactions.
• Label delay & censoring: Chargeback/confirmed-fraud labels arrive weeks to months later; declined transactions never receive an outcome label; some disputes are "friendly fraud" (mislabeled).
• Action space: For each transaction, you may approve, decline, step-up authenticate (e.g., 3-D Secure / SCA, OTP, push approval), or queue for asynchronous review.
• Objective: Minimize expected dollar loss, balancing fraud losses against false-decline (lost-sale + customer friction) costs, not maximizing raw accuracy.

Part 1 — Accept / Decline the Two Transactions

For Transaction A and Transaction B, decide whether to accept, decline, or take a conditional action (e.g., step-up authentication), and justify your reasoning from the available signals. State explicitly what you would do if a conditional action's prerequisite (e.g., a 3DS challenge) is unavailable or fails.

Part 2 — End-to-end Fraud-Detection Strategy

Outline a full fraud-detection strategy for card transactions. Cover: (a) the data required (what is available synchronously at auth vs. maintained from history vs. enrichment/labels), (b) feature engineering, (c) real-time deterministic rules, and (d) model-based approaches, including system architecture and how you meet the latency budget.

Part 3 — Unsupervised Learning for Fraud Detection

Explain how unsupervised learning can be applied to fraud detection here, why it earns a place given the label situation, and list suitable algorithm families. Be specific about how an unsupervised signal is integrated into the overall system rather than treated as a standalone blocker.

Part 4 — Evaluation Metrics

Detail appropriate evaluation metrics for fraud models. Address: (a) how you turn a model score into an action threshold given the cost asymmetry, (b) the right offline ranking/quality metrics under extreme imbalance, (c) validation discipline specific to fraud, and (d) how to evaluate unsupervised methods without labeled data.

Similar LeetCode problem: Detect Capital (though this is a system design problem, not an algorithm problem)