Central Bank of Jordan: test the mobile banking app behind your customers' accounts.
The Central Bank of Jordan's Instructions of Cyber Risks Resilience require penetration tests of critical systems at least once a year, at the application level too. Its Cybersecurity Framework for the financial sector adds concrete rules for mobile banking apps: TLS pinning, no install on rooted or jailbroken devices, five-minute session timeouts and one-time secrets valid for five minutes at most. Ostorlab supports your testing obligations for the app and the APIs behind it, on every release.
- Penetration testing by AI agents behind login, including one-time codes
- Checks root and jailbreak detection and TLS pinning, and what the app does when they trigger
- Static and dynamic testing of the build you ship, with no source code needed
- Risk ratings, tickets and retests, so every fix can be proven
- Who it applies to
- Licensed banks, financial institutions, credit bureaus and microfinance companies supervised by the CBJ
- Legal basis
- Instructions of Cyber Risks Resilience, issued 6 February 2018
- Focus
- Cyber risk management, penetration testing and electronic service delivery
- Reference
- Instructions of Cyber Risks Resilience, Article 35; Cybersecurity Framework, sections G.2, G.9.5 and H.2
The CBJ texts behind the mobile channel
Binding instructions, a detailed framework and fraud guidance. The dates below are for the texts cited on this page.
- 25 October 2016
IT governance instructions
Instructions No. (65/2016) on Governance and Management of Information and Related Technology, based on COBIT 5, in force eighteen months after issuance.
- 6 February 2018
Instructions of Cyber Risks Resilience
Cybersecurity governance, protection, detection, response, testing and outsourcing rules, effective twelve months after issuance.
- July 2021
Cybersecurity Framework, Version 1.0
The CBJ's framework for the financial sector sets cybersecurity baselines, including mobile and web banking controls. FinCERT assesses its implementation.
- May 2023
Guidance on combating financial fraud
Fraud controls for companies licensed to provide electronic payment services, including banks: strong customer authentication and rooted device detection.
- Every year
Penetration tests and IT audit reports
Penetration tests of critical systems at least once a year, and annual internal and external IT audit reports to the CBJ during the first quarter.
- Every month
Vulnerability scanning of critical systems
The framework highly recommends vulnerability scanning at least once a month for critical and sensitive systems.
The CBJ's cyber rules, applied to your mobile app
The Instructions of Cyber Risks Resilience, the Cybersecurity Framework for the financial sector and the CBJ's fraud guidance. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- Instructions of Cyber Risks Resilience, Article 35(a)
Penetration test critical systems at least once a year
What the text says
Implement penetration tests for critical systems at least once a year or after a radical change to the system, with a scope based on the sensitivity of the systems and the systems that support them. Tests are implemented at the level of applications as well as internal and external networks. Tests may be carried out by a third party, but not outsourced to the same third party for more than two consecutive years.
Source:Instructions of Cyber Risks Resilience, Article 35(a)
What it means for your mobile app
If your mobile banking app supports critical systems, it and its APIs belong in the yearly penetration test, and in a new test after any radical change.
How Ostorlab helps
The AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. It can run on every release, between your yearly tests.
What stays with you
Scoping the yearly test, choosing and rotating the tester, and deciding what counts as a radical change.
- Instructions of Cyber Risks Resilience, Article 35(b) and (c); Cybersecurity Framework, G.9.5
Assess vulnerabilities and monitor for new gaps
What the text says
Assess vulnerabilities and security gaps of critical systems and their supporting systems periodically, address the gaps found, and monitor systems continuously to detect new ones. The framework highly recommends vulnerability scanning at least once a month for critical and sensitive systems, performed both bypassing and through the applied controls.
Source:Instructions of Cyber Risks Resilience, Article 35(b) and (c); Cybersecurity Framework, G.9.5
What it means for your mobile app
Between yearly pentests, the app and its APIs need regular automated scanning, with findings fixed and tracked.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Scheduled runs of your pipeline keep a weekly cadence between releases. Findings are rated critical, high, medium or low, tracked as tickets and retested once the fix ships.
What stays with you
Infrastructure and network scanning, and the scanning frequency for each system.
- Cybersecurity Framework, G.2.2 and G.2.3
Test security throughout development
What the text says
Define a secure development lifecycle: static code analysis during coding, and dynamic code analysis through vulnerability scanning and penetration testing during testing, with results reviewed and remediated. Secure coding must address at least the OWASP Top Ten and the CWE/SANS Top 25. Securing applications should not rely on obscuring functionality, source code, keys or strings, and remediation must be tested thoroughly before release.
What it means for your mobile app
Each release of the app should pass static and dynamic testing before it reaches the store, and keys hidden in the app are not a control.
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 and captures traffic, stack traces and screenshots. Ostorlab also finds hardcoded secrets such as API keys and tokens before they ship.
What stays with you
Threat modeling, manual code reviews by someone other than the coder, and developer training.
- Cybersecurity Framework, H.2.1(2)
Harden the mobile banking app
What the text says
For mobile and web banking, the app must verify the customer's mobile number and device IMEI or ESN on first use, terminate sessions after a maximum of five minutes of inactivity, prohibit concurrent sessions while allowing up to three validated devices, use techniques against man-in-the-middle attacks such as TLS pinning, avoid caching sensitive data and encrypt data stored on the device, and prevent installation on rooted or jailbroken devices.
What it means for your mobile app
Each of these is a testable property of the app. Pinning and root detection also have to resist an attacker trying to bypass them.
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. Ostorlab also looks for tokens and personal data in local storage, caches, logs and screenshots.
What stays with you
Choosing and configuring your shielding product, and the device registration process.
- Cybersecurity Framework, H.2.1(1) and H.4(2)
Add authorization factors for sensitive actions
What the text says
Implement additional authorization factors for account activation, password reset, financial transactions, and adding or modifying beneficiaries, using out-of-band one-time secrets, time-based or hash-based OTPs, or cryptographic authenticators. One-time secrets are valid for a maximum of five minutes. Changes to contact details through an electronic channel require multi-factor authentication, with alerts and the second factor sent to the old number or email address.
What it means for your mobile app
Step-up checks on payees, resets and contact-detail changes are the controls fraudsters try to skip. They have to hold on the server, whatever the app sends.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests 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
Choosing authentication methods and the channels for one-time secrets.
- Cybersecurity Framework, G.3 (7.4, 7.6, 8.3) and H.3(5)
Count factors correctly and lock out after three failures
What the text says
Authentication counts as multi-factor only when at least two authenticators of different factors are used. Device verification, knowledge-based authentication, location and behavioural biometrics are not authentication factors. Access to electronic payment services must be blocked after a maximum of three failed authentication or authorization attempts, and temporary passwords must expire quickly.
Source:Cybersecurity Framework, G.3 (7.4, 7.6, 8.3) and H.3(5)
What it means for your mobile app
A trusted device plus an SMS code is not the same as two factors if both can be obtained together. Lockout and expiry have to be enforced by the backend.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, and traffic analysis shows how credentials travel from the app to the backend.
What stays with you
The password policy, lockout durations and the reactivation procedure.
- Cybersecurity Framework, I.3
Secure the APIs you open to third parties
What the text says
For information access and payment initiation providers, third parties must be authenticated before consuming any API, with mutual TLS highly recommended. Users are authenticated by at least two factors before consent is registered, clients are authenticated at API level with OAuth 2.0 and OpenID Connect highly recommended, and users can revoke consent at any time.
Source:Cybersecurity Framework, I.3
What it means for your mobile app
The APIs behind the app and any open APIs need authorization that holds for every request, whoever calls them.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
Onboarding third parties, VPN connectivity, consent management and API risk catalogues.
- CBJ Guidance on Combating Financial Fraud in the National Payment System, Internal control procedures, C, D and G
Build fraud controls into the app
What the text says
Authenticate customers with at least two factors and avoid relying solely on SMS OTPs, including when accessing mobile applications, performing transactions and activating the app on a new device. Require a third factor for anomalous sessions or transfers from a non-trusted device to a new beneficiary. Mobile apps should detect jailbreaking or rooting and block the app or restrict sensitive features, and limit concurrent log-ins or the number of devices.
What it means for your mobile app
Fraud controls live in the app and in the payment APIs. Rooted device detection, device binding and step-up rules are part of your fraud defence.
How Ostorlab helps
Ostorlab tests the fraud-relevant controls inside the app and its APIs: authentication, step-up checks, session handling, device protections and the business logic behind payments.
What stays with you
Transaction monitoring, the fraud unit, blacklists and customer awareness.
- Instructions No. (65/2016), Article 9 and Annex 5
Give auditors evidence of your testing
What the text says
The audit committee and the external auditor send the CBJ an annual internal and an annual external IT audit report during the first quarter of each year. The audit programme covers, among other items, the efficiency and sufficiency of vulnerability assessment and penetration tests, and the operation controls for electronic channels and electronic payment systems.
What it means for your mobile app
Auditors will ask how the app was tested, what was found and whether it was fixed.
How Ostorlab helps
Scan results, findings with reproduction steps and retest results give you a dated record of how the app's controls were tested and fixed, release after release.
What stays with you
The audit itself, the IT governance framework and reporting to the CBJ.
Summary of the English versions of public CBJ texts, checked on 27 September 2026. Some texts apply to specific licence types, as noted. This page is not legal advice.
CBJ rules, control by control
The mobile and API controls in the CBJ texts, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Application-level penetration testingCyber Risks Resilience, Art. 35(a) | 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 |
| Regular vulnerability scanningCyber Risks Resilience, Art. 35(b); CSF G.9.5 | Automated scans from your CI/CD pipeline on every build, including scheduled runs, and monitoring of store releases. Details | Scan results per build and per store release |
| Static and dynamic analysis before releaseCSF G.2.2 | 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 |
| No keys or secrets hidden in the appCSF G.2.3 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| No install on rooted or jailbroken devicesCSF H.2.1; fraud guidance, G | 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 |
| TLS pinning against man-in-the-middle attacksCSF H.2.1 | Attempts to bypass TLS pinning at runtime and intercepts the app's traffic when it can. Details | Evidence of which protections held and which were bypassed |
| Sensitive data cached or stored on the deviceCSF H.2.1 | 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 |
| Authorization factors, five-minute sessions and one-time secretsCSF H.2.1, H.4, H.3 | Logs in with one-time codes and tests MFA enforcement, step-up flows, timeouts and session invalidation. Details | Findings on login, session and step-up flows with reproduction steps |
| API authentication and authorizationCSF I.3 | 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 |
| Remediation tracked and retestedCyber Risks Resilience, Art. 35(b); ITG 65/2016, Annex 5 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
Ostorlab tests controls in the app and its APIs. Cybersecurity governance, IT governance under COBIT, network and infrastructure testing, SOC monitoring, incident response, business continuity, outsourcing and cloud oversight, fraud operations and reporting to the CBJ stay with your teams.
CBJ mobile controls to test in your app
A practical list for security, fraud and audit teams in Jordan.
Yearly penetration test
Put the mobile app and its APIs in scope of the yearly penetration test of critical systems, and retest after any radical change.
Scanning between tests
Scan every build and store release, and aim for at least monthly scans of critical systems as the framework recommends.
Rooted and jailbroken devices
Run the app on rooted and jailbroken devices and confirm it refuses to install or run, or restricts sensitive features.
TLS pinning
Try to intercept the app's traffic and confirm pinning holds against bypass attempts.
Sessions and one-time secrets
Verify the five-minute inactivity timeout, the ban on concurrent sessions, one-time secret expiry and the three-attempt lockout.
Step-up on sensitive actions
Check that activation, password reset, transfers, new beneficiaries and contact-detail changes require an extra factor, enforced by the server.
Data and secrets in the app
Look for cached sensitive data, unencrypted storage and hardcoded keys or tokens in the app package.
Evidence for the auditors
Keep results, tickets and retests for each release, ready for the annual internal and external IT audit reports.
A suggested list, not a CBJ 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
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.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
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.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
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Instructions of Cyber Risks ResilienceCentral Bank of Jordan, No. 26/1/1/1984, 6 February 2018, effective twelve months after issuance. Applies to licensed banks, financial institutions, credit bureaus and microfinance companies; Article 35 covers penetration tests and vulnerability assessments
- Cybersecurity Framework for Jordan Financial Sector, Version 1.0Central Bank of Jordan and FinCERT, July 2021. Baselines for CBJ-regulated entities, including secure development, vulnerability scanning and penetration testing, mobile and web banking, and open APIs
- Governance and Management of Information and Related Technology Instructions No. (65/2016)Central Bank of Jordan, 25 October 2016, based on COBIT 5, in force eighteen months after issuance. Covers IT governance and the annual IT audit reports to the CBJ
- Guidance on Combating Financial Fraud in the National Payment SystemCentral Bank of Jordan, Oversight and Supervision on the National Payments System Department, May 2023. For companies licensed to provide electronic payment services, including banks
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 the CBJ rules
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests with our team.