What are the best practices for handling imbalanced classes in fraud detection models?

All answers to this question.

In my experience with high-frequency trading fraud, SMOTE often fails because it ignores the underlying distribution of the majority class. Instead of oversampling, you should look into Precision-Recall curves rather than Accuracy or ROC-AUC. Cost-sensitive learning, where you penalize the misclassification of the minority class more heavily, usually yields more robust results in production. Also, consider Anomaly Detection techniques like Isolation Forests or One-Class SVMs, which treat fraud as an outlier rather than a class to be learned through traditional supervision.

   Answered 2025-12-12 by Megan Foster

Are you currently using a fixed threshold for your classification, or are you dynamically adjusting the decision boundary based on the daily volume of transactions?

   Answered 2025-12-15 by Gary Thompson

• I’m currently using a fixed threshold of 0.5, but I realize that’s likely the problem. Moving to a dynamic threshold based on the cost-benefit matrix of a False Positive versus a False Negative seems like the next logical step for our engineering team to implement in the pipeline.

     Commented 2025-12-18 by Eric Sullivan

You could also try EasyEnsemble or BalancedRandomForest from the imbalanced-learn library. They under-sample the majority class in each bootstrap sample to keep data integrity.

   Answered 2025-12-20 by Rebecca Hayes

• BalancedRandomForest is a great suggestion. It’s much more efficient than SMOTE because it doesn't create "fake" data but rather balances the learning process itself.

     Commented 2025-12-22 by Jeffrey Miller