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.

|Home/Machine Learning/TikTok
TikTok logo
TikTok
Jul 12, 2025
hardData ScientistOnsiteMachine Learning
25
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?
Loading comments...