CBE rules: test your mobile banking app behind login and before every release.
The CBE requires banks and payment providers to assess internet banking and mobile payment systems at least every three months, to run a penetration test at least once a year that covers every release of the mobile app, and to send the pre-launch penetration test report to the CBE with no high or medium risk findings. The Financial Cybersecurity Framework and the Personal Data Protection Law add governance, incident reporting and data protection duties. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests two-factor codes, re-authentication for high-risk transfers, lockout and session timeouts with your test accounts
- Checks root and jailbreak detection, anti-tampering, screenshots and the data the app leaves on the phone
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Who it applies to
- Banks and payment service providers and operators regulated by the CBE, and the mobile apps they offer
- Key date
- Internet banking rules approved on 4 November 2014; mobile payment services rules, third edition, April 2021; PDPL compliance from 31 October 2026
- Focus
- Vulnerability assessment and penetration testing, including every mobile app release, authentication and app hardening
- Main reference
- CBE Financial Cybersecurity Framework (EG-FinCSF) and the CBE payment services regulations
The CBE texts behind your mobile channel
The internet banking and mobile payment rules set the technical baseline, and the cybersecurity framework and the data protection law have been added on top since then. The dates below are for the texts cited on this page.
- 4 November 2014
Internet banking rules
The CBE board approves the Rules regulating the provision of banking services via the Internet, issued to banks by circular on 9 November 2014. The rules cover authentication, password management, encryption and the security assessment of internet banking systems.
- April 2021
Mobile payment services rules
The third edition of the rules regulating mobile payment services sets authentication and password requirements, application security measures and a security assessment cycle that must include every release of the mobile payment application.
- 26 October 2021
Instant Payment Network rules
The CBE issues the rules for the Instant Payment Network, with requirements for encryption, device risk detection, two-factor authentication and annual penetration testing with reports sent to the CBE.
- December 2021
Financial Cybersecurity Framework
The CBE circulates the first edition of the Financial Cybersecurity Framework (EG-FinCSF), the sector framework for banks and payment providers, alongside EG-FinCIRT, the sector's computer emergency response team.
- 1 November 2025
PDPL Executive Regulations
Decree No. 816 of 2025 publishes the Executive Regulations of the Personal Data Protection Law, in force the next day. The one-year grace period ends on 31 October 2026, when full enforcement applies.
- 23 August 2026
Digital financial identity rules
The CBE issues rules for the digital financial identity system used for electronic KYC, requiring periodic review of infrastructure and cybersecurity testing and a cybersecurity self-assessment reported to the CBE.
The CBE rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. The internet banking, mobile payment and digital identity texts are in Arabic and are summarised here; the IPN rules are in English.
- CBE Internet Banking Rules, 3-8-1 to 3-8-3; CBE Mobile Payment Services Rules, 3-11-1 to 3-11-4 (Arabic text)
Assess internet banking and mobile payment systems on a fixed cycle
What the text says
The CBE rules require a periodic assessment of the security of every system related to internet banking and mobile payment services, at the main site and the disaster recovery site. The minimum activities are a vulnerability assessment at least every three months, or after a fundamental change to the operating environment, and a penetration test at least once a year or before launching any new vital service. The vulnerability assessment must cover common weaknesses such as SQL injection, authentication bypass and insecure storage; findings must be fixed and the fix validated by retesting. The scope of the assessment activities must include every release of the mobile payment application available to the bank's customers.
What it means for your mobile app
The app is explicitly in scope, and not only the version tested a year ago: the rules say every release available to customers. A quarterly assessment and an annual penetration test are the floor.
How Ostorlab helps
An 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. Mobile SAST, Mobile DAST and SCA run from your CI/CD pipeline on every build, so each store release is assessed between the formal test rounds.
What stays with you
Scoping the assessments, testing servers, network equipment and the disaster recovery site, and reporting the results internally.
- CBE IPN Services Rules, 7-3-3 and 7-3-4; CBE Internet Banking Rules, 4-5-1 (Arabic text)
Send the pre-launch penetration test report to the CBE
What the text says
A new service must not be launched before the CBE has received the penetration test report on the production environment, showing that there are no high or medium risk weaknesses. The bank must obtain the CBE's approval to activate the service, and the report must be submitted within three months of its issue. The penetration test must be performed by an independent third-party provider under a non-disclosure agreement, with a signed initial report and remediation plan, validation of the fixes on both main and disaster recovery systems, and a signed final report submitted to the CBE. The same provider must not run more than two consecutive penetration tests.
Source:CBE IPN Services Rules, 7-3-3 and 7-3-4; CBE Internet Banking Rules, 4-5-1 (Arabic text)
What it means for your mobile app
This is a release gate, not an annual ritual. The evidence has an audience outside your institution, so findings and retests need to be documented and reproducible.
How Ostorlab helps
Ostorlab produces per-finding evidence you can attach to the submission: a replayable exploit for each AI-agent finding and request and response evidence for API findings, with retest results after the fix ships.
What stays with you
Choosing and contracting the independent provider, signing the reports, testing the disaster recovery site and the submission to the CBE.
- CBE Mobile Payment Services Rules, 3-4 and 3-5 (Arabic text)
Use two factors and re-authenticate high-risk operations
What the text says
Authentication for mobile payment services must combine two of three elements: something the user knows, something the user holds, such as a digital signature or one-time passwords from security token devices or apps, or something the user is, such as biometrics. High-risk activities, including payment orders to multiple beneficiaries, transfers above the maximum limit and changes to the customer's contact details, must be re-authenticated with two means, and one-time passwords for individuals must not be delivered automatically by SMS or email for those operations. One-time passwords must be at least six characters and valid for no more than 90 seconds; PINs must be at least six digits, preferably eight, with no easy values; and the service must block access after a set number of failed attempts, without revealing whether the user name or the password was wrong.
Source:CBE Mobile Payment Services Rules, 3-4 and 3-5 (Arabic text)
What it means for your mobile app
The controls are specific enough to test: which flows require the second factor, where the one-time code comes from, how long it lives, and what happens after failed attempts.
How Ostorlab helps
Authenticated testing completes SMS, email or TOTP one-time codes with your test accounts, tests MFA enforcement and step-up flows for high-risk actions, and checks lockout, user enumeration and one-time code reuse on the app and the APIs behind it.
What stays with you
Choosing the authentication methods, biometric calibration, and the risk classification of each transaction type.
- CBE Mobile Payment Services Rules, 3-9; CBE IPN Services Rules, 7-1-9 and 7-1-10
Harden the app against compromised devices and tampering
What the text says
The mobile payment rules expect the app to detect risky devices and resist tampering. The measures include sufficient detection that the phone is not rooted or jailbroken, protection against reverse engineering such as code obfuscation, protection against automatic screenshots taken by spyware on the same device, blocking the app from storing or displaying previously entered passwords, and automatic logout after a period of inactivity. When a new release fixes a security issue, the bank must require customers to install it before they can use the app. The app must be published from the bank's official store account with the right brand, and banks must search the stores for fake copies to limit malware that targets customer credentials.
Source:CBE Mobile Payment Services Rules, 3-9; CBE IPN Services Rules, 7-1-9 and 7-1-10
What it means for your mobile app
Each of these is a testable behaviour of the build your customers install, not a policy statement: does the app stop or warn, can the check be bypassed, and does an old version keep working?
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts to bypass root and jailbreak detection, anti-tampering and anti-instrumentation, and shows whether the app blocks the workflow, refuses to start or keeps running.
What stays with you
Choosing the shielding product, writing the force-update policy and running the fake-app monitoring process.
- CBE Mobile Payment Services Rules, 3-5, 3-8 and 3-9-8; CBE IPN Services Rules, 7-1-2, 7-1-6 and 7-1-8
Encrypt data in transit and keep little on the device
What the text says
Data stored in the internal memory of the phone must be limited, and anything kept for a genuine need must be protected. Data sent over the mobile network must be encrypted at the application layer, so PINs and passwords are not exposed at any intermediate stage between the app and the host server, where they are verified. Passwords must never be processed, sent or stored as clear text, and encryption must use strong methods or an adequate key length, with the keys protected through their lifecycle. The IPN rules add that the process must be encrypted from the payment channel to the servers executing the payment order, and that internationally recognised encryption should be used.
What it means for your mobile app
What the app writes to files, caches, logs and screenshots, and how the traffic is protected end to end, are things a tester can demonstrate rather than assume.
How Ostorlab helps
Ostorlab looks for tokens, passwords and personal data in local storage, caches, logs and screenshots, checks transport protections, and finds keys, tokens and credentials left in the app package.
What stays with you
Data classification, key management, and choosing and configuring the encryption stack.
- CBE Internet Banking Rules, 3-6-13 to 3-6-15; CBE Mobile Payment Services Rules, 3-8-6, 3-9-2, 3-9-3 and 3-9-4 (Arabic text)
Test that authentication cannot be bypassed, and enforce rules on the server
What the text says
The internet banking rules require banks to test that authentication cannot be bypassed or omitted to enter the system, to define strict identity and authorisation procedures for systems and databases, to design system processes securely and to keep audit trails. The mobile payment rules add comprehensive validation of input, including data entered by the user and database queries the user may try to execute, performed on the network servers, and require that user authorisation checks and transfer rules run on the server, in the bank's back-end systems, before the operation completes. Systems must run with the least privileges necessary, must not use well-known or default passwords, and error messages shown to customers must not reveal system details.
What it means for your mobile app
A client-side check is not a control. The app can be modified, so the server has to enforce authentication, authorisation and the business rules of a transfer.
How Ostorlab helps
Ostorlab modifies the app and replays calls to test whether authentication can be skipped and whether authorization is enforced server-side, checking for broken object and function level authorization (BOLA, BFLA, IDOR), tampered parameters and business logic abuse.
What stays with you
Secure design and coding standards, code review, and your audit trail and logging platform.
- CBE Mobile Payment Services Rules, 3-9-10 to 3-9-12; CBE IPN Services Rules, 2-2-2-5, 2-2-2-8, 7-1-11 and 7-2-1
Manage third-party components and the app store channel
What the text says
The mobile payment rules require adequate security controls when third-party libraries or ready-made application components are used to build the payment app, and say the app must not expose any service of a third-party application running on the same device, or from any other external source, other than the bank's own back-end systems. The IPN rules require the bank to know the third parties it relies on, and to obtain the CBE's approval before outsourcing external services. Applications for the Instant Payment Network must be subject to multiple tests before operation, and the bank's systems must be protected with the appropriate infrastructure, including intrusion detection and prevention systems and firewalls.
What it means for your mobile app
Every SDK bundled into the app is third-party code with network access, and a new service goes live only after it has been tested and, where required, approved by the CBE.
How Ostorlab helps
SCA and SBOM list the SDKs and native libraries in each release with versions and location in the bundle and map them to known vulnerabilities, release after release. Ostorlab monitors store releases without manual triggers.
What stays with you
Third-party due diligence, contracts, CBE approvals for outsourcing and the asset inventory.
- CBE Mobile Payment Services Rules, 2-2, 2-3, 3-10 and 3-12 (Arabic text); CBE Digital Financial Identity Rules, 23 August 2026; CBE cybersecurity pages
Run cyber governance and report incidents to the CBE
What the text says
The board and senior management are responsible for a clear security strategy, an approved information security policy, risk classification for mobile payment services and continuous review. Banks must monitor the systems and infrastructure proactively, 24 hours a day, seven days a week, record security violations, breaches and suspected weaknesses, protect audit trails from manipulation and review security alerts. Incident procedures must cover immediate reporting and handling, containment, evidence collection and escalation. The compliance officer must notify the CBE of incidents including phishing and credential theft, unauthorised access to systems, destructive data operations, prolonged or deliberate service stoppage, and internal fraud. The CBE circulated the Financial Cybersecurity Framework (EG-FinCSF) and runs EG-FinCIRT, the sector's computer emergency response team, as the channel for cyber incident reporting. For electronic KYC services, banks must review infrastructure and cybersecurity testing periodically, assess cyber maturity and readiness, complete a cybersecurity self-assessment aligned with the CBE framework, have it verified by an independent party and send the results to the CBE.
What it means for your mobile app
Governance and monitoring stay with the bank, but the app is part of the estate being monitored, and it is where device risk signals and suspicious login patterns become visible.
How Ostorlab helps
Ostorlab tests the controls in the app and its APIs and gives evidence per finding, which feeds the assurance and self-assessment work. It does not run SOC monitoring, incident response or the reporting to the CBE and EG-FinCIRT.
What stays with you
The security programme, 24x7 monitoring, incident response, the CBE and EG-FinCIRT reporting, and the eKYC self-assessment.
- Central Bank and Banking System Law No. 194 of 2020, Articles 140, 142, 197, 198 and 231 (Arabic text)
Keep customer data confidential under the Banking Law
What the text says
The Central Bank and Banking System Law makes all customer data, including accounts, deposits, items held in safe custody and transactions, strictly confidential. It may not be disclosed without the client's written consent or a judicial or arbitral order, and the obligation continues after the banking relationship ends and after an employee leaves their position. Payment system operators and providers must guarantee adequate protection of their electronic systems against hacking, unauthorised access, data manipulation and breaches of confidentiality or privacy, and must notify the CBE of any incident affecting service continuity or system operation. Violations of the confidentiality articles carry imprisonment of not less than one year and a fine, or either penalty.
What it means for your mobile app
Confidentiality is a legal duty with criminal penalties, and the mobile app is one of the places where customer data is most exposed.
How Ostorlab helps
Ostorlab finds personal data and credentials the app leaves on the device or sends in the clear, and tests whether the APIs behind the app let one customer reach another customer's data.
What stays with you
Legal interpretation, consent and disclosure procedures, and data loss prevention.
- Personal Data Protection Law No. 151 of 2020, Articles 4, 7, 8, 14, 15, 16, 17 and 38; Executive Regulations, Decree No. 816 of 2025 (Arabic text)
Meet the Personal Data Protection Law and its Executive Regulations
What the text says
The Personal Data Protection Law requires controllers to obtain consent or another lawful basis, verify that data is accurate and relevant, implement the technical and organisational measures needed to protect it, keep a record of processing and erase data when the purpose ends. Controllers and processors must appoint and register a data protection officer, and must notify the Personal Data Protection Center of a personal data breach within 72 hours, and the affected individuals within three working days. Transferring personal data abroad is prohibited unless the destination offers a level of protection not less than the law and the transfer is licensed or authorised by the Center. Direct electronic marketing needs prior consent and an opt-out. The Executive Regulations, Decree No. 816 of 2025, set out the licensing and permit categories, security measures during processing and breach reporting procedures. A one-year grace period ends on 31 October 2026, after which full enforcement and the penalties in the law apply.
What it means for your mobile app
The app collects, stores and transmits personal data, so consent flows, data minimisation, retention, breach reporting and the choice of hosting region are all part of the app's design.
How Ostorlab helps
Ostorlab shows what personal data leaves the app, where it is stored or cached on the device, and how it travels to the backend, so the technical measures and breach response can be verified rather than assumed.
What stays with you
Licences and permits from the Center, DPO registration, consent notices, cross-border transfer approvals and the breach notification runbook.
Summary of public CBE and Egyptian texts, checked on 27 September 2026. The internet banking, mobile payment and digital identity texts are in Arabic and are summarised here; the IPN rules are in English. The Financial Cybersecurity Framework is circulated to institutions rather than published as a standalone public document, so it is described only from public CBE material. This page is not legal advice.
CBE rules, control by control
The controls the CBE 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 |
|---|---|---|
| Vulnerability assessment of internet banking and mobile payment systemsInternet Banking Rules 3-8-2; Mobile Payment Rules 3-11-2 | Mobile DAST runs the app and exercises it from your pipeline, and API testing intercepts traffic even with TLS pinning and probes common weaknesses such as injection and broken authorization. Details | Scan results per run, with request and response evidence for each finding |
| Annual penetration test covering every app releaseInternet Banking Rules 3-8-3; Mobile Payment Rules 3-11-3 and 3-11-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 |
| Pre-launch production test with no high or medium risk findingsInternet Banking Rules 4-5-1; IPN Rules 7-3-3 | Tests the app and the APIs it calls behind login and retests after fixes, so findings and closures are documented release candidate by release candidate. Details | Initial findings, remediation status and retest results for each release candidate |
| Two-factor authentication and re-authentication for high-risk operationsMobile Payment Rules 3-4 | Logs in with one-time codes and tests MFA enforcement and step-up flows, including how attackers try to manipulate them. Details | Findings on login and step-up flows, with reproduction steps |
| Failed-attempt lockout, no user enumeration and session timeoutMobile Payment Rules 3-5-1 and 3-9-16 | Tests lockout after consecutive failures, user enumeration, automatic logout after inactivity and session invalidation. Details | Session and token findings, with request and response logs |
| Root and jailbreak detection, anti-tampering and screenshot protectionMobile Payment Rules 3-9-17 to 3-9-19 | Runs the app in rooted and jailbroken environments and attempts to bypass detection, instrumentation and screenshot blocking. Details | Hardening score, and bypass evidence for each protection that failed |
| Data left on the device and application-layer encryptionMobile Payment Rules 3-8-1, 3-8-2, 3-9-8 and 3-9-14 | Mobile SAST analyses storage, cryptography and logging code in the binary, across the app and its embedded SDKs. Details | Findings with decompiled source context, and file system evidence showing what was written, where and when |
| Third-party components, SDKs and the app store channelMobile Payment Rules 3-9-10 to 3-9-12 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Server-side authorization and input validationMobile Payment Rules 3-8-6 and 3-9-2 | Intercepts app 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 |
| Credentials and keys in the app packageMobile Payment Rules 3-5-1 and 3-9-3; IPN Rules 7-1-2 | 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 |
Ostorlab tests controls in the app and its APIs. The security programme, 24x7 monitoring, incident response and reporting to the CBE and EG-FinCIRT, penetration tests of servers and networks, disaster recovery, governance and physical security stay with your teams.
CBE controls to test in your mobile app
A practical list for security and compliance teams, based on the CBE internet banking, mobile payment and digital identity rules and the Personal Data Protection Law.
Quarterly assessment
Put internet banking and mobile payment systems, including every store release of the app, in the scope of a vulnerability assessment at least every three months and a penetration test at least once a year.
Pre-launch report
Require a production penetration test with no high or medium risk findings before launching a new service, and send the report to the CBE within three months of its issue.
Two factors on the right flows
Check that high-risk actions require re-authentication with two means, that one-time passwords for individuals do not arrive by SMS or email for those actions, and that codes expire within 90 seconds.
Harden the build
Test root and jailbreak detection, obfuscation, screenshot blocking and force-update behaviour against a modified build and runtime hooks.
Data on the phone
Look for PINs, passwords, tokens and personal data in storage, caches, logs and screenshots, and check application-layer encryption and key handling.
Components and stores
Keep a versioned list of the SDKs and libraries in each release, verify the security controls of third-party components, and watch the stores for fake copies of the app.
Governance and incidents
Confirm 24x7 monitoring and audit trails are in place, and that the CBE and EG-FinCIRT incident reporting list is wired into your runbooks.
Personal data
Register the data protection officer, prepare 72-hour breach reporting, review cross-border transfers against the PDPL licensing rules, and plan for the 31 October 2026 deadline.
A suggested list, not a CBE 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
- 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
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.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.
- Rules regulating the provision of banking services via the InternetCBE, approved by the board on 4 November 2014 and issued by circular dated 9 November 2014. Arabic text. Parts on authentication (3-2), password management (3-3), encryption (3-5), security assessment (3-8) and licensing (4-5)
- Rules regulating the provision of mobile payment services, third editionCBE, April 2021. Arabic text. Authentication (3-4), password management (3-5), confidentiality and integrity (3-8), application security (3-9), security monitoring (3-10), security assessment (3-11) and incident response (3-12)
- Rules regulating services for the Instant Payment Network inside the Arab Republic of EgyptCBE, October 2021, issued by circular dated 26 October 2021. English text. Information confidentiality and integrity (7-1), infrastructure and monitoring (7-2), security evaluation including penetration testing (7-3) and incident response (7-4)
- Rules of the digital financial identity system for the eKYC of banks' customersCBE, circular dated 23 August 2026. Arabic text. Electronic identity verification and remote onboarding, an annual review of the risk management arrangements, and a cybersecurity self-assessment aligned with the CBE framework, verified independently and reported to the CBE
- Central Bank and Banking System Law No. 194 of 2020Official CBE PDF, Arabic text. Confidentiality of customer data (Articles 140 and 142), payment system operators and providers, including protection of electronic systems and incident notification to the CBE (Articles 197 and 198), and penalties for disclosure (Article 231). An English translation was used for reading
- Personal Data Protection Law No. 151 of 2020Official Gazette, 2020. Arabic text. Controller obligations (Article 4), breach notification within 72 hours (Article 7), data protection officer (Article 8), cross-border transfers (Articles 14 to 16), direct marketing (Article 17) and penalties (Article 38). An English translation was used for reading
- Executive Regulations of the Personal Data Protection Law, Decree No. 816 of 2025Official Gazette, issue No. 244 (Supplement A), 1 November 2025, in force on 2 November 2025. Licences and permits, security measures during processing, data protection officer registration and breach reporting procedures. The one-year grace period ends on 31 October 2026. An English translation was used for reading
- Financial Cybersecurity Framework (EG-FinCSF) and cybersecurity pagesCBE. The first edition of the sector framework was circulated in December 2021, and the CBE runs EG-FinCIRT, the computer emergency response team for the financial sector. The framework is circulated to institutions rather than published as a standalone public document, so this page describes it from public CBE material
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 CBE rules
Start with a free scan of your app from the store, or book a demo to run logged-in and shielding tests of your app and APIs with our team.