Remote Access Scam Prevention for Banks

In a remote access scam the genuine customer is logged in on their own device, passes every authentication check, and then watches someone else read their screen or drive their banking app. Because credentials, device binding and strong customer authentication all look correct, the bank's best chance is to notice the session itself: screen capture running, a remote control or accessibility app active, a call in progress with an unknown number, or input that does not look like the customer. This guide is for fraud strategy, mobile engineering and fraud operations teams at banks, building societies, payment firms and fintechs. It covers the in-session signals available on Android, iOS and web, how to combine them into decisions, and the response flow when a session looks controlled. Scam mechanics and reimbursement rules are covered in the Authorised Push Payment (APP) Fraud Guide, and staff-side screen sharing controls in the Screen Sharing Security Guide; this page goes deeper on detection and response inside the banking session.

Key takeaways

Detect the session, not the login. The customer authenticates correctly, so remote access scams are only visible through session context: capture state, controlling apps, call state and input patterns.
Mobile platforms now expose usable signals. Android offers screen recording callbacks, FLAG_SECURE, overlay blocking and the Play Integrity app access risk verdict; iOS exposes UIScreen.isCaptured; web sessions rely mainly on behavioural and device signals.
Combine signals with the payment context. A controlling app on its own is weak evidence; a controlling app plus a new payee, a raised limit and a large first payment is a classic scam pattern.
Prefer interruption to silent blocking. Platform guidance favours challenges over outright denial: pause the journey, ask the customer to end sharing, and route high-risk cases to a trained human.
Operating system protections now help. Android's in-call protections and the financial app warning shown during screen sharing with unknown callers add a layer the bank does not control, so design journeys that work with them, not around them.

How remote access scams show up in a banking session

The pattern is consistent across bank impersonation, refund, tech support and investment scams: a call or message creates urgency, the victim is persuaded to install or open a remote access or screen sharing tool, and the scammer either watches the victim make payments or takes control of the device. On mobile the same result can come from an app that abuses accessibility permissions to read and drive the screen. MITRE ATT&CK describes the enterprise behaviour as T1219 Remote Access Tools (including T1219.002 Remote Desktop Software), and the mobile matrix lists T1663 Remote Access Software, T1513 Screen Capture, T1417 Input Capture and T1516 Input Injection. The tools themselves are usually legitimate products, for example AnyDesk, Microsoft Quick Assist and TeamViewer (listed alphabetically), misused through social engineering rather than through any flaw in the product.

Scam stage	What the bank can observe	Channel
Victim is on a call with the scammer	Call in progress during the session; the OS may already have warned about an unknown caller	Mobile
Remote tool installed or opened	A capturing or controlling app present or running; newly installed app from outside the store	Mobile (Play Integrity, app signals); desktop only indirectly
Screen being shared or recorded	Capture state change during a sensitive screen	Android, iOS
Scammer drives the session	Input that looks injected, unusual navigation, cursor or touch patterns unlike the customer's history	All channels (behavioural)
Money moves	New payee, limit increase, transfers between own accounts then out, large first payment	All channels (transaction monitoring)

The coaching signals that do not depend on remote tools, such as hesitation, dictated typing and pasted payee details, are covered in the Transaction Monitoring and Behavioural Biometrics Guide. This page concentrates on the remote access and capture layer.

Android signals and controls

Android gives a banking app several first-party signals and protections. Each has limits, so treat them as inputs to a risk decision rather than verdicts.

Control or signal	What it does	Limits documented by Google
`WindowManager.LayoutParams.FLAG_SECURE`	Blocks screenshots of the window and display on non-secure displays; Google's fraud prevention guidance says it helps against remote screen sharing abuse and blanks background screenshots	Not reliable against overlay attacks and may not detect every active recording; on Android 11 and lower Google says it helps reliably on about 70% of devices
`HIDE_OVERLAY_WINDOWS` permission (Android 12+)	Lets the app opt out of application overlays being drawn over it	Applies to application overlays, not to accessibility based control
`WindowManager#addScreenRecordingCallback` (Android 15)	Callback fires when the app's windows become visible or invisible in a screen recording (`SCREEN_RECORDING_STATE_VISIBLE`); intended to tell the user when a sensitive operation is being recorded	Reports recording of your app's windows; the app decides what to do
`accessibilityDataSensitive` and `setFilterTouchesWhenObscured`	Marks views with sensitive data so apps that hold accessibility permission but are not declared accessibility tools cannot read them; views filtering obscured touches are treated as sensitive automatically	Depends on the OS version on the customer's device; legitimate accessibility tools are unaffected by design
Play Integrity `appAccessRiskVerdict`	Server-side verdict listing whether other running apps could capture the screen (`KNOWN_CAPTURING`, `UNKNOWN_CAPTURING`), control the device or inputs (`KNOWN_CONTROLLING`, `UNKNOWN_CONTROLLING`) or draw overlays (`KNOWN_OVERLAYS`, `UNKNOWN_OVERLAYS`)	Opt in through the Play Console; needs Android 6 or later, a phone, tablet or foldable, and a trustworthy device; verified accessibility services are excluded; an empty verdict means not evaluated
Play Integrity `playProtectVerdict`	`NO_ISSUES`, `NO_DATA`, `POSSIBLE_RISK` (Play Protect off), `MEDIUM_RISK`, `HIGH_RISK`, `UNEVALUATED`	Google suggests asking the user to act on Play Protect warnings, or blocking the server-side action if they cannot

Three points matter in practice. First, the KNOWN_ and UNKNOWN_ prefixes distinguish apps from Google Play or the system partition from everything else, which is a strong discriminator because many scams depend on an app installed from a link. Second, Play Integrity offers remediation dialogs, CLOSE_UNKNOWN_ACCESS_RISK and CLOSE_ALL_ACCESS_RISK, which ask the user to close the risky apps before continuing. Third, the verdict adds latency to standard requests, so request it at sensitive moments (new payee, limit change, payment confirmation) rather than on every screen. See the Android App Security Guide for wider app hardening and the Android Banking Trojans Guide for malware that abuses the same permissions.

Operating system protections the bank does not control: Google announced in May 2025 that Android blocks some risky actions during calls with non-contacts, including disabling Play Protect (Android 6 and later), and first-time sideloading and granting accessibility permissions (Android 16). It also piloted, first in the UK, a warning when a customer opens a participating financial app while screen sharing on a call with a number not in their contacts. As described by Google in December 2025, the warning labels the situation a probable scam, offers one tap to end the call and stop sharing, and imposes a 30 second wait before the customer can continue; it requires Android 11 or later and was extending to further countries. Banks taking part should make sure their own warnings and the OS warning do not contradict each other.

iOS and web signals

iOS: UIScreen.isCaptured is true when the system is recording, mirroring or using AirPlay to stream the screen, and UIKit posts UIScreen.capturedDidChangeNotification when that state changes. Apple's documentation frames the property as something an app observes and responds to, for example by hiding content. A banking app can use the change to mask balances and one-time codes, pause a payment journey and show a scam warning, and report the state to the server as a risk attribute. Confirm the current API surface against Apple's documentation for the iOS versions you support. See the iOS App Security Guide.

Web: a browser cannot see which other applications run on the computer, so a desktop remote control session is mostly visible indirectly. Useful signals are:

Input dynamics: pointer movement and keystroke timing that differ sharply from the customer's own baseline, or that change mid-session after a period of normal behaviour.
Session discontinuities: sudden changes in window size, screen resolution or focus pattern during a session, and long idle gaps followed by fast, confident navigation to payee and limit screens.
Cross-channel context: the same customer recently active on mobile with a capture or call signal, or a recent inbound call record from the bank's own telephony showing the customer is not on a genuine bank call.
Device intelligence: a new or unusual device for this customer combined with payee changes. See the Device Intelligence and Fingerprinting Guide.

Web signals are weaker than mobile ones, which is one reason some firms route high-value new-payee journeys to the mobile app, where capture and controlling-app signals exist.

Turning signals into decisions

No single signal proves a scam. Accessibility users, people sharing screens with a family member and customers recording a problem for support all produce the same raw signals. Score combinations, and weight them by the payment context.

Signal combination	Risk band	Suggested action
Capture or controlling app only, browsing balances	Low to elevated	Mask sensitive data, show a short in-app notice that screen sharing is active, log the attribute
Capture state active on a payee, limit or payment screen	Elevated	Pause the journey with a scam warning tailored to remote access ("no bank will ask you to share your screen"), offer Play Integrity remediation where available
`UNKNOWN_CONTROLLING` or recent unknown install, plus new payee	High	Hold the payment and route to a trained scam team on a known number; restrict new payees for the session
Call in progress plus capture plus large first payment or limit increase	Very high	Stop the payment, end the online session, freeze outbound payments pending contact, flag the payee account to the receiving firm
Signals present but long-standing for this customer, with a verified accessibility need	Context dependent	Treat as baseline; rely on payment context and payee risk instead

Decision guidance: a large bank with mobile engineering capacity can implement the native signals itself and feed them into its fraud decision engine alongside behavioural and transaction scores. Smaller firms usually take these signals through a fraud or device intelligence SDK and should ask for raw attributes (capture state, verdict values, call state) and reason codes, not just a score. Whatever the size, start by adding the signals in observe-only mode so you learn the false positive rate before you intervene. See the Fraud Prevention Platform Buyer's Guide.

Privacy: session signals are personal data. Explain them in the privacy notice, collect only what the decision needs, keep retention short, and avoid using vulnerability or disability as a proxy for risk. See the Elder Financial Abuse and Scam Prevention for Banks and Care Providers Guide for the vulnerability angle.

Response flow when a session looks controlled

Interrupt in-app. Mask balances, codes and card details; pause the journey; show a warning specific to remote access. Do not show a generic "are you sure?" that a coached customer will click through.
Break the scammer's control. Ask the customer to end the call and stop sharing, using platform remediation (Play Integrity dialogs) or the OS controls. Hold any payment created in the session.
Contact on a trusted channel. A trained colleague calls the customer on the number held on file, after a pause long enough for the scam call to end, and asks open questions about who asked them to share their screen.
Contain the account. If control is confirmed or likely: revoke active sessions, remove payees added in the session, reset online banking credentials and re-bind the device, and check for new devices, changed contact details or raised limits.
Clean the device. Guide the customer to uninstall the remote access tool, remove unknown apps holding accessibility or overlay permissions, and run Play Protect, before re-enabling digital payments.
Recover and report. Notify the receiving firm about the payee account, record the case outcome against the signals that fired, and follow your reimbursement and reporting obligations as set out in the APP fraud guide.
Feed back. Use confirmed cases to tune thresholds and warnings, and to update the list of tools and app behaviours you treat as high risk.

How to implement

Inventory existing signals. List which apps and SDK versions already report capture state, Play Integrity verdicts or call state, and where those attributes land in the decision engine.
Harden sensitive screens. Apply FLAG_SECURE, HIDE_OVERLAY_WINDOWS and sensitive-view flags on login, payee, limit and payment screens; mask data when iOS reports capture.
Collect in observe mode. Opt in to the app access risk and Play Protect verdicts, request them at sensitive actions, and log alongside payment outcomes for four to eight weeks.
Design interventions. Write remote access specific warnings, define the risk bands above against your own data, and train the scam team on the call-back script.
Pilot in rings. Enable interventions for one segment or payment type, compare scam losses, false positive rates and abandonment against a control group, then expand.
Keep a rollback. Put each intervention behind a feature flag so it can be returned to observe mode within minutes if it blocks genuine customers at scale.

Detection and measurement

Coverage: share of payment-confirmation events with a capture or app access risk attribute recorded, by platform and app version.
Hit rate: confirmed remote access scams where at least one session signal fired before the payment, as a share of all confirmed remote access scams.
Precision: share of high-band interventions that the scam team confirms as scam or likely scam.
Customer impact: abandonment and complaint rates for sessions that received a remote access warning.
Time to contact: median minutes from hold to trusted-channel contact for high-band cases.
Losses: value of remote access scam payments sent, and value stopped by holds, trended monthly.

Framework mapping

Framework	Reference	How it applies
MITRE ATT&CK Enterprise	T1219 Remote Access Tools; T1219.002 Remote Desktop Software; T1566.004 Spearphishing Voice	The scam's tooling and the voice lure that starts it
MITRE ATT&CK Mobile	T1663 Remote Access Software; T1513 Screen Capture; T1417 Input Capture; T1516 Input Injection	Behaviours the Android and iOS signals above are designed to surface
NIST CSF 2.0	DE.CM-03; DE.AE-02; RS.MI-01	Monitor session activity, analyse adverse events, contain the incident
NIST SP 800-53 Rev 5	SI-4 System Monitoring; IA-11 Re-authentication; SC-15 Collaborative Computing Devices and Applications	Session monitoring, re-authentication on risk, controlling remote activation of sharing
OWASP MASVS	MASVS-PLATFORM (Platform Interaction)	Preventing sensitive data leaking through screenshots and other platform mechanisms

Common failure patterns

Relying on authentication: step-up and one-time codes stop impostors but not a coached customer, and a code shown on a shared screen is visible to the scammer.
Blocking on a single signal: treating every capture or accessibility signal as fraud harms customers who rely on assistive technology and trains staff to ignore alerts.
Checking once at login: scammers often start sharing after login; request verdicts and capture state at the payee, limit and payment steps.
Generic warnings: "beware of fraud" text is ignored; a warning that names screen sharing and says the bank never asks for it is harder to talk past.
No trusted call-back: calling the customer while the scam call is still live, or from a number the scammer has spoofed, lets the scammer coach the answers.
Leaving the device compromised: re-enabling payments before the remote tool and risky permissions are removed invites a second loss.

Practitioner checklist

Apply FLAG_SECURE, overlay blocking and sensitive-view flags on all payee, limit and payment screens.
Register for Android screen recording callbacks and iOS capture notifications, and report the state to the server.
Opt in to Play Integrity app access risk and Play Protect verdicts and request them at sensitive actions.
Combine session signals with payee novelty, limit changes and payment value before intervening.
Write remote access specific warnings and test them with customers.
Route high-risk cases to a trained scam team that calls back on the number on file.
Remove session-added payees, re-bind the device and clean the handset before restoring payments.
Run new signals in observe mode first and keep every intervention behind a feature flag.
Record signal outcomes on every confirmed case and review thresholds monthly.

Remote Access Scam Prevention for Banks: Detecting Screen Sharing and Remote Control During Sessions