A mobile banking app is now the bank’s main branch and its largest attack surface at the same time. Account takeover through SIM swaps and social engineering, malware that overlays fake screens on real apps, remote-access tools talked onto a customer’s phone by a fraudster, and authorised push payment scams over instant rails have all grown with digital adoption in the region. Regulators have responded with frameworks that go well beyond penetration tests, and customers have responded by switching banks after a bad experience.
This guide covers the threats that matter most in the Middle East today, what the main regulatory frameworks expect from a mobile channel, and the engineering checklist we apply when we build and audit banking apps.
Saudi Arabia: SAMA’s Cyber Security Framework
SAMA’s Cyber Security Framework, first issued in 2017 and updated since, is the baseline for every bank, insurer and financial company in the Kingdom. It covers governance, risk management, operations and third parties, and it is assessed through a maturity model that institutions report against. For mobile channels the relevant controls include secure development lifecycle, application security testing, strong authentication through Nafath, transaction signing, session management, device security checks, logging and fraud monitoring. SAMA has since added specific guidance on anti-fraud and on counter-fraud for payments, and it expects banks to act on behavioural indicators in real time rather than after the loss.
UAE and the wider Gulf: Information Assurance and anti-fraud
The Central Bank of the UAE’s Information Assurance Regulation and its Consumer Protection Regulation set equivalent expectations: secure design, multi-factor authentication, customer notification of every transaction, controls on new payees and limit changes, and a liability framework that pushes banks toward prevention. The Central Bank of Kuwait and the Central Bank of Oman have cyber security frameworks modelled on similar lines, and all four regulators run coordinated anti-fraud campaigns because the same scams move between their markets.
Threats that actually cause losses
Four patterns account for most mobile banking fraud in the region. Social engineering, where the customer is talked into approving a transaction or sharing a one-time code, often by a caller impersonating the bank or a government agency. SIM swap and number porting, which defeats SMS codes. Remote access and overlay malware on Android, which captures credentials or manipulates what the customer sees. And account opening with stolen or synthetic identities, which turns onboarding into the first line of defence. Notice that most of these defeat a technically secure app by going around it, which is why controls must cover the customer and the session, not only the code.
Authentication and session controls
Bind the app to the device at enrolment, using hardware-backed keys, and treat a new device as a high-risk event. Use the national digital identity (Nafath, UAE Pass) for enrolment and for step-up on high-risk actions, and move away from SMS codes wherever regulation allows. Sign transactions, not sessions: the customer should see and approve the beneficiary and amount on the device, with the approval cryptographically tied to those values. Enforce cooling-off periods on new payees and limit increases, and notify on another channel. Expire sessions aggressively and re-authenticate for sensitive views.
Device and runtime protection
Detect rooted or jailbroken devices, debuggers, emulators and hooking frameworks, and decide deliberately what the app does in each case. Detect screen-overlay and accessibility-service abuse on Android and block sensitive screens while an overlay or remote-access session is active. Protect the binary with obfuscation and integrity checks, pin certificates, and store nothing sensitive in local storage that is not encrypted with hardware-backed keys. These are standard in a modern runtime application self-protection layer; the mistake is to treat them as a vendor feature rather than part of the app’s threat model.
Real-time fraud monitoring
The regulatory direction everywhere is toward behavioural, real-time monitoring: how the customer types and navigates, whether a call is in progress during a transaction, whether the device is new, whether the beneficiary has been seen before, whether the amount and time fit the customer’s pattern. Models that score each session and each payment against those signals, and feed the score into the authentication policy, catch the social-engineering cases that rule engines miss. They also generate the evidence regulators now ask for after a loss.
Secure development and the supply chain
Most app vulnerabilities enter through third-party SDKs and rushed releases. A secure development lifecycle with threat modelling at design, static and dynamic testing in the pipeline, dependency scanning, secrets management, and independent penetration testing before each major release is what every framework expects. For banks that outsource mobile development, the regulators are explicit that accountability stays with the bank, so the partner’s pipeline, access controls and code ownership arrangements are part of the bank’s control environment.
How Eurisko builds and audits banking apps
Eurisko has built mobile banking apps for banks in Saudi Arabia, the UAE, Kuwait and Lebanon since 2009, under SAMA, CBUAE and CBK requirements, with device binding, transaction signing, runtime protection and fraud hooks built into our Eurisko DXP mobile layer. We also audit existing apps against the checklist above and the relevant framework. If your app is due for a security review, or you are planning a rebuild, our team can help.
