E-Mobility Fraud Detection

Overview

E-mobility subscription platforms face a specific fraud profile: abuse of charging credits, multi-account schemes, and anomalous usage patterns that differ from the payment fraud problems common in e-commerce. This project ran from initial exploration all the way through to a production microservice, with the product team treating it as their first hands-on experience with ML in production.

Problem Definition

The project started with a talented intern who led the initial data exploration, mapping out the shape of the transaction data and surfacing candidate fraud signals. Together, we worked with the client and their systems team to answer a harder question than “can we detect fraud”: which part of fraud could we concretely define, and which part of it did we have clean data for?

That scoping process was the most valuable phase of the project. It constrained the problem to a tractable subset of fraudulent behaviour, defined the labeling logic clearly enough to build a reliable training set from the existing database, and aligned all stakeholders on what the model would and would not do before any training had begun.

Model Development

With a clean problem definition and a reliable dataset in hand, we experimented with several classification architectures. We also ran Azure ML’s AutoML over the same data, which produced surprisingly competitive results in a fraction of the iteration time. It proved a genuinely useful tool for quickly testing whether a problem is learnable before committing to a specific modelling approach.

The winning model was a gradient-boosted classifier (scikit-learn). Because fraud rates were low, class weighting and threshold tuning were important to achieving useful precision at operational recall levels.

Deployment

Azure ML’s AutoML was fast for experimentation, but its model deployment and management tooling felt underbuilt for the team’s needs. Instead, I wrapped the trained scikit-learn model in a FastAPI service and packaged it as a Docker container. This gave the systems team a simple, self-contained artefact they could deploy, scale, and version on their own terms without any dependency on Azure ML’s runtime.

As the product team’s first ML project, it introduced them to the concept of an “Oracle” microservice: a stateless endpoint that accepts a request and returns a prediction. It also raised the right questions about statistical validation in production, such as how to detect when a deployed model starts to drift and what ground truth looks like when fraud labels arrive with a lag.

What I Learned

• Clear problem framing is worth more than any modelling choice: the project succeeded because we defined a tractable, well-labeled problem before touching a training loop
• AutoML is a practical feasibility tool. Running it early gave us a credible baseline quickly and helped justify continued investment
• Deployment tooling matters independently of modelling quality. A model the systems team can own and operate is worth more than a technically superior one they cannot
• Introducing a team to ML in production requires as much thought about process and expectations as about the technical artefacts