That moved who pays for a vishing call. It did nothing to the call itself.
A fraudster still rings. The number on screen still matches the bank. Over the next eleven minutes the customer is walked through their own banking app by somebody on the other end of the line. Their biometric. Their registered handset. Their tap on the approval prompt. Each control returns true because the right person is satisfying it correctly, while someone else chooses what happens next.
One condition runs through that whole sequence, and no authentication check looks at it. A voice call is active on the same device as the banking session. Active call detection is the control that reads it.
This guide covers what the control does, what Notice 3057 says, and how to prevent vishing attacks in mobile banking using session controls instead of warnings.
What Is Active Call Detection?
Active call detection lets your mobile banking app decide if an active voice call exists at the time you are using it.
The way this works is quite simple. The banking app requests from the operating system what the current telephony (or call) state of the device is. There are two ways this can be done:
● Android provides this by offering call-state callback functionality
● On iOS, CallKit offers similar functionality
Regardless of how it is provided, all that comes back is information on whether or not there currently is a live call.
So why would knowing this help with the use of a banking application? Live callers have a reaction to hesitation that no phishing email has been able to replicate. Customers who have a phone to their ear will generally read screens poorly. And, since verbal instructions cannot remain within an app they do not create any content based upon which controls can be inspected.
Privacy teams will raise one question before any other, so deal with it up front. Detecting a call is not recording one. Your app learns that a call is active. Nothing else. No audio is captured anywhere in the process. Call recording is a separate capability with separate legal footing, and describing the two together is how you lose a sign-off.
Inside a broader CBUAE mobile app security strategy, active call detection for banking apps is one contextual input among several. It earns its place by matching how the attack gets delivered.
What Is Vishing and Why Is It a Risk for Mobile Banking?
Vishing is voice phishing. Somebody calls pretending to be an organisation you trust, then talks you into doing something you otherwise would not.
The targeting is rarely casual. Attackers pull details from old breach dumps so the opening line lands. VoIP spoofing handles the rest by putting a familiar number on the screen, which removes the one check most people actually perform.
Then the pressure starts. There is a suspicious transaction on your card. A transfer completes in four minutes unless you act right now. All of it exists to compress the time for thinking, because thinking is what ends these calls.
What the caller asks for has changed as banks hardened their authentication. The request now tends to be behavioural rather than informational: open the app, go to beneficiaries, approve the prompt that is about to appear. Some scripts talk the customer into installing remote-desktop software.
Where does that leave the bank? Looking at a customer properly logged into a real session on a bound device, performing valid actions under instruction from somebody else. Mobile banking fraud prevention UAE teams keep finding this pattern in loss data long after every other control has passed.
What Does CBUAE Notice 3057 Require?
CBUAE Notice 2025/3057, issued in May 2025, told UAE-licensed banks to stop using SMS and email one-time passwords for customer authentication. The transition opened on 25 July 2025. Full compliance was required by 31 March 2026. Approved replacements include biometric verification, FIDO2 passkeys and in-app push approvals, and Gulf News covered the rollout.
The notice also moved liability. Where fraud traces back to OTP-based authentication, the institution reimburses the customer.
Now the part worth getting right. Teams searching for a CBUAE active call detection requirement will not find one named in the notice. CBUAE Notice 3057 vishing protection works better as a set of obligations than a single clause you can quote. Across CBUAE's risk management and internal controls framework and its consumer protection standards, those cover:
● Anti-fraud controls a bank can demonstrate, not describe
● Consumer protection extending to social-engineering losses
● Session management with attempt limits and enforced timeouts
● Risk-based authentication on payee additions and high-value transfers
● Audit trails detailed enough to reconstruct a disputed payment
● Continuous risk assessment across the session
Put together, those describe a bank that spots rising risk mid-session and responds in proportion. Active call detection closes that gap. It satisfies CBUAE mobile app security requirements without being a clause anybody can cite, and credible CBUAE vishing protection pairs it with other signals.
The liability shift moves this onto a budget line. Once your institution carries the loss, any control that interrupts a fraudulent session before settlement has paid for itself.
How Active Call Detection Protects Banking Sessions
Seven steps, all inside the app. Here is how active call detection protects banking sessions:
The customer opens the mobile banking application. Everything looks normal, because it is.
The application identifies a sensitive session or transaction. A balance check does not qualify. Adding a beneficiary does, as does a transfer above your threshold.
The application checks device state. Call status sits alongside root and jailbreak posture, plus indicators for screen-sharing and remote access.
An active voice call is detected. The app learns the fact, nothing about the content.
The application triggers a security response. Your risk engine weighs call state against session context, then decides in proportion.
The sensitive session is suspended or restricted. Suspend banking session during phone calls for your highest-risk actions. Everything else gets a cap or a step-up once the call ends.
The customer is prompted to end the call. Wording earns its keep: "For your security we have paused this transfer while you are on a call. Your bank will never ask you to move money during a phone call."
Fraudsters run on momentum. A customer reading an unexpected warning is a customer thinking again.
Log every trigger with timestamp, device state and outcome. That log turns banking app session protection into something an examiner can actually inspect.
Challenges in Implementing Active Call Detection
7 issues determine if your fraud reduction strategy will continue to reduce fraud during the next six months, or simply be silently shut down by end users (or administrators). They are:
Privacy without compromising security. After reading the caller ID read no farther. Describe how you have designed this feature. Explain how much of the call information you intend to store. Secure an attorney's approval prior to deploying it.
Parity across iOS & Android. Platforms provide different ways to access call information and permission structures are changing all the time. An application which can consistently enforce controls on Android but only sometimes enforces them on iOS provides less consistent protection and therefore may be harder to defend against an auditor compared to providing no controls at all.
Detection within real-time. The check for legitimate call state has to be completed in the process flow for each transaction. If you receive notification of a legitimate call state after you submit payment you should include it in a record of an audit.
False positives. False positives kill almost every program. Clients will contact their family members while attempting to check account balances. They will contact your company’s customer service center. Do not treat call state independently as being an absolute indicator of the legitimacy of a call and you will likely suspend good transactions on the first day of operation.
Friction vs. Protection. Any friction caused by an application results in fewer completed transactions. Only allow limited action based upon user-defined criteria. Suspend calls only when they represent a flow through which the applicant loses money.
Integration With Existing Controls. Call states must enter the same risk evaluation system as does device posture and behavioral analytics.
Consistent enforcement across versions. Customers run old builds for months. Without over-the-air policy control, enforcement is whatever shipped last year.
Best Practices for CBUAE-Compliant Active Call Protection
Eleven controls, and sequence matters as much as the list. Together they describe the mobile banking vishing prevention UAE institutions can defend in an audit.
● Real-time device-state monitoring feeding a live risk decision, not a nightly batch.
● Active call detection scoped to sensitive workflows only.
● Session suspension with clear, honest messaging.
● Transaction protection through caps and beneficiary confirmation.
● Risk-based authentication scaling friction to combine signal strength.
● Runtime Application Self-Protection (RASP) so detection lives inside the app, not at a boundary customers bypass daily.
● Anti-tampering and app shielding, because a control that can be patched out is decoration.
● Root and jailbreak detection, since every other control assumes an OS still enforcing its own boundaries.
● Malware and overlay detection for whatever vishing arrives bundled with.
● Secure API communication protecting the mobile-to-backend path.
● Security event logging with exports your fraud team and examiners can both use.
Run together, these are what mobile application security for CBUAE compliance and workable vishing protection for banking apps look like in production.
Active Call Detection vs Traditional Vishing Prevention
Control | Acts when | Depends on | Limitation |
Customer awareness training | Before the call | Customer recalling it under pressure | Fails at the moment it is needed |
SMS warnings | Before or during | Customer reading and believing it | Easily dismissed mid-call |
Fraud alerts | After the transaction | Post-event review | Money has usually moved |
Transaction monitoring | At or after submission | Pattern deviation | Coached payments can look normal |
Active call detection | During the session | Device state | A contextual signal needing corroboration |
Runtime protection | Throughout the session | In-app instrumentation | Needs deployment and tuning |
Read down the "Acts when" column. Most traditional controls fire before the attack or after it. Vishing happens in the window between, and only two entries operate inside it.
Customer education still earns its budget. It lowers how many people engage with the call, while application-level controls protect the ones who do.
How Banks Can Implement Active Call Detection
This is how banks can detect active calls during transactions without turning every session into an interrogation.
Identify sensitive banking workflows. Beneficiary addition, high-value transfers, limit increases, new device enrollment.
Define session suspension rules. Decide what suspends and what only warns. Write the thresholds down, then let fraud ops change them without a ticket.
Integrate device-state detection. Call state should arrive alongside root, jailbreak, screen-sharing and remote-access signals, through one SDK.
Detect active calls during sensitive sessions. Scope the check to the workflows you listed in step one.
Trigger automated session controls. The response fires without a human in the loop, because fraud completes in minutes.
Log security events. Timestamp, device state, rule fired, outcome.
Test across supported devices. Both platforms, your oldest supported OS versions, and the carriers your customers actually use.
Monitor and improve. Track trigger rates against false positives and confirmed fraud prevention, then return quarterly.
Evaluating a CBUAE compliance solution for vishing attacks? Ask vendors to demonstrate steps three through seven on a live build. Step one is easy to describe and hard to get right.
Active Call Detection Checklist for UAE Banks
Control | In place? |
Active call detection | ☐ |
Sensitive-session identification | ☐ |
Automated session suspension | ☐ |
Transaction protection | ☐ |
Runtime threat detection | ☐ |
Malware detection | ☐ |
Overlay detection | ☐ |
Root and jailbreak detection | ☐ |
Anti-tampering | ☐ |
Security logging | ☐ |
Incident monitoring | ☐ |
Regular security testing | ☐ |
Score by maturity rather than presence. Most programs tick ten boxes and run three at a depth no fraudster would notice.
How Protectt.ai Helps Banks Protect Against Vishing Attacks
Protectt.ai does not treat vishing as a transaction-monitoring problem. By the time a coached payment reaches a rules engine, the customer has already approved it. We work a layer earlier, while the call is still connected.
● AppProtectt is a zero-code SDK that drops into your banking app and protects it from the inside out. Active call detection ships alongside 100+ runtime controls.
● AppAuth is the intelligence layer, using device fingerprinting and behavioural analytics to generate real-time Dynamic Trust Scores. Call state feeds that score rather than firing alone, which keeps your false positives survivable.
● AppBind locks identity to verified hardware and carrier networks through Zero Trust device and SIM binding, closing the re-enrollment path fraudsters use after a successful call.
● Fraud and risk management runs a behavioural backend engine across millions of devices, holding suspicious transactions with no added latency.
Here is the scenario every UAE fraud team recognises. A caller persuades your customer to install TeamViewer or AnyDesk so he can "fix" an app issue. Our screen sharing and remote desktop protocol detection flags the moment an external party can see the interface. Sensitive input fields go blank. The session can be terminated outright. App spoofing detection stops cloned versions of your app being used in the same script.
Policy responses scale with severity instead of defaulting to a block. Over-the-air updates change posture without an app store release. That is what makes a vishing protection solution for UAE banks deployable inside a release cycle.
Send us your banking app. We will show you which vishing signals it sees today, and which it misses.
Conclusion
Active call detection is a narrow control that sits exactly where vishing operates. It notices your customer is on a call during an action that moves money, then creates a pause.
CBUAE has not named it in Notice 3057. What CBUAE has done is make institutions liable for fraud and expect continuous risk assessment backed by audit trails. A bank that can show it detects live social-engineering risk and responds in proportion is meeting those obligations.
Build it as one input into a risk engine. Scope it to the flows where your losses concentrate. Tune it against how your customers behave. Done that way, the mobile banking session protection UAE regulators expect becomes something you can put in front of them. Need help? Try Protectt.ai today!
Frequently Asked Questions
What is active call detection?
A runtime control that lets a banking app determine whether a voice call is in progress during a session, by reading device telephony state through standard OS APIs.
Is active call detection a CBUAE requirement?
Not as a named clause. Notice 3057 covered OTP phase-out and fraud liability. Active call detection is one way to meet broader obligations on risk-based authentication and session management.
Does active call detection record phone conversations?
No. It detects whether a call is active without capturing audio or identifying the caller. Document your permissions and retention, since implementations vary by platform.
How can banks detect active calls during transactions?
Through an SDK that queries call state and feeds the result into the risk engine alongside device posture, scoped to sensitive workflows.
Can a bank suspend a banking session during a phone call?
Yes. Policy defines which actions qualify, and the app pauses with a clear explanation. Alternatives include transaction caps, cooling-off windows or a step-up once the call ends.
Does active call detection stop every vishing attack?
No. It is a contextual risk signal that works when combined with transaction monitoring, behavioural analysis and device-risk detection.