1a:I[38422,["/_next/static/immutable/chunks/1h7dhfcxqyyyi.js","/_next/static/immutable/chunks/22f4ki7e-tzov.js","/_next/static/immutable/chunks/1hn6b-rqwx1uz.js","/_next/static/immutable/chunks/1rh742y4nq95m.js","/_next/static/immutable/chunks/0df6dxev7renw.js"],"default"] 1b:T1742,

the problem

Credit card fraud detection in production rarely fails at the algorithmic level. It fails at the infrastructure level. Models degrade due to unseen data drift, APIs crash from malformed client inputs, and retraining loops lack proper experiment tracking. Furthermore, acquiring real-world financial datasets is exceptionally difficult due to strict privacy regulations and extreme class imbalance. The objective was to build a robust machine learning operations (MLOps) pipeline that addresses these deployment realities before a model ever reaches production.

the solution

I architected an end-to-end machine learning platform for credit card fraud detection. The system generates synthetic transaction data, engineers merchant-level aggregate features via a feature store, trains a baseline classifier, and serves predictions through a validated REST API. It includes continuous data drift monitoring and containerised deployment to simulate a complete enterprise MLOps lifecycle.

Key Technical Decisions

Decision 1: Synthetic Data Generation vs. Real-World Datasets

I considered using the standard Kaggle Credit Card Fraud dataset. I rejected it because its extreme imbalance (0.17% fraud) requires extensive algorithmic tuning that distracts from demonstrating MLOps infrastructure. I chose to generate 10,000 synthetic transactions with deliberate, distinct fraud patterns (higher amounts, late-night hours). This ensured the pipeline components could be validated quickly while proving the system could handle the data ingestion pipeline.

Decision 2: Dual Serving Environments (Naive vs. Validated)

I built both an unvalidated FastAPI endpoint and a strictly validated endpoint. The trade-off was maintaining two separate serving scripts, but this was necessary to demonstrably prove the failure modes of unvalidated inputs to stakeholders. It shows exactly how an API degrades when faced with out-of-bounds transaction amounts or missing merchant categories.

Decision 3: Algorithm Selection

I selected a Random Forest Classifier instead of a neural network. While deep learning might yield higher raw accuracy on complex data, Random Forest provides immediate feature importance metrics, requires significantly less compute for rapid CI/CD iteration, and is highly interpretable for financial compliance auditing.

Decision 4: Automating the MLOps Lifecycle via CI/CD

I implemented a GitHub Actions pipeline to automate the transition from code commit to containerised deployment. The trade-off was the initial time investment to configure the YAML workflows, but this was necessary to eliminate human error during deployment. The pipeline is configured to trigger on every pull request to run linting and unit tests, ensuring no broken data validation logic reaches the main branch. Upon merging to main, the workflow automatically builds the Docker image and prepares it for the serving environment. This ensures the ML platform is truly reproducible and continuously integrated.

The Hardest Challenge

The most difficult technical hurdle was integrating Great Expectations for data validation alongside Feast for feature management. The batch validation scripts broke when Great Expectations updated to the 1.19.0 API. Additionally, the Feast feature store successfully computed aggregate metrics like fraud_rate and transaction_count, but injecting these asynchronously computed features into the synchronous training pipeline caused data leakage risks.

I solved this by decoupling the feature store from the immediate training loop. I implemented strict, transaction-level validation rules manually within the FastAPI serving layer to ensure immediate system stability. I left the Feast feature definitions materialised and ready, structuring the repository so the next iteration can wire the online store directly into the inference endpoint without refactoring the core architecture.

Results

Containerised the entire MLOps pipeline using Docker for reproducible local deployment.
Achieved a baseline F1 score of 0.50 on the synthetic holdout dataset using the Random Forest classifier.
Successfully integrated MLflow for experiment tracking, automatically logging hyperparameters, train/test metrics, and feature importances directly to the Model Registry.
Deployed a DriftMonitor class capable of detecting statistical distribution shifts between the reference training data and incoming production traffic.
Designed and implemented a continuous integration and continuous deployment (CI/CD) pipeline using GitHub Actions, reducing manual deployment steps to zero and ensuring automated test coverage on every commit.

Retrospective

If I were to rebuild this, I would fully integrate the Feast online store directly into the FastAPI /predict endpoint to serve real-time aggregate features, rather than keeping the feature store isolated in the offline training stage.

I would also update the Great Expectations integration to fully comply with the v1 API for automated batch validation. Finally, I would add rate limiting, TLS encryption, and authentication to the API and implement cost-sensitive learning to handle the extreme class imbalance inherent in real-world financial data.

11:["$","$L1a",null,{"projects":[{"id":"a0acd864-abd4-49d4-a9c1-41f4c2d6a5d0","slug":"a-credit-card-fraud-detection-pipeline","title":"End-to-End MLOps Platform for Credit Card Fraud Detection","status":"completed","summary":"A locally built end-to-end machine learning platform for credit card fraud transaction detection using a Random Forest Classifier, covering data validation, experiment tracking, and CI/CD deployment.","cover_image_url":"https://vhouehibzzxyhwzakocl.supabase.co/storage/v1/object/public/images/uploads/1787830736489-zwn5yn.png","gallery_urls":null,"tags":["Python","Scikit-Learn","FastAPI","MLflow","Feast","Great Expectations","Docker","Pandas"],"links":{"repo":"https://github.com/iftekharalamfahim/fraud-credit-detection"},"started_at":"2026-08-22","created_at":"2026-08-27T11:39:19.447184+00:00","updated_at":"2026-09-04T02:46:12.487119+00:00","publish_status":"published","body_json":{"type":"doc","content":[{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"the problem","type":"text","marks":[{"type":"textStyle","attrs":{"color":"#e5a93c"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Credit card fraud detection in production rarely fails at the algorithmic level. It fails at the infrastructure level. Models degrade due to unseen data drift, APIs crash from malformed client inputs, and retraining loops lack proper experiment tracking. Furthermore, acquiring real-world financial datasets is exceptionally difficult due to strict privacy regulations and extreme class imbalance. The objective was to build a robust machine learning operations (MLOps) pipeline that addresses these deployment realities before a model ever reaches production.","type":"text"}]},{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"the solution","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I architected an end-to-end machine learning platform for credit card fraud detection. The system generates synthetic transaction data, engineers merchant-level aggregate features via a feature store, trains a baseline classifier, and serves predictions through a validated REST API. It includes continuous data drift monitoring and containerised deployment to simulate a complete enterprise MLOps lifecycle.","type":"text"}]},{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"Key Technical Decisions","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"heading","attrs":{"level":3,"textAlign":null},"content":[{"text":"Decision 1: Synthetic Data Generation vs. Real-World Datasets","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I considered using the standard Kaggle Credit Card Fraud dataset. I rejected it because its extreme imbalance (0.17% fraud) requires extensive algorithmic tuning that distracts from demonstrating MLOps infrastructure. I chose to generate 10,000 synthetic transactions with deliberate, distinct fraud patterns (higher amounts, late-night hours). This ensured the pipeline components could be validated quickly while proving the system could handle the data ingestion pipeline.","type":"text"}]},{"type":"heading","attrs":{"level":3,"textAlign":null},"content":[{"text":"Decision 2: Dual Serving Environments (Naive vs. Validated)","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I built both an unvalidated FastAPI endpoint and a strictly validated endpoint. The trade-off was maintaining two separate serving scripts, but this was necessary to demonstrably prove the failure modes of unvalidated inputs to stakeholders. It shows exactly how an API degrades when faced with out-of-bounds transaction amounts or missing merchant categories.","type":"text"}]},{"type":"heading","attrs":{"level":3,"textAlign":null},"content":[{"text":"Decision 3: Algorithm Selection","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I selected a Random Forest Classifier instead of a neural network. While deep learning might yield higher raw accuracy on complex data, Random Forest provides immediate feature importance metrics, requires significantly less compute for rapid CI/CD iteration, and is highly interpretable for financial compliance auditing.","type":"text"}]},{"type":"heading","attrs":{"level":3,"textAlign":null},"content":[{"text":"Decision 4: Automating the MLOps Lifecycle via CI/CD","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I implemented a GitHub Actions pipeline to automate the transition from code commit to containerised deployment. The trade-off was the initial time investment to configure the YAML workflows, but this was necessary to eliminate human error during deployment. The pipeline is configured to trigger on every pull request to run linting and unit tests, ensuring no broken data validation logic reaches the main branch. Upon merging to main, the workflow automatically builds the Docker image and prepares it for the serving environment. This ensures the ML platform is truly reproducible and continuously integrated.","type":"text"}]},{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"The Hardest Challenge","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"The most difficult technical hurdle was integrating Great Expectations for data validation alongside Feast for feature management. The batch validation scripts broke when Great Expectations updated to the 1.19.0 API. Additionally, the Feast feature store successfully computed aggregate metrics like ","type":"text"},{"text":"fraud_rate","type":"text","marks":[{"type":"code"}]},{"text":" and ","type":"text"},{"text":"transaction_count","type":"text","marks":[{"type":"code"}]},{"text":", but injecting these asynchronously computed features into the synchronous training pipeline caused data leakage risks.","type":"text"}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I solved this by decoupling the feature store from the immediate training loop. I implemented strict, transaction-level validation rules manually within the FastAPI serving layer to ensure immediate system stability. I left the Feast feature definitions materialised and ready, structuring the repository so the next iteration can wire the online store directly into the inference endpoint without refactoring the core architecture.","type":"text"}]},{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"Results","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"bulletList","content":[{"type":"listItem","content":[{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Containerised the entire MLOps pipeline using Docker for reproducible local deployment.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Achieved a baseline F1 score of 0.50 on the synthetic holdout dataset using the Random Forest classifier.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Successfully integrated MLflow for experiment tracking, automatically logging hyperparameters, train/test metrics, and feature importances directly to the Model Registry.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Deployed a ","type":"text"},{"text":"DriftMonitor","type":"text","marks":[{"type":"code"}]},{"text":" class capable of detecting statistical distribution shifts between the reference training data and incoming production traffic.","type":"text"}]}]},{"type":"listItem","content":[{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"Designed and implemented a continuous integration and continuous deployment (CI/CD) pipeline using GitHub Actions, reducing manual deployment steps to zero and ensuring automated test coverage on every commit.","type":"text"}]}]}]},{"type":"heading","attrs":{"level":2,"textAlign":null},"content":[{"text":"Retrospective","type":"text","marks":[{"type":"textStyle","attrs":{"color":"rgb(229, 169, 60)"}}]}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"If I were to rebuild this, I would fully integrate the Feast online store directly into the FastAPI ","type":"text"},{"text":"/predict","type":"text","marks":[{"type":"code"}]},{"text":" endpoint to serve real-time aggregate features, rather than keeping the feature store isolated in the offline training stage.","type":"text"}]},{"type":"paragraph","attrs":{"textAlign":null},"content":[{"text":"I would also update the Great Expectations integration to fully comply with the v1 API for automated batch validation. Finally, I would add rate limiting, TLS encryption, and authentication to the API and implement cost-sensitive learning to handle the extreme class imbalance inherent in real-world financial data.","type":"text"}]},{"type":"paragraph","attrs":{"textAlign":null}},{"type":"horizontalRule"},{"type":"paragraph","attrs":{"textAlign":null}}]},"body_html":"$1b","topic":"Machine Learning"}]}]

MORSETA

End-to-End MLOps Platform for Credit Card Fraud Detection