Notifications
Clear all
Topic starter
14/08/2026 6:33 pm
TL;DR: Banks are finding that app shielding alone is not enough, with runtime visibility, device attestation, behavioural context, and fraud intelligence now needed to spot ATS malware, scams, and APP fraud, according to OneSpan and ThreatFabric. The governance problem is no longer whether a control exists, but whether it can see and respond to attacks that leave the app looking normal.
NHIMG editorial — based on content published by OneSpan: Closing the gaps in mobile app security, fraud, and response
By the numbers:
- In about 72% of fraud losses by value, traditional signals such as a new device, new IP address, known malware flags, remote access tools, and failed authentication are absent.
Questions worth separating out
Q: How should banks detect mobile fraud when the app itself looks normal?
A: Banks should rely on runtime telemetry, device integrity, behavioural context, and transaction signals, not only on app tamper checks.
Q: Why do static app protections fail against mobile banking scams?
A: Static protections are designed to stop reverse engineering and repackaging, but scams and ATS malware often abuse the live session, accessibility services, overlays, or remote control.
Q: What do security teams get wrong about mobile malware and identity risk?
A: They often stop at authentication and overlook what happens after login.
Practitioner guidance
- Build runtime visibility into mobile sessions Instrument app, device, and session telemetry so teams can detect rooted devices, emulators, overlays, accessibility abuse, and anomalous behaviour during active use.
- Correlate fraud signals before step-up decisions Combine remote-access indicators, behavioural analytics, device intelligence, and transaction context before adding friction or approving a high-risk payment.
- Use attestation as backend input Feed integrity signals and device attestation into fraud engines and orchestration layers so response logic changes with live risk, not just static policy.
What's in the full article
OneSpan's full post covers the operational detail this analysis intentionally leaves at the governance and control level:
- Regional regulatory differences across Europe, Asia, and the Americas for mobile threat controls
- Examples of mobile attack techniques including rooting, overlays, hooking, code injection, and remote access tools
- How banks are using dynamic friction and specialist intervention teams to interrupt scams in progress
- The discussion on explainability, model governance, and when machine learning helps fraud teams
👉 Read OneSpan's analysis of mobile app security, fraud, and response →
Mobile banking protection is moving to runtime and fraud context?
Explore further
14/08/2026 6:41 pm
Static mobile app protection is now a governance liability when it is treated as the whole control set. The article shows that many banks have deployed shielding, yet runtime abuse, scam coercion, and ATS malware still pass through because the app is only one layer of the control plane. In governance terms, the problem is not missing controls alone, but a false belief that deployment equals effective protection. Practitioners should treat mobile security as a live assurance problem, not a build-time checkbox.
A question worth separating out:
Q: Who is accountable when a compromised mobile device completes a fraudulent transaction?
A: Accountability usually spans fraud operations, IAM, mobile security, and the business owner of the transaction flow. If the programme treats device integrity as outside identity governance, the control gap is structural. Teams should define ownership for post-authentication session trust before fraud patterns force the issue.
👉 Read our full editorial: Mobile app security must shift from shielding to runtime defense
