Source-linked AI summary
SCARFF: a Scalable Framework for Streaming Credit Card Fraud Detection with Spark
Fabrizio Carcillo, Andrea Dal Pozzolo, Yann-Aël Le Borgne, Olivier Caelen, Yannis Mazzer, Gianluca Bontempi
TL;DR
Electronic-payment growth makes fraud detection increasingly important, while existing learning solutions rarely address scalable streaming implementation. The paper presents SCARFF, an open-source Kafka, Spark, and Cassandra platform with a scalable Balanced Random Forest, and reports robust high-rate processing alongside trade-offs affecting performance.
Problem
Electronic-payment growth increases fraud risks, while most existing learning solutions assume in-memory datasets and rarely study scalable fraud-detection implementations.
Method
SCARFF is an open-source platform that analyzes streaming data in near real time and uses a scalable Balanced Random Forest trained on majority-class subsamples and the full fraud class.
Results
200 transactions per second was handled robustly, compared with 2.4 transactions per second currently managed by the industrial system, while experiments assessed scalability, parameter sensitivity, and classification accuracy.
Takeaways & Limitations
The open-source workflow demonstrates a scalable big-data approach for real-world fraud detection, but efficiency requires managing trade-offs among throughput, feature-engineering complexity, batch duration, and executors.
Takeaways & Limitations
Combining rapidly evolving big-data tools can cause platform instability and make ad hoc Cassandra queries from Spark difficult.
Abstract
from arXiv · showhide
The expansion of the electronic commerce, together with an increasing confidence of customers in electronic payments, makes of fraud detection a critical factor. Detecting frauds in (nearly) real time setting demands the design and the implementation of scalable learning techniques able to ingest and analyse massive amounts of streaming data. Recent advances in analytics and the availability of open source solutions for Big Data storage and processing open new perspectives to the fraud detection field. In this paper we present a SCAlable Real-time Fraud Finder (SCARFF) which integrates Big Data tools (Kafka, Spark and Cassandra) with a machine learning approach which deals with imbalance, nonstationarity and feedback latency. Experimental results on a massive dataset of real credit card transactions show that this framework is scalable, efficient and accurate over a big stream of transactions.
1. Introduction
SCARFF addresses the limited scalability of existing fraud-detection research by implementing and testing an open-source, realistic platform for streaming credit-card transactions. It combines scalable learning with mechanisms for imbalance, concept drift, and delayed feedback.
- Research context: Existing fraud-detection methods commonly address class imbalance, concept drift, and verification latency in credit-card transaction labeling.Fraudulent transactions are usually rare, fraud distributions can change over time, and human verification delays labels.
- Research gap: Most prior learning techniques assume the complete dataset resides in memory, leaving relatively few scalable implementations and performance studies.Existing scalable work closer to fraud detection is described as preliminary, incomplete, or lacking validation results.
- Proposed framework: SCARFF is an open-source platform that processes streaming data and returns fraud alerts in a nearly real-time setting.The framework is presented as a realistic and scalable implementation of a fraud-detection system.
- Contributions: The architecture integrates open-source components across ingestion, streaming, feature engineering, storage, and classification.The stated contributions include an Apache-based solution and a distributed online feature-engineering function that updates historical features.
- Evaluation: The framework was assessed for scalability, computational performance, and precision using more than 8 million transactions from over 1.9 million cards.The dataset was provided by an industrial partner and used to evaluate the platform under real-world conditions.
2. Real-world Fraud Detection Systems
Real-world fraud-detection systems combine automated controls with manual investigation. SCARFF focuses on the near-real-time data-driven model layer, while organizing alerts for a manageable investigator workload.
- System layers: Fraud-detection systems combine offline human investigation with automatic components operating in real-time or near-real-time configurations.Real-time controls act before payment authorization, whereas near-real-time controls score transactions after payment.
- Real-time controls: Real-time controls include terminal checks and transaction-blocking rules that execute in milliseconds and generally cannot use complex engineered features.Examples include PIN or balance checks and expert rules such as blocking transactions from blacklisted shops.
- Near-real-time controls: Near-real-time controls use scoring rules and data-driven machine-learning models to assess fraud risk after payment.The data-driven model predicts the probability that a new transaction is fraudulent and is the paper’s main focus.
- Alerting: Alerts are raised when estimated fraud risk exceeds a threshold or when a transaction ranks among the top-N highest-risk cases.These alerts are handled by investigators in the offline control layer.
- Investigation workflow: The pipeline uses near-real-time processing so investigators can receive alerts at a constant pace rather than an unpredictable daily volume.The authors chose this option because investigator capacity and organizational guidelines constrain how many alerts can be processed.
3. The Big Data ecosystem
SCARFF uses Kafka, Spark, and Cassandra to implement a distributed pipeline for collecting, analyzing, classifying, and storing streaming transactions. Spark Streaming supplies second-scale mini-batch processing suitable for the paper’s nearly real-time setting.
- Architecture: The framework integrates Kafka, Spark, and Cassandra for the data-driven fraud-detection module, using components that support fault tolerance and task distribution.These tools form the standard Apache ecosystem foundation of the proposed implementation.
- Transaction collection: Kafka collects distributed transaction messages from multiple producers, while partitioning and retention support recovery after processing interruptions.The experimental setup injects transactions into Kafka at a desired rate using a bash program.
- Data analysis: Spark distributes computation over resources, supports streaming and MapReduce analysis, and provides RDD recovery information when partitions are lost.Its MLlib and Streaming libraries support machine learning and streaming analysis within one platform.
- Streaming: Spark Streaming processes incoming data in mini-batches with latency on the order of seconds, which the authors consider suitable for near-real-time fraud detection.The paper treats this latency as harmless in its target setting.
- Storage and processing: Spark aggregates historical transactions for feature engineering, performs online classification, and stores transactions in Cassandra.Cassandra provides distributed storage with replication across nodes or datacenters and support for scalable retrieval.
4. Online learning and streaming solutions
The framework’s functionality is divided into a machine-learning classification engine and a streaming component. Its scalable learner uses a weighted ensemble and addresses class imbalance through a Balanced Random Forest implementation.
- Framework functionality: The pipeline implements two main functionalities: a machine-learning classification engine and a streaming component.The classification engine and streaming functionality are described in separate subsections.
- Machine-learning engine: The machine-learning engine includes a weighted ensemble of two classifiers.
4.1. The machine learning engine
The machine learning engine combines feedback-driven and delayed classifiers to estimate transaction fraud risk under delayed labels, imbalance, and concept drift. It uses distributed balanced-tree training and sliding windows to support scalable updating.
- Delayed feedback: Investigator feedback is sparse because labels are returned mainly for transactions that trigger alerts, leaving most transactions temporarily unlabeled.This motivates using delayed historical observations alongside recent feedback.
- Classifier design: The engine combines a Feedback Random Forest trained on recent investigator-labeled transactions with a Delayed ensemble of Balanced Random Trees trained on older transactions.The Delayed classifier typically uses more samples, while each tree is specific to one day.
- Adaptation: A sliding window updates both classifiers for concept drift: Feedback uses the latest 14 days, while the Delayed model retains BRTs for 13 days and discards older ones.The classifiers are updated periodically but continuously used for streaming risk assessment.
- Risk aggregation: The aggregated fraud probability is a weighted average of the posterior probabilities produced by the Feedback and Delayed classifiers.The paper sets the overall-model weight wA to 0.5.
- Distributed learning: The scalable Balanced Random Forest trains each tree on all fraudulent cases and a random subsample of genuine cases.Its distributed implementation builds trees across genuine-transaction partitions while broadcasting the fraud array to executors.
4.2. The streaming analytics engine
The streaming analytics engine processes Kafka data as Spark batches, engineering historical and categorical features before classification and storage. Its throughput depends on keeping batch processing within the configured duration to avoid accumulating delay.
- Data throughput: Spark Streaming represents Kafka throughput as a DStream, a continuous sequence of RDDs generated and appended at the configured batch duration.Each new batch begins after the previous batch finishes.
- Data throughput: If RDD processing exceeds the batch duration, batches queue and scheduling delay accumulates; prolonged violations can risk application failure.The available resources impose a limit on sustainable delay.
- Data preprocessing: Preprocessing replaces missing values with medians and encodes high-cardinality categorical values using their historical fraud probabilities.The probability dictionary can be updated when new batches of labels arrive to address potential drift.
- Feature engineering: Feature engineering retrieves historical Cassandra data and computes aggregates such as maximum, minimum, count, and average over configurable recent windows.The historical window size and number of recent transactions can noticeably affect streaming behavior.
- Online processing: The streaming procedure classifies incoming transactions with current models, stores the riskiest topN alerts, and periodically persists transactions and aggregates in Cassandra.At day end, models are retrained, alerts are saved, and unneeded transactions are discarded.
5. Experiments
Experiments assess SCARFF’s computational scalability, resource behavior, and classification precision on a large transaction dataset. Results show reduced processing time with more executors, stable fully operational memory use, and average card precision of 0.24.
- Dataset and setup: The experiments used a ten-machine cluster with 24 cores and 80GB of RAM per machine, running Spark on Yarn.Each executor received 1GB of RAM and the driver received 10GB.
- Dataset and setup: Experiments ran on more than 8 million transactions from almost 2 million cardholders, with 18 original and 17 engineered features.The data covered 40 consecutive days, and feature engineering used a one-week time window.
- Scalability: During initialization, processing time increased as stored transactions grew and the random forest became more complex.Initialization precedes the fully operational phase, when preprocessing, feature engineering, and classification are active.
- Scalability: 25 executors exceeded the 240-second batch duration, while 35 and 45 executors were typically faster than the threshold; retraining caused peaks in the 35-executor run.The 10-, 20-, and 30-executor configurations were insufficient to absorb 100 transactions per second.
- Scalability: Average processing time decreased as executors increased, although gains diminished because shuffling costs can offset parallelization benefits.This behavior indicates scalability with a practical limit to the benefit of adding executors.
- Resource use: Feature Engineering was the heaviest streaming task, followed by Cassandra reads; Model Update accounted for 12.3% of total processing time.Read and classification tasks consumed more resources during the fully operational phase, while feature-engineering time remained similar in absolute terms across phases.
- Classification precision: Average card precision was CPk = 0.24 for k = 100, meaning 24 of 100 alerts were correct on average.Precision generally improved from the partial to the full ensemble, and the ensemble usually outperformed its individual classifiers.
6. Conclusions and future work
SCARFF is presented as an open-source, reproducible platform for near-real-time fraud detection that integrates big-data tools and scalable learning. Experiments report robust throughput and confirmed precision, while the authors caution that deployment requires managing tool maturity and system-level trade-offs.
- Contributions: SCARFF is an open-source platform for automatically detecting fraud in near-real time, tested on massive real-world data.The workflow is also made reproducible through a Docker container and an artificial dataset.
- Results: Kafka, Spark, and Cassandra provide the integrated infrastructure for receiving, aggregating, and classifying transactions at high rates.The experimental evaluation covered scalability, parameter sensitivity, and classification accuracy.
- Results: 200 transactions per second was handled robustly, compared with the industrial partner’s current 2.4 transactions-per-second rate.The authors state that higher rates may be possible with suitable executor and batch-duration settings.
- Results: The framework confirmed precision results previously obtained with a conventional architecture whose data remained resident in main memory.
- Limitations: Large-scale deployment is constrained by the rapid evolution of open-source tools and difficult cross-tool integration, including inefficient Cassandra queries from Spark.
- Conclusions: Efficient deployment requires explicit management of software and hardware trade-offs affecting computational and classification performance.