Problem
A freelance gift-card client was losing money to fraudulent transactions and needed a more systematic way to catch it than manual review could provide.
A freelance gift-card client was losing money to fraudulent transactions and needed a more systematic way to catch it than manual review could provide.
We had access to user information, transaction records, and a set of transactions the client had already identified as fraudulent — a labeled dataset that made a trained model a realistic option rather than a purely rules-based approach.
The team identified a suitable model, trained it against the labeled fraud cases, and deployed it into production. My own role centered on data prep — preparing and querying the underlying transaction and user data in SQL so the model had clean, relevant signal to train and run on.
SQL for the data prep work I focused on, and Python for the team's model building, training, and deployment.
The most important work wasn't the modeling itself — it was understanding who the platform's actual average user was, which turned out to be different from our initial assumption. Getting that picture right, largely through the data prep work, shaped which signals the model could actually rely on.
The model reduced fraud during its test period by tens of percent.
Understanding the client's needs and who the real end user actually is matters as much as the modeling technique — the average user is often not who you initially assume, and that gap is where a model either works or doesn't.