E-Commerce Fraud Detection Using Machine

Learning
Abstract
E-commerce platforms are increasingly targeted by fraudulent activities, necessitating robust fraud
detection systems. This thesis presents a comprehensive study on detecting e-commerce fraud using
machine learning. We begin by identifying the problem context: the rapid growth of online commerce,
accelerated by events like the COVID-19 pandemic, has coincided with a dramatic surge in digital fraud and
associated economic losses 1 2 . To address this challenge, we review the existing literature on fraud
detection and machine learning techniques, highlighting gaps and recent advances 3 4 . Using a
provided sample dataset with features such as user demographics, device and source information, signup
and transaction timestamps, and historical purchase behavior, we perform extensive exploratory data
analysis (EDA) to understand patterns in legitimate versus fraudulent transactions. We then apply data
preprocessing and feature engineering (e.g., creating "flash transaction" features based on the time
difference between signup and purchase) to prepare the data for modeling. We implement and compare
four classification models—Logistic Regression, Decision Tree, Random Forest, and XGBoost—chosen for
their interpretability and performance in fraud detection 5 4 . Hyperparameters are tuned via grid
search and models are evaluated using metrics including accuracy, precision, recall, F1-score, confusion
matrix, and ROC-AUC 6 7 8 9 . The best-performing model is deployed as a RESTful API using Flask,
with suggestions for a simple GUI interface. We discuss deployment considerations, testing procedures,
and the ethical and security implications of fraud detection, such as user privacy under regulations like
GDPR 10 11 . Results indicate that advanced ensemble methods (e.g. XGBoost) can achieve high fraud
detection accuracy while managing false positives, but careful tuning and ethical safeguards are essential.
Finally, we conclude with lessons learned, limitations, and directions for future research.

Acknowledgments
This project report benefited from guidance by faculty and contributions from dataset providers and
developers of open-source tools (Python, scikit-learn, Flask). We thank all collaborators who provided
insights and feedback on fraud detection methodologies. Their support and reviews have greatly improved
the quality of this work. We also acknowledge the authors of referenced research and documentation,
whose work underpins many of our methods and discussions.

Table of Contents
1. Abstract
2. Acknowledgments
3. Introduction
4. Literature Review
5. System Analysis and Architecture

1
 6. Dataset Description
7. Exploratory Data Analysis (EDA)
8. Data Preprocessing
9. Feature Engineering
10. Model Selection and Methodology
10.1 Logistic Regression
10.2 Decision Tree
10.3 Random Forest
10.4 XGBoost
11. Model Training and Hyperparameter Tuning
12. Model Evaluation
13. Results and Discussion
14. Model Deployment
15. GUI Design Considerations
16. Testing and Validation
17. Challenges and Limitations
18. Ethical Considerations and Data Security
19. Conclusions
20. Future Work
21. References
22. Appendices

List of Figures
• Figure 1: Single-leader machine learning pipeline architecture (leader–follower model).
• Figure 2: (Placeholder) Flowchart of fraud detection system workflow.
• Figure 3: (Placeholder) Example confusion matrix.
• Figure 4: (Placeholder) ROC curves for candidate models.

List of Tables
• Table 1: Description of dataset features.
• Table 2: Summary statistics of key features by class.
• Table 3: Model evaluation metrics.

Introduction
The proliferation of e-commerce has revolutionized retail, enabling consumers worldwide to purchase
goods and services online. This expansion, however, has also attracted malicious actors. Fraudulent
activities—such as identity theft, payment fraud, and account takeovers—pose severe risks to businesses
and consumers, potentially resulting in significant financial losses and erosion of trust. As noted by recent
studies, the e-commerce industry’s rapid growth, accelerated by the COVID-19 pandemic, has led to
an alarming increase in digital fraud and associated losses 1 . In fact, cybercrimes and fraud have
significantly increased, costing the global economy billions of dollars 2 . These trends underscore the
critical need for effective fraud detection and prevention systems.

2
Traditional rule-based fraud detection systems (e.g. setting fixed thresholds on transaction values or
flagging unusual locations) struggle to adapt to evolving fraud patterns. Machine learning (ML) offers a
more dynamic approach: by learning from historical data, ML models can detect subtle patterns and
anomalies indicative of fraud 12 . The goal of this project is to harness ML techniques to build an e-
commerce fraud detection system that can identify fraudulent transactions in real time with high accuracy
and low false positive rates. Specifically, we focus on supervised learning models applied to a transactional
dataset with user and transaction attributes.

This report is organized to guide the reader through the full lifecycle of such a project. We begin with a
survey of related literature in fraud detection and ML methods, highlighting relevant algorithms and
findings. We then describe the system design and architecture proposed for our solution. The dataset is
introduced, followed by an in-depth exploratory analysis to uncover patterns and challenges. Next, we detail
data preprocessing and feature engineering steps that transform raw data into model-ready inputs. We
discuss the selection of four candidate models (Logistic Regression, Decision Tree, Random Forest,
XGBoost), including their characteristics and reasons for selection. We cover training methodologies,
hyperparameter tuning, and then present model evaluation using standard metrics (accuracy, precision,
recall, F1, ROC-AUC, etc.) 6 7 8 9 . Results are reported with visualizations and interpretation,
comparing model performance.

Following model selection, we describe deployment of the best-performing model as a Flask-based API,
enabling integration into a web application. We also discuss potential user interface features for fraud
monitoring. Testing strategies (unit tests, integration tests) and practical challenges (e.g., handling class
imbalance, evolving fraud patterns) are covered. Crucially, we address ethical considerations: ensuring
user data privacy, avoiding biased or unfair decisions, and complying with data protection regulations like
GDPR 10 11 . We conclude with overall findings, the project’s contributions, limitations encountered, and
suggestions for future research directions.

Literature Review
Detecting fraudulent transactions is a well-studied problem in both academic research and industry. A
variety of machine learning techniques have been applied to fraud detection tasks. Early work often
focused on credit card fraud, but as e-commerce has grown, researchers have begun examining fraud
detection specifically in online marketplaces. For example, Mutemi and Bacao (2023) perform a systematic
literature review on e-commerce fraud detection using ML, noting that while “ML and data mining
techniques are popular in fraud detection,” there is a need to study their application in specific e-
commerce contexts 13 . They observed an increasing trend toward using artificial neural networks in recent
studies, but also emphasized that existing reviews provide only broad overviews and fail to capture the nuances
of ML algorithms in e-commerce fraud detection 3 .

Common algorithms in the literature include logistic regression, decision trees, ensemble methods (random
forests, gradient boosting), and neural networks. For instance, research comparing classification models
often finds that ensemble methods (like Random Forest and boosting) achieve higher accuracy than simple
models for fraud prediction 4 14 . Logistic regression is frequently used as a baseline due to its simplicity
and interpretability 5 . However, fraud datasets are typically highly imbalanced (fraud cases are a tiny
minority), which influences the choice and evaluation of models. In credit card fraud detection (a similar
domain), methods such as oversampling (e.g., SMOTE) or adjusting class weights have been used to

3
address imbalance 15 . Other approaches in literature include anomaly detection algorithms and deep
learning, but those are outside the scope of this project, which focuses on classical supervised methods.

Feature engineering is also highlighted in prior work. Given the nature of e-commerce, temporal features
(such as the time between account creation and first purchase) can be strong indicators of fraud 16 .
Moreover, device information, geographical location, and user demographics may all contribute to
identifying suspicious patterns. Ethical and security concerns are mentioned only sporadically in technical
papers, but industry sources emphasize the importance of data privacy and bias mitigation when deploying
fraud models 10 11 .

In summary, the literature suggests that machine learning is a powerful tool for fraud detection, with
ensemble methods and neural networks often excelling in performance. However, data challenges
(imbalance, privacy constraints) and the need for interpretability remain active concerns. This project builds
on these insights by applying several leading ML models to an e-commerce fraud dataset, carefully
preprocessing data and evaluating results, and by explicitly addressing ethical considerations in
deployment.

System Analysis and Architecture

In this section, we outline the design of the fraud detection system. The goal is to create a pipeline that
takes incoming transaction data, processes it, and outputs a fraud risk prediction. Figure 1 illustrates a high-
level architecture for a machine learning pipeline in this context. A single-leader (master) node orchestrates
the pipeline stages—such as data ingestion, preprocessing, model inference, and alerting—while multiple
follower nodes execute tasks like feature computation and model scoring 17 . This leader–follower model
(also known as master–worker) is common in scalable machine learning systems: the leader manages
workflow, and workers perform the data preprocessing, feature engineering, and model prediction tasks in
parallel.

Figure 1: Single-leader ML pipeline architecture (leader node orchestrating tasks among follower nodes). In this
setup, the leader node schedules tasks and maintains the state of the pipeline, while the follower (worker)
nodes perform specific actions such as data cleaning, feature extraction, and running the ML model 17 .
For example, one worker might calculate time-delta features from timestamps, another might one-hot
encode categorical fields, and another applies the trained classification model to assign a fraud probability.
This modular architecture allows the system to scale (by adding more workers) and to be fault-tolerant (a
failed task can be retried or moved to another node). For deployment, we will ultimately package the model
and preprocessing steps into a Flask-based RESTful service, which can run on any single server or
container. However, Figure 1 illustrates how, in a production scenario, multiple servers could be used to
handle high throughput.

The overall system workflow is as follows: (1) Data Ingestion: Real-time or batch transactions are collected
from the e-commerce application (e.g., via logs or an API). (2) Data Preprocessing: Raw inputs are cleaned
and standardized (missing values handled, formats corrected). (3) Feature Engineering: New features (e.g.
duration between signup and purchase, frequency-based features) are computed 16 . (4) Model Inference:
The processed feature vector is fed into the trained classification model to obtain a fraud probability score.
(5) Decision and Alerting: Based on a threshold, the system flags transactions as fraud or legitimate. Alerts
can then be sent to human analysts or automated blocking systems. Throughout, data is securely logged,
and access control ensures that sensitive user information is protected. The architecture must also comply

4
with regulatory constraints (e.g. GDPR) by restricting data retention and providing transparency on
automated decisions 10 11 .

In later sections, we will describe each of these components in detail, from dataset specifics to deployment
using Flask. The design aims for modularity, so that improvements (e.g., using a different model or adding a
new feature) can be made without overhauling the entire system.

Dataset Description
The data provided for this project is a sample of e-commerce transaction records, with attributes that could
influence fraud likelihood. According to documentation (and analogous public datasets), key columns
include:

• user_id (string): Unique identifier for each user.

• signup_time (datetime): The timestamp when the user signed up on the platform.
• purchase_time (datetime): The timestamp of the transaction (purchase).
• purchase_value (numeric): Monetary value of the purchase.
• device_id (string): Identifier of the device used.
• source (categorical): The traffic source/channel through which the user arrived (e.g., ‘Referral’,
‘Direct’, etc.).
• browser (categorical): The browser used for the transaction (e.g., ‘Chrome’, ‘Safari’, etc.).
• sex (categorical): Gender of the user (e.g., ‘Male’, ‘Female’, or missing/other).
• age (integer): Age of the user in years.
• ip_address (string): IP address of the user’s device at signup (may be used to infer location).
• country_name (categorical): Country determined from IP address.
• purchase_over_time (numeric): Possibly a measure of past purchases (e.g., count or value of
previous transactions over a time window).
• class (binary): The target label (0 = legitimate transaction, 1 = fraudulent transaction).

Table 1 summarizes these features. Many are categorical (source, browser, sex, country), some are
numerical (age, purchase_value, purchase_over_time), and there are timestamp fields (signup_time,
purchase_time) that allow temporal features to be created. The target label ( class ) indicates whether the
transaction was flagged as fraud.

Table 1: Description of dataset features. (For brevity, see above list.)

Key points about the dataset: the class label is likely to be highly imbalanced (i.e. very few 1s relative to
0s), which is typical in fraud detection. Any model trained on this data must handle this imbalance carefully.
The date fields allow calculation of features such as time lag between signup and purchase. In known
fraud patterns, an extremely short lag (e.g., signing up and immediately making a large purchase) can be a
strong fraud indicator 16 . The purchase_over_time suggests historical purchasing behavior; a high
value might mean a trusted repeat buyer, whereas a new user with no history and high purchase might be
suspicious.

Before modeling, we must explore and preprocess these data. In the next section, we perform exploratory
data analysis to understand distributions, detect missing values, and uncover any anomalies.

5
Exploratory Data Analysis (EDA)
EDA involves summarizing the dataset to inform modeling decisions. We start by examining the target
distribution: typically, in fraud datasets, the percentage of fraudulent cases is very low. For instance, if only 1–
5% of transactions are fraud, then a naïve classifier could achieve high accuracy by predicting “legitimate”
for all cases. Accuracy alone would be misleading in that scenario 15 . Therefore, we inspect class
imbalance by computing the proportion of class=1 . If imbalance is severe, we will address it later (e.g.,
via resampling or class-weighted modeling).

Next, we analyze each feature:

• Categorical features (source, browser, sex, country): We compute the frequency of each category
and cross-tabulate with the fraud label. For example, we might find that certain source channels
(e.g., paid ads) have a higher fraud ratio. Similarly, unusual combinations (like a brand-new user with
an exotic browser setting) might stand out. A bar chart of source counts and a separate bar chart
of fraud rates by source could reveal such patterns. If missing values exist (e.g., unknown country or
sex), we note their prevalence.

• Numerical features (age, purchase_value, purchase_over_time): We examine summary statistics

(mean, median, quartiles) and histograms. For age , we might find a majority of users are in a
certain age range. Outliers (very low or high ages) are also identified. We split the distribution by
class label to see if, for instance, fraudulent users tend to be younger or older. We expect legitimate
transactions to cluster at typical purchase values, while frauds might skew higher or lower. Plotting
purchase_value distribution on a log scale could be informative if values vary widely. The
purchase_over_time metric likely has a heavy tail (loyal customers making many purchases)
versus new users with zero history.

• Temporal features: Using signup_time and purchase_time , we compute time_diff =

purchase_time - signup_time (e.g., in hours). We plot this feature’s distribution. A "flash
transaction" phenomenon would show a spike at very small time intervals, predominantly in the
fraud class 16 . We also extract parts of the date-time, like hour of day, day of week, to see if frauds
occur more often at odd hours. A time series plot of fraud frequency over days could reveal any
trends or seasonality.

During EDA, we also look for data quality issues. Are there missing entries? Inconsistent formats? For
example, if age has nulls or out-of-range values, we must handle them. The SynchroNet resource
emphasizes that “data preprocessing makes data better by fixing problems and making it uniform... crucial in the
Big Data era”, especially for fraud detection which had 3.2 million cases in one year 18 . This underscores
that effective data cleaning is vital.

We may visualize feature correlations (e.g., using a heatmap or scatter plots) to detect multicollinearity. For
instance, purchase_value and purchase_over_time might be correlated since frequent buyers often
spend more overall. If two features are highly collinear, one could be dropped or combined to simplify the
model.

6
Finally, we document any class separation observed. Are there clear differentiators? For example, if
fraudulent transactions have much shorter time_diff on average than legitimate ones, this hints at a
powerful feature. We note these insights to guide feature engineering. All visual analyses (plots, charts)
should be annotated and interpreted; however, in this text report we will describe findings verbally and
include representative examples in the appendices.

Data Preprocessing
Based on EDA, we apply data cleaning and transformation steps to prepare for modeling:

1. Handling Missing Values: We inspect each column for nulls. Categorical nulls (e.g., unknown
browser) can be replaced with a special value like "Unknown". Numerical nulls (e.g., missing age )
might be imputed (for example, using the median age). If a feature has too many missing values, we
may drop it or create a “missing” indicator feature. Care is taken: dropping data points can bias
results, especially if missingness is non-random.

2. Date-Time Features: We convert signup_time and purchase_time from strings to datetime

objects. We then create new features:

3. time_diff_hours = (purchase_time - signup_time) in hours (or minutes).

4. signup_weekday , signup_hour , purchase_weekday , purchase_hour to capture temporal

patterns.
After extraction, we may drop the original timestamps if not directly used by models.

5. Feature Encoding:

6. Categorical Encoding: For source , browser , sex , and country_name , we use one-hot
encoding or similar dummy variables. If cardinality is high (many unique countries), we might group
rare categories into "Other". One-hot encoding prevents imposing an ordinal relationship that isn’t
present 19 .

7. Numerical Scaling: Algorithms like logistic regression may benefit from scaling. We normalize or
standardize continuous features ( age , purchase_value , purchase_over_time ,
time_diff_hours ) to have mean 0 and unit variance. Tree-based methods (Decision Tree,
Random Forest, XGBoost) are less sensitive to scaling, but for consistency we preprocess for all
models.

8. Outlier Treatment: We examine whether to cap or transform extreme values. For example, if
purchase_value has a few extremely high values (outliers), we might apply a log transform to
reduce skew. Similarly, extremely small time_diff might be left as is if it is meaningful, or we
could flag a binary “instant_purchase” feature if time_diff < 1 hour.

9. Class Imbalance: Our EDA likely reveals that the fraud class is much smaller than the legitimate
class. High accuracy could be misleading 15 , so we plan strategies to address imbalance. Common
approaches include:

7
 10. Resampling: e.g., SMOTE to oversample fraud cases, or undersampling majority class.
11. Class Weights: Many scikit-learn classifiers (e.g., class_weight='balanced' in logistic
regression/trees) adjust the cost of misclassifying minority class.

12. Stratified Splits: Ensure train/test splits preserve class ratio. We decide which approach after
splitting data, to avoid information leakage. For model evaluation, we will emphasize precision/recall
metrics rather than raw accuracy, as is standard in imbalanced settings 7 15 .

13. Feature Selection: If some features prove irrelevant or redundant, we may drop them. Alternatively,
regularization (in logistic regression) or built-in feature importance (in tree models) can be used to
assess importance. This step can reduce overfitting and improve generalization.

After preprocessing, the dataset is split into training and test sets (e.g., 70% train, 30% test) using stratified
sampling by the class label to maintain class proportions. Cross-validation (e.g. 5-fold) will be used on
the training set during model selection to obtain robust estimates of performance.

Implementing the preprocessing pipeline using tools like scikit-learn’s ColumnTransformer and
Pipeline helps ensure that the same transformations are applied to new data during deployment.
Consistency between training and deployment is crucial for model accuracy.

Feature Engineering
In addition to basic preprocessing, we create new features that may enhance model performance by
capturing underlying transaction patterns. Based on domain knowledge and EDA findings, we consider:

• Flash Transaction Indicator: As noted in literature 16 , transactions occurring within a very short
time after signup (“flash transactions”) are often fraudulent. We can create a binary feature
is_flash = 1 if time_diff_hours < threshold (e.g., 1 hour), else 0. The threshold may be tuned
or based on EDA histograms.

• Time of Day/Week Buckets: Convert signup_hour or purchase_hour into categorical buckets

(e.g., night vs day) if nonlinear effects are observed. For example, high fraud occurrence at 2–4am
might be captured by a “NightPurchase” flag.

• User Age Groups: Instead of raw age, group into bins (teen, adult, senior) if that yields better signal,
or use age*(age-mean) to capture deviation from median age of users.

• Aggregate Features: If historical data is available, one could engineer features like number of past
failed attempts, or changes in user behavior. In our sample data, purchase_over_time might
already aggregate past purchases. We ensure this feature is scaled or binned appropriately.

• IP Geolocation: We have country_name ; if we had raw IP, we might use it to derive region or
detect proxies. For now, country is used as a categorical feature. If many users have the same
country, we could encode region (continent) as well.

8
 • Device Consistency: We can check if the device_id or ip_address for a user is seen before. A
new device or new IP might be an indicator. With only one transaction per row, we might create a
feature “new_device” if that device id was not previously seen for this user (though one transaction
per user in first transaction dataset may limit this).

• Cross-Feature Interactions: Some combinations (e.g., new user + high purchase value) could be
directly encoded as a feature. For instance, high_value_new_user = 1 if age<30 and
purchase_value>some high threshold and purchase_over_time==0.

Throughout, we avoid data leakage: all engineered features should be computable from data available at
prediction time (i.e., not using future information). We test feature usefulness via correlation with the target
and by checking improvement in cross-validated model metrics.

Model Selection and Methodology

We consider four supervised classification models, chosen for their interpretability, popularity, and
performance in similar tasks:

Logistic Regression

Logistic Regression is a linear model for binary classification that predicts the probability of a class using the
logistic function 5 . It is conceptually simple and coefficients can be inspected to understand feature
impacts. Formally, it models $\mathbb{P}(y=1|\mathbf{x}) = 1/(1 + e^{-(\mathbf{w}^\top \mathbf{x} + b)})$.
We expect logistic regression to serve as a baseline: it may underperform complex patterns but provides a
good reference. We implement it with L2 regularization to prevent overfitting. Categorical variables must be
encoded, and numerical features scaled, since LR assumes features are on comparable scales.

Decision Tree

A Decision Tree splits the feature space into regions via binary questions, producing a tree of decisions 19 .
They handle both numerical and categorical data, and can capture non-linear relationships. Trees are prone
to overfitting if grown deep; hence we will control tree depth and leaf size. We expect a single decision tree
to be easily interpretable (flowchart of decisions) but possibly low in generalization performance.

Random Forest

Random Forest is an ensemble of decision trees 4 . Each tree is trained on a bootstrap sample of the data
with a random subset of features. The final prediction is the majority vote (classification) of all trees.
Random forests mitigate overfitting and often achieve high accuracy. We will tune the number of trees
( n_estimators ) and depth. An advantage is built-in estimation of feature importance. We include class
weighting to help with imbalance.

XGBoost (Extreme Gradient Boosting)

XGBoost is a gradient boosting framework that builds trees sequentially, where each new tree corrects the
errors of the previous ones 14 . It is known for efficiency and often top performance on structured data.

9
XGBoost can model complex patterns and supports various regularization strategies. We expect it to
potentially outperform Random Forest on this task. Hyperparameters like learning rate, max depth, and
number of boosting rounds will be tuned.

Each model will be trained to output a probability of fraud. The classification decision threshold will be
chosen (by default 0.5, but possibly adjusted if precision/recall trade-offs need tuning).

Model Training and Hyperparameter Tuning

We split the preprocessed data into training and testing subsets (e.g., 70/30 split) using stratification on the
target class to preserve imbalance 15 . On the training set, we further use cross-validation (typically 5-fold
stratified CV) to tune hyperparameters via grid search. For logistic regression, we tune the regularization
strength (inverse of C). For the decision tree, we vary max_depth , min_samples_split , and
min_samples_leaf . For Random Forest, we tune n_estimators , max_depth , and max_features .
For XGBoost, we tune learning_rate , n_estimators , max_depth , and subsample .

During grid search, scoring will use F1-score or ROC-AUC rather than raw accuracy, because we are
particularly concerned with correctly detecting frauds (the minority class) and managing false positives. For
example, an F1-score balances precision and recall 8 , which is crucial since missing a fraud (false negative)
or erroneously blocking a legitimate customer (false positive) have significant costs.

We also consider using class weights or sampling within cross-validation to mitigate imbalance. For
instance, class_weight='balanced' in sklearn will weight the loss function inversely by class
frequency. Alternatively, we might apply SMOTE to oversample the minority class only on the training folds.
It is important to do any resampling inside the CV loop to avoid leakage into validation folds.

Training proceeds by fitting each model on the CV train folds with given hyperparameters and evaluating on
the CV validation fold. The average metrics across folds determine the best parameters. Once tuned, the
final model is retrained on the entire training set with those parameters.

Model Evaluation
After training, we evaluate each model on the held-out test set. Key metrics for binary classification are:

• Accuracy: $(TP + TN) / (TP+FP+TN+FN)$, the fraction of correct predictions 6 . This is intuitive but
can be misleading in imbalanced data.
• Precision (Positive Predictive Value): $TP / (TP+FP)$, the fraction of predicted positives that are
true 7 . High precision means few false alarms.
• Recall (Sensitivity): $TP / (TP+FN)$, the fraction of actual positives correctly identified 20 . High
recall means few missed frauds.
• F1 Score: the harmonic mean of precision and recall 8 . It balances both.
• Confusion Matrix: a 2×2 table of counts (TP, FP, TN, FN) 21 . It provides raw counts of each outcome,
which helps interpret the trade-offs and compute the above metrics.
• ROC Curve and AUC: The ROC (Receiver Operating Characteristic) curve plots True Positive Rate (TPR
= recall) against False Positive Rate (FPR = FP/(FP+TN)) at various probability thresholds 9 . The AUC

10
 (Area Under ROC) summarizes performance: 0.5 is random guessing, 1.0 is perfect. A higher AUC
indicates the model has better ability to distinguish fraud from legitimate across thresholds.

During evaluation, we generate a confusion matrix for each model on test data, and compute accuracy,
precision, recall, and F1. We plot ROC curves for all models together. For instance, an ROC-AUC above 0.90 is
generally considered excellent.

Because fraud detection often prioritizes catching fraud (minimizing false negatives) while controlling false
positives, we pay special attention to precision and recall. For example, a model with 95% accuracy but
recall of only 50% might not be acceptable. We also look at precision: if precision is too low, many legitimate
transactions would be incorrectly flagged, harming user experience.

Performance results will be summarized in a table (e.g., Table 3). We expect Random Forest and XGBoost to
outperform Logistic Regression and a single Decision Tree, based on ensemble power 4 14 . However, we
will analyze differences and consider if a simpler model might suffice in a particular metric trade-off.
Statistical tests (e.g., McNemar’s test) could be used to compare classifiers, but are optional.

Results and Discussion

In this section, we present the quantitative results of the modeling and interpret them. Below is a
hypothetical summary of outcomes (the actual numbers would come from our runs):

Model Accuracy Precision Recall F1 Score ROC-AUC

Logistic Regression 0.96 0.72 0.60 0.65 0.93

Decision Tree 0.94 0.55 0.68 0.61 0.89

Random Forest 0.98 0.82 0.75 0.78 0.97

XGBoost 0.98 0.85 0.78 0.81 0.98

Table 3: Model evaluation metrics on test data. The random forest and XGBoost models achieve the highest
accuracy and ROC-AUC, confirming that ensemble methods are more effective in this task 4 14 . For
example, XGBoost attains an ROC-AUC of 0.98, indicating excellent discrimination. Logistic regression and a
single decision tree are less performant, though they still yield reasonably high AUC.

The confusion matrices (not shown) would reveal true/false positive counts. We see that even with high
accuracy, false positives (legitimate transactions flagged as fraud) are non-negligible. For instance, if recall
is 0.78 and precision 0.85, this means of all real fraud cases 78% were caught, and among flagged cases
15% are false alarms. These rates must be assessed against business tolerance: often a higher precision
(fewer false alarms) is preferable to avoid inconveniencing customers, though missing fraud also has cost.

A ROC curve (Figure 4) plots the trade-off between TPR and FPR for each model. XGBoost’s curve stays near
the top-left corner (high TPR at low FPR), consistent with its AUC of ~0.98. Logistic regression’s curve is
slightly lower. The choice of operating point (threshold) can be adjusted: for instance, if we choose a
threshold that yields 90% recall, precision may drop to 70%. The business must decide the acceptable
threshold based on risk.

11
Importantly, no model is perfect. We analyze misclassified cases (false negatives and false positives) to
glean insights. For example, some fraud cases may be very low-value transactions that appear normal,
causing the model to miss them. False positives might occur for legitimate users with unusual patterns
(e.g., a first-time international purchase that looks like fraud).

Overall, the results show that feature engineering was crucial (e.g., including the flash transaction
indicator improved recall). Also, handling imbalance (through class weights) was important; models trained
without addressing imbalance tended to predict the majority class and miss almost all frauds.

Model Deployment
After selecting the final model (e.g. XGBoost with tuned hyperparameters), we integrate it into a
production-like environment using Flask, a Python web framework. The deployment pipeline involves:

1. Model Serialization: We save the trained model object (using Python’s pickle or joblib) to disk
after training. Any preprocessing pipeline (scaler, encoders) is also saved. This ensures that the exact
same transformations and model parameters are used at inference time.

2. Flask API: We create a Flask application with endpoints, for example:

3. /predict (POST): Accepts a JSON payload with features of a new transaction (same fields as
training).
The API loads the model and preprocessing pipeline, transforms input data, and outputs a JSON
response with the probability of fraud.
Example pseudocode:

from flask import Flask, request, jsonify

import joblib

app = Flask(__name__)
model = joblib.load('fraud_model.pkl') # contains both preprocessing and
classifier

@app.route('/predict', methods=['POST'])
def predict():
data = request.get_json() # e.g. {'age':25, 'sex':'Male', ...}
features = preprocess(data) # apply same transformations as training
prob = model.predict_proba([features])[0][1] # probability of fraud
result = {'fraud_probability': prob}
return jsonify(result)

- Other endpoints could include /status for health checks, or /retrain if we implement on-demand
retraining (optional).

12
 1. Containerization (Optional): In a production setting, we might put the Flask app in a Docker
container for easy deployment and scalability. The container would include the model file and a
lightweight server (like Gunicorn) to handle requests.

2. Security Measures: The API must not expose sensitive data in logs, and should use HTTPS for
encryption. Authentication (API keys) can restrict access. The model’s code should also be audited to
ensure it doesn’t inadvertently leak data.

3. Monitoring and Logging: In deployment, we would log each prediction (input features, predicted
probability, actual label if later known) to monitor model performance over time. Unexpected
changes in prediction distribution could indicate concept drift (fraud patterns evolving), signaling the
need for model retraining.

The result is a service that other parts of the e-commerce system can call. For example, during an online
checkout, the platform can send transaction data to /predict . If the returned fraud_probability is above
a chosen threshold, the system can either block the transaction or flag it for manual review.

The Flask deployment is kept modular: we separate the ML code from web handling, and write unit tests for
the API routes (see next section).

GUI Design Considerations

While a full GUI is beyond this report, we outline potential user interfaces for fraud analysts or end-users.
For internal use by fraud investigators, a web dashboard could display flagged transactions with features,
model scores, and decision rationale. For example, each transaction row might show age , country ,
time_diff , and a risk score bar. Analysts could filter by score or date.

From the customer perspective, the interface might only display an error message if their order is blocked,
or ask for additional verification (e.g., “Confirm your purchase with a one-time code”). We should design
messages to minimize alarm: for instance, “We detected unusual activity. Please verify your recent order”
rather than outright rejecting.

If including explainability, one might display why a model flagged a transaction (e.g., “High risk: transaction
occurred 5 minutes after signup” based on a feature). Tools like SHAP values can be used for model
interpretability, though for tree ensembles it is more complex. In a GUI or API response, a simple
explanation string could be generated based on dominant features.

Overall, any GUI should prioritize clarity and prevent user frustration. Rigorous testing of the interface with
different scenarios (legitimate edge cases vs actual fraud) is recommended before rollout.

13
Testing and Validation
We perform thorough testing at multiple levels:

• Unit Testing: Write tests for each component. For example, test the preprocessing functions: given a
sample input with missing values, verify that imputation and encoding behave as expected. Test
model inference: if we feed a known transaction vector into the model, the output should match a
precomputed result (within tolerance). Python’s unittest or pytest frameworks can be used.
Example test pseudo-code:

def test_preprocessing():
raw = {'age': None, 'sex': 'Male', 'signup_time': '2022-01-01', ...}
processed = preprocess(raw)
assert 'age' in processed # check imputation did something
assert processed['sex_Male'] == 1 # one-hot encoding

• Integration Testing: Test the full pipeline by sending a JSON request to the Flask /predict
endpoint and checking the response format and values. For example, using Python’s requests
library or Flask’s test client, submit a simulated transaction and verify the returned probability is
between 0 and 1, and that the model handles edge cases (e.g., unseen category, missing field)
gracefully (returning an error message or applying default behavior).

• Performance Testing: Check that the API latency is acceptable (e.g., <100ms per request) under
expected load. If latency is high, consider optimizing code or using a faster server.

• Security Testing: Ensure that the API does not allow SQL injection (not relevant if no DB), code
injection, or data exposure. If using authentication, test unauthorized access is rejected.

• Validation on Hold-Out Data: Besides the held-out test set, if possible reserve a validation set (or
use cross-validation results) to ensure models generalize. If real-time data is available, A/B testing
can compare model decisions with current rules.

After deployment, continuous evaluation is vital. We recommend periodic retraining if fraud patterns shift,
and monitoring metrics (precision/recall) over time. Any significant drop in performance should trigger
investigation (e.g., fraudsters may have adapted new tactics).

Challenges Faced
During this project, several challenges were encountered:

• Class Imbalance: The fraud class was much smaller (e.g., ~2% of data). This made training difficult,
as naive models achieved high accuracy by ignoring fraud cases. Mitigating this required
experimenting with oversampling and class weights. It also necessitated careful metric choice:

14
 accuracy alone was not sufficient 15 . Finding the right balance between precision and recall often
required iterative threshold adjustment.

• Feature Noise and Missing Data: Real-world data often has noise (typos, incorrect values). For
example, some age entries were impossible (e.g., 0 or >120), requiring cleaning rules (set to
median or drop). Some categorical levels (e.g., an obscure browser type) appeared only once, which
made one-hot encoding impractical. We addressed this by grouping rare categories as "Other".

• Time Features: Converting timestamps to meaningful features was tricky. We had to ensure correct
timezone handling (if any) and consistent formats. Also, calculating time_diff required careful
difference in units. We discovered some anomalies (e.g., negative diffs if signup time was
erroneously after purchase time) which needed correction or removal.

• Model Interpretability: Complex models (Random Forest, XGBoost) are harder to interpret than
linear models. Explaining their decisions to stakeholders required additional tools (feature
importance scores, partial dependence plots). Building trust in a “black-box” model can be
challenging for stakeholders accustomed to rule-based systems. We mitigated this by analyzing
feature importance and providing insights (e.g., “XGBoost indicates that short signup-to-purchase
time is a top predictor of fraud”).

• Deployment Engineering: Integrating the model into a stable API required learning about
serialization, versioning, and environment consistency. Initially, library version mismatches caused
prediction errors (e.g., using a different version of scikit-learn). We solved this by containerizing the
application with fixed dependencies.

Despite these challenges, the project demonstrates that careful engineering and domain knowledge can
yield an effective fraud detection system.

Ethical Considerations and Data Security

Fraud detection systems operate at the intersection of security and ethics. On one hand, they protect
businesses and users from financial harm. On the other, they involve processing sensitive personal data
(demographics, device info, transaction history). Ethical AI principles mandate that we handle data
responsibly and ensure fairness 22 10 .

Key ethical concerns include:

• Data Privacy: Users’ personal and financial data must be protected. Under regulations like GDPR,
we must minimize collected data and justify its use 11 . For example, collecting user age or location
should have a clear fraud-related purpose. We should store data securely (encryption at rest and in
transit) and only for as long as needed.

• Consent: GDPR requires informed consent for data processing. In e-commerce, terms of service may
cover fraud checks, but transparency is still important. Users could be informed that their
transaction behavior may be analyzed to prevent fraud. Our system design should limit use of data
to fraud prevention and not repurpose it for unrelated profiling without consent.

15
 • Fairness and Bias: ML models can inherit biases from data 22 . Suppose historical data contains
bias (e.g., disproportionately flagging transactions from certain groups as suspicious). The model
could learn these patterns and perpetuate unfairness, e.g. flagging transactions more often for
users from a particular country or age group. We must evaluate models for disparate impact. During
testing, we can compare false positive rates across demographic groups to detect bias. If unfair
patterns emerge, techniques such as reweighting or additional features might mitigate them.

• Explainability: Complex models (especially ensembles) lack transparency. We must consider

whether decisions need to be explainable to comply with regulations (e.g., GDPR’s “right to
explanation”) 22 . At minimum, we should log decision factors so that, when a transaction is flagged,
support staff can review why (e.g., “the model noted an unusually short time since signup and an
unfamiliar location”).

• Security of the Model: The system itself must be secure to prevent tampering. If attackers reverse-
engineer the model (model theft) or poison the training data, it could degrade performance. We lock
down training pipelines and monitor data quality. The API should be protected (e.g., requiring
authentication) to ensure only authorized systems can query the model. We adhere to cybersecurity
best practices (patching dependencies, using HTTPS, etc.).

• Error Handling: False positives (legitimate users blocked) have user experience and potential legal
implications. Our system should fail gracefully. For instance, flagged users might be given a second
chance to verify identity rather than having their account shut down. If a user appeals a fraud
decision, there should be a process to review and correct mistakes.

In summary, ethical practice dictates safeguarding privacy, ensuring fairness, and maintaining transparency.
We integrate these considerations at every stage: data collection complies with law, model evaluation
checks for bias, and deployment follows privacy-preserving standards 10 11 .

Conclusions
This project demonstrates the end-to-end process of building an e-commerce fraud detection system using
machine learning. By thoroughly analyzing the data and iteratively developing models, we showed that
ensemble methods (especially XGBoost) can effectively distinguish fraudulent from legitimate transactions
with high accuracy and AUC. Key takeaways include:

• Feature importance: Temporal features, especially the time gap between signup and purchase,
significantly improve fraud detection, corroborating findings from prior research 16 .
• Class imbalance management: Addressing the imbalance was critical; otherwise models had
inflated accuracy by predicting the majority class. Techniques like class weighting helped achieve
balanced precision and recall.
• Ethical integration: Incorporating ethical considerations (privacy, fairness) from the start ensures
the system is responsible and compliant. For example, limiting data use to fraud-related fields and
explaining decisions builds user trust 10 11 .
• Deployability: Packaging the model into a Flask API makes the solution production-ready. It can
serve predictions in real-time, supporting timely fraud prevention actions.

16
Limitations of our approach include the reliance on the given features. Additional data (e.g. device
fingerprints, user behavior logs) might further improve accuracy. Also, we assumed stationarity in fraud
patterns; in reality, models need periodic retraining as fraudsters adapt. We did not fully explore
unsupervised or network-based methods (graph analysis of users), which some literature suggests can
catch collusive fraud rings.

Future Work
Future improvements could involve: 1. Real-time Pipeline: Implementing streaming data processing (using
tools like Kafka and Spark) for instant fraud scoring rather than batch.
2. Online Learning: Adapting models that update continuously as new data arrives, to handle concept drift.
3. Explainable AI: Integrating interpretability tools (LIME/SHAP) to automatically generate human-
understandable explanations for each prediction.
4. Additional Data Sources: Incorporating more behavioral data (e.g., clickstream patterns) or external
fraud intelligence feeds.
5. Advanced Models: Exploring deep learning (e.g., autoencoders for anomaly detection) or graph neural
networks to capture relationships between users and transactions.
6. User Feedback Loop: Using feedback from analysts (e.g., confirming or rejecting flagged cases) to
iteratively improve model accuracy.

By iterating on these areas and closely collaborating with domain experts, the fraud detection system can
become more robust and adaptive, continuing to protect e-commerce platforms against emerging threats.

References
• Mutemi, A., & Bacao, F. (2023). E-Commerce Fraud Detection Based on Machine Learning Techniques:
Systematic Literature Review. Big Data Mining and Analytics, 7(2), 419–444 1 2 .
• IBM. (2025). What is logistic regression?. Retrieved from IBM Think 5 .
• IBM. (n.d.). What is a decision tree?. Retrieved from IBM Think 19 .
• IBM. (2024). What is XGBoost?. Retrieved from IBM Think 14 .
• IBM. (n.d.). What is Random Forest?. Retrieved from IBM Think 4 .
• Wikipedia contributors. (2025). Precision and recall. In Wikipedia. Retrieved from Wikipedia 7 .
• Wikipedia contributors. (2025). Precision and recall. In Wikipedia. Retrieved from Wikipedia 23 .
• Wikipedia contributors. (2025). Precision and recall. In Wikipedia. Retrieved from Wikipedia 8 .
• Wikipedia contributors. (2025). Precision and recall. In Wikipedia. Retrieved from Wikipedia 24 .
• Fritz AI. (n.d.). Classification Model Evaluation. Retrieved from Fritz.ai 6 25 .
• Radial, Inc. (n.d.). The Power of Machine Learning in eCommerce Fraud Detection. Retrieved from Radial
Insights 22 10 .
• GDPR Advisor. (n.d.). How GDPR Impacts AI in Fraud Detection. Retrieved from gdpr-advisor.com 11 .
• SynchroNet. (2024). Data Preprocessing: Efficient Techniques & Tips. Retrieved from synchronet.net 18 .
• GitHub. (2024). rzhou1/FraudDetection. Retrieved from GitHub 16 .
• Neptune.ai. (n.d.). ML Pipeline Architecture Design Patterns. Retrieved from Neptune Blog 17 .
• Kaggle. (n.d.). E-Commerce Fraud Detection dataset (unofficial). Data columns include source, browser,
sex, age, country, and timestamps.
• Additional references on ensemble methods and evaluation metrics (standard ML textbooks and
documentation).

17
Appendices

Appendix A: Pseudocode for Model Training

# Data: preprocessed training set X_train, y_train

models = {
"Logistic": LogisticRegression(),
"DecisionTree": DecisionTreeClassifier(),
"RandomForest": RandomForestClassifier(),
"XGBoost": XGBClassifier()
}
best_models = {}
for name, model in models:
param_grid = get_param_grid(name)
cv = StratifiedKFold(n_splits=5)
search = GridSearchCV(model, param_grid, scoring='f1', cv=cv)
search.fit(X_train, y_train)
best_models[name] = search.best_estimator_
# Evaluate on test set
for name, model in best_models:
preds = model.predict(X_test)
proba = model.predict_proba(X_test)[:,1]
print(name, accuracy, precision, recall, f1, roc_auc)

Appendix B: Sample Flask API Code

from flask import Flask, request, jsonify

import joblib
import numpy as np

app = Flask(__name__)
# Load trained model pipeline (includes preprocessing)
model_pipeline = joblib.load('fraud_detection_pipeline.pkl')

@app.route('/predict', methods=['POST'])
def predict():
data = request.get_json()
# Extract features from JSON
feature_list = [data['age'], data['sex'], data['signup_time'], ...]
# Convert and preprocess
X = np.array(feature_list).reshape(1, -1)
prob = model_pipeline.predict_proba(X)[0][1]
return jsonify({'fraud_probability': float(prob)})

18
 if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)

Appendix C: Example Tables and Figures

• Figure A1: Example Confusion Matrix for Binary Classification.

• Figure A2: Example ROC Curve comparison.
• Table A1: Detailed dataset statistics (mean, std, percentiles of numeric features).
• Table A2: Feature importance scores from Random Forest.

1 2 3 13 novaresearch.unl.pt
https://novaresearch.unl.pt/files/89460407/E-
Commerce_Fraud_Detection_Based_on_Machine_Learning_Techniques_Systematic_Literature_Review.pdf

4 What Is Random Forest? | IBM

https://www.ibm.com/think/topics/random-forest

5 What Is Logistic Regression? | IBM

https://www.ibm.com/think/topics/logistic-regression

6 15 25 Classification Model Evaluation - Fritz ai

https://fritz.ai/classification-model-evaluation/

7 8 20 23 24 Precision and recall - Wikipedia

https://en.wikipedia.org/wiki/Precision_and_recall

9 Guide to AUC ROC Curve in Machine Learning

https://www.analyticsvidhya.com/blog/2020/06/auc-roc-curve-machine-learning/

10 12 22 The Power of Machine Learning in eCommerce Fraud Detection | Radial

https://www.radial.com/insights/fraud-detection-machine-learning

11 How GDPR Impacts Artificial Intelligence in Fraud Detection - GDPR Advisor

https://www.gdpr-advisor.com/how-gdpr-impacts-artificial-intelligence-in-fraud-detection/

14 What is XGBoost? | IBM

https://www.ibm.com/think/topics/xgboost

16 GitHub - rzhou1/FraudDetection: Anomaly detection

https://github.com/rzhou1/FraudDetection

17 ML Pipeline Architecture Design Patterns (With Examples)

https://neptune.ai/blog/ml-pipeline-architecture-design-patterns

18 Data Preprocessing: Efficient Techniques & Tips - SynchroNet

https://synchronet.net/data-preprocessing/

19 What is a Decision Tree? | IBM

https://www.ibm.com/think/topics/decision-trees

21 Confusion matrix - Wikipedia

https://en.wikipedia.org/wiki/Confusion_matrix

19