A mobile security team should evaluate on-device fraud protection by mapping each step of a real victim journey to a signal the app can observe, being clear about which conclusions the app can reach on its own and which need your fraud team, and testing proportionate responses that protect legitimate users before anything is blocked. This guide is for fraud, risk and mobile teams in banking, payments and wallets. It covers fraud that runs through your genuine app on the customer’s own phone. Scripted API abuse and whole-device security scanning sit outside it.
Signal-level detail is covered on on-device fraud prevention. The wider fraud programme is covered on mobile fraud prevention.
Attack behaviour: the victim journey
On-device fraud rarely looks like hacking. The customer is logged in, on their own device, often guided by a caller. What changes is who is really in control of the screen.
Typical journeys
- Guided remote session. A caller persuades the customer to install a remote support tool, then watches or drives the payment.
- Overlay capture. A malicious app draws a fake screen over the real login or card entry form on Android.
- Accessibility takeover. A malicious service reads the screen and taps buttons on the customer’s behalf on Android.
- Screen sharing. The customer shares the screen during a call, exposing one-time codes and balances.
Build your behaviour-to-signal matrix
| Behaviour in the journey | What the app can observe | Platform |
|---|---|---|
| Another person drives the session | Remote access conditions | Android |
| Screen content leaves the device | Screen sharing or mirroring during sensitive steps | Android, iOS |
| Fake screen over the real one | Non-system overlay on a sensitive screen | Android |
| Automated taps and reads | Accessibility service acting on the app; taps and text entry delivered by software | Android |
| Tampered runtime | Root, jailbreak, hooking, repackaged copy | Per platform |
- Which journeys appear in your own fraud cases, and at which step does money or data leave?
- Which rows above apply to your app, and on which platform?
How Otukan answers. Otukan detects overlays, accessibility services acting on the app and remote access conditions on Android, and screen sharing or mirroring during sensitive steps on Android and iOS. On Android it also recognises taps and text entry delivered by software rather than a finger. Otukan correlates every signal within one session, recording order and timing. A remote tool plus an overlay during a transfer reads as one story, not scattered alerts.
Detection limits: what the app can and cannot see
An app works from its own vantage point. That is a strength, because the signal comes from the exact screen where fraud happens. It also sets a boundary your evaluation should respect.
- Does the option state which signals come from inside the app and which claim to judge the whole device?
- On iOS, where the sandbox keeps apps from inspecting each other, how does the option describe its scope?
- Is a signal presented as context for your fraud engine, or as a confirmed incident?
- Who confirms an incident: the app, the fraud analyst or the customer on a verification call?
How Otukan answers. Otukan reports what your app observes, per platform, and labels each signal by source. Root, jailbreak, hooking and repackaged copies are added as context. Signals are attached to sensitive requests so your backend and fraud engine decide with the full account picture, and your analysts confirm the incident.
Response: proportionate controls and support paths
Choose the response per step
- Which steps need a pause: adding a payee, raising a limit, a first large transfer, changing the phone number?
- Which steps only need a signal recorded for review?
- What does the customer see when a step is paused, and does it tell them how to continue safely?
Protect legitimate users
- Run each signal against a clean-device baseline and against legitimate tools: screen readers, password managers, approved remote support.
- Define the support path for a customer paused by mistake, including who they call and what the agent sees.
- Decide how long you observe before you restrict, and which result lets you move on.
How Otukan answers. You set a response per user flow: observe, warn, restrict or terminate. Otukan can pause the protected step in the app while your backend holds the matching transaction, so the rest of the app keeps working. When a step is paused, the customer sees a plain-language message explaining what was noticed and what to do next. Before enforcement, we test every signal with your team against a clean-device and legitimate-tool baseline. Otukan protects Android, iOS, Flutter and React Native apps, fits your existing build and release pipeline, and leaves your signing keys with your team.
Android overlay attacks are covered on overlay attack detection. Guided sessions are covered on remote access fraud prevention. The scam signal contract and friction workflow are covered on the social engineering protection solution guide.