Every closed-loop payment network has a fraud vector that its designers didn't plan for, and it's rarely a clever one. In fleet fuel, the shape is simple: a wallet approves an amount, a pump dispenses something, and a person stands between the two with an incentive for those numbers not to match.
I own the wallet at Octane — the ledger and transaction engine behind Egypt's largest fleet-payment network, 1,600+ corporate fleets fueling at 2,400+ stations. This is the story of how we cut fraud by 82%, and why the fix was not the machine-learning model everyone assumed it would be.
What fraud looked like
The network already had the strong controls: NFC vehicle identification, so a transaction is tied to a specific vehicle, and real-time spend controls, so a fleet manager can cap what a driver can spend and when. Those stop the obvious cases.
What they don't stop is the gap between the wallet and the nozzle. The wallet did exactly what it was told. The problem was that what it was told was not what happened at the pump.
We saw it the way most fintechs see fraud first: in reconciliation — numbers that should have agreed, and didn't.
Why detection kept losing
The instinctive answer was a detection model: score every transaction on history, flag the outliers, let an ops team review. We looked at it seriously, and it fails for a reason that has nothing to do with model quality.
Detection runs after the money has moved. By the time a transaction scores badly, the fuel is in a tank and the wallet has been debited. Every flagged case becomes a dispute — a fleet manager, a station, a driver and a customer-support agent arguing about something none of them can see any more. Even a perfect model would only have made us better at arguing.
The other problem is the data. A model is only as good as the signal it gets, and the one signal that would have settled every dispute — what the pump actually showed — wasn't in the system at all.
Moving verification to before the charge
So instead of scoring transactions, we changed what a transaction is.
We added a live OCR step to the fueling flow. The signal that was never in the system — what the pump actually shows — is captured at the pump and read in real time, and the reading is checked against the transaction before the wallet is charged. If the numbers don't match, the wallet isn't debited. There is nothing to dispute later, because the transaction never completes.
Two design decisions mattered more than the OCR itself:
- The check is synchronous. It sits on the hot path, before the debit, which means it has a latency budget — one we measured and could afford. A verification step that people learn to bypass because it's slow is worse than none.
- It fails closed, with a human path. When a reading can't be trusted, the charge doesn't happen and a person steps in. The important part is that "we're not sure" never becomes "charge it anyway".
What changed
Fraud dropped by 82%. The reconciliation breaks that used to take a week of back-and-forth mostly stopped appearing, because the transactions that caused them stopped completing.
The second-order effect surprised me more than the number. Once verification was in the flow, the wallet's own data got better: every transaction now carries a verified reading, which made the spend-control rules and the fleet analytics more trustworthy too.
What I'd tell another payments team
- Put verification where the money moves, not where the reports are read. A control that runs before the debit removes disputes; a control that runs after creates them.
- Find the signal that ends the argument. Ask what a fleet manager and a station would both accept as proof, and build the system that captures it.
- Respect the hot path. Any check before the charge needs a latency budget and a fail-closed rule that people can live with at 6 a.m. at a pump.
- Keep the model idea for later. Once the flow is honest, a model has something real to learn from. Before that, it's a better way to be wrong.
The ledger and the orchestration behind all of this — Formance for postings, Temporal for the fueling workflow with retries and compensation — deserve their own post. That one's next.
Muhammad Alnaqeeb is a senior software engineer in Cairo. He works on wallets, ledgers and fraud controls, most recently at Octane. Reach him at [email protected].
← More writing