Every KSA bank that issues Mada cards has a fraud detection system. Most of them are rule engines: if the transaction amount exceeds X, if the merchant category is Y, if the velocity in the last hour exceeds Z — flag it. These rules were written by fraud analysts, tuned over years, and they work reasonably well for the fraud patterns that existed when they were written.
The problem is not that rule engines are wrong. The problem is that fraud patterns evolve faster than rule engines are updated. The team that writes the rules is a specialist fraud operations function, not an agile engineering team. New rules go through a change advisory board. By the time a new card-not-present pattern is documented, escalated, translated into a rule, tested, and released, the fraud ring has already moved on. The gap between pattern emergence and rule deployment is weeks to months. Real-time machine learning on the stream closes that gap to days — but only if the leadership decisions that surround it are made clearly before the engineering team builds anything.
The decision that looks technical but isn’t
The most consequential decision in a real-time fraud detection programme is not which stream processing engine to use or which ML framework to deploy. It is: who sets the score threshold?
A gradient-boosted model outputs a probability between 0 and 1. The engineering team can build everything — the feature pipeline, the Flink job, the ONNX-embedded scorer, the Kafka sink to the authorisation gateway — and still be blocked at go-live because nobody has decided what probability of fraud is high enough to decline a transaction automatically. That threshold is not a technical constant. It is a business decision about the trade-off between fraud losses and customer friction, expressed as a number between 0 and 1.
At 0.90 threshold, the bank declines very few transactions and misses some fraud. At 0.65 threshold, the bank catches more fraud and incorrectly declines more legitimate transactions. Each wrongly declined Mada transaction generates a customer complaint that SAMA classifies and tracks. The threshold that maximises fraud prevention may not be the threshold that minimises SAMA complaints. That tension cannot be resolved by the engineering team. It is resolved by the Chief Risk Officer and the Head of Retail Banking jointly, with input from the fraud operations team and the customer experience function.
What SAMA expects and where it looks
SAMA’s Cyber Security Framework and the Payment Fraud Management Guidelines set expectations for fraud detection capability. What SAMA actually examines during a payments review is not the architecture document. It is the evidence of a functioning control: the false-positive rate on card declines, the mean time to detect a confirmed fraud pattern, and the process by which the fraud detection model is updated when performance degrades.
A bank that can show a documented model governance process — who approved the current threshold, when it was last reviewed, what triggered the last change, what the metrics were before and after — is in a defensible position regardless of whether it uses a rule engine or a gradient-boosted model. A bank that has deployed a technically sophisticated ML pipeline but has no documented governance around the model’s threshold and retraining cycle has built something it cannot defend to an examiner.
The feature ownership problem
A real-time fraud model is only as good as its features. The most predictive features in card fraud are velocity-based: how many transactions in the last minute, last five minutes, last hour, across how many distinct merchants, across how many distinct geographies. These are not hard to compute — the engineering challenge is manageable — but they require access to real-time transaction data that sits in systems owned by different teams.
The card authorisation system is typically owned by the card processing team. The IPS payment gateway is owned by the payments engineering team. The customer master — which holds the account history and risk profile that enriches the velocity features — is owned by the core banking team. A fraud detection pipeline that joins these streams in real time crosses three organisational boundaries. Without explicit feature ownership agreements — which team is responsible for ensuring the card-auth Kafka topic has the right schema, at the right latency, with the right throughput guarantee — the fraud pipeline degrades silently when any of those upstream systems changes.
This is a governance problem, not a technology problem. The technology to consume and join those streams exists. The question is whether the teams that own the source systems have a contractual obligation to the fraud pipeline team to maintain compatibility, to notify ahead of schema changes, and to include the fraud pipeline in their impact assessments. Without that obligation, explicitly agreed at VP level and documented in the integration governance framework, the fraud team is building on sand.
The feedback loop is not optional
A fraud model that cannot retrain is a model that decays. The empirical evidence across card fraud programmes at KSA and GCC banks is consistent: a gradient-boosted model trained on historical data loses 5–10% of its precision at a fixed recall threshold within three months of deployment if it is not retrained. Fraud patterns shift. New merchant categories emerge. New attack vectors appear. The model that worked at go-live will be materially worse by the end of the quarter unless it is continuously fed new labels.
Labels come from one source: resolved disputes. When a customer disputes a transaction and the dispute is resolved as confirmed fraud, that transaction becomes a training example. When the dispute is resolved as customer error (legitimate transaction, disputed in error), that becomes a negative example. Both are valuable. Neither reaches the data science team automatically unless the chargeback and dispute management system is wired to emit structured events that the feedback pipeline can consume.
Most banks have not wired this. The dispute management system is a legacy CRM with no API. Dispute outcomes are recorded by analysts in a web form. The data science team extracts it quarterly in a manual export. By the time it enters the training dataset the fraud patterns it describes are three months old. The retraining cycle is effectively annual. This is the norm, not the exception — and it is fixable with a relatively modest integration project, not a platform transformation.
What the team needs from leadership to ship it
Three decisions that cannot be delegated below VP level:
Who sets and governs the model threshold? The Risk function and the Retail Banking function must agree on a joint governance process: a threshold review cadence (quarterly at minimum), the metrics that trigger an out-of-cycle review (false-positive rate above X%, missed fraud rate above Y%), and the authority to make changes on an expedited basis when fraud losses spike. Without this process, the threshold set at go-live becomes a permanent fixture that nobody feels authorised to change.
Which teams are obligated data providers? The card processing team, the IPS payments team, and the core banking team need explicit SLAs for the data streams they feed to the fraud pipeline. Latency, schema stability, throughput, and change notification lead times. These SLAs should be in the integration governance framework, not in a separate fraud programme document that gets lost when the programme team rolls off.
Who owns the feedback pipeline and funds it? The dispute management integration is not a large project — three to six months for a team of four — but it is not glamorous, it does not appear on any fraud dashboard, and it does not show up in the fraud rate until six months after it is deployed (because the training cycle needs time to incorporate the labels). It is the easiest work to cut when the programme is under budget pressure, and the hardest to justify reinstating after the model has decayed. The decision to fund it needs to be made at programme initiation, not deferred until the model performance graph starts trending down.
For the engineering depth behind this topic — Feast feature store design, Flink KeyedProcessFunction for velocity aggregation, embedded ONNX scoring, exactly-once Kafka sink configuration, and the point-in-time join pattern that prevents training-serving skew — see the companion Lab article: Data Streaming: Real-Time Fraud Detection Pipeline.