Fraud Detection in 20 Hours: One Focused Workflow
20 continuous hours, 191 competitors, ranked 6th. The advantage did not come from trying more models — it came from deciding what the data had to contain before modelling it.
TL;DR: Under a hard deadline, the first hours are better spent framing the problem than tuning a model. Understanding what normal behaviour looks like, how imbalanced the target is, and which behavioural features can carry signal produces a baseline you can validate and submit. Feature engineering is not just a modelling step; it is often the fastest route to a useful baseline — and complexity only earns its place when there is time to evaluate it.
The Problem
A fraud-detection hackathon gave us 20 continuous hours and 191 competitors. The constraint was not knowledge; it was time. There was no room for endless experimentation, no room for model tourism, and no room to build a complex system that could not be validated or submitted reliably before the deadline.
That constraint changes the strategy. In a short competition the failure mode is rarely "the model was too simple". It is running out of hours with nothing submitted, or submitting something whose validation you do not trust.
The Approach
Instead of asking what the most advanced model was, I asked where the fraud signal was likely to appear, what normal customer behaviour looked like, how imbalanced the target was, which features could represent suspicious behaviour quickly, what validation was realistic enough to trust, and which single model could become a stable baseline. The first hours went to problem framing, not tuning.
Understand the data before modelling it
Target balance, consumption patterns and payment behaviour came first. Knowing what normal looks like is what makes an anomaly legible — and it tells you whether accuracy is a meaningful metric at all.
Turn domain understanding into behavioural features
Features described behaviour rather than identity: changes in consumption, irregular payment patterns, and deviations from a customer's own history. These were fast to build and easy to explain.
Stabilise one strong gradient-boosting baseline
One well-understood model, trained on a realistic split, beat a pile of half-evaluated candidates. It gave a submission I could trust and a reference point for any later change.
Match validation to the imbalance
With a rare target, the validation design matters more than the model card. I kept the split realistic for the task, looked at ranking and recall-oriented behaviour rather than raw accuracy, and refused changes I could not evaluate in time.
Set the operating threshold, then protect the submission
The competition metric rewarded a particular trade-off, so the threshold was a decision, not a default. After that, the submission workflow stayed stable — no last-minute restructuring of something that already worked.
What I deliberately did not do was equally important: exhaustive hyperparameter search, complex stacking, and unstable last-minute changes. Those approaches are not wrong in general. They simply do not fit a deadline that leaves no time to evaluate, debug or maintain them.
Outcome
The submission ranked 6th out of 191 competitors in the 20-hour sprint. More useful than the placement was the confirmation of a pattern: under time pressure, clarity outperforms complexity. A complicated ensemble can be the right answer when there is time to evaluate and maintain it; in a constrained setting, the biggest early advantage usually comes from understanding the data and turning that understanding into useful features.
Since then I have used the same order on deadline work: frame the problem, inspect the target and the behaviour behind it, build a small number of explainable features, stabilise one baseline, and only then spend remaining time on model variants. The first hours are for framing, not tuning.
Key Takeaway
Design insight: Under a hard deadline, the first hours are better spent framing the problem than tuning a model. Understanding what normal behaviour looks like, how imbalanced the target is, and which behavioural features can carry signal produces a baseline you can validate and submit. Feature engineering is not just a modelling step; it is often the fastest route to a useful baseline — and complexity only earns its place when there is time to evaluate it.
Related
Better Features Beat More Model Shopping → Categorical to Behavioural Signal → SMOTE Is Not the Default Answer to Class Imbalance → Focal Loss for Imbalanced Classification → Start With a SQL Baseline → GBDTs Are Not Dead: Strong Baselines → Speed Buys Iterations → ML Competition Workflow Then vs Now → Steg Fraud Detection: Zindi Competition →