A regional retail bank came to us with a problem that will be familiar to most fraud and risk teams: their rules-based fraud engine was catching the fraud patterns of two years ago, and missing the ones happening now. False positives were blocking legitimate customers at a rate that was generating real complaint volume, while genuinely fraudulent transactions, particularly card-not-present fraud and rapid account takeover attempts, were slipping through in the gaps between static rules. Within two quarters of deploying a real-time machine learning fraud model, the bank had reduced confirmed fraud losses by 37 percent, while also cutting the false positive rate that had been frustrating legitimate customers.
This is the story of how that model was built, why the old rules-based approach could not keep pace, and what other institutions can take from the engagement.
Why rules-based fraud detection was falling behind
The bank's existing system worked the way most legacy fraud engines do: a large set of hand-written rules flagged transactions based on fixed thresholds, such as transaction amount, geography, or time of day. Rules are easy to explain to auditors and regulators, which is why they remain common in regulated banking environments. But they share a structural weakness: they can only catch fraud patterns that someone has already seen and encoded as a rule. Fraud rings adapt faster than rule libraries can be updated, and by the time a new rule is written and deployed, the pattern it targets has often already moved on.
The bank's risk team estimated that rule updates were taking, on average, three to four weeks from pattern identification to production deployment. In that window, a coordinated fraud ring could extract significant losses before the gap closed. At the same time, overly broad rules aimed at catching a fast-moving pattern were blocking a wide swath of legitimate transactions, driving customer complaints and increasing the manual review workload on an already stretched fraud operations team.
Designing a model that fits real-time banking constraints
The engagement began with a data and infrastructure assessment rather than a model-building exercise. Fraud models are only as good as the transaction, device, and behavioural data feeding them, and the bank's existing data pipeline was not built for the millisecond-level latency that real-time scoring demands. Before any model work started, we redesigned the streaming data pipeline so that transaction, device fingerprint, and behavioural signals could be assembled and scored within the transaction authorisation window, without adding noticeable latency at the point of sale or in the mobile app.
With the pipeline in place, we built a supervised machine learning model trained on the bank's historical transaction data, labelled fraud outcomes, and device and behavioural signals. Rather than replacing the existing rules engine outright, the model was deployed alongside it in a hybrid architecture: rules continued to handle clear-cut, high-confidence cases that regulators expect to see explicitly documented, while the machine learning model scored every transaction for anomaly risk and flagged the harder, more ambiguous cases that rules alone had been missing.
Three design choices that made the difference
- Hybrid, not replacement. Keeping the rules engine for explainable, high-confidence cases satisfied audit and regulatory requirements, while the model handled the nuanced, adaptive detection rules cannot.
- Feedback loop into retraining. Confirmed fraud and confirmed false positives were fed back into the model on a scheduled retraining cycle, so the model's understanding of fraud patterns kept pace with how fraud actually evolved.
- Explainability layer. Every model flag came with a set of contributing factors the fraud analyst could review, so the system supported human decision-making rather than operating as an unauditable black box.
Results after two quarters in production
The impact showed up in three places: fraud losses, false positive rate, and analyst workload. Confirmed fraud losses fell by 37 percent compared to the same period the prior year. At the same time, the false positive rate, transactions blocked or flagged that turned out to be legitimate, dropped by roughly a quarter, which reduced both customer complaints and the manual review backlog that had been building up in the fraud operations team.
Just as important as the headline numbers was the operational shift inside the fraud team. Analysts moved from reactively chasing customer complaints and manually tuning rule thresholds to reviewing a smaller, higher-quality queue of model-flagged cases with clear contributing factors attached. That shift freed up capacity for the team to focus on investigating organised fraud rings rather than triaging individual false positives.
What other institutions should take from this
The lesson is not simply "add machine learning to fraud detection." It is that the data infrastructure and the governance model matter as much as the algorithm itself. A fraud model built on a slow, batch-oriented data pipeline will not perform in a real-time authorisation context, regardless of how sophisticated the model is. And a model deployed without an explainability layer will struggle to earn the trust of fraud analysts, auditors, and regulators, all of whom need to understand why a transaction was flagged.
Institutions considering this path should start with an honest assessment of their transaction data pipeline and their existing fraud rules, before committing to a specific modelling approach. In our experience, the hybrid model, rules for explainable certainty, machine learning for adaptive detection, is the pattern most likely to satisfy both risk reduction goals and regulatory expectations in African banking markets today.
