In most banks, more than ninety percent of the alerts generated by anti-money-laundering transaction monitoring turn out to be nothing. Analysts spend their days closing alerts on salary payments that crossed a threshold and remittances that matched a country rule, while the patterns that matter, structured deposits across accounts, mule networks, trade-based laundering, are spread thinly enough across rules that no single alert fires. The cost is measured in headcount, in regulatory findings about backlog, and in the laundering that gets through.
Machine learning does not replace the rules a regulator expects to see. It changes what the compliance team spends its time on. This guide explains how, what regulators in the Gulf and the Levant accept, and what a bank needs in place to deploy it.
Why rules alone fail
Rules are thresholds and typologies written down: cash deposits above an amount, transfers to high-risk jurisdictions, rapid movement of funds. They are transparent, which regulators like, and static, which launderers like more. Each rule is tuned in isolation, so the overall alert volume is the sum of many individually reasonable decisions. Rules see one transaction or one account at a time, so behaviour that is only suspicious in aggregate, across accounts, counterparties and time, is invisible. And every rule generates false positives in proportion to how many legitimate customers resemble the typology, which in a market with large expatriate remittance flows is a lot.
What machine learning adds
Alert prioritisation is the first and least controversial use: a model trained on the outcomes of past alerts scores each new alert by its likelihood of being escalated to a suspicious activity report, so analysts work the highest-risk cases first and the lowest-risk tail can be closed with lighter review or auto-closed under a documented policy. Banks typically see the volume analysts must fully investigate fall by half or more with no loss of true positives.
Behavioural anomaly detection is the second: models that learn each customer’s and each segment’s normal pattern and flag deviations the rules were not written for. Network analytics is the third: graph methods that find clusters of accounts linked by transfers, devices, addresses or beneficiaries, which is how mule networks and layering schemes are actually structured. Entity resolution underpins all of it, because the same person or company appears under slight name and identifier variations across systems.
Deploying it in a way regulators accept
Regulators in Saudi Arabia, the UAE, Kuwait, Oman and Lebanon all follow the Financial Action Task Force standards and all accept technology that improves effectiveness, provided the bank can explain and evidence it. The accepted pattern is to run models alongside rules rather than instead of them. Rules remain the regulatory baseline and the floor on coverage. Models prioritise what the rules produce, add alerts the rules miss, and are validated against the same outcomes. Every model decision is explainable at the alert level: which features drove the score, in language an analyst and an examiner can follow. Thresholds and auto-closure policies are documented, approved by the money-laundering reporting officer and tested before and after launch.
Validation is the part most often underestimated. A model trained on past alert outcomes learns the past analysts’ decisions, including their mistakes, so the training set needs review, the model needs testing on known cases and red-team scenarios, and performance needs monitoring for drift as customer behaviour and laundering methods change.
Data and operating model
The models are only as good as the data: complete transaction histories across products and channels, customer and KYC data, counterparty information, device and session data from digital channels, and the alert and case history with outcomes. Most banks find that building a unified financial-crime data layer is the majority of the work, and that it pays off across fraud, AML and sanctions screening together.
The operating model changes too. Analysts move from clearing queues to investigating prioritised cases and giving feedback that improves the models. A model owner in compliance, a validation function in risk and a data and engineering team in technology each have defined roles. And the system runs inside the bank’s data boundary, which the residency rules in most of the region require in any case.
Real-time rails raise the stakes
Instant payments and open banking move the problem from overnight to real time. Mule accounts are funded and emptied within minutes, and the bank that receives the money has seconds to act. That pushes AML and fraud closer together: the same behavioural features and network signals that detect laundering after the fact can score a payment before it settles. Banks that have built the unified data layer and the model infrastructure for AML are the ones able to extend it to real-time payment screening without starting over.
How Eurisko helps
Eurisko builds financial-crime data platforms and machine learning systems for banks in the Gulf and Lebanon: alert prioritisation, behavioural and network detection, explainability at the alert level, validation and monitoring, integrated with existing rule engines and case management and deployed inside the bank. If your compliance team is drowning in alerts, our AI team can show you what your own alert history would support.
