The short answer: SAMA's Counter-Fraud Framework expects every regulated financial institution to run a fraud detection system that monitors transactions and behaviour around the clock, and for higher-risk areas it explicitly lists artificial intelligence and machine-learning models among the capabilities to add on top of rules. A workable design scores each payment in real time, blocks only the clearest fraud, routes a grey zone to analysts with an explanation of why each case was flagged, and feeds every analyst decision back into the model. Judge the result on false positives as well as caught fraud, because every legitimate payment you block costs a customer's trust.
Digital banking transactions in Saudi Arabia have surged with the adoption of Mada, Apple Pay, STC Pay and instant bank transfers. SAMA's instant payment system, sarie, launched in 2021 and processes low-value transfers of up to SAR 20,000 instantly, 24/7, including to recipients identified only by a mobile number or national ID. With this growth comes a proportional increase in fraud attempts, from card-not-present fraud to account takeover attacks, and less time to stop a payment before the money moves.
The false positive problem
Traditional rule-based fraud detection systems are blunt instruments: to catch more fraud, teams tighten the rules, and every tightened rule also flags more legitimate purchases by real customers. Each false positive means a blocked transaction, a frustrated customer, and a manual review by the fraud team. At scale, this creates enormous operational costs and customer churn.
What SAMA's Counter-Fraud Framework expects
Two Saudi Central Bank (SAMA) frameworks shape how fraud detection is built in Saudi financial institutions. The SAMA Counter-Fraud Framework sets the controls regulated institutions must implement and expects them to operate at maturity level 3 or higher, a level that requires a fraud detection capability to prevent and proactively detect fraud; automated real-time monitoring of control effectiveness is described only at the highest maturity level (5). The SAMA Cyber Security Framework, which applies to banks, insurance companies and financing companies, governs the security of the systems that run those controls. For an AI-based detection engine, that translates into practical design requirements: decisions an analyst can explain (no pure black-box models), complete audit trails of all flagged and cleared transactions, regular model retraining on updated fraud patterns, human oversight for high-value transaction blocks, and data kept within the Kingdom wherever regulation requires it.
The Counter-Fraud Framework is organised into four domains (Governance, Prevent, Detect and Respond) and is principle-based. Institutions assess themselves against it periodically, SAMA reviews and audits those self-assessments, and a control that cannot be implemented needs compensating controls and a formal waiver request to SAMA.
Its section on fraud detection systems is the most specific guidance for anyone building or buying a detection engine:
| SAMA control requirement | What it means for the system |
|---|---|
| Detection systems operate 24/7 with resources to handle their output | Scoring and case queues must never pause, including overnight and on weekends |
| Data from all products, all channels, external lists and non-transactional activity such as device usage and geo-location | One feature pipeline across cards, transfers, online and mobile banking |
| Payment data should be real-time to allow intervention before funds are transferred | Score inside the authorisation path, not in an overnight batch |
| Baselined behaviour profiles, a rules library, customer segmentation and weighted risk scores | Rules and models work together; thresholds differ by segment |
| Alerts linked to a case management system | Every flag becomes a tracked case with an outcome |
| Where fraud risk is higher, AI and machine learning (for example decision trees, random forests and neural networks) plus network and link analytics | The explicit basis for ML models and fraud-ring detection |
| Precision and recall testing, feedback loops on false positives and negatives, documented rule changes, reporting of the false positive rate | Model governance is part of compliance, not an optional extra |
The framework's section on monitoring to detect fraud also asks institutions to cover first-party fraud (customers misrepresenting themselves), second-party fraud (people knowingly lending their identity or account) and third-party fraud (criminals using stolen customer details). Each needs different signals, so test the model against all three.
How AI changes the game
Machine learning models analyse hundreds of features per transaction in milliseconds. These features include transaction amount relative to customer history, merchant category and location, device fingerprint and IP geolocation, time of day and day of week patterns, velocity checks across multiple time windows, and behavioural biometrics such as typing patterns and swipe behaviour. Graph features add another layer: accounts that share a device, a beneficiary or an IP address with known fraud cases score higher, which is how mule networks surface.
Data protection and explainability
The Personal Data Protection Law treats biometric data used to identify a person as sensitive data, so behavioural biometrics need a clear legal basis and careful minimisation. Its Implementing Regulation requires the controller to notify the regulator within 72 hours of becoming aware of a personal data breach that could cause harm. SDAIA's AI Ethics Principles add that automated decisions, particularly those that may harm the people affected, should be traceable and explainable. For a fraud engine that means reason codes on every score, such as "new device plus new beneficiary plus amount well above this customer's usual range", which analysts can read and complaints teams can relay to customers.
Implementation architecture
The recommended architecture processes transactions in real time through a scoring engine that sits in the authorisation path. Transactions scoring above a threshold are blocked automatically or sent for step-up authentication; SAMA's framework itself names further authentication of the user as one response to behaviour that deviates from the baseline. Transactions in a grey zone are routed to a human analyst with AI-generated explanations. The system continuously learns from analyst decisions, improving over time.
- Rules and models together. Keep hard rules for known typologies and regulatory blocks, and let the model rank everything else.
- Champion and challenger. Run a new model in shadow mode beside the live one and promote it only when it beats the incumbent on your own data.
- Case management first. Analysts need one screen with the score, the reason codes, the customer's history and a one-click outcome that feeds the next training run.
- Tamper-evident change log. Record every threshold and rule change with the reason, as the framework requires.
How to evaluate a fraud detection platform
- Latency: can it score within your authorisation time budget at peak volume?
- Labels: chargebacks and confirmed fraud cases can arrive weeks after the transaction, so check how the vendor handles delayed and missing labels.
- Metrics: ask for precision, recall and false-positive rate on your own historical data, not a vendor benchmark.
- Explainability: every score should come with reasons an analyst can act on.
- Drift: fraud patterns change quickly, so confirm how drift is detected and how often models are retrained.
- Data residency: confirm where data and models are hosted and how that maps to your regulatory obligations.
What the evidence shows
Most published results come from vendors, so read them as indicators rather than guarantees. Mastercard reported in 2024 that initial modelling of generative-AI enhancements to its Decision Intelligence scoring boosted fraud detection rates by 20% on average, and that its own analysis showed false positives falling by more than 85%. Results inside a Saudi bank depend on data quality, the current rule set and how the grey-zone review queue is staffed, so we baseline your false-positive rate, detection rate and manual review workload before go-live and report against that baseline.
How Mantiqi can help
Mantiqi designs and builds AI fraud detection for Saudi financial institutions and fintechs: our AI and intelligent automation team develops the scoring models and reason codes, our data analytics team builds the feature pipelines and the false-positive dashboards, and our payment solutions team connects scoring to your payment flows. See the wider banking and fintech picture, read our guides to Saudi payment gateway integration and AI agents in Saudi business, or contact us to discuss your fraud prevention strategy.