Otukan protects mobile banking customers at the steps attackers target, then hands the evidence to the bank’s own authentication and fraud systems to decide. At login and recovery, Otukan proves the request comes from the genuine app on the device the session belongs to. During payee changes and transfers, it detects malware, overlays and remote control while the customer acts. At onboarding, it checks that selfie and document images come from a real camera. The bank keeps every decision; Otukan makes each one better informed. Each control has its own Android and iOS scope, and banking trojan defences are specific to Android.
Sensitive banking journeys
Mobile banking fraud concentrates on a small number of journeys. Otukan protects each one with the evidence that matters there and delivers it to the system that decides.
| Journey | What attackers try | What Otukan provides | Bank system that decides |
|---|---|---|---|
| Onboarding | Synthetic identities, injected selfies, scripted sign-ups | Camera injection signals, emulator and automation signals, app integrity | Identity verification |
| Account recovery | Takeover with stolen details and a new device | New app instance detection, device binding state, remote access and overlay signals | Identity and authentication |
| New device enrolment | Registering the attacker’s phone as trusted | App attestation, runtime integrity, device binding for the new app instance | Authentication |
| Payee changes | Adding a mule account while the customer is coached or the device controlled | Accessibility abuse (Android), screen sharing and mirroring, social engineering signals | Fraud engine |
| Transfers | Moving money through malware or a remote session | Malware behaviour signals, remote access context, overlay signals on the approval screen (Android) | Fraud engine and payment controls |
Recovery and enrolment get the strongest protection. They exist to let a customer in without their usual factors, which is exactly what an attacker needs. For the takeover chain in detail, see mobile account takeover prevention.
How Otukan’s controls fit together
Runtime and integrity
Every other signal depends on the app being the one the bank shipped. Otukan’s runtime checks detect hooking, debugging, emulators and modified operating systems, together with integrity checks on the app itself, and their status travels with every other signal. Runtime detail is covered on mobile RASP.
Malware and on-device fraud
On Android, banking malware relies on overlays and accessibility services to capture credentials and approve transfers. Otukan detects both, shields sensitive views and pauses the step. On iOS, those routes are closed to third-party apps, so Otukan concentrates on jailbroken devices, screen capture and mirroring, and social engineering. Each platform has its own signals. On-device fraud is covered on on-device fraud prevention.
Attestation
Platform attestation gives the bank’s servers evidence that a request came from the genuine app. Play Integrity on Android returns verdicts about the app, the device and the installing account. App Attest on iOS proves that a key belongs to a genuine instance of the app on an Apple device. Otukan uses each on its own terms and has the result verified on the bank’s server, out of the attacker’s reach. Attestation is covered on app attestation.
Network
Otukan’s certificate pinning refuses connections that present certificates the app does not expect, which shuts out interception through installed certificates and hostile networks. It ships with a rotation plan so a certificate change does not lock customers out. Android and iOS handle pinning differently, and Otukan configures and tests each platform separately. For pinning in detail, see certificate pinning.
One picture per journey
No single control covers a journey, and Otukan does not ask it to. A payee change draws on runtime integrity to trust the signals, malware and remote access signals to judge the session, and device binding to confirm the device. Otukan documents which signal feeds which decision in the bank’s systems.
Built for bank priorities
Banks weigh three things beyond the threat list. Otukan is designed around all three.
- Release compatibility. Otukan fits the bank’s existing build and release pipeline, and signing keys stay with the bank. Protected builds are tested for store review, clean install and update, crash behaviour and start-up across the bank’s supported devices. Response policy changes without a new release.
- Genuine-customer impact. Signals start in observe mode. Otukan measures how often each fires on real customers, including those using assistive tools, older devices and remote support from the bank’s own help desk, before any response is enforced.
- Audit evidence. For each control, Otukan provides its platform scope, the test records behind it, the response policy and the team that owns it. That record supports the bank’s own assessment for internal audit and supervisors.
For the wider application security picture, return to mobile app security. If your banking app is already published, request a free App Exposure Check of the public store release.