Transaction risk & fraud detection

The problem

Fraud models live between two kinds of failure: missed fraud, and legitimate customers whose payments get blocked. Transaction data is high-volume, full of duplicates and incomplete records, and behaviour varies enormously from one account to the next.

Features first

Transaction and customer-level data was prepared with Python, SQL, Pandas and NumPy, then moved to Apache Spark / PySpark for the volumes involved. Reusable SQL and Python routines turn raw activity into model-ready datasets, so training and validation sets refresh without manual rework.

The features describe behaviour: transaction frequency, payment amounts, merchant activity, customer history, timing patterns and account-level signals.

Models, tuned for the right errors

I compared XGBoost, LightGBM, CatBoost, Random Forest and Logistic Regression, evaluated with AUC-ROC, precision, recall, confusion matrices and cross-validation. The focus was on incorrectly flagged transactions and missed risk cases, not on one headline number. Learning rates, tree depth, regularization and sampling were tuned with Optuna, Grid and Randomized Search.

Making decisions explainable

• SHAP and LIME show risk analysts why a transaction scored high, case by case and across the model.
• Text signals: Hugging Face Transformers, BERT and Sentence Transformers extract classification and semantic signals from customer-support and case text.
• Case search: a semantic search layer with FAISS and OpenSearch lets analysts find similar historical cases without exact phrases.

Delivery

Inference components were containerized with Docker and exposed through FastAPI and REST. Across the lifecycle I used AWS S3, SageMaker, ECS, Glue and Redshift, with MLflow for model history and Redis + Celery for long-running jobs. Thresholds and features were revisited with product, risk and data teams after each testing cycle.