We trained a small model on a public mobile-money simulator so you can see how a scored review queue works. The data is fake. The method is what you would reuse on your data.
Synthetic data only. Nothing here is your production traffic, and nothing here is a promise about accuracy on a real wallet, bank, insurer, or logistics system. When we work with you, we rebuild and recheck the score on your data.
In this simulator, volume falls and the fraud rate gets noisier later on. So we train on earlier hours and test on later hours. That is closer to real life than shuffling the whole file.
On your data, the same idea applies: train on the past, check on what came next. If future weeks look different, a shuffled test can make a model look better than it is.
Before any fancy history features, a few basic fields already separate many fraud rows from genuine ones. In this simulator, fraud shows up in cash-out and transfer. Amounts and balances look different too.
That does not mean “large equals fraud.” It means your first model can often start with fields you already store, then grow as your labels and history improve.
One transform made the model look much stronger because many fraud rows in PaySim drain the whole balance. The model basically learned a yes/no flag from the simulator.
On your data, “moved most of the balance” can still matter. It is rarely that clean. We keep the useful idea and reject the easy win that only works because the fake data is too neat.
The demo workbench shows a review queue with scores, reasons, and a live score on synthetic events. You can confirm fraud or not fraud the way an analyst would.
That is the product shape: turn your data into a clearer next decision, keep people in control, and measure whether the score helps. Payments and fraud are one example. The same pattern fits claims, lending, logistics exceptions, and other repeated decisions.