SAMA rules for the mobile banking app your customers use.
The Saudi Central Bank asks banks for an annual review and penetration test of customer and internet-facing services, security testing of every change, multi-factor authentication on every e-banking service, and mobile apps that detect rooted and jailbroken devices. Ostorlab helps you test those controls in your app and its APIs, on every release.
- Penetration testing by AI agents behind login, with a replayable exploit for each AI-agent finding
- Static and dynamic testing of the build you ship, with no source code needed
- MFA, lockout and step-up flows tested with your test accounts
- Root and jailbreak detection tested in rooted and jailbroken environments
- Who it applies to
- Banks operating in Saudi Arabia, and other SAMA-regulated financial institutions
- Key dates
- Cyber Security Framework issued 24 May 2017, full compliance due by the end of October 2018
- Focus
- Yearly penetration tests of internet-facing services, MFA and fraud controls in digital channels
- Reference
- SAMA Cyber Security Framework, Counter-Fraud Framework, IT Governance Framework, FEER
SAMA's cyber and fraud rules, date by date
The SAMA frameworks are in force today. These are the dates and cadences your app testing is measured against.
- 24 May 2017
Cyber Security Framework
SAMA issues the framework. All domains apply to banks, including application security and electronic banking services.
- End of October 2018
Full compliance for banks
The deadline SAMA set for banks to fully comply with the Cyber Security Framework.
- 13 May 2019
FEER red teaming framework
Threat intelligence based red teaming of live production environments, at least once every three years.
- 4 November 2021
IT Governance Framework
Rules for system development, secure code review and testing of every change before production.
- 11 October 2022
Counter-Fraud Framework
Risk-based authentication, fraud prevention standards and mobile app controls such as root and jailbreak detection.
- Every year
Review and penetration test
Customer and internet-facing services are subject to an annual review and penetration test, with follow-up until issues are addressed.
SAMA's cyber and fraud rules, applied to your mobile app
SAMA's frameworks set principles and control considerations for banks. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- SAMA Cyber Security Framework, 3.2.4
Pentest customer and internet-facing services every year
What the text says
The cyber security status of information assets must be reviewed periodically. Customer and internet-facing services should be subject to annual review and penetration tests. The results, issues and recommended actions are recorded, reported to the business owner and followed up until all identified issues are addressed.
What it means for your mobile app
A mobile banking app and the APIs it calls are customer and internet-facing services. They need at least a yearly review and penetration test, and a record that every issue found was closed.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, typically in a few hours, with a working exploit you can replay for each AI-agent finding. Findings are tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
The annual review itself, the choice of testers and the report to the business owner.
- SAMA Cyber Security Framework, 3.3.7; IT Governance Framework, 3.4.4 and 3.4.5
Security-test every change before it goes live
What the text says
Change management must include security testing which, if applicable, covers penetration testing and code review, or a code review report or equivalent, such as an independent assurance statement, when the source code cannot be provided. The IT Governance Framework adds that all changes are tested in a separate test environment, with security testing among the minimum test types.
Source:SAMA Cyber Security Framework, 3.3.7; IT Governance Framework, 3.4.4 and 3.4.5
What it means for your mobile app
Each new release of the app is a change. It should pass security testing before it reaches the store, including third-party code you do not have the source for.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. Both run from your CI/CD pipeline on every build.
What stays with you
Change Advisory Board approval, user acceptance testing and deciding what counts as an equivalent assurance statement.
- SAMA Cyber Security Framework, 3.3.6
Set and test an application security standard
What the text says
Define, approve and implement cyber security standards for applications, monitor compliance and periodically evaluate their effectiveness. Development follows an approved secure SDLC, and the standard covers secure coding, identity and access management, protection of customer data against unauthorized access and leakage, and vulnerability and patch management.
What it means for your mobile app
Your secure coding and data protection rules for the app need evidence that they hold in the build you ship, not only in a policy.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, finds API keys, tokens and credentials in the app package, and lists the SDKs and native libraries in each release with their versions.
What stays with you
Writing the standard, the SDLC methodology and segregation of duties.
- SAMA Cyber Security Framework, 3.3.17; Circular No. 381000091275
Run vulnerability management at a set cadence
What the text says
Define and implement a vulnerability management process for application and infrastructure vulnerabilities. It covers all information assets, a risk-based scan frequency, classification of vulnerabilities, defined timelines to mitigate per classification, and patch management. A later SAMA circular asked banks for a roadmap to reach Maturity Level 4 in vulnerability management by the end of Q3 2022.
Source:SAMA Cyber Security Framework, 3.3.17; Circular No. 381000091275
What it means for your mobile app
Findings in the app and its libraries need a classification, a deadline and proof of closure, on a cadence you can defend.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Findings are rated critical, high, medium or low and retested once the fix ships. SCA fingerprints statically compiled libraries that manifest-based scanners can miss.
What stays with you
Setting mitigation timelines and scanning the rest of your estate.
- SAMA Cyber Security Framework, 3.3.13
Harden online and mobile banking channels
What the text says
The electronic banking services security standard covers, for online and mobile banking, use of official application stores and websites, detection and take-down of malicious apps and websites, sandboxing, non-caching techniques, and communication techniques to avoid man-in-the-middle attacks. SAMA approval is needed before launching a new electronic banking service.
What it means for your mobile app
The app should not leave sensitive data in caches, and its traffic should resist interception, even on a device the attacker controls.
How Ostorlab helps
Ostorlab checks what the app writes to storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections. Mobile Shielding Scan attempts bypasses of TLS pinning and shows which protections held.
What stays with you
Brand protection, take-down of malicious apps and websites, and SAMA approval for new services.
- SAMA Cyber Security Framework, 3.3.13
Multi-factor authentication on every e-banking service
What the text says
Use multi-factor authentication during customer registration and for all electronic banking services, including sign-on, adding or modifying beneficiaries, adding utility and government payment services, high-risk transactions above predefined limits and password reset. Revoke customer access after 3 successive incorrect passwords or invalid PINs.
What it means for your mobile app
Every one of these flows must demand the second factor on the server side, and the lockout after 3 failed attempts must hold whatever the app sends.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows.
What stays with you
Channel rules such as changing the mobile number only at a branch or ATM, and SMS notifications.
- SAMA Counter-Fraud Framework, 4.4
Authenticate by risk, not by SMS alone
What the text says
The authentication standard covers digital channels such as online services and mobile apps. Multi-factor authentication should not solely consist of OTPs sent via SMS. High-risk activity, such as registration, activating a token on a new device, logging in from an unknown device and adding beneficiaries, needs multi-factor authentication, and anomalous sessions need a third factor.
What it means for your mobile app
Device binding, push approval in the app and step-up on anomalous sessions are controls fraudsters try to skip by replaying or reshaping API calls.
How Ostorlab helps
Authenticated testing covers MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes.
What stays with you
The authentication standard, the risk engine that flags anomalous sessions and the definition of low-level transactions.
- SAMA Counter-Fraud Framework, 4.6.2
Detect rooted devices and limit abuse
What the text says
Fraud prevention standards include the capability for mobile apps to detect use on jailbroken or rooted devices and then block the app or restrict access to sensitive data or features, device registration, a restriction on concurrent log-ins or on the number of devices, and, on a risk-based approach, robotic prevention mechanisms before a payment is instructed.
What it means for your mobile app
Root and jailbreak detection has to react, not just detect, and the backend has to stop scripted and concurrent use that the app alone cannot prevent.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. API testing covers abuse such as enumeration, replay and automation.
What stays with you
Choosing your shielding product, transaction limits, blacklists and fraud monitoring.
- SAMA Financial Entities Ethical Red-Teaming Framework, 1.3 and 1.6
Red teaming at least once every 3 years
What the text says
Each SAMA-regulated member organization should be tested, as a minimum once every three years, with a threat intelligence based red teaming test of its live production environment under the FEER framework. SAMA can also select an organization for a test. Red teaming is not a penetration test: it replicates a targeted attack against the whole organization.
Source:SAMA Financial Entities Ethical Red-Teaming Framework, 1.3 and 1.6
What it means for your mobile app
The mobile app and its APIs are likely entry points for a red team. Weaknesses that routine testing could have found use up red team time.
How Ostorlab helps
Ostorlab does not run red teaming tests and does not replace them. It helps you go into a test with known app and API issues already fixed, and retest the app and API findings afterwards.
What stays with you
The red teaming exercise, the providers and the dialogue with SAMA.
Summary of SAMA texts published in the SAMA Rulebook, checked on 27 September 2026. Some frameworks apply to specific sectors, as noted. This page is not legal advice.
SAMA rules, control by control
The controls the SAMA texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Annual review and penetration test of internet-facing servicesCSF 3.2.4 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Security testing of each change before releaseCSF 3.3.7; ITGF 3.4.5 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Testing third-party code without the sourceCSF 3.3.7; ITGF 3.4.4 | Taint analysis across embedded SDKs, and dependency analysis of the compiled app. Details | Findings attributed to the SDK or library they come from |
| Vulnerability classification, timelines and follow-upCSF 3.2.4, 3.3.17 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. Details | Ticket history and retest result for each finding |
| Non-caching and protection of customer data on the deviceCSF 3.3.6, 3.3.13 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Protection against man-in-the-middle attacksCSF 3.3.13 | Attempts to bypass TLS pinning at runtime and checks transport protections. Details | Evidence of which protections held and which were bypassed |
| MFA on sign-on, beneficiaries, password reset and high-risk transactionsCSF 3.3.13; CFF 4.4 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Lockout after 3 failed attempts, and session handlingCSF 3.3.13 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Root and jailbreak detection that blocks or restricts the appCFF 4.6.2 | Runs the app in rooted and jailbroken environments and attempts to bypass root and jailbreak detection. Details | Hardening score, and bypass evidence for each protection that failed |
| Bot, replay and concurrent-use abuse of payment APIsCFF 4.6.2 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
Ostorlab tests controls in the app and its APIs. Governance, awareness, event monitoring and the SOC, incident management, business continuity, fraud monitoring, brand protection and reporting to SAMA stay with your teams.
SAMA app controls to test before your next review
A practical list for security, fraud and compliance teams working with the SAMA frameworks.
Annual pentest on the calendar
Book the yearly review and penetration test of the app and its APIs, and add scans on every release in between.
Security gate in the release pipeline
Run static and dynamic testing on each build before it goes to the Change Advisory Board and the store.
Third-party code covered
List the SDKs and libraries in each release and decide how you get assurance on code you have no source for.
MFA on every listed flow
Check sign-on, beneficiaries, payment services, high-risk transactions and password reset all require a second factor, enforced by the server.
Lockout and sessions
Verify access is revoked after 3 failed attempts, and test session time-outs, token refresh and logout.
Rooted and jailbroken devices
Run the app on compromised devices and confirm it blocks or restricts sensitive features, as the Counter-Fraud Framework expects.
Data left on the device
Look for tokens and personal data in caches, logs and screenshots, and for credentials hardcoded in the app.
Findings tracked to closure
Classify each finding, set a deadline, retest after the fix and keep the record for SAMA inspections and internal audit.
A suggested list, not a SAMA template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- SAMA Rulebook: Cyber Security FrameworkSaudi Central Bank, Circular No. 381000091275, 24 May 2017. Applies to banks, insurers, financing companies and credit bureaus. Covers application security, change management, electronic banking services and vulnerability management
- SAMA Rulebook: Circular Re. Cyber Security FrameworkSaudi Central Bank, Circular No. 381000091275. Sets full compliance by the end of October 2018 and Maturity Level 4 roadmaps for event, incident, threat and vulnerability management. English translation, the Arabic text governs
- SAMA Rulebook: Counter-Fraud FrameworkSaudi Central Bank, Circular No. 44021528, 11 October 2022, banking sector. Covers authentication, fraud prevention standards and mobile app controls. SAMA notifies the organizations required to implement it
- SAMA Rulebook: Information Technology Governance FrameworkSaudi Central Bank, Circular No. 43028139, 4 November 2021, banking sector and credit bureaus. Covers system development, secure code review and testing of changes
- SAMA Rulebook: Financial Entities Ethical Red-TeamingSaudi Central Bank, Circular No. 562240000067, 13 May 2019. Threat intelligence based red teaming, at least once every three years
- SAMA Rulebook: Cyber Resilience Fundamental Requirements (CRFR)Saudi Central Bank, 1 January 2022. Applies to finance companies, payment service providers, money exchange and sandbox entities, not banks. Penetration testing twice a year and app shielding
- SAMA Rulebook: Rules on Outsourcing, Section VSaudi Central Bank, Circular No. 41027017, 15 December 2019, banking sector. Written SAMA no objection needed for outsourcing to providers located overseas
- SAMA Open Banking FrameworkSaudi Central Bank. Business rules and technical standards, including API specifications, available on request from the SAMA Open Banking team, so not quoted on this page
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against SAMA's controls
Start with a free scan of your app from the store, or book a demo to run logged-in and shielding tests with our team.