Uae banking fraud rules push stronger customer authentication

At a glance

What this is: The CBUAE has set stronger authentication and fraud-detection requirements for digital banking and e-wallets, with SMS OTP no longer acceptable as the only control for key financial actions.

Why it matters: IAM teams need to treat banking authentication, transaction approval, and fraud detection as one governance problem across human identity, NHI-driven risk scoring, and channel controls.

By the numbers:

• The institutions covered by the new guidance have until 31 March 2026 to meet most requirements.
• OneSpan says it works with 60% of the 100 largest banks in the world across mobile apps, online banking, ATMs, branch systems, and call centres.

👉 Read OneSpan's analysis of the CBUAE fraud and authentication rules

Context

The CBUAE is changing the baseline for digital banking identity assurance by treating weak authentication and fraud detection as linked controls rather than separate issues. In practical terms, the policy makes SMS OTP, email OTP, and static passwords insufficient on their own for financial transactions and account provisioning.

For IAM teams, the important shift is that consumer identity, transaction approval, device trust, and behavioural fraud signals now need to work together. That is a familiar control pattern in mature banking environments, but the regulation makes it explicit and enforceable across mobile, online, and e-wallet channels.

Key questions

Q: How should banks replace SMS OTP for high-risk transactions?

A: Banks should move high-risk actions to step-up authentication that is bound to the transaction, not the login. That usually means in-app approval, software tokens, device biometrics, or other stronger second factors, plus beneficiary confirmation for payment events. The goal is to make the approval decision harder to intercept, replay, or socially engineer.

Q: Why do weak authentication methods create fraud risk in digital banking?

A: Weak methods create fraud risk because they authenticate a session without proving that the person, device, and transaction are still trustworthy. SMS OTP and static passwords can be stolen, forwarded, or abused in social-engineering attacks. Once attackers reach the session, they can alter beneficiaries, payment details, or account settings before the user realises it.

Q: How do organisations know whether transaction monitoring is working?

A: Transaction monitoring is working when suspicious transfers are interrupted before completion and the risk score reflects the actual behaviour of the session, not just the login event. Useful indicators include blocked anomalous payments, fewer successful account-takeover paths, and consistent escalation on unusual beneficiary or device patterns.

Q: Who is accountable when fraud occurs through weak customer authentication?

A: Accountability depends on the specific channel and control failure, but regulators increasingly place responsibility on the institution when weak authentication remains in use for high-risk transactions. In practice, banks should assume ownership of the decision chain from authentication through confirmation, because the customer cannot be expected to compensate for weak control design.

Technical breakdown

Why SMS OTP and static passwords fail as sole transaction controls

The notice rejects single-factor or weakly protected authentication for financial actions because those methods do not bind the transaction to a trustworthy user or device. SMS OTP can be intercepted, forwarded, or socially engineered, while static passwords are reusable and often exposed elsewhere. The regulatory model is effectively moving banks toward stronger proofing and step-up verification for high-risk events such as card changes, new beneficiaries, and personal data updates. This is not just about login strength. It is about ensuring that the approval event itself is tied to a higher-confidence identity signal.

Practical implication: replace sole reliance on OTP or passwords with transaction-specific step-up controls for high-risk banking actions.

How real-time fraud detection changes identity governance

The guidance treats transaction monitoring as part of identity assurance, not a separate fraud team function. Banks are expected to analyse behaviour in real time, score risk per transaction, and stop or deny suspicious activity before completion. That means identity context now includes velocity, location anomalies, beneficiary patterns, device state, and session signals. In other words, authentication establishes a starting point, but the transaction decision must remain continuously challenged as the session progresses. This is a classic zero-trust pattern applied to consumer banking.

Practical implication: connect authentication events to real-time risk scoring so suspicious transfers can be challenged before they settle.

Why mobile session controls matter for account takeover

The policy explicitly calls for mobile sessions to be suspended when screen sharing, malware, remote access tools, or active calls are detected, and for online banking sessions to block screen-sharing applications. That addresses a common account takeover pattern in which a legitimate user is manipulated during an otherwise valid session. The bank must therefore govern the session environment, not just the credential. This is especially important where fraud occurs through live social engineering rather than stolen credentials alone.

Practical implication: monitor session integrity signals and terminate or suspend sessions when remote-control or screen-sharing conditions appear.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Strong banking authentication now has to be transaction-bound, not login-bound. The CBUAE notice makes a familiar IAM mistake impossible to ignore: assuming that proving identity once is enough for the rest of the session. In high-risk banking, the approval event is the security boundary, not the initial login. Practitioners should read this as a governance shift from access assurance to transaction assurance.

Session-aware fraud controls are becoming part of identity governance. When the policy requires mobile banking to suspend sessions under screen-sharing, malware, or remote access conditions, it effectively extends identity control into the runtime environment. That is a broader control surface than classic MFA or account policy management. Banks that still separate IAM from fraud operations will find their response model too fragmented for this threat pattern.

Beneficiary confirmation is a trust problem, not just a user-interface problem. The requirement to show beneficiary details before transfer confirmation recognises that users are often the final control in the loop. If the interface does not surface enough context, the identity layer is not actually governing the payment event. The failure mode here is not missing authentication strength alone. It is weak transaction intelligibility.

Named concept: transaction-bound identity assurance. The policy pushes banks toward a model where authentication, device trust, behavioural monitoring, and beneficiary confirmation all apply to a single payment decision. That matters because attackers increasingly exploit the gap between who logged in and what the session later authorises. Practitioners should treat that gap as a control boundary, not an edge case.

Fraud regulation is now shaping IAM architecture in the same way privacy rules shaped data controls. The practical consequence is that consumer identity, mobile security, and fraud detection can no longer be designed as separate stacks. The banks that operationalise this most effectively will be the ones that build shared policy decisions across authentication, device posture, and transaction risk. That is where enforcement pressure will land first.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap matters because fragmented control planes often hide exposed credentials until attackers have already used them, a pattern explored in LLMjacking: How Attackers Hijack AI Using Compromised NHIs.

What this signals

Transaction-bound identity assurance: banking programmes will increasingly be judged on whether they can tie authentication to a specific, high-risk action rather than a generic session. That has consequences for access policy design, fraud operations, and customer journey engineering. Teams that still treat authentication as a one-time gate will struggle to satisfy this model, especially where mobile and online channels share the same risk surface.

The regulatory pattern is converging with zero trust. NIST Cybersecurity Framework 2.0 remains a useful organising model for identify, protect, detect, respond, and recover functions, but the practical emphasis here is on detection and response at the point of transaction. Banks should expect more pressure to demonstrate that identity controls can interrupt fraud in-session, not only after the fact.

For practitioners

• Map high-risk banking actions to step-up controls Require stronger verification for card limit changes, security setting changes, new card requests, personal data edits, and first-time device enrolment. Treat these as separate policy points rather than general login events.
• Bind transaction approval to beneficiary transparency Surface beneficiary name, account number, bank details, and account type before transfer confirmation so the customer can validate the payment target. This reduces mistaken-payee and social-engineering risk.
• Instrument mobile session integrity checks Detect screen sharing, malware, remote access tools, and active call conditions, then suspend the session before the payment flow completes. Extend the same control logic to online banking where screen-sharing applications are active.
• Integrate fraud scoring into identity decisions Feed device, location, velocity, and account-behaviour signals into real-time transaction approval so identity assurance is continuously recalculated during the session, not assumed after login.

Key takeaways

• The CBUAE rules move banking security away from single-factor login thinking and toward transaction-specific identity assurance.
• The scale of the problem is visible in the immediate ban on SMS OTP for key 3-D Secure flows and the requirement for real-time fraud interruption.
• Banks that cannot bind authentication, device trust, and beneficiary confirmation into one decision path will remain exposed to account takeover and social engineering.

Key terms

• Step-up Authentication: Step-up authentication is an additional verification step triggered when an action is higher risk than a normal login. In banking, it is used to re-check identity before payments, profile changes, card management, or other sensitive operations, because the original login signal is not enough on its own.
• Transaction-bound Identity Assurance: Transaction-bound identity assurance means the control decision is tied to a specific payment or account action, not just to a user session. It combines authentication strength, device trust, and behavioural context so the institution can judge whether the action itself should be allowed.
• Session Integrity: Session integrity is the state of the live banking session after login, including device posture, active tools, and surrounding risk signals. When screen sharing, malware, or remote access is detected, the session may no longer be trustworthy even if the credentials were valid at the start.

Deepen your knowledge

Banking authentication, step-up verification, and fraud-aware session controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for regulated digital banking, it is worth exploring.

This post draws on content published by OneSpan: La Banque centrale des Émirats arabes unis renforce la protection des consommateurs contre la fraude. Read the original.