From the banking app’s perspective, the session may look legitimate: the correct customer is using a registered device and completing the expected authentication flow. From the perspective of UAE banking app fraud prevention teams, however, the customer may be acting under real-time influence from an attacker.
This is the problem that modern authentication alone cannot solve. Vishing attacks UAE can go beyond passkeys, biometrics and in-app approvals which make it harder to steal credentials or intercept codes, but they do not automatically prove that a customer understands the transaction they are approving.
In this guide, we will cover how vishing attacks UAE operate and how to prevent vishing attacks in UAE banking. You will learn how they manipulate UAE mobile-banking sessions, why authentication and intent are different security questions, and how active call detection can provide an additional risk signal inside your banking app.
What Is Vishing and How Does It Work?
Vishing is short for "voice phishing" and it's a type of phone-based social engineering scam where attackers can use voicemails or voice calls to trick you into revealing sensitive information. Sometimes they may coerce the individual over the phone to send them money.
But they're not random, vishing is targeted. Scammers take their time to collect personal, corporate, and financial details from social media, public records, banking apps, and past data breaches. They use VoIP technology to fake the phone number that's displayed, which makes the incoming phone call appear legitimate, almost as if it's coming directly from the bank itself.
Some scammers may start off by sending you a fake SMS or email and prompt you to call a specific banking customer service number. Since these texts contain no malicious link, they can bypass traditional email security filters.
Vishing scams UAE use lures to convince you into handing over multi-factor authentication codes, passwords, credit card numbers, and even trick you into installing remote desktop software to "fix" banking app issues and approve fraudulent transactions.
How Vishing Attacks Can Hijack a Banking Session
There is a sequence that vishing attacks follow when it comes to hijacking banking sessions. Eight steps, generally taking less than fifteen minutes.
● The customer gets a phone call from a spoofed number from their bank.
● The caller introduces himself as being part of either fraud operations, compliance, or the government agency.
● He informs the customer of a problem, such as a fraudulent transaction, blocked card, or pending transfer.
● The caller asks the customer to log into their banking application to "verify" or "reverse" the issue.
● The customer logs into the application in the usual way, using their biometrics or passcode.
● The caller then walks the customer through the process, staying on the line.
● The customer enters a code, approves an in-app prompt or completes another security-sensitive action under the caller’s direction.
● An additional beneficiary is added, or the transfer takes place.
Take note of the absence of certain things. Nothing is ever directly hacked. All steps were conducted by the actual customer on his or her own registered device and in a proper session. Mobile banking session hijacking UAE cases rarely entail the hacking of the credentials, since the attacker focuses on the customer and gets their guard down to slip past through.
Why Traditional Authentication Alone Cannot Stop Vishing?
Authentication answers: Is this the right person?
Vishing does not dispute it. It is the right person, being told what to do.
SMS OTP failed on a different axis and CBUAE was right to retire it. Codes could be intercepted through SIM swap, read by malware from the notification shade, or talked out of a customer.
The guidelines on digital identity provided by NIST provide an explanation for this. Authentication in mobile banking security UAE proves that a claimant controls the authenticator but it does not prove that the claimant understands what the transaction is all about or that he is being forced to perform the act.
But replacing OTP with passkeys or in-app approvals solves interception, not instruction. A customer persuaded to read a code aloud can be persuaded to press a button. MFA confirms identity without establishing intent, so a fraudster coaching somebody through a legitimate flow never defeats a control. Every control returns true.
Which is why CBUAE guidance points toward risk-based and adaptive authentication, with stronger checks on high-risk activity like adding payees and high-value transfers. Mobile banking fraud prevention has to read the situation a transaction happens in.
What Happens Inside the Mobile App During a Vishing Attack?
From the perspective of the application itself, virtually everything is perfect. The user is authenticated successfully and is using a bound device; they are logged in.
What the application does not know is who is giving instructions verbally.
The app may not know the caller’s identity or intent, but it can observe contextual signals. The payee is added ninety seconds after the login by the customer who has not added one in two years. Direct navigation to the transfer page. Hesitation between tapping buttons because somebody is waiting for the next instruction. And in most cases, there is also an ongoing voice call during the session.
None of these, separately, could be used as a proof of the fraudulent activity. All together they indicate the involvement of another person into the session.
Banking app session security depends on signals the authentication layer never collects.
What Is Active Call Detection?
Active Call Detection is a runtime control that allows a mobile app to know whether or not there is a voice call in progress at any point in time while the app is running.
The mobile app uses OS APIs to know the status of the phone call. The app knows that there is a call in progress. This is all it knows.
And for those reviewing this from a privacy perspective: detecting a call is not monitoring a conversation. There is no recording, no transcription, no knowledge of what is being discussed or by whom, since the signal is binary.
Used alone it means little, since plenty of people take calls while checking a balance. Fed into a risk engine with session context it becomes useful, because the combination carries the information: an active call plus a first-time payee addition plus a high-value transfer is a different picture from a call during a balance check.
Active call detection for banking apps turns device state into a fraud signal, the one input correlating directly with the attack method.
How Active Call Detection Can Stop Vishing Inside the App
The control flow fits in one line:
Active Call Detected → Sensitive Session Identified → Risk Control Triggered → Session Suspended or Transaction Restricted → Customer Ends Call → Session Resumes
● Real-time detection. The app registers an active call while the session is live, without touching audio.
● Sensitive-session identification. Policy decides which screens matter. Balance enquiry, no. Beneficiary addition, high-value transfer, limit change, yes.
● Automated session suspension. The app pauses the action and explains why, in plain language.
● Transaction restriction. Where suspension is too blunt, cap the amount, enforce a cooling-off window, or step up once the call ends.
● Customer notification. An honest message does real work: "For your security, we have paused this transfer while you are on a call. Banks never ask you to make transfers over the phone." That breaks the spell more often than any campaign.
● Event logging. Every trigger recorded with timestamp, device state and action taken, which is what a CBUAE examiner asks for.
That is how active call detection prevents vishing: not by identifying the fraudster, but by interrupting the moment a customer is least able to think clearly.
What Active Call Detection Cannot Prove
An active call is a risk signal, not proof that fraud is taking place. Customers may legitimately check their account while speaking with family, colleagues or a bank representative. A call may also be placed through a channel or device state that the app cannot reliably identify.
For that reason, banks should avoid treating call status as an automatic fraud verdict. A more proportionate design combines it with signals such as:
● Whether the customer is creating a new beneficiary.
● Whether the payment amount differs significantly from the customer’s normal behaviour.
● Whether the device, location or network posture has changed.
● Whether remote-access, screen-sharing, overlay or accessibility-abuse indicators are present.
● Whether the session shows unusual navigation or repeated failed attempts.
● Whether the customer has recently logged in, changed a limit or enrolled a new device.
The response should be proportionate to the combined risk. Possible actions include a clear warning, a confirmation showing the beneficiary and amount, a cooling-off period, an out-of-band callback through a trusted channel, session suspension during vishing calls, temporary transaction restriction, or referral to a fraud analyst.
Other Mobile Security Controls That Can Stop Vishing-Enabled Fraud
Active call detection covers the coached customer. Vishing often arrives bundled with other techniques, so mobile application protection against vishing needs the wider set. This is where runtime protection against banking fraud earns its place.
● Runtime Application Self-Protection (RASP) - detection inside the app rather than the network. See the RASP complete guide.
● Device binding - ties the account to one verified handset.
● Risk-based authentication - friction that scales with signal strength.
● Transaction monitoring - scoring payments against that customer's own history.
● Malware detection - banking trojans that read screens and forward messages.
● Overlay attack detection - fake screens drawn over the real app.
● Remote-access Trojan detection - the attacker operating the device directly.
● Screen-sharing detection - the usual escalation when a caller says "let me show you."
● Root and jailbreak detection - compromised devices where the OS stops enforcing boundaries.
● Anti-tampering - app shielding so controls cannot be patched out.
● API security - protecting the mobile-to-backend path.
● Session protection - timeouts, attempt limits, re-verification on posture change.
Layered properly, these prevent social engineering attacks in banking apps from completing, even when the customer cooperates fully. All of them are an important part of CBUAE mobile app security.
Vishing vs Malware vs Remote Access Attacks
Attack | Primary Technique | Risk to Banking Session | Key Protection |
Vishing | Social engineering over phone | Customer performs attacker-directed actions | Active call detection + risk controls |
Malware | Malicious software on device | Credentials and data can be compromised | Malware and RAT detection |
Overlay attack | Fake screen over banking app | Credentials and OTP can be captured | Overlay detection |
Remote access | Attacker controls device remotely | Transactions can be manipulated | RAT and screen-sharing detection |
App tampering | Modified application | Security controls may be bypassed | Anti-tampering and app shielding |
What CBUAE Expectations Mean for Mobile Banking Security
CBUAE's direction of travel is consistent: move authentication off interceptable channels, and hold institutions accountable for outcomes.
Notice 2025/3057 did both. Alongside the OTP phase-out completed on 31 March 2026, it shifted liability: where fraud traces back to OTP-based authentication, the institution reimburses the customer. Gulf News reported the rollout as it began in July 2025.
CBUAE mobile banking security controls translate into concrete expectations. Anti-fraud controls have to be demonstrable rather than described. Customer protection extends to social-engineering cases the customer initiated. Session management needs attempt limits and timeouts. Authentication should be risk-based, with audit trails detailed enough to reconstruct a disputed payment.
Continuous risk assessment runs through all of it, and it reshapes which mobile banking security solutions UAE institutions buy. A control evaluating risk once at login cannot satisfy a framework expecting assessment throughout the session, which is where CBUAE vishing protection and CBUAE active call detection conversations land.
Active Call Detection vs Customer Awareness
Both matter, at different moments. Conflating them is how banks end up with awareness campaigns as their only line of defense.
Customer awareness tells customers never to share OTPs and helps them recognize suspicious calls. It depends entirely on the customer applying that knowledge while frightened, rushed and spoken to by somebody who sounds official. Awareness works in the classroom. It fails in the moment, which is the only moment that counts.
Active call detection works inside the application. It identifies an active call during a sensitive session, triggers automated controls without waiting for the customer to reach a conclusion, and creates a pause the fraudster did not plan for.
The strongest strategy runs both. Education lowers how many customers answer. Application-level controls protect the ones who do.
Mobile Banking Vishing Protection Checklist for UAE Banks
Control | In place? |
Active call detection | ☐ |
Sensitive-session detection | ☐ |
Automated session suspension | ☐ |
Risk-based authentication | ☐ |
Transaction monitoring | ☐ |
Device binding | ☐ |
Malware detection | ☐ |
Overlay detection | ☐ |
RAT detection | ☐ |
Screen-sharing detection | ☐ |
Root and jailbreak detection | ☐ |
Anti-tampering | ☐ |
API protection | ☐ |
Security event logging | ☐ |
Incident monitoring | ☐ |
Score by maturity, not presence. Most programs tick twelve boxes and run four at a depth no fraudster would notice.
How Protectt.ai Helps Stop Vishing Attacks Inside Banking Apps
Protectt.ai doesn't help you combat vishing scams with just an AI-driven, mobile-native fraud protection suite. We know how hackers work their way around technical tools and are aware of their latest social engineering schemes.
So, we blunt attacks on the mobile device layer. Here's how:
● AppProtectt is a zero-code SDK that directly integrates into your banking apps. We protect your app from inside out and secure active user sessions even on compromised devices.
● AppAuth is our intelligence layer that uses device fingerprinting and behavioral analytics to generate real-time Dynamic Trust Scores for active user sessions.
● AppBind is meant for zero-trust devices and SIM binding. You can use it to eliminate vulnerable credential tracking by locking user identities directly to specific, verified hardware, and carrier networks. ApiProtectt shields the mobile-to-backend pathway.
● When it comes to fraud and risk management in UAE, we also provide a behavioral-driven backend engine that can process telemetry across millions of devices. This engine will help you stop suspicious transactions with zero performance latency.
Here is how our products and services work together:
If a fraudster calls you and tries to coerce you into initiating a screen-sharing session (via an app like TeamViewer or AnyDesk) to harvest OTPs or watch you log in. Our screen mirroring and screen sharing detection alongside remote desktop protocol (RDP) detection can immediately flag if an external party is viewing the interface and automatically blank out sensitive input areas. It can also terminate the banking session dynamically.
We can detect the presence of remote admin tools and block banking apps from launching them when these tools are active. Protectt.ai's app spoofing detection can prevent scammers from using fake/cloned versions of banking apps and our Runtime Application Self-Protection (RASP) can continuously monitor apps while they run to detect tampering, debugging, and block code injection attacks. If you are using any AI apps or features alongside your banking apps on your phone (or even desktop), then our AI security solutions which include agentic red teaming, agentic scanners, runtime guardrails, and MCP security, will all have you covered!
This is what vishing protection for mobile banking apps looks like in a production environment. Send us your banking app, and we will show you exactly which vishing signals it sees, and which it blindly ignores. Get in touch with our team for a live demo.
Conclusion
Vishing attacks work off of trust and not technology. No exploit exists to patch because the customer takes each step on a valid device and session.
Neither SMS OTP nor MFA solves this. CBUAE made the correct decision to end the use of OTP but both are identifying the customer but not their intentions.
There must be context-aware runtime controls for mobile apps. Authentication happens once at the front door but vishing attacks take place inside the room.
An active call detection feature provides the necessary signal associated with the attack method without any recording. Session suspension turns that into an intervention at the moment a customer is least able to think clearly.
No single control covers this. Real-time vishing protection UAE banks can rely on comes from layering authentication, device security, runtime protection and transaction controls, tuned against how customers actually behave. Try Protectt.ai today!
Frequently Asked Questions
What is vishing?
Vishing is voice-based phishing. An attacker uses a phone call, often while impersonating a bank, government agency or another trusted organisation, to persuade a person to disclose information or complete an action. In mobile banking, the action may include signing in, adding a beneficiary or approving a transfer.
How is vishing different from phishing?
Phishing is a broad term for deceptive attempts to obtain information or influence an action. Vishing is the voice-call form of phishing. Smishing uses text messages, while phishing may also occur through email, websites, social media or messaging platforms.
Can vishing happen even when a bank uses biometrics or passkeys?
Yes. Biometrics and passkeys can strengthen authentication and reduce some forms of credential theft or interception. They do not necessarily tell the bank whether a genuine customer is being coached into approving a fraudulent transaction.
Does active call detection record phone conversations?
Not necessarily. A call-state implementation may detect whether a call is active without recording or transcribing audio. The exact data collected depends on the operating system, permissions and implementation, so banks should document the technical and privacy design clearly.
Can active call detection stop every vishing attack?
No. It is a contextual risk signal, not proof of fraud. It works best when combined with transaction monitoring, behavioural analysis, device-risk detection, customer warnings and proportionate controls such as cooling-off periods or transaction review.
What should a bank do when a customer is on a call during a sensitive transaction?
The bank can display a clear warning, ask the customer to end the call, require additional verification, delay the transaction, apply a risk-based restriction or refer the event for review. The response should account for the customer’s normal behaviour and the sensitivity of the action.
What should I do if I receive a suspicious call claiming to be from my bank?
End the call and contact the bank through the official number shown in its app, on its website or on the back of your card. Do not share passwords, PINs, OTPs or approval codes, and do not install remote-access software at the caller’s request. If you suspect fraud, report it to the bank immediately and follow the relevant UAE reporting channel.
Dubai Police has warned residents about fake calls and messages impersonating officials and banks and directs people to official reporting routes such as the eCrime platform or 901. The UAE Financial Intelligence Unit also lists phishing and vishing among recognised fraud typologies.
What are the CBUAE vishing requirements?
CBUAE vishing requirements dictate that UAE banks must assess vishing controls within their broader fraud-management, consumer-protection, authentication, and incident-response obligations. While specific technical requirements depend on the institution and applicable CBUAE rules, the overarching goal is to shift away from interceptable channels like SMS OTPs in favor of risk-based, contextual security.
Does phasing out SMS OTP eliminate vishing?
No. It can reduce risks associated with SMS or email code interception, but a caller may still manipulate a customer into approving an in-app request or completing a legitimate banking flow.