How gyrojoestar/fraud-detection works
This repository combines offline fraud-model development with a small prediction API and a separate Supabase data-preparation/storage path. The principal serving workflow accepts 29 transaction features, loads the highest-PR-AUC model from MLflow at startup, and returns a fraud probability and label. Database seeding and exploratory user grouping are not wired into prediction in the sampled source; the README provides no further capability detail.
Main entry points: main.py Prediction service · populate_supabase.py Database seeding · train.py Model training · eda.py EDA and grouping
Components 12
Prediction API
- Prediction service
backend/main.py - XGBoost model
backend/main.py
Model lifecycle
- Model training
model_training/train.py - MLflow tracking
- Transaction dataset
Transaction data
- EDA and grouping
eda.py - Database seeding
database/populate_supabase.py - Transaction schema
database/model.py - DB sessions
database/connection.py - Supabase PostgreSQL
- Sample query
app.py
Other components
- API client
Connections 11
- API client → Prediction service: submits features
- Prediction service → XGBoost model: predicts probability
- Prediction service → MLflow tracking: loads best run
- Model training → Transaction dataset: reads dataset
- Model training → MLflow tracking: logs model
- EDA and grouping → Transaction dataset: reads dataset
- EDA and grouping → Database seeding: writes seed CSV
- Database seeding → DB sessions: requests session
- Database seeding → Transaction schema: inserts records
- DB sessions → Supabase PostgreSQL: opens sessions
- Sample query → Supabase PostgreSQL: queries transactions