A mobile security team should evaluate automated transfer fraud detection by whether it can show who actually drove a payment: the customer’s own hands, a service on the phone, a remote operator or a script calling your API. Otukan answers that on every payee and transfer request. It flags accessibility-driven input on Android, screen sharing and remote access during payment screens, requests missing genuine-app evidence, and tampering with the code that builds a transfer. Your fraud engine receives the evidence before funds leave and makes the decision. Otukan sees what happens inside your app, not the rest of the device, and treats willing scam payments as a separate case.
Attack behaviour
How automated transfers happen
The attacker’s goal is to move money from a genuine account on a genuine device, so that credentials, device and location all look normal. Three techniques do that at scale. Android malware with accessibility access fills in a payee and taps approve while the customer is away or looking at a fake screen. A remote access session lets an operator drive the app directly. A script replays a captured session against your API without the app at all.
The victim journey
The customer often grants the access themselves, persuaded by a fake update or a caller posing as support. Days later, a transfer appears at night or while the screen shows something harmless. By the time a statement arrives, the money has moved on through mule accounts.
Why server rules alone struggle
Transaction monitoring looks for unusual amounts, new payees and odd hours. Automated transfer fraud is built to avoid those patterns: small amounts, payees added days earlier, sessions on the customer’s usual phone. What the server cannot see is how the payment was entered. That fact exists only inside the app, and it is the fact Otukan supplies.
What each technique leaves behind
| Technique | Observable behaviour | Where Otukan sees it |
|---|---|---|
| Accessibility-driven transfer (Android) | Fields set and buttons pressed without touch events | Inside the transfer screens |
| Remote-operated session | Screen sharing, and on Android remote access, during payment | During the payment step |
| Scripted API calls | Requests arriving without valid app evidence | At your backend, via attestation and binding |
| Manipulated transfer logic | Instrumentation on the code that builds the request | In the app’s process |
Detection limits
App-visible signals
Otukan observes the transfer screens, the input reaching them and the integrity of the code that sends the request. Those are the points automation has to pass through, which makes them a dependable place to look.
Beyond the app
Finding the malware package, cleaning the device or confirming how the customer was compromised is incident work for device security tools and your fraud investigators. Otukan’s contribution is the session-level record: which step, which signal, which platform and app version. That record gives investigators and dispute teams something concrete to work from.
Evidence for a decision, not the decision
A single automation signal is strong evidence, but your fraud engine sees more: payee age, amount patterns, velocity and history. Otukan is designed to feed that engine, not to replace it.
Response
Proportionate controls per step
| Evidence | Typical response |
|---|---|
| No automation signal | Transfer proceeds normally |
| Remote session during approval | Pause with a warning; resume if the session ends |
| Accessibility-driven input on payee or amount | Hold and ask for confirmation through a separate step |
| Missing app evidence or instrumentation | Refuse and end the session |
Each step can start in observe mode, so you measure how often evidence appears before it affects customers.
Support paths for legitimate users
Some genuine customers rely on assistive tools, and some use remote support from your own help desk. Both are tested against the policy before enforcement. When a transfer is held, the message explains what was noticed and how to complete the payment, for example by confirming in a separate step or calling a number the customer already trusts.
Tested before it ships
Each route is reproduced in an authorised lab, repeated on a clean device with ordinary tools, then checked through install, update, sign-in and a full transfer. For bot-driven API traffic, see mobile bot detection. The parent control set is mobile fraud prevention.