CBUAE Notice 2176: prove your mobile banking app holds up against fraud.
UAE law makes robust fraud prevention and detection a legal duty for licensed financial institutions, and the Central Bank's Notice 2176 focuses on mobile banking fraud. Public CBUAE rules already set expectations for authentication, sessions, APIs, device protections and testing. Ostorlab tests how your app's defenses behave on rooted and jailbroken devices, behind login, and in the APIs that move money.
- Checks root and jailbreak detection, anti-tampering and anti-instrumentation, and what the app does when they trigger
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Follows the app into the payment APIs, even with TLS pinning
- Proves each failure with bypass evidence or a replayable exploit
- Who it applies to
- Licensed financial institutions in the UAE
- Legal basis
- Federal Decree-Law No. 6 of 2025, Article 149, in force since 16 September 2025
- Focus of Notice 2176
- Mobile banking fraud
- Status of the notice
- Not published in the public CBUAE Rulebook
The CBUAE rules behind the mobile channel
Notice 2176 lands on top of rules that have been in force for years. The dates below are for the public texts cited on this page.
- 30 October 2020
SVF Regulation
Technology risk rules for stored value facilities, which also apply to licensed banks carrying out stored value business.
- 6 June 2021
Retail Payment Services Regulation
Technology risk, authentication and session rules for payment service providers, with best-practice guidance in Annex II.
- 15 November 2021
Enabling technologies guidelines
Guidance on APIs, including authentication, multi-factor authentication and yearly independent testing.
- 16 September 2025
Federal Decree-Law No. 6 of 2025
Article 149 makes robust fraud prevention and detection a legal duty for licensed financial institutions.
- Date not public
Notice 2176
Actions on mobile banking fraud for supervised institutions. The notice is not published in the public Rulebook.
- Every quarter
Reporting to the CBUAE
Fraud-related complaints and apparent vulnerabilities in security and online systems are reported quarterly, and a fraud report is filed every year by 31 January.
The CBUAE's fraud and security rules, applied to your mobile app
Notice 2176 sits alongside public CBUAE rules on fraud, consumer protection, payments and technology risk. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- Federal Decree-Law No. 6 of 2025, Article 149
Run robust fraud prevention and detection
What the text says
Licensed financial institutions must implement robust fraud prevention and detection mechanisms to protect customers against unauthorized transactions, social engineering, identity theft and other fraud. The CBUAE may set minimum security standards for digital banking, including authentication protocols, and institutions must implement the preventive measures it prescribes within the deadlines it sets.
What it means for your mobile app
Fraud prevention is a legal duty, and the CBUAE sets the minimum controls. For most banks, the mobile app is where customers authenticate and pay, so it is where many of those controls live.
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, fraud operations and meeting the CBUAE's deadlines.
- Consumer Protection Standards, Articles 6.1.1.4 and 6.1.1.8
Keep every delivery channel secure
What the text says
Provide a safe, secure and confidential environment in all delivery channels. Secure digital transaction processing and controls, implement detailed activity monitoring and enhance consumer identification methods in line with the Central Bank's requirements for strengthening digital channels.
Source:Consumer Protection Standards, Articles 6.1.1.4 and 6.1.1.8
What it means for your mobile app
The mobile app is a delivery channel. The data it stores and sends, and the transactions it starts, need protection from the device to the backend.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks for misconfigurations that weaken transport and session protections, and tests the APIs behind transactions.
What stays with you
Activity monitoring and the identification methods you choose.
- Consumer Protection Standards, Article 6.1.1.7; Retail Payment Services and Card Schemes Regulation, Article 13
Authenticate strongly, and again for high-risk actions
What the text says
Apply more than one evidence of identity verification for electronic services. For payment service providers, multi-factor authentication is required for high-risk transactions, with re-authentication, such as two-factor authentication, before each one, including payments over predefined limits and changes of personal contact details.
What it means for your mobile app
Step-up checks on payee changes, limit increases 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 setting transaction limits.
- Retail Payment Services and Card Schemes Regulation, Article 13
Limit login attempts, sessions and one-time password validity
What the text says
Limit the number of login and authentication attempts, implement time-out controls and time limits for the validity of authentication, keep one-time password validity to the strict minimum necessary, and encrypt passwords end to end between the mobile app and the system that verifies them.
Source:Retail Payment Services and Card Schemes Regulation, Article 13
What it means for your mobile app
These are concrete, testable settings: lockout after failed attempts, session expiry, one-time password lifetime and replay, and password protection in transit.
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 policy values themselves, such as the lockout threshold and one-time password lifetime.
- Retail Payment Services and Card Schemes Regulation, Annex II
Treat customer devices as exposed
What the text says
CBUAE guidance for payment service providers says customer devices should be assumed to be exposed to security vulnerabilities, with measures against unauthorized device access, malware, compromised or insecure mobile devices, and unauthorized mobile apps.
Source:Retail Payment Services and Card Schemes Regulation, Annex II
What it means for your mobile app
Rooted phones, repackaged apps and runtime hooking tools are the conditions banking malware works in. Protections should react, not just detect.
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. You get a hardening score and bypass evidence.
What stays with you
Choosing and configuring your shielding or runtime protection product.
- Guidelines for Financial Institutions Adopting Enabling Technologies, APIs: Design, 3.11 to 3.18
Secure your APIs and test them independently every year
What the text says
Use access management and authentication so only authorised parties reach API resources, and implement authentication so attackers cannot compromise tokens or assume other users' identities. Use multi-factor authentication when a customer first accesses an online service that uses APIs, separate administrator and user roles, and limit the size or number of resources a user can request. An independent function or external expert should run vulnerability assessments and penetration tests at least annually.
Source:Guidelines for Financial Institutions Adopting Enabling Technologies, APIs: Design, 3.11 to 3.18
What it means for your mobile app
The APIs behind the app need the same scrutiny as the app: at least yearly by someone independent, and ideally on every release.
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
Choosing who performs the independent annual assessment, and API design.
- SVF Regulation, Article 12; Retail Payment Services and Card Schemes Regulation, Annex II
Review code and test before release
What the text says
Adopt secure development standards and risk-based source code reviews, including automated analysis. Only properly tested and approved systems should reach production, with tests covering business logic and security controls. Use automated tools and manual techniques for regular vulnerability assessments, and regularly assess the need for penetration and cyber-attack simulation testing.
Source:SVF Regulation, Article 12; Retail Payment Services and Card Schemes Regulation, Annex II
What it means for your mobile app
Each release of the app should pass automated security testing before it reaches the store, with deeper testing for high-risk changes.
How Ostorlab helps
Mobile SAST analyses the binary, including embedded SDKs, and Mobile DAST tests the running app; both run in CI/CD. The AI-agent pentest tests the business logic of payment and account flows.
What stays with you
Manual reviews, user acceptance testing, segregation of duties and release approval.
- Consumer Protection Standards, Articles 5.1.1.45, 6.2.1.11 and 6.2.3.3
Be able to show your controls were secure
What the text says
Transactions are considered authorized if proper and secure validation procedures were applied, unless the consumer can show reasonable doubt. Institutions may be liable for direct losses caused by breaches of their security controls, and must report apparent vulnerabilities in their security and online systems to the Central Bank every quarter.
Source:Consumer Protection Standards, Articles 5.1.1.45, 6.2.1.11 and 6.2.3.3
What it means for your mobile app
When a disputed transaction or a loss claim comes in, it matters that you can show your validation procedures were secure and tested.
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 dispute process, the quarterly reports and the legal assessment.
- CBUAE Notice 2176, not publicly available
Notice 2176: act on mobile banking fraud
What the text says
Notice 2176 sets out actions on mobile banking fraud for the institutions the CBUAE supervises. It is not published in the public CBUAE Rulebook, so this page does not quote it.
Source:CBUAE Notice 2176, not publicly available
What it means for your mobile app
Treat each point of the notice like the public rules above: link it to a control in the app or the backend, a test, and an owner.
How Ostorlab helps
Once you have mapped the notice, Ostorlab can test the app and API controls it covers and give you evidence for each one.
What stays with you
Reading the notice, mapping it to your controls and reporting to the CBUAE.
Summary of public CBUAE texts, checked on 27 September 2026. Some texts apply to specific licence types, as noted. This page is not legal advice.
CBUAE rules, control by control
The controls the public CBUAE 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 |
|---|---|---|
| Protections against compromised devicesRetail payments, Annex II | 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 |
| Protections against tampering and repackagingRetail payments, Annex II | Modifies the binary and checks whether the app blocks execution. Details | Pass or fail rating for anti-tampering |
| Protections against runtime hookingRetail payments, Annex II | Injects debuggers and hooks and adapts the attempt to get past anti-instrumentation defenses. Details | Evidence of which protections held and which were bypassed |
| Multi-factor authentication and re-authentication for high-risk actionsCPS 6.1.1.7; retail payments, Art. 13 | 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 |
| Login attempts, time-outs and one-time password validityRetail payments, Art. 13 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| API authentication, token security and access controlEnabling technologies, 3.11 to 3.17 | 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 |
| Data protection on the device and in transitCPS 6.1.1.4 | 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 |
| Code review and testing before releaseSVF, Art. 12; retail payments, Annex II | Mobile SAST and DAST in CI/CD, and an AI-agent pentest of the business logic. Details | Scan results for each build, and a replayable exploit for each AI-agent finding |
| Hardcoded credentials in the appCPS 6.1.1.4 | 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 |
| A record of secure, tested controlsCPS 5.1.1.45, 6.2.1.11, 6.2.3.3 | Keeps scan results, tickets and retests for each release. | Dated scan history, tickets and retest results |
Ostorlab tests controls in the app and its APIs. Transaction monitoring, fraud operations, customer awareness and reporting to the CBUAE stay with your teams.
Mobile fraud controls to test in your app
A practical list for security and fraud teams. Use it together with your copy of Notice 2176.
Compromised devices
Run the app on rooted and jailbroken devices and check that protections trigger and the app reacts.
Repackaged and hooked apps
Try a modified build and runtime hooks, and confirm that the app refuses to run or blocks sensitive flows.
Step-up on high-risk actions
Check that adding a payee, changing contact details and exceeding limits all require re-authentication, enforced by the server.
Login and one-time password settings
Verify lockout after failed attempts, session time-outs, one-time password lifetime and replay protection.
APIs behind payments
Test authorization on every payment and account API, including requests for other customers' data and repeated requests.
Data left on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and for credentials hardcoded in the app.
Independent yearly test
Plan the independent vulnerability assessment and penetration test of your APIs, at least annually, that the enabling technologies guidelines call for.
Evidence for reporting
Keep results and retests for each release, to support quarterly reporting and the handling of disputed transactions.
A suggested list, not a CBUAE template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- 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 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
- 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.
- CBUAE Rulebook: Federal Decree-Law No. (6) of 2025, Article (149) Fraud PreventionApplies to all licensed financial institutions, effective from 16 September 2025
- CBUAE Rulebook: Consumer Protection Standards, Article 5: Business ConductIncludes the rules on unauthorized transactions (5.1.1.43 to 5.1.1.46)
- CBUAE Rulebook: Consumer Protection Standards, Article 6: Protection of Consumer Data and AssetsSecure delivery channels, identity verification, fraud detection, liability and quarterly reporting
- CBUAE Rulebook: Retail Payment Services and Card Schemes Regulation, Article (13) Technology Risk and Information SecurityBinding rules for payment service providers on authentication, sessions, APIs and penetration testing, effective from 6 June 2021
- CBUAE Rulebook: Retail Payment Services and Card Schemes Regulation, Annex IIGuidance on the best practices for technology risk and information security for payment service providers
- CBUAE Rulebook: Stored Value Facilities Regulation, Article (12) Technology and Specific Risk ManagementAlso applies to licensed banks carrying out stored value business, effective from 30 October 2020
- CBUAE Rulebook: Guidelines for Financial Institutions Adopting Enabling Technologies, APIs: DesignAPI authentication, access control and yearly independent testing, issued on 15 November 2021
- CBUAE Notice 2176Sent to supervised institutions and not published in the public CBUAE Rulebook, so it is 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.
Check your mobile banking app's fraud defenses
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.