Payment Risk
Workbench.

The decision behind the prediction

Approving a legitimate payment earns a small margin. Approving a fraudulent one can lose the full transaction amount. Declining a payment avoids that loss, but also gives up any legitimate revenue. The useful question is how to balance those outcomes.

This project connects fraud-risk modeling to an explicit approval policy. The demo starts with a 0.3% margin on legitimate payments, a 100% loss on fraud, and zero return for declined payments. You can change the assumptions and see how the decision threshold and modeled profit respond.

From exploration to a working service

I used a public credit-card dataset with 284,807 transactions and 492 fraud cases. Identical transaction patterns stay together across the training, model-selection, calibration, and evaluation splits, reducing leakage from repeated records.

The workflow covers exploratory analysis, feature engineering, model comparison, experiment tracking, explanations, and an API. Logistic regression, Random Forest, and LightGBM provide different starting points; the deployed LightGBM candidate comes from the low-margin development comparison.

Ranking performance, score calibration, and economic outcomes answer different questions. I keep them separate so that a good fraud-ranking metric does not become an unsupported claim about profit.

Explore the trade-offs

The transaction explorer lets you search and filter payments, inspect model scores, and view TreeSHAP contributions for an individual prediction. The policy lab changes the economics, plots modeled profit across score cutoffs, and lets you export the resulting decisions.

The application is a small FastAPI service with a plain HTML, CSS, and JavaScript interface. Docker packages the model and service together; GitHub Actions checks the build, and Render hosts the live demo.

What the demo can show

The explorer uses 200 curated development examples with extra fraud cases to make the trade-offs visible. Its totals illustrate those examples, rather than estimating population fraud rates or real business impact. The deployed model is a development candidate with uncalibrated scores, and the low-margin policy has not had an independent final holdout evaluation.

The public dataset’s anonymized features also limit interpretation: model contributions explain which inputs moved a score, without identifying the underlying customer or merchant behavior.

The live demo runs on a free instance and may take about a minute to wake after inactivity.