Fraud detection

01 · CONTEXT

An interview question that looks simple

Given a set of credit card purchases in which each record is labeled as fraudulent or safe, how do you build a fraud detection algorithm? This is the classic formulation of the exercise, and the description of the course that covers it sums up the goal as identifying unusual or suspicious transactions in financial data to prevent fraudulent activity. It is a good starting point for thinking about production ML systems.

Many questions on this list are ambiguous on purpose: it is up to the person answering to ask clarifying questions and bound the scope before designing.

02 · IMBALANCE

Fraud is rare

In real payment data, fraud is rare: on the order of one in a thousand payments, according to Stripe's fraud team. In a credit card transaction dataset, fraudulent purchases can make up less than 0.1 percent of the examples, according to Google's machine learning crash course.

This imbalance hurts training: a severely imbalanced dataset may not contain enough examples of the minority class for adequate training. It also hurts evaluation, since accuracy is usually a poor metric for evaluating a model trained on imbalanced data.

Standard training mixes two goals: learning what each class looks like and learning how common each class is. The two-step technique of downsampling and upweighting the majority class separates these two goals.

03 · DELAYED LABELS

The label arrives months later

Fraud detection is an example of a task with long feedback loops: for a period after the transaction, the user can dispute whether it was fraudulent or not.

A typical dispute window runs from one month to three months. Once the window passes without a dispute from the user, the transaction can be presumed legitimate.

This weighs on monitoring: if there is a problem in the fraud model and it takes months to be noticed, the fraud the model let through may have driven a small business into bankruptcy. When the true label is not available or arrives too late to be useful, other distributions of interest can be monitored.

04 · COST-SENSITIVE THRESHOLD

What a mistake costs

Stripe Radar needs to balance blocking bad transactions against false positives, that is, good payments blocked, which hurt consumers and the results of Stripe's users.

A credit example shows how cost enters the equation: in the German credit dataset used by scikit-learn, classifying a bad credit as good is, on average, five times more costly than the opposite.

One solution described by scikit-learn is to tune the classifier's decision threshold after the model has been trained. The optimal threshold is chosen to maximize a given metric; in the documentation's example, the tuned threshold optimizes a utility metric defined by the business. The same documentation warns against using the same data to train the classifier and to tune the threshold, because of the risk of overfitting.

05 · THE ARCHITECTURE

Fast decision, slow learning

The diagram below brings together the three themes: the decision path, the label loop, and threshold tuning. Events go through a message queue before reaching the transaction log.

1. In the diagram, the buyer reaches the payments API, which is connected to the scoring service.

2. In the diagram, the scoring service queries the online feature store. For reference, Stripe Radar makes the fraud decision in under one hundred milliseconds.

3. The decision policy threshold is tuned after the model is trained, to maximize a metric; in the documentation's example, a utility metric defined by the business.

4. In the diagram, the API publishes each transaction and the decision to an event queue, which feeds the transaction log.

5. For a period after the transaction the customer can dispute it, and a typical window runs from one month to three months. Once the window passes without a dispute, the transaction can be presumed legitimate.

6. In the diagram, the label join feeds training, which publishes the model to the scoring service and the threshold to the decision policy. The documentation warns against using the same data to train the classifier and tune the threshold, because of the risk of overfitting.

06 · FEATURES

Real time or near real time

Real-time features are computed when the prediction request arrives, and the computation latency adds directly to the latency the user sees. Near-real-time features are precomputed with a stream processing engine; because they are computed asynchronously, their latency does not add to the user's.

1. Near-real-time features are computed with a stream processing engine, here fed by the event queue.

2. Because these features are computed asynchronously, the computation latency does not add to the latency the user sees.

3. In the diagram, a batch job reads the historical log and writes to the same online store.

4. In the diagram, the scoring service reads the ready-made features from the store. Real-time features, by contrast, are computed when the prediction request arrives, and the computation latency adds directly to the latency the user sees.