Design Real-Time Credit Card Fraud Detection System

Q: Design Real-Time Credit Card Fraud Detection System

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.

Q: How do I approach Machine Learning interview questions?

Machine Learning questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master machine learning interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty Machine Learning question, commonly asked during Onsite rounds at TikTok.

Q: What role is this question designed for?

This question is commonly asked for Data Scientist candidates at TikTok during technical interviews.

Question

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?

Design Real-Time Credit Card Fraud Detection System

Quick Overview

Design Real-Time Credit Card Fraud Detection System

Design a Real-Time Credit-Card Fraud Detection System

Constraints & Assumptions

Clarifying Questions to Ask Guidance

Part 1 - Data Sources and Labels

What This Part Should Cover Guidance

Part 2 - Features and Models

What This Part Should Cover Guidance

Part 3 - Real-Time Architecture

What This Part Should Cover Guidance

Part 4 - Monitoring, Retraining, and Thresholds

What This Part Should Cover Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Write your answer

Design Real-Time Credit Card Fraud Detection System

Quick Overview

Design Real-Time Credit Card Fraud Detection System

Design a Real-Time Credit-Card Fraud Detection System

Constraints & Assumptions

Clarifying Questions to Ask Guidance

Part 1 - Data Sources and Labels

What This Part Should Cover Guidance

Part 2 - Features and Models

What This Part Should Cover Guidance

Part 3 - Real-Time Architecture

What This Part Should Cover Guidance

Part 4 - Monitoring, Retraining, and Thresholds

What This Part Should Cover Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Write your answer