TL;DR: The Central Bank of the UAE has issued new rules that ban SMS OTP, email OTP, and static passwords as sole methods for financial transactions and account provisioning, while requiring step-up authentication, real-time fraud detection, and stronger beneficiary confirmation, according to OneSpan. The shift makes authentication quality, transaction monitoring, and mobile session controls central to banking identity governance.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: New CBUAE banking fraud rules tighten authentication, beneficiary confirmation and session controls across digital banking channels.
Why it matters: It matters because IAM and fraud teams in regulated financial services now need to align authentication strength, transaction risk checks and mobile-session controls with a regulator-backed control model.
Context
The central issue is not just stronger login security, but the failure of single-factor and weak-factor authentication to withstand modern banking fraud. In this regulatory model, identity assurance must extend from first access through transaction approval, beneficiary verification and mobile-session protection.
For IAM practitioners, the important shift is that authentication, fraud detection and customer approval are now treated as one operating chain rather than separate controls. That changes how banks design digital onboarding, account changes, step-up authentication and high-risk payment flows.
The article is about banking identity governance for consumer access. The article's assumptions are typical for regulated retail banking, but the CBUAE rules make the control gap more explicit and more operationally binding.
Key questions
Q: What breaks when banks rely on SMS OTP as the only transaction authentication method?
A: Banks expose themselves to account takeover and transaction fraud because a stolen or relayed OTP proves only that a code was received, not that the session, device, or transaction is trustworthy. Once the attacker controls the channel or the user is socially engineered, the code becomes a weak hurdle rather than a real assurance step.
A: Because the attacker’s goal is usually not just login, but misuse of an authenticated session to move money or alter account settings. When regulators make banks accountable for fraudulent outcomes, authentication has to be tied to transaction intent, beneficiary verification and runtime session safety rather than treated as a separate front-door control.
Q: What are the warning signs that a digital banking session may already be compromised?
A: Screen sharing, active remote-access tools, unexpected malware signals and live phone calls during sensitive banking actions are all signs that the session may be under pressure or takeover. Banks should treat these signals as evidence that authenticated access is no longer trustworthy and suspend the session before fraud can complete.
Q: What should banks do when a regulator makes fraud detection part of authentication governance?
A: They should connect identity assurance, transaction monitoring and account-risk analytics into one control plane. That means step-up rules, beneficiary checks, mobile-session protection and anomalous-activity detection need to trigger from the same governance model, so fraud prevention is enforced at the point of action rather than after the loss.
Technical breakdown
Why weak factors no longer satisfy financial transaction assurance
The notice treats SMS OTP, email OTP and static passwords as insufficient when used alone for transactions and account provisioning. That matters because these methods prove possession of a channel or knowledge of a secret, but they do not reliably bind the session to a trusted device or a verified customer action. The rule set therefore shifts assurance toward stronger factors such as in-app confirmation, device biometrics and secured secondary-channel approval. For banks, this is an identity assurance problem, not just an MFA preference.
Practical implication: replace single-factor transaction flows with layered authentication that ties approval to a trusted device and a verified second channel.
How beneficiary confirmation changes payment authorisation
Beneficiary confirmation is a control that forces the customer to validate payee details before a transfer is completed. In the UAE rules, that includes name, account number, banking details and account type for domestic transfers, plus name verification for instant payments. This is important because fraud often succeeds when the customer approves a transfer that looks routine but routes funds to an attacker-controlled destination. The control shifts authorisation from purely user-initiated payment intent to payment intent plus explicit payee verification.
Practical implication: build beneficiary verification into payment journeys so the customer confirms the destination, not only the amount and recipient label.
Why mobile-session controls now sit inside fraud governance
The rules extend beyond authentication into session security. Financial institutions must suspend mobile banking sessions when screen sharing, malware, remote-access tools or active calls are detected, and they must prevent online sessions from continuing when screen-sharing apps are active. This is a governance response to session takeover and social engineering patterns, where the customer is technically authenticated but operationally compromised. In practice, identity assurance now includes runtime context, not just initial login state.
Practical implication: monitor mobile and web sessions for takeover indicators and terminate or suspend activity when the runtime context becomes unsafe.
Threat narrative
Attacker objective: The attacker wants to complete fraudulent banking activity while appearing to act as an authenticated customer.
- Entry occurs when attackers exploit weak customer authentication paths such as SMS OTP, email OTP or static passwords used as sole verification for financial activity.
- Escalation happens when the attacker moves from login access to fraudulent transaction authorisation, beneficiary manipulation or account-setting changes that require stronger proof but do not receive it.
- Impact is financial fraud completed through authorised-looking transfers, account provisioning abuse or compromised mobile banking sessions that defeat user intent.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Weak-factor authentication is no longer a sufficient control boundary for regulated banking. The CBUAE rules show that customer identity assurance must now be evaluated at the transaction layer, not just the login layer. That is a structural shift for IAM teams because the control that matters is the one that binds the customer to a high-risk action, not the one that merely opens the session.
Beneficiary verification is becoming a governance control, not a UX enhancement. Once banks are responsible for validating payee identity before transfer completion, payment workflows become part of identity governance and fraud governance at the same time. The implication is that authorisation design, customer confirmation design and fraud monitoring can no longer be managed as separate programmes.
Runtime session context is now part of the identity model. A banking session that remains active while screen sharing, remote access or malware is present is no longer a trustworthy identity event. The practical conclusion is that banking IAM must incorporate behavioural and environmental signals into assurance decisions, because static authentication state does not describe the real risk.
Confirmation without resistance to takeover is incomplete control. The rules recognise that an authenticated customer may still be under social engineering or remote access pressure. That makes transaction approval a contested identity event, not a simple consent step. Practitioners should treat fraud controls, session controls and authentication assurance as one operating model rather than separate control towers.
Regulated banking is moving toward continuous assurance across the payment journey. The strongest reading of the CBUAE notice is that banks must prove who is acting, what they are approving and whether the session is safe at each decision point. For identity leaders, that means the governance boundary has moved from account access to transaction confidence.
What this signals
Beneficiary verification is the new control point: banks that only verify the customer but not the payee are leaving the final fraud decision too late in the journey. The operational question is whether your payment flow proves both the actor and the destination before money leaves the account.
The CBUAE notice also shows that mobile banking security can no longer stop at app login. When screen sharing, remote access or malware is visible during a session, the identity event is no longer trustworthy and the safest response is to interrupt the session rather than accept the risk.
For practitioners, this is a programme-design issue as much as a compliance issue. Fraud controls, authentication policy and customer experience now have to be designed together, because a high-friction step that arrives too late will not reduce the real attack window.
For practitioners
- Replace sole-factor transaction approval Remove SMS OTP, email OTP and static passwords as standalone approval methods for financial transactions and account provisioning, then map each high-risk journey to stronger second-channel or device-bound proof.
- Embed beneficiary verification into payment flows Show payee name, account number, bank details and account type before transfer completion so the customer confirms the destination, not only the payment amount.
- Add runtime session-risk interruption Suspend mobile and online banking sessions when screen sharing, malware, remote-access tools or active calls are detected, and prevent continuation when screen-sharing apps are present.
- Rework step-up triggers around change events Trigger stronger authentication for card limits, security settings, new card requests, payments and personal-data changes so sensitive actions cannot ride on an old login state.
- Align fraud monitoring with account-risk signals Correlate dormant-account activity, unusual withdrawals, location anomalies and mule-account indicators so fraud detection is tied to account behaviour, not just authentication events.
Key takeaways
- The CBUAE rules treat weak authentication as an insufficient defence for digital banking, especially when the same session can be used to authorise payments or change account settings.
- The article shows that beneficiary confirmation, real-time fraud detection and session interruption are now part of the same control stack, not separate security projects.
- Banks that keep SMS OTP or static passwords as sole approval methods will need to redesign authentication journeys around higher-assurance verification and runtime risk checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article is centered on stronger customer authentication for regulated banking transactions. |
| Recommendation — Apply SP 800-63B to strengthen authentication assurance for customer login and high-risk transaction approval. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The notice ties access assurance to transaction-level authorization and step-up decisions. |
| PR.DS-10 — Integrity Verification | Beneficiary confirmation and anti-tamper session controls both protect the integrity of customer actions. | |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The article requires real-time fraud and session monitoring across mobile and online banking. | |
| Recommendation — Use PR.AA-05 to govern who can approve high-risk banking actions and when step-up is required. Apply PR.DS-10 to verify payment details and session integrity before sensitive actions complete. Use DE.CM-01 to monitor banking sessions for takeover indicators and fraudulent behaviour in real time. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The article references secure secondary channels and stronger verification methods for customer approval. |
| Recommendation — Apply A.8.24 to protect approval channels and cryptographic verification used in banking transactions. | ||
Key terms
- Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
- Beneficiary Verification: The process of confirming who will receive value before a transfer is completed. In regulated crypto environments, it reduces misdirection, sanctions exposure, and fraud risk by ensuring the receiving account and associated identity details are trusted enough for the transaction being attempted.
- Session risk: The changing level of trust assigned to an active login or token after it has been issued. Session risk reflects device state, application context, privilege depth, and behavior, so a session that began legitimately can become unsafe before it ends.
- Transaction Authentication: Transaction authentication is the control layer that validates the trustworthiness of a digital interaction after identity has been established. It focuses on confidentiality, integrity, and availability of the exchange itself, which makes it especially relevant when sign-in alone does not protect the action.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org