In April 2026, the Central Bank of the UAE issued Notice No. 2176.2026 in response to malware affecting Android devices in the UAE. Its 20 requirements cover immediate customer protections, transaction controls, mobile threat detection, runtime application self-protection, API security, and incident evidence.
The message for bank leaders is that authentication and backend fraud monitoring remain essential. But they can’t show everything happening inside a customer’s mobile session.
For example, a customer may authenticate successfully while malware observes the screen or abuses Android accessibility services. The app may be running on a rooted device or inside an emulator. Or local evidence may disappear before investigators can examine it.
Notice 2176 responds to these risks with specific technical and operational requirements. For UAE banks, payment providers, and other financial institutions, the mobile app now needs to be treated as an active fraud control point.
This is where Promon Shield for Mobile™ operates. Applied post-compile and embedded in the app, it detects threats such as rooting, hooking, emulation, repackaging, tampering, and malware at runtime. It can then report the threat or respond according to the institution’s policy, without requiring source-code changes.
While Notice 2176 is the immediate priority, it doesn’t stand alone. Notice 3057 and the CBUAE’s wider regulatory framework have already increased the focus on fraud prevention across digital banking and payment services.
Article 149 of the CBUAE Rulebook requires Licensed Financial Institutions to implement fraud prevention and detection mechanisms. These controls must help safeguard customers against unauthorized transactions, social engineering, identity theft, and other fraudulent activity.
CBUAE oversight also extends across stored value facilities, retail payment systems, payment service providers, and card schemes. The regulator’s payments and settlements framework reflects the scale of that responsibility.
Notice 2176 turns this wider direction into a more immediate mobile security task. It tells financial institutions where Android malware is creating risk and where controls need to improve.
Many mobile fraud controls begin with identity. They assess who is logging in, whether the device is recognized, and whether the transaction fits the customer’s normal behavior.
Modern Android malware can operate inside that trusted journey. It may watch the screen, control input, intercept messages, exploit accessibility permissions, or guide the customer through a fraudulent payment. To the backend, the activity may still appear to come from an authenticated user.
Read more: PlayPraetor malware: Why banking apps need protection from the inside out
Banks therefore need evidence about the condition of the app and its runtime environment. They also need the ability to act on that evidence during the session.
Notice 2176 reflects this need in several concrete requirements.
Requirement 6 calls for Google Play Integrity API checks whenever the application launches. These checks should identify rooted devices, emulators, and tampered app binaries.
Promon Shield for Mobile™ can run Play Integrity checks at launch and add its own runtime detections. This gives the bank evidence about whether the app and device meet its security policy.
The requirement also calls for suspicious outward transfers to newly added beneficiaries to be blocked under defined conditions when integrity checks fail. Shield provides the integrity signal and protects the app. The bank or its fraud platform must use that signal when applying the transaction rule.
Requirement 10 explicitly calls for Mobile Threat Defense or Runtime Application Self-Protection controls. It identifies rooted or jailbroken devices, custom ROMs, and system tampering as areas that need attention.
Shield is embedded into the compiled app after build. It provides the in-app runtime application self-protection (RASP) layer called for by Notice 2176. Because it operates inside the application, it can detect and respond where runtime attacks take place.
This gives banks a RASP layer that operates inside the application where the attack is taking place.
Read more: What is RASP and how does it secure web apps vs. mobile apps?
Android accessibility services support legitimate users, but malware can abuse them to read screens, capture text, control input, and escalate privileges.
Requirement 11 calls for application-level controls that can detect and block this abuse. Shield can identify accessibility-service activity that breaches the bank’s policy and stop the app from operating in that environment.
The response must be configured carefully. Banks need to block malicious use without unnecessarily excluding customers who rely on legitimate accessibility features.
Requirement 13 calls for network-level detection of a hardcoded Alibaba Cloud Simple Log Service exfiltration header associated with the malware.
Requirement 13’s header detection belongs within the bank’s network security controls. Promon Verify™ adds a complementary layer at the app-to-API boundary. It cryptographically validates requests and checks the integrity of the app and its runtime environment. Banks can reject requests from modified, repackaged, emulated, or otherwise untrusted clients before they reach protected APIs.
This helps prevent a compromised client from being treated as a trusted application, even when malware is present on the device.
Requirement 18 recognizes that advanced malware may delete local logs, SMS messages, and browser history. It therefore calls for detailed server-side evidence that can help investigators reconstruct an attack.
Promon Insight for App Security™ collects structured runtime telemetry from Shield-protected apps. Events are timestamped, severity-tagged, and can be forwarded to SIEM, fraud, or compliance systems.
Verify’s server-side integration also allows attestation outcomes to be recorded alongside backend activity. This helps institutions preserve evidence outside the device, where local malware cannot simply delete it.
Notice 2176 contains 20 requirements. Promon protections can’t act as the answer to all of them.
Banks still need controls for biometric authentication, transaction limits, cooling-off periods, GPS anomalies, command-and-control traffic, customer communications, and regulatory reporting. These responsibilities sit across fraud operations, identity systems, network security, customer service, and compliance.
Promon strengthens the parts of the response that depend on the condition of the mobile app, the integrity of its runtime environment, trusted access to APIs, and evidence of what happened during the session.
For organizations using LexisNexis® ThreatMetrix®, these capabilities can extend the information already available to fraud teams. ThreatMetrix provides digital identity, device, and behavioral intelligence. Shield protects the app and produces trusted runtime signals. Insight makes those signals available for investigation and decision-making.
The strategic alliance between LexisNexis Risk Solutions and Promon is designed to bring these control layers together. Existing fraud decisions can then account for whether the mobile app and its runtime environment can be trusted.
A Notice 2176 review should begin with the controls already in production.
Confirm that Play Integrity checks run at every required application launch and that failed checks produce the intended response.
Test whether the app detects rooted devices, emulators, tampered binaries, custom ROMs, and runtime manipulation.
Check how the app responds when malware abuses Android accessibility services.
Verify that compromised or unauthorized clients cannot make trusted calls to banking APIs.
Confirm that runtime evidence reaches server-side security, fraud, and investigation systems before it can be lost from the device.
The aim is to identify which requirements are already covered, where a control only provides part of the answer, and where new protection or integration is needed.
Notice 2176 gives UAE financial institutions a clear reason to examine the mobile layer now. A documented control is not enough if it fails when malware is active during a real customer session.
Promon helps banks protect Android apps after build, enforce runtime controls, verify trusted API access, and preserve evidence for fraud and security teams. These capabilities can be added without redesigning the banking journey or placing a new SDK integration burden on developers.
CBUAE Payments and Settlements Regulations and Standards
CBUAE Rulebook: Article 149, Fraud Prevention
CBUAE Notice No. 2176.2026: Urgent Action Required – Malware Affecting Android Devices in the UAE