Closing the gaps in mobile app security, fraud, and response
Why mobile banking protection has moved to the boardroom
App shielding, device checks, and fraud engines tuned with rules and scores are all part of how banks secure their mobile channels today. Yet, in the executive fireside chat I recently hosted, experts from OneSpan and ThreatFabric made it clear that these controls, on their own, are no longer enough.
Customers now interact with their banks primarily through mobile channels, which means any successful attack, prolonged outage, or wave of scams is no longer a narrow security incident. It is a business event that affects revenue, brand, and regulatory exposure.
As I moderated the session, my goal was to connect three worlds that are still too often handled separately:
- App shielding,
- Fraud and scams,
- Regulatory readiness.
Together with Christian Schlaeger and Frederik Mennes from OneSpan and Rohan Mer from ThreatFabric, we explored the biggest gaps in how banks protect, monitor, and respond to mobile threats.
From static shielding to lifecycle defense
Our first poll revealed that most attendees already have some form of app shielding in place for their banking apps, but many still lack runtime visibility into what happens on the device once the app is in use. That result was not a surprise to Christian, who has spent years building and deploying mobile application protection solutions for banks globally.
Christian pointed to findings from a study of around 120 banking apps. Roughly 80 percent of banks are doing something on mobile app security, and some even deploy multiple overlapping controls, yet only about 11 percent are effectively protected across key attack vectors. In other words, many banks are investing, but still missing critical threats or operating with limited visibility into real-world attacks.
Why visibility matters more than deployment
Christian argued that that app shielding has to evolve from a static control into an operational security layer. That starts with protecting the app package and logic against reverse engineering, repackaging, and abuse; extends into runtime defenses that can identify compromised devices, hostile execution environments, and anomalous app behavior; and concludes in a stronger trust model between the app and the bank’s back end, where integrity signals, app and device attestation, and runtime telemetry can inform fraud, risk, and orchestration decisions.
The shift is subtle but important: the app has transformed from something the bank simply publishes into a live source of trust, context, and response. Christian also warned against checkbox-driven security, noting that static or compliance-led approaches can create a false sense of protection when they are not tied to visibility, adaptability, and real attack conditions.
ATS malware exposes the limits of traditional shielding
Frederik reinforced this point with an example from the field: automated transfer system (ATS) malware. Unlike older banking Trojans that primarily stole credentials, ATS malware abuses accessibility services, overlay attacks, and MFA interception to log in and move money without the customer noticing. Because the app itself may not be modified, traditional shielding that focuses only on tampering or reverse engineering often fails to see the attack. From the app’s perspective, everything still looks normal.
Fraud and scams: Closing the detection gap
When we shifted to the fraud side, Rohan grounded the discussion in attacker behavior and threat intelligence. ThreatFabric tracks the global mobile banking malware ecosystem, and the picture is sobering: roughly 160 distinct banking malware families are active, and device takeover and ATS capabilities are increasingly becoming standard.
However, the more important challenge beyond simply the number of malware families is the “signal problem.” In about 72% of fraud losses by value, traditional signals such as a new device, new IP address, known malware flags, remote access tools (RATs), and failed authentication are absent. In other words, everything looks normal through the lens of traditional fraud controls.
When the customer becomes part of the attack chain
Much of this challenge stems from rising social engineering, scams, and APP fraud. Increasingly, attackers do not need to impersonate customers. They only need to manipulate them into initiating transactions from a trusted device. As a result, fraud teams must answer a more difficult question than identity alone can answer. On top of “Is this really our customer?”, the question “Is this customer making this decision under normal circumstances, or under coaching, duress, coercion, or remote control?” also needs to be answered.
To close that gap, the panel converged on the need for richer signals: in-app intelligence, device-level telemetry, behavioral analytics, and a clearer view of how the session unfolds over time. Christian described the importance of binding app, device, and user behavior together throughout the transaction journey. He also stressed that these insights become most powerful when they are monitored centrally and shared with fraud and security teams in the backend.
Reducing fraud without increasing friction
Rohan added a practical layer in the Q&A: the most promising approaches do not necessarily add more friction. Banks are increasingly using passive monitoring and dynamic friction, applying intervention only when device intelligence, remote access indicators, call context, or behavioral analytics suggest heightened scam risk.
In some cases, that means step-up checks. In others, especially social engineering cases, it means high-touch intervention from specialist teams trained to break the spell while the scam is in progress.
Regulation and governance: Why it all connects
Frederik brought the regulatory and governance lens into focus. Regulation has long been a driver for cybersecurity investment, and mobile app security is now firmly part of that agenda.
He described how PSD2 first introduced strong customer authentication and technical requirements for online payments, and how PSD3 and related initiatives are being shaped partly in response to APP fraud and scam trends.
Outside Europe, regulators in Singapore, Hong Kong, Malaysia, Indonesia, the UAE, and other markets have published guidance that explicitly addresses mobile threats like rooting, emulator use, overlays, hooking, code injection, and remote access tools. Frederik also noted that the Americas remain somewhat different, with less detailed mobile-specific regulation and more reliance on banks to determine their own path.
Contact us
Talk to a cybersecurity expert
We're happy to answer your questions and get you acquainted with our solutions.
Contact usRising scrutiny around scams and reimbursement
On scams and APP fraud, regulation is also evolving quickly. The UK first moved with a contingent reimbursement model in 2019, then introduced mandatory reimbursement rules. Other markets are taking their own approaches, including scam-related frameworks in Australia and shared-responsibility models in places such as Singapore.
Liability is becoming a central issue, and in some jurisdictions the conversation is expanding beyond banks to telcos and social media platforms.
Mobile security is now a board-level responsibility
The most important governance point came later in the session, when Frederik made clear that cybersecurity, and mobile app security in particular, can no longer be treated as purely technical problems. He cited DORA in the European Union as a major milestone because it explicitly requires boards of financial institutions to have ICT or cybersecurity risk expertise and holds management bodies personally accountable for digital resilience.
That is a major shift from mobile security as a back-office issue, to a part of executive oversight and board responsibility.
Demonstrate effectiveness, not just compliance
Christian added that regulators and internal audit teams are asking for more than simple proof that a control exists. They increasingly want visibility, reporting, and evidence that the bank understands what is happening in its mobile environment, has managed risk appropriately, and can show that its controls are effective over time.
He also highlighted GDPR compliance, GRC reporting, and data sovereignty requirements that keep sensitive data within the appropriate jurisdiction.
AI, fraud detection, and explainability
Rohan extended the governance discussion into AI and model risk. Machine learning has been part of fraud prevention for years, but banks are now facing more detailed scrutiny around explainability and model governance. This view was pragmatic: traditional machine learning models remain highly effective, while broader AI claims often outpace practical value. Fraud teams still need models that perform well, can be explained, and do not outsource risk decisions in ways the bank itself cannot defend.
Bringing app shielding, fraud and intelligence together
One pattern stood out throughout the discussion: effective mobile protection is holistic, intelligence-ed, and operational. From Christian’s perspective, banks need protection across the app lifecycle, plus the ability to monitor, interpret, and act on what they see.
From Rohan’s perspective, banks need to understand the specific fraud patterns affecting them, use both internal and external intelligence, and bring fraud teams and cyber teams closer together. He described the rise of cyber-fraud fusion functions, where cybersecurity, intelligence, SOC, and fraud teams share data in real time and build a common language around the threats they face.
From Frederik’s perspective, good mobile protection is also a business discipline. It should reduce fraud without damaging the customer experience, preserve trust in the brand, and help banks treat security not just as an IT cost but as business enabler. He repeatedly comes back to the value of holistic approach that combines mobile threat intelligence, app shielding, and behavioral detection rather than relying on any one of them in isolation.
In practical terms, that means treating mobile apps as active security controls rather than passive front ends, using runtime signals and behavioral context to improve fraud decisions, sharing intelligence across apps, fraud, cyber, and risk teams, and building the visibility needed to explain decisions to regulators, auditors, and internal stakeholders. It also means staying disciplined about technology: using machine learning where it genuinely improves detection, while remaining skeptical of AI claims that lack transparency or operational substance.
Why the full discussion is worth your time
This recap delivers a structured view of the conversation, but it cannot capture every nuance or example the panel shared. Over the course of the webinar, Christian, Frederik, and Rohan went deeper into regional differences, threat patterns, practical controls, and what banks should prioritize next.
Watch the full recording, especially if you are responsible for mobile app security, fraud strategy, digital channels, or risk.
