Zero to One: Building an Enterprise-Grade Fraud Detection System from Scratch

How I architected a production-ready MLOps pipeline with 96% precision using XGBoost, MLflow, and FastAPI ?

Introduction: The Problem with Notebooks

We've all been there. You train a model in a Jupyter Notebook, get great accuracy, and think "Done!" But in the real world, a model is just a file. It doesn't handle API requests, it doesn't monitor itself for data drift, and it certainly doesn't explain why it flagged a transaction to a compliance officer.

For my MLOps capstone, I didn't want to just train a model. I wanted to build a system.

I built FraudGuard, a complete end-to-end fraud detection platform that handles the entire lifecycle of an ML product—from ingestion to inference. Here is the journey of how I took this project from Zero to One.

1. The Challenge: Needle in a Haystack

Fraud detection is notoriously difficult because of Class Imbalance. Less than 1% of transactions are fraudulent. If your model just guesses "Not Fraud" every time, it will be 99% accurate—and completely useless.

Precision was my North Star metric.

• Low Precision = Blocking legitimate users (User churn).

• Low Recall = Letting fraud through (Financial loss).

My goal was to maximize Precision without tanking Recall, all while keeping inference latency under 50ms.

2. Architecture: The "Zero to One" Pipeline

I moved away from monolithic scripts and adopted a modular architecture.

• Ingestion Setup: I used a custom DataLoader to handle robust ingestion, cleaning messy transaction data before it ever touched a model.

• Feature Engineering: Raw data isn't enough. I engineered time-based features (e.g., frequency of transactions in last 24h) to capture behavioral patterns.

3. The Tech Stack

I chose a stack that balances performance with developer velocity:

• Modeling: XGBoost & LightGBM. For tabular financial data, Gradient Boosting Trees still outperform Deep Learning in both speed and accuracy.

• Tracking: MLflow. Every experiment, every hyperparameter, and every metric was logged. This moved development from "guessing" to "data-driven decisions."

• Serving: FastAPI. Used for the prediction microservice. It’s asynchronous and provides automatic Swagger documentation.

• Containerization: Docker. The entire environment is containerized, ensuring that "it works on my machine" means "it works in production."

4. Solving the "Black Box" Problem with SHAP

One of the biggest blockers in FinTech AI is explainability. You can't just tell a user "Transaction Denied" without knowing why.

I integrated SHAP (SHapley Additive exPlanations) values directly into the dashboard. Now, for every flagged transaction, the system outputs the exact features that contributed to the decision (e.g., "Transaction amount > $5000" or "Location mismatch"). This turns the AI from a black box into a glass box.

5. Deployment & Monitoring

A model is only good if it stays good. I integrated Evidently AI to monitor Data Drift.

If customer spending habits change (e.g., during holidays), the distribution of data shifts. The monitoring service detects this drift and alerts that the model needs retraining, closing the MLOps loop.

6. Results

The final production model achieved:

• Precision: 96.2%

• Recall: 82.5%

• Inference Time: <50ms

Conclusion

Taking a project from Zero to One isn't about the code you write in a notebook; it's about the scaffolding you build around it. FraudGuard taught me that the "ML" part is actually the smallest piece of the puzzle. The real challenge—and fun—is in the Ops.

Check out the code for FraudGuard on GitHub: github.com/AB0204/FraudGuard