Katkat

Build a Payment Fraud Detection Model

AdyenMachine Learning Engineer · HR Screen

Last 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 transaction
  • user_id: Customer identifier
  • amount: Transaction amount in EUR (float)
  • card_country and ip_country: ISO country codes (strings, with ~3% missing values in ip_country)
  • merchant_category: Categorical identifier (approx. 250 distinct categories)
  • is_fraud: Ground-truth label where 1 indicates a confirmed fraudulent chargeback and 0 indicates 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:

  1. 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?
  2. 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.
  3. 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).
  4. 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?