A mobile app should handle remote-control risk at the moment it matters: right before a transfer, a payee change or an account recovery step. Otukan checks at that point whether the screen is being shared, recorded or mirrored and, on Android, whether something other than the customer’s own touch is operating the app. The app then applies the response you set for that flow and sends the signal to your backend. Signals are built separately for Android and iOS. The app cannot see the person on the other end or hear the call, so your policy decides what each signal means.
Threat scenarios
Remote access fraud covers three situations that look alike on a dashboard and call for different responses.
Coercion
A caller posing as the bank, the police or a delivery firm persuades the customer to share their screen or install a support tool. The customer holds the phone and makes every tap. The attacker watches balances, codes and confirmation screens, and talks the customer through the payment.
Legitimate remote tools
Help desks, family members helping an older relative and managed work devices all use screen sharing or remote support. These sessions are normal, and a policy that treats them as fraud creates complaints and support load. They form the baseline your policy is measured against.
Malicious control
On Android, a remote access trojan can operate your app through accessibility services, often behind a black or fake update screen so the customer does not see what is happening. The attacker taps, types and confirms. The customer may be asleep or unaware.
| Scenario | Who makes the taps | What your app can observe | Flow most at risk |
|---|---|---|---|
| Coercion | The customer | A shared, recorded or mirrored screen | Transfers and new payees |
| Legitimate remote tools | The customer or a known helper | The same sharing signals, in expected contexts | Rarely a sensitive flow |
| Malicious control (Android) | The attacker, through a service | Injected input, cover screens, screen capture | Transfers, limit changes, recovery |
Signals: app-level visibility and blind spots
What Otukan sees on each platform
| Signal | Android | iOS |
|---|---|---|
| Screen shared, recorded or broadcast | Reported | Reported |
| Screen mirrored or cast to another display | Reported | Reported |
| Input performed by an accessibility service | Reported | Not applicable: third-party apps cannot operate other apps |
| Window laid over your screen | Reported | Not applicable |
| Login from a device not bound to the account | Reported | Reported |
Blind spots
The app does not see the phone call, the other person, their device or what they are asking the customer to do. It cannot tell a genuine bank employee from an impostor on a sharing session. A shared screen during a transfer is strong context, not a verdict, which is why Otukan labels it as a detection and your backend makes the decision.
Transaction policy
Set a response per flow, then decide how each response escalates.
| Flow | Signal present | Suggested response |
|---|---|---|
| Viewing balances and history | Screen shared | Observe and record |
| Adding a payee | Screen shared or mirrored | Warn in context and ask the customer to confirm |
| Transfer above your review threshold | Screen shared | Hold and verify outside the session |
| Any transfer | Injected input or cover screen (Android) | Refuse the step and end the session |
| Account recovery or new device enrolment | Sharing plus an unbound device | Stop and route to your verified recovery channel |
Contextual warnings
A warning works when it names the situation the customer is in. For example: “Your screen is being shared. We will never ask you to share your screen to move money.” Keep the wording short, avoid blame, and offer a way out, such as ending the call and contacting you on the number printed on the card.
Escalation choices
Holds and cooling-off periods give the customer time to step away from the caller. Call-backs to a known number and checks in a separate trusted channel keep verification away from the shared screen. Each hold opens a case in your fraud team’s queue with Otukan’s signals attached, so the reviewer sees what the app saw.
For malware that takes over sessions, see mobile app malware detection. The wider fraud model is covered on mobile fraud prevention.
To see how your public release looks to an attacker today, request a free App Exposure Check.