Design Real-Time Credit Card Fraud Detection System

Quick Overview

Evaluates real-time credit-card fraud detection system design under latency, drift, and asymmetric costs. Strong answers cover data, delayed labels, features, models, serving architecture, monitoring, retraining, and thresholding.

Design Real-Time Credit Card Fraud Detection System

Company: TikTok

Role: Data Scientist

Category: Machine Learning

Difficulty: hard

Interview Round: Onsite

##### Scenario An online payments company needs to build a system that detects fraudulent credit-card transactions in real time. ##### Question Design a credit-card fraud-detection strategy. Describe data sources, feature engineering, model choices, real-time architecture, retraining cadence, and how you would monitor model drift. ##### Hints Think supervised vs unsupervised methods, latency constraints, feedback loops, threshold tuning.

Overview: Evaluates real-time credit-card fraud detection system design under latency, drift, and asymmetric costs. Strong answers cover data, delayed labels, features, models, serving architecture, monitoring, retraining, and thresholding.

TikTok logo
TikTok
Jul 12, 2025
hardData ScientistOnsiteMachine Learning
28
0

Design a Real-Time Credit-Card Fraud Detection System

You are designing a real-time fraud detection system for an online payments platform that processes high-volume credit-card transactions. The system must flag or block suspicious transactions with strict latency constraints while maintaining high approval rates for legitimate users.

Design a fraud-detection strategy from data and modeling through real-time serving, decisioning, and monitoring.

Constraints & Assumptions

  • Fraud labels such as chargebacks arrive with delay and may be noisy.
  • False declines and fraud losses have asymmetric business costs.
  • Real-time decisions must fit within a strict p95 or p99 latency budget.
  • The system should support manual review, step-up authentication, approval, and blocking actions.
  • Fraud patterns change over time due to adversarial behavior and concept drift.

Clarifying Questions to Ask Guidance

  • What is the transaction volume and latency budget?
  • Which actions are available: approve, challenge, manual review, block, or hold?
  • What labels are available, and how delayed are chargebacks or confirmed fraud outcomes?
  • What risk tolerance, approval-rate target, and loss budget does the business have?

Part 1 - Data Sources and Labels

Describe the data and labeling strategy.

What This Part Should Cover Guidance

  • Include transaction, merchant, card, account, device, IP, location, authentication, and historical behavior data.
  • Include real-time event streams and offline warehouse features.
  • Handle delayed labels from chargebacks, manual review, issuer responses, customer reports, and rules.
  • Discuss label leakage, weak labels, class imbalance, and feedback bias from blocked transactions.

Part 2 - Features and Models

Propose features and model choices for fraud detection.

What This Part Should Cover Guidance

  • Include velocity features, amount deviations, device and account history, merchant risk, geo-distance, graph or network features, and behavioral patterns.
  • Compare supervised models, rules, anomaly detection, graph methods, and ensemble strategies.
  • Use cost-sensitive learning or thresholding to reflect asymmetric costs.
  • Address calibration, interpretability, and reviewability for operations teams.

Part 3 - Real-Time Architecture

Design the low-latency scoring and decisioning path.

What This Part Should Cover Guidance

  • Include ingestion, feature store, streaming aggregations, model service, rules engine, decision service, logging, and fallback behavior.
  • Break down the latency budget and identify p99 risks.
  • Handle missing features, stale features, service degradation, retries, and idempotency.
  • Log decisions and features for audit, monitoring, and future training.

Part 4 - Monitoring, Retraining, and Thresholds

Explain how the system adapts after launch.

What This Part Should Cover Guidance

  • Monitor fraud loss, approval rate, false declines, review rate, chargeback rate, feature drift, score drift, and latency.
  • Retrain on a cadence that accounts for label delay and drift.
  • Tune thresholds by segment and action type using business costs and operational capacity.
  • Run champion-challenger tests, backtests, alerting, and post-incident reviews.

What a Strong Answer Covers Guidance

  • Treats fraud detection as a decision system, not only a model.
  • Balances fraud loss reduction with customer experience and approval rate.
  • Handles delayed labels, feedback loops, adversarial drift, and real-time reliability.
  • Gives a concrete architecture with monitoring and fallback plans.

Follow-up Questions Guidance

  • How would you evaluate the model when most fraudulent transactions are blocked and never receive chargeback labels?
  • How would you reduce false declines for good customers?
  • What would you do after a sudden spike in fraud from a new attack pattern?