Build a Payment Fraud Detection Model
AdyenMachine Learning Engineer · HR ScreenLast updated
Tests practical machine learning design for payment fraud detection, covering data preprocessing, temporal validation splits, class imbalance handling, and metric selection.
Scenario
You are tasked with designing the initial machine learning pipeline for a real-time payment gateway processing millions of credit card transactions per day. The dataset contains 12 months of historical payment events, where each record includes:
transaction_id: Unique identifier (string)timestamp: UTC timestamp of the transactionuser_id: Customer identifieramount: Transaction amount in EUR (float)card_countryandip_country: ISO country codes (strings, with ~3% missing values inip_country)merchant_category: Categorical identifier (approx. 250 distinct categories)is_fraud: Ground-truth label where1indicates a confirmed fraudulent chargeback and0indicates legitimate (fraud rate: ~0.15%)
Note that fraud labels suffer from a 30- to 60-day reporting lag because chargebacks take time to be filed by cardholders.
Tasks
Outline a structured approach for the following components of the modeling pipeline:
-
Data Splitting Strategy:
- Explain how you would split the dataset into training, validation, and test sets. Discuss why traditional random k-fold cross-validation is inappropriate for this domain.
- How do you account for the 60-day chargeback label delay?
-
Feature Preprocessing:
- How should you handle missing values in
ip_country? - Propose an encoding strategy for high-cardinality categorical features such as
merchant_category. - Describe two domain-specific velocity or behavioral features you would engineer.
- How should you handle missing values in
-
Class Imbalance & Modeling:
- Choose an appropriate baseline algorithm for tabular fraud detection and justify your choice.
- Compare two strategies for handling the severe 0.15% class imbalance during training (e.g., re-sampling vs. cost-sensitive learning).
-
Evaluation Metrics:
- Why are Accuracy and standard ROC-AUC insufficient or misleading for this business use case?
- Propose two primary evaluation metrics aligned with payment processing goals (minimizing financial loss while avoiding excessive false declines).
Hints
Hint 1
Consider how standard random splitting allows future transaction patterns to leak into past predictions and how label maturity affects recent data.
Hint 2
Categorical features with hundreds of unique values can overfit if one-hot encoded; look into target encoding or tree-native handling.
Hint 3
Because legitimate transactions massively outnumber fraud cases, focus on metrics that isolate the positive class trade-offs rather than true negative rates.
Follow-up questions
- How would you adjust your decision threshold if the business requires that no more than 0.5% of legitimate users experience a transaction decline?
- How would you detect and adapt to concept drift when fraudsters alter their transaction behavior every few weeks?
- What architectural components would you need to calculate real-time velocity features (e.g., number of transactions in the last 15 minutes) with sub-50ms latency?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.