On this page
- Why do Saudi fintechs need mobile app and API penetration testing?
- Which SAMA and NCA rules apply to mobile apps and APIs?
- What does the SAMA Open Banking Framework mean for API security testing?
- What should a mobile app penetration test cover?
- What should the API penetration test cover?
- How often should a Saudi fintech test its mobile app and APIs?
- What should a fintech prepare before a mobile and API penetration test?
- How Sumrite helps
- Frequently asked questions
Saudi fintechs live on their mobile apps. The app is the product, the API is the bank connection, and both are exposed to anyone who downloads the app. This guide explains which SAMA and NCA rules apply, what a mobile and API test should cover, and what to prepare.
Delivered with a verified NCA-registered partner
Sumrite runs mobile app and API penetration testing for Saudi fintechs and app companies end to end with our verified NCA-registered partner firm, and has served 100+ Saudi clients across Riyadh, Jeddah, Dammam and other cities. See how we deliver in Saudi Arabia.
Why do Saudi fintechs need mobile app and API penetration testing?
Saudi fintechs need mobile app and API penetration testing because SAMA rules require periodic penetration testing of customer-facing services, and because open banking connects fintech apps directly to bank data and payments. A flaw in a fintech’s API can now expose another institution’s customers.
Open banking has moved from pilot to licensing. SAMA issued the Open Banking Framework in November 2022, with the first release focused on the Account Information Service (AIS). The second release, issued in 2024, covers the Payment Initiation Service (PIS) and lets customers start payments from inside third-party apps. In March 2026, SAMA announced it had started licensing fintech companies to provide open banking services after a supervised sandbox phase.
That sequence matters for security. Read-only account data was the first step; payment initiation means a broken authorisation check can move money. Mobile apps also ship to every attacker’s phone, where the binary can be decompiled, instrumented and replayed. For the full regulatory picture, start with our SAMA Cyber Security Framework guide and the penetration testing guide for Saudi Arabia.
Which SAMA and NCA rules apply to mobile apps and APIs?
Three rule sets apply: the SAMA Cyber Security Framework for licensed financial institutions, the SAMA Cyber Resilience Fundamental Requirements for sandbox entrants and new licensees, and NCA ECC-2:2024 where an entity is a government body, a government-affiliated company or Critical National Infrastructure. Which one binds you depends on your licence status.
| Rule set | Who it applies to | What it says about mobile apps and testing |
|---|---|---|
| SAMA Cyber Security Framework (2017) | Banks, insurance and reinsurance companies, financing companies, credit bureaus and financial market infrastructure | 3.2.4: customer and internet facing services subject to annual review and penetration tests. 3.3.13: official app stores, detection and take-down of malicious apps, and multi-factor authentication for all electronic banking services |
| SAMA Cyber Resilience Fundamental Requirements (2022) | Entities intending to enter SAMA’s Regulatory Sandbox or seeking a licence | 3.2.5: periodic vulnerability assessment of application and infrastructure layers. 3.2.6: penetration testing twice a year as a minimum or after a major or critical change. 3.2.8: shielding such as code obfuscation, white box cryptography and anti-tampering |
| NCA ECC-2:2024 | Government agencies, their affiliated companies, and CNI operators | ECC 2-11-3-1: penetration testing scope includes internet-facing services, explicitly naming mobile apps alongside websites, web applications, email and remote access |
SAMA states that the CRFR is not a replacement for the Cyber Security Framework: once licensed, entities still have to comply with SAMA’s other frameworks. Plan for the stricter cadence early. Financial institutions that also fall under NCA should read NCA ECC vs SAMA CSF, which shows how one testing programme can serve both.
What does the SAMA Open Banking Framework mean for API security testing?
The SAMA Open Banking Framework means fintechs and banks must expose standardised APIs that pass conformance testing, but conformance is not security: a separate API penetration test is needed to prove those APIs resist abuse. The two answer different questions.
According to SAMA’s Open Banking portal, the technical standards include customer experience guidelines, API specifications, implementation requirements and operational guidelines, and the Open Banking Lab gives banks and fintechs a sandbox that simulates bank APIs, with conformance suites to test and certify services against the framework.
- Conformance testing asks
- Does the API return the right response, in the right format, for a valid request from an authorised party?
- Penetration testing asks
- Can a valid user, an expired consent or a tampered request reach data or payments outside its authority?
- Conformance evidence
- Certification from SAMA's Open Banking Lab that the service works with the framework.
- Penetration test evidence
- A report of attempted abuse cases, findings, fixes and retest results that a SAMA reviewer or partner bank can read.
Open banking API test cases worth insisting on:
- Consent scope: can a token issued for account information be used to initiate a payment, or to read accounts the customer did not select?
- Consent lifecycle: does access stop immediately after a customer revokes consent or the consent expires?
- Object-level authorisation: can one customer’s account or payment ID be swapped for another’s?
- Payment integrity: can amounts, beneficiaries or currency be altered between consent and execution, or a payment request be replayed?
- Rate and enumeration limits: can an attacker enumerate accounts or brute-force one-time passwords?
What should a mobile app penetration test cover?
A mobile app penetration test should cover the app binary, data stored on the device, network traffic, authentication and session handling, platform interactions such as deep links, and the backend APIs the app calls. The OWASP Mobile Application Security project’s MASVS and MASTG are the reference standards.
- Local storage: no tokens, card data or personal data left in logs, caches, screenshots or unencrypted files
- Network: TLS everywhere, certificate pinning where your risk model calls for it, and no sensitive data in URLs
- Authentication: biometric unlock bound to a server-side check, MFA on sensitive actions, and session timeouts that match SAMA CRFR 3.2.15 (inactive sessions no longer than 5 minutes)
- Resilience: obfuscation, root and jailbreak detection, anti-tampering and anti-hooking, as SAMA CRFR 3.2.8 expects
- Platform: deep links, intents, WebViews and clipboard handling that cannot be abused by another app
- Secrets: no API keys, signing keys or environment URLs hard-coded in the build
- Arabic and English builds and both iOS and Android, since behaviour often differs
Our mobile app penetration testing checklist based on OWASP MASVS breaks each area into test cases.
What should the API penetration test cover?
The API penetration test should cover every endpoint the mobile app and partners call, tested directly against the OWASP API Security Top 10 (2023), with most effort on authorisation flaws. In practice, the most serious fintech findings sit in the API, not on the device, because the app is only a client.
The OWASP API Security Top 10 (2023) lists broken object level authorisation as API1, and it is the classic fintech failure: change an account or transaction ID in a request and receive someone else’s data. Broken authentication, broken object property level authorisation (returning more fields than the app displays) and unrestricted access to sensitive business flows follow closely. Our OWASP API Top 10 checklist walks through each one.
Ask for the API to be tested from three positions: as an unauthenticated user, as a normal customer trying to reach other customers’ data, and as a lower-privilege role trying to reach admin or operations endpoints.
How often should a Saudi fintech test its mobile app and APIs?
A Saudi fintech in SAMA’s sandbox or licensing track should test at least twice a year and after every major or critical change under CRFR 3.2.6, while licensed institutions under the SAMA CSF must test customer and internet facing services at least annually under CSF 3.2.4. Fintechs that release every sprint usually need more than either minimum.
Mobile releases change the attack surface constantly: a new payment feature, a new SDK or a new API version can all reopen closed findings. Many fintechs therefore pair a full annual or twice-yearly test with release-based testing, which our post on continuous pentesting in Saudi Arabia covers. If you are deciding between a pentest and a full adversary simulation, see SAMA ethical red teaming vs penetration testing.
What should a fintech prepare before a mobile and API penetration test?
Before a mobile and API penetration test, a fintech should prepare test builds, test accounts for every role, API documentation, and a written scope and authorisation. Good preparation moves testing days from setup to finding real issues.
- Builds: an IPA and APK, or TestFlight and internal-track access. A build without heavy obfuscation speeds up testing, with a release-build check at the end to confirm protections work.
- Accounts: at least two customer accounts with funded or simulated balances, plus each staff or merchant role.
- API documentation: OpenAPI files or a Postman collection, including open banking endpoints and sandbox credentials from the Open Banking Lab where relevant.
- Environment: a staging environment that matches production, with payment rails stubbed or in sandbox mode.
- Authorisation: signed rules of engagement, test windows and a technical contact, with contract clauses on confidentiality and data deletion.
How Sumrite helps
Sumrite runs manual mobile app VAPT and API security testing for Saudi fintechs end to end with our verified NCA-registered partner firm. Testing follows OWASP MASVS and the OWASP API Security Top 10, covers open banking consent and payment flows, maps findings to SAMA CSF, SAMA CRFR and NCA ECC 2-11 as relevant, and includes a retest. Through our Saudi Arabia service, the Sumrite VAPT report for Saudi reviews is delivered in 48 hours. Comparing providers first? Use our checklist for choosing a penetration testing company in Saudi Arabia.
Scope your mobile and API test
Tell us your apps, API versions and SAMA licence status, and we will scope a test that matches the rule set you answer to. Book a scoping call.
Frequently asked questions
Do SAMA-regulated fintechs need mobile app penetration testing?
Yes. The SAMA Cyber Resilience Fundamental Requirements (CRFR), which apply to entities entering SAMA's Regulatory Sandbox or seeking a licence, require penetration testing at least twice a year or after a major or critical change. Licensed banks, insurers and financing companies fall under the SAMA Cyber Security Framework, whose section 3.2.4 requires annual review and penetration tests of customer and internet facing services, which includes mobile banking apps.
Does SAMA Open Banking Lab certification replace an API penetration test?
No. The SAMA Open Banking Lab provides conformance suites that certify an API works as the Open Banking Framework specifies. Conformance testing checks that the API behaves correctly for valid requests, while an API penetration test checks whether an attacker can abuse consent, tokens or object identifiers to reach data or payments they should not.
What standard should a mobile app penetration test follow?
A mobile app penetration test should follow the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Application Security Testing Guide (MASTG). The backend APIs the app calls should be tested against the OWASP API Security Top 10 (2023), because most serious mobile findings sit in the API rather than on the device.
What app protection does SAMA expect from fintech mobile apps?
The SAMA Cyber Resilience Fundamental Requirements (CRFR) ask entities to implement shielding techniques such as code obfuscation, white box cryptography and anti-tampering. The CRFR also states that inactive sessions should not exceed 5 minutes for applications and underlying infrastructure, and a mobile penetration test should verify both.
When did SAMA release the Open Banking Framework?
The Saudi Central Bank (SAMA) issued the first release of the Open Banking Framework, covering the Account Information Service (AIS), in November 2022. SAMA issued the second release, covering the Payment Initiation Service (PIS), in 2024, and announced in March 2026 that it had started licensing fintech companies to provide open banking services.
Faisal Khan is a Director at Sumrite, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
