Mobile Banking App Security: Protecting Financial Applications at Runtime

A fraudulent transfer cleared on a mobile banking app costs more than the entire mobile security budget that should have stopped it. The CFO does the math the morning after. The CISO does the math during the regulator’s site visit. The mobile team does the math when they’re rewriting the auth flow under a deadline that exists because nobody did the math six months earlier. The asymmetry between what a successful attack returns to its operator and what it costs the bank to prevent is the entire field of mobile banking app security in one sentence.

Most guides on this topic miss the audience entirely. They talk to consumers about not losing their phones. They tell IT teams to enable 2FA. They produce listicles of fifteen tips that never connect to the regulations, the threats, or the code that actually has to ship. This guide is for the people building and defending the app: the mobile lead, the security engineer, the CISO who has to demonstrate to an examiner that PCI MPoC, PSD2, DORA, FFIEC, or OWASP MASVS-L2 controls operate inside the binary.

The structure is a four-layer defense-in-depth model that applies to every banking app I’ve reviewed: the code you write, the binary you ship, the process that executes on a hostile device, and the backend that decides whether to trust any of it. Each layer maps to specific iOS and Android APIs, and each layer maps to specific regulatory requirements. By the end you’ll have a working architecture, working code in Kotlin and Swift, a checklist organized by layer, and a compliance table you can hand to an auditor.

The Mobile Banking Threat Surface in 2026

A banking app’s threat surface is not the threat surface of a generic mobile app with money attached. The economics push attackers to invest serious engineering time, the regulations push defenders to demonstrate controls, and the threats themselves are categorically different from the ones consumer apps face. Nine attack patterns matter most right now.

Banking trojans on Android. FluBot, BRATA, SharkBot, Anatsa, Coper, Cerberus, and their successors form a continuous lineage of malware families whose only purpose is to take over banking apps. The pattern repeats: SMS phishing delivers a fake delivery-tracking or utility app, the app coerces the user into granting Accessibility Services permission, and from that point on the malware reads the screen, intercepts SMS one-time passwords, and can draw overlays on top of any banking app the user launches. FluBot was hit hard by a 2022 Europol operation, but the family pattern outlives any individual variant.

Overlay attacks via Accessibility Services. This is the workhorse technique. The malware sits dormant until the user opens a banking app it recognizes; then it draws a credential-capture overlay that looks identical to the bank’s login screen. The user types their password into the overlay. The malware logs it, dismisses, and the real banking app appears underneath with the user none the wiser. Detection happens at runtime, not at install time.

Repackaging. An attacker decompiles a legitimate banking APK, splices in callbacks to their command-and-control server, re-signs with their own key, and republishes through a third-party store or a phishing link. Users who sideload land on a trojanized clone of their own bank’s app. The signature-verification countermeasure described in Layer 2 is what catches this.

Frida and Objection hooking. Frida is the dominant runtime instrumentation framework on both iOS and Android, and Objection is the layer of banking-app-pen-test tooling built on top of it. The attack pattern is to hook BiometricPrompt.AuthenticationCallback.onAuthenticationSucceeded (Android) or the equivalent LAContext evaluator callback (iOS) and make it return success regardless of whether biometric authentication happened. Hooking the runtime verification of a signing certificate is the same idea applied to Layer 2 controls.

NFC relay attacks on Tap to Pay. Two devices, a relay protocol over a fast link, and an attacker can drain a contactless card by holding one device near the victim’s wallet and the other near a payment terminal. As Tap to Pay generalizes from cards into phone-to-phone payments, the relay vector follows the rails.

Screen recording and screen capture. Malware with MediaProjection permission on Android can record the screen during a transfer flow, capturing account numbers, recipient details, and OTPs as they’re typed. The FLAG_SECURE window flag prevents this; banking apps that don’t set it on transfer screens get recorded.

Deep link abuse on transactions. A user clicks a link on a compromised site that resolves to yourbank://transfer?to=attacker&amount=999. The banking app opens with the parameters pre-filled. Apps that execute the transfer instead of pre-populating a confirmation screen with step-up authentication walk users into fraud. Allowlists plus mandatory step-up are the controls.

SIM swap. Not strictly in-app, but everything banking apps build on top of SMS for OTP delivery is compromised when an attacker socially engineers the carrier into porting the number. The mitigation is the same as what PSD2 actually requires: possession of a device-bound key, not possession of an SMS, plus inherence via biometric.

Repackaged review-bombing. Regional variants of legitimate banking apps land in third-party Android stores and target users in regions where the official Play Store presence is thin. The countermeasure is the same as for ordinary repackaging plus user education about install sources.

Categorizing those, every banking app threat falls into one of five patterns: credential theft via overlay, transaction substitution via runtime hooking, repackaging and redistribution, session hijacking via SIM swap or token theft, and inter-component abuse via deep links or exported services. Keep that taxonomy in mind as you read the layers; each layer defends against one or more of these patterns, and no layer covers all five.

Why Defense in Depth Beats Single-Layer Security in Banking

Banking apps that pick one layer of protection and call it done are the apps that get compromised. Apps that cover all four are the ones that survive a motivated attacker and pass an examiner’s review. The four-layer model maps cleanly to the technical reality of a mobile banking app.

Layer 1, the code you write. Keystore and Keychain hardware-backed storage, biometric step-up authentication tied to cryptographic operations rather than to boolean callbacks, sealed transaction state in Kotlin or enum-with-associated-values in Swift, certificate pinning with backup pins, deep link allowlists that pre-populate UI rather than execute action. Most banking app vulnerabilities are introduced here and most are cheapest to fix here.

Layer 2, the binary you ship. R8 and Swift symbol stripping in release builds, string and resource encryption beyond what the platform compilers do, signature and code-sign verification at runtime, SBOM and supply chain integrity. The banking app’s APK or IPA lives on the attacker’s device the moment a user installs it. The hardening at this layer decides what the attacker can read when they decompile it.

Layer 3, the process that executes. Jailbreak and root detection that actually accounts for Magisk on Android and Liberty Lite on iOS, anti-debugger checks, Frida and Objection fingerprinting in memory, overlay attack detection on Android, integrity attestation through Play Integrity and DeviceCheck or App Attest, and the Mobile ADR layer that catches what the others miss. This is the only layer that sees what’s actually happening on the user’s device while the app is running. Banks block transfers on rooted devices because the FFIEC’s Mobile Financial Services guidance is explicit about device integrity, and because the layers underneath stop working once the runtime is hostile.

Layer 4, the backend you trust. Server-side authorization on every transaction, server-side verification of Play Integrity and App Attest tokens, behavioral anomaly detection on telemetry streamed from Layer 3, per-session rate limiting bound to integrity-attested tokens, and transaction velocity controls. The mobile client is a hostile environment by default; the backend is what decides whether to act on what the client claims.

Each layer defends against a different attack pattern from the previous section, and the patterns compose. An attacker who can’t read your code statically pivots to Frida at runtime. An attacker who can’t hook your process repackages with their own logic. An attacker who can’t tamper with the client hits your backend with replayed requests from what looks like a legitimate session. The architecture that holds is the one where every pivot meets a different control. This is also what runtime security means when the security industry uses the term: security as an architecture the application participates in, not security as a perimeter that hopes the application doesn’t have to.

Layer 1: Code, Banking-Specific Patterns

The Layer 1 work for a banking app overlaps with Layer 1 for any mobile app, but the consequences are bigger and a few patterns deserve banking-specific framing. For the deeper platform coverage of Layer 1 generally, our complete Android security guide and the iOS security deep dive cover the patterns end-to-end. This section covers what changes specifically when the app moves money.

Biometric step-up tied to transaction signing

The single most common Layer 1 mistake in banking apps is using biometric authentication as a UX shortcut for login while leaving every transaction to a regular form-submit. The fix is to use biometric as a step-up for transactions, and to bind the biometric to the cryptographic operation that signs the transaction itself.

On Android, that means a BiometricPrompt with a CryptoObject wrapping a Keystore-backed signing key. The biometric unlocks the key; the key signs a server-issued challenge; the server verifies the signature. A Frida hook on the biometric callback gets nothing useful, because the operation that produces the signature never runs unless the real biometric unlocks the real key.

import androidx.biometric.BiometricManagerimport androidx.biometric.BiometricPromptimport androidx.fragment.app.FragmentActivityimport androidx.core.content.ContextCompatimport java.security.KeyStoreimport java.security.Signatureimport android.security.keystore.KeyGenParameterSpecimport android.security.keystore.KeyPropertiesclass TransactionSigner(private val activity: FragmentActivity) {    private val keyAlias = "transaction_signing_key"    fun ensureKey() {        val ks = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }        if (ks.containsAlias(keyAlias)) return        val spec = KeyGenParameterSpec.Builder(            keyAlias,            KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY,        )            .setAlgorithmParameterSpec(java.security.spec.ECGenParameterSpec("secp256r1"))            .setDigests(KeyProperties.DIGEST_SHA256)            .setUserAuthenticationRequired(true)            .setUserAuthenticationParameters(                0,                KeyProperties.AUTH_BIOMETRIC_STRONG,            )            .setInvalidatedByBiometricEnrollment(true)            .build()        val gen = java.security.KeyPairGenerator.getInstance(            KeyProperties.KEY_ALGORITHM_EC,            "AndroidKeyStore",        )        gen.initialize(spec)        gen.generateKeyPair()    }    fun signTransaction(        serverChallenge: ByteArray,        onSigned: (signature: ByteArray) -> Unit,        onFailure: () -> Unit,    ) {        val ks = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }        val privateKey = ks.getKey(keyAlias, null) as java.security.PrivateKey        val signature = Signature.getInstance("SHA256withECDSA").apply {            initSign(privateKey)        }        val prompt = BiometricPrompt(            activity,            ContextCompat.getMainExecutor(activity),            object : BiometricPrompt.AuthenticationCallback() {                override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {                    val sig = result.cryptoObject?.signature ?: return onFailure()                    sig.update(serverChallenge)                    onSigned(sig.sign())                }                override fun onAuthenticationFailed() = onFailure()            },        )        val info = BiometricPrompt.PromptInfo.Builder()            .setTitle("Confirm transfer")            .setSubtitle("Authorize this payment with biometric")            .setNegativeButtonText("Cancel")            .setAllowedAuthenticators(BiometricManager.Authenticators.BIOMETRIC_STRONG)            .build()        prompt.authenticate(info, BiometricPrompt.CryptoObject(signature))    }}

The onSigned callback only ever fires with a real signature produced by a key that only unlocks under genuine biometric. The server verifies the signature against the public key registered during enrollment and against the challenge it just issued; replay is impossible because the challenge is single-use.

On iOS, the equivalent pattern uses LAContext to gate access to a Secure Enclave key, and SecKeyCreateSignature to produce the signature. The library on top is different; the architecture is the same.

import LocalAuthenticationimport Securityimport CryptoKitenum SignError: Error {    case keyUnavailable    case userCancelled    case signingFailed}final class TransactionSigner {    private let keyTag = "com.example.bank.transaction.signing".data(using: .utf8)!    func ensureKey() throws {        if try existingKey() != nil { return }        let access = SecAccessControlCreateWithFlags(            kCFAllocatorDefault,            kSecAttrAccessibleWhenUnlockedThisDeviceOnly,            [.privateKeyUsage, .biometryCurrentSet],            nil        )!        let attributes: [String: Any] = [            kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,            kSecAttrKeySizeInBits as String: 256,            kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,            kSecPrivateKeyAttrs as String: [                kSecAttrIsPermanent as String: true,                kSecAttrApplicationTag as String: keyTag,                kSecAttrAccessControl as String: access,            ],        ]        var error: Unmanaged<CFError>?        guard SecKeyCreateRandomKey(attributes as CFDictionary, &error) != nil else {            throw SignError.keyUnavailable        }    }    func signTransaction(challenge: Data) async throws -> Data {        guard let key = try existingKey() else { throw SignError.keyUnavailable }        let context = LAContext()        context.localizedReason = "Authorize this payment with biometric"        var error: Unmanaged<CFError>?        guard let signature = SecKeyCreateSignature(            key,            .ecdsaSignatureMessageX962SHA256,            challenge as CFData,            &error        ) else {            throw SignError.signingFailed        }        return signature as Data    }    private func existingKey() throws -> SecKey? {        let query: [String: Any] = [            kSecClass as String: kSecClassKey,            kSecAttrApplicationTag as String: keyTag,            kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,            kSecReturnRef as String: true,        ]        var item: CFTypeRef?        let status = SecItemCopyMatching(query as CFDictionary, &item)        guard status == errSecSuccess else { return nil }        return (item as! SecKey)    }}

On both platforms, the implementation pattern matters more than the API names: a hardware-backed key, an explicit setUserAuthenticationRequired or biometry-gated access control, and a signing operation tied to a server challenge. Anything less is a step-up that a determined attacker bypasses with a callback hook.

Certificate pinning with backup pins and a rotation plan

PSD2’s regulatory technical standards on strong customer authentication require an authenticated communication channel between the client and the bank’s servers (article 26). Certificate pinning is the standard implementation, and the standard implementation mistake is pinning a single certificate without a backup. When the certificate rotates and the app still pins the old one, every user on the previous version is locked out until they update.

The pattern is two pins: the current intermediate certificate and the next one queued for rotation. Banking apps with hundreds of branches and millions of users cannot afford forced upgrades the same day a CA renewal happens.

// Android: OkHttp with backup pinsimport okhttp3.CertificatePinnerimport okhttp3.OkHttpClientval pinner = CertificatePinner.Builder()    // Current production intermediate    .add("api.examplebank.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")    // Next intermediate, pre-pinned for zero-downtime rotation    .add("api.examplebank.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")    .build()val client = OkHttpClient.Builder()    .certificatePinner(pinner)    .build()

// iOS: URLSessionDelegate with backup pinsimport Foundationimport CryptoKitfinal class PinnedSessionDelegate: NSObject, URLSessionDelegate {    private let expectedPins: Set<String> = [        // Current production intermediate        "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=",        // Next intermediate, pre-pinned for rotation        "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=",    ]    func urlSession(        _ session: URLSession,        didReceive challenge: URLAuthenticationChallenge,        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void    ) {        guard let serverTrust = challenge.protectionSpace.serverTrust,              SecTrustEvaluateWithError(serverTrust, nil) else {            return completionHandler(.cancelAuthenticationChallenge, nil)        }        let certificates = (0..<SecTrustGetCertificateCount(serverTrust))            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }        let matched = certificates.contains { cert in            guard let publicKey = SecCertificateCopyKey(cert),                  let keyData = SecKeyCopyExternalRepresentation(publicKey, nil) as Data?            else { return false }            let hash = SHA256.hash(data: keyData)                .withUnsafeBytes { Data($0).base64EncodedString() }            return expectedPins.contains(hash)        }        if matched {            completionHandler(.useCredential, URLCredential(trust: serverTrust))        } else {            completionHandler(.cancelAuthenticationChallenge, nil)        }    }}

The rotation procedure is operational: before the new intermediate goes live, ship an app version that pins both. Once a sufficient share of the install base is on that version, rotate the certificate on the server. When the next rotation is planned, ship a new version that pins the new current plus the next backup. The pin set is never empty of the live certificate, and users on slightly stale versions don’t lose access.

Sealed transaction state and exhaustive matching

Banking apps that model transactions with a status string and a few boolean flags ship double-spending bugs to production. The fix is a sealed hierarchy in Kotlin or an enum with associated values in Swift, and an exhaustive when or switch everywhere the state is read. The compiler refuses to let a developer add a new state and forget to handle it.

sealed class TransactionState {    data class Drafted(val amount: Long, val recipient: String) : TransactionState()    data class Submitted(val id: String, val submittedAt: Long) : TransactionState()    data class RequiresStepUpAuth(val id: String, val challenge: ByteArray) : TransactionState()    data class Signed(val id: String, val signature: ByteArray) : TransactionState()    data class Confirmed(val id: String, val confirmedAt: Long) : TransactionState()    data class Failed(val id: String?, val reason: TransactionFailure) : TransactionState()    data class Reversed(val id: String, val reversedAt: Long, val reason: String) : TransactionState()}sealed class TransactionFailure {    data object NetworkError : TransactionFailure()    data object SignatureRejected : TransactionFailure()    data object IntegrityCheckFailed : TransactionFailure()    data object InsufficientFunds : TransactionFailure()    data class Other(val message: String) : TransactionFailure()}fun nextStep(state: TransactionState): Action = when (state) {    is TransactionState.Drafted -> Action.PromptUserToReview(state)    is TransactionState.Submitted -> Action.WaitForServer(state.id)    is TransactionState.RequiresStepUpAuth -> Action.LaunchBiometricSign(state.challenge, state.id)    is TransactionState.Signed -> Action.SubmitSignatureToServer(state.id, state.signature)    is TransactionState.Confirmed -> Action.ShowSuccess(state.id)    is TransactionState.Failed -> Action.ShowFailure(state.reason)    is TransactionState.Reversed -> Action.ShowReversal(state)}

If a future engineer adds TransactionState.AwaitingManualReview and forgets to update nextStep, the Kotlin compiler refuses to build. The same property in Swift comes from making the enum non-frozen and letting the compiler enforce exhaustive switches. The category of bug this prevents is the one where a transaction lands in a half-state, the UI infers something reasonable, and the user ends up debited twice or the recipient ends up paid twice.

Secure storage and the no-PAN rule

The boring rule first: banking apps do not store the Primary Account Number on the device, ever. PCI is explicit about it. The card number lives in the tokenization vault on the issuing bank’s side, surfaced to the app as a token through Apple Pay, Google Pay, or the bank’s own tokenization SDK. If the app handles raw card data during a new-card onboarding flow, the card number sits in a CharArray (Android) or a mutable buffer (iOS), gets used, gets wiped, and never gets logged.

What does live on the device: access tokens, refresh tokens, the device-binding key, and the transaction signing key from earlier. All four sit in the Android Keystore with setUserAuthenticationRequired(true) for the high-value ones, or in the iOS Keychain with kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly and Secure Enclave protection. The exact platform patterns are covered in the complete Android security guide and the iOS deep dive; the banking-specific addition is the no-PAN rule and the audit trail that proves it.

The secrets the backend depends on, including OAuth client secrets, signing certificate keys, and third-party API credentials for payment networks and KYC providers, never ship with the binary. They live in a secrets management layer like ByteHide Vault, which keeps them out of the APK, out of the IPA, out of source control, and rotatable when needed. PSD2 and PCI both care about how those secrets are handled, and the answer “they’re in our environment variables” doesn’t survive an audit.

Deep link parsing that pre-populates instead of executes

A deep link is an attacker-controlled input. The pattern that fails is parsing yourbank://transfer?to=X&amount=Y and executing the transfer immediately. The pattern that holds is parsing the deep link into a typed intention, pre-populating a confirmation screen with the parsed values, and requiring biometric step-up before anything moves money.

import android.net.Urisealed class DeepLinkIntent {    data class TransferDraft(val recipient: String, val amount: Long) : DeepLinkIntent()    data class StatementView(val accountId: String) : DeepLinkIntent()    data object Invalid : DeepLinkIntent()}private val ALLOWED_HOSTS = setOf("examplebank.com", "app.examplebank.com")private val RECIPIENT_REGEX = Regex("^[A-Z0-9]{8,34}$")  // IBAN-likeprivate val ACCOUNT_REGEX = Regex("^[a-zA-Z0-9_-]{1,40}$")private const val MAX_DEEP_LINK_AMOUNT = 10_000_00L  // EUR 10,000 in centsfun parseDeepLink(uri: Uri): DeepLinkIntent {    if (uri.scheme !in setOf("https", "yourbank")) return DeepLinkIntent.Invalid    if (uri.scheme == "https" && uri.host !in ALLOWED_HOSTS) return DeepLinkIntent.Invalid    return when (uri.pathSegments.firstOrNull()) {        "transfer" -> {            val to = uri.getQueryParameter("to") ?: return DeepLinkIntent.Invalid            val amount = uri.getQueryParameter("amount")?.toLongOrNull() ?: return DeepLinkIntent.Invalid            if (!RECIPIENT_REGEX.matches(to) || amount <= 0 || amount > MAX_DEEP_LINK_AMOUNT) {                return DeepLinkIntent.Invalid            }            DeepLinkIntent.TransferDraft(to, amount)        }        "statement" -> {            val id = uri.getQueryParameter("account") ?: return DeepLinkIntent.Invalid            if (!ACCOUNT_REGEX.matches(id)) return DeepLinkIntent.Invalid            DeepLinkIntent.StatementView(id)        }        else -> DeepLinkIntent.Invalid    }}

TransferDraft is a parsed intention, not authorization. The UI uses it to fill in a confirmation form. The user reviews. The biometric step-up signs the actual transaction. Layer 4 verifies the signature and applies its own velocity controls. Three layers of independent check, all because the deep link is treated as adversarial input, which is what it is.

Layer 2: Build-Time Hardening for Banking Apps

R8 on Android and Swift’s symbol stripping on iOS are the table-stakes obfuscation. They rename symbols, remove dead code, and inline what they can. They don’t encrypt strings, they don’t flatten control flow, they don’t insert anti-tampering instrumentation. For a generic mobile app, that’s enough to raise the floor for casual reverse engineering. For a banking app it’s the starting point of Layer 2, not the end.

Beyond the compiler: string encryption, resource encryption, control-flow flattening

Mobile hardening platforms are the category that addresses this. When JADX decompiles a banking APK protected only by R8, it produces near-source Kotlin with renamed classes and methods. The strings are right there in plaintext: endpoint URLs, certificate pin hashes, business logic constants, error messages that hint at internal structure. The control flow is the same shape it was in the source. The attacker reads the protocol by reading the strings, finds the cryptographic constants, locates the right call site, and pivots to Frida. ByteHide Shield is the in-house option, applying string encryption, resource encryption, control-flow flattening, and class encryption on top of the R8 baseline. The same hardening pattern is documented in the cross-platform mobile app shielding deep dive. Other commercial options in the category include GuardSquare DexGuard, Promon SHIELD, Appdome, and Verimatrix XTD; open-source partial alternatives like the Paranoid Gradle plugin handle string encryption only. The honest framing is that maintaining a correct, current obfuscator is a multi-year engineering investment that pays off if you’re selling obfuscators. For everyone else, including banks, it’s a buy decision.

Signature verification at runtime

A repackaged banking app is signed with the attacker’s key, not the bank’s. The check is to embed the expected SHA-256 hash of the release signing certificate into the binary at build time, then verify the running app’s signing certificate against that hash at runtime. The naive attacker who repackages without removing the check gets caught immediately. The sophisticated attacker who notices the check Frida-hooks it to return success, which is exactly why this check belongs in concert with Layer 3 hook detection and Layer 4 server verification, not as a standalone defense.

The implementation detail is the same as for any Android or iOS app, covered in the platform deep dives. The banking-specific layer is what happens after detection: a graduated response that blocks high-stakes flows (transfers, account changes) on detected tampering while still allowing read-only flows so the legitimate user on a falsely-flagged device can at least see their balance and call support.

SBOM and supply chain integrity

OWASP M2 (Inadequate Supply Chain Security) is the catchall for a category of attack that’s grown sharply in financial services: a transitive dependency, a build plugin, or a CI artifact gets compromised, and the release ships the compromise to every customer of every bank that uses that dependency. The 2024 events around xz-utils were the proof of concept everyone in the field had been warning about. The mitigation lives in two places.

First, generate an SBOM in CycloneDX or SPDX format for every release, sign it, and archive it. CycloneDX has well-maintained Gradle and CocoaPods plugins. The SBOM is what an auditor or an incident-response team needs to answer “did our app ship with the compromised version of library X?” without spending three days reconstructing build artifacts.

Second, run dependency vulnerability scanning in CI, with reachability analysis where possible. Reachability matters because not every CVE in a transitive dependency is actually invoked from your code. ByteHide Code does this on top of standard SCA; competitive options include Snyk and Mend with their own reachability variants. The result moves dependency review from a quarterly chore to a per-PR gate.

iOS-specific build hardening

A few iOS-specific items that don’t appear in the Android stack. Set Strip Style: All Symbols for release builds so debug symbol names don’t end up in the IPA. Enable App Transport Security in strict mode and explicitly justify every exception in Info.plist (most banks have none). Implement SecCodeCheckValidityWithErrors at app startup as a self-verification of the code signature, paralleling the Android signature-hash check.

Layer 3: Runtime, Mobile ADR for Banking Apps

Layer 3 is the only layer that sees what happens on the user’s device in real time. Build-time hardening produces a binary that resists static analysis at rest. Once that binary is executing on a rooted Android phone with a Frida server attached, or on a jailbroken iPhone with Liberty Lite hiding the jailbreak from naive checks, every static guarantee is up for negotiation. Runtime detection is what tells you “this build is currently being instrumented” and gives you the option to do something about it.

This is also the layer with the largest gap in most banking apps I’ve reviewed. The pattern is: extensive Layer 1 work, some Layer 2 hardening from a commercial vendor, and Layer 3 either absent or stuck at the level of a /system/xbin/su check that Magisk Hide bypasses in zero effort. Layer 3 done well is what separates banking apps that survive contact with motivated attackers from the ones that show up in the next quarterly fraud report.

This is where ByteHide App Runtime, the product previously named Monitor, lives, and where the Mobile ADR component matters most. Application Detection and Response is a category that’s been mature for several years on backend runtimes, with comparable products there including Contrast, Oligo, and Miggo. None of those vendors cover mobile. The mobile shielding vendors (GuardSquare, Promon, Appdome) cover Layer 2 hardening but not the detection-and-response loop that ADR implies. App Runtime is the only ADR built specifically for mobile, and banking apps are the natural use case because the stakes are high enough to justify the integration and the regulations require demonstrable runtime controls.

Why runtime detection is non-negotiable for banking apps

Three reasons, in order of how they tend to come up in conversations with banking security teams. First, build-time hardening protects a binary at rest. An attacker downloads your APK, decompiles what they can, and then runs the app on a device they control with Frida hooks attached. Hardening did its job up to that point; runtime detection is what notices the Frida agent in memory and decides what to do about it. Second, regulators are explicit. FFIEC’s Mobile Financial Services guidance calls out device integrity directly. PCI MPoC requires attestation of device integrity at transaction time. PSD2 RTS article 9 requires that authentication factors remain independent, which means the inherence factor (biometric) and the possession factor (device-bound key) need to actually be independent, which means you need to know the device isn’t compromised. Third, examiners want evidence. “We have hardening” doesn’t survive a thorough audit. “We stream root-detection, Frida-detection, and integrity-attestation events into our SIEM in real time” does.

Banks block transfers on rooted and jailbroken devices

Real examples from public app store listings and published security policies: Chase, Bank of America, Wells Fargo, ING, BBVA, and most major issuers refuse to run transfer flows on devices that report as rooted or jailbroken. Some refuse to launch at all on detected compromise; most ship a graduated response that blocks high-stakes actions while permitting balance checks and customer-support flows. The pattern is documented in the cross-platform jailbreak and root detection guide; the banking-specific framing is the graduated response.

enum class TransactionRisk { LOW, MEDIUM, HIGH }fun decideTransactionPolicy(    integrity: DeviceIntegrity.RiskLevel,    txRisk: TransactionRisk,): Policy = when {    integrity == DeviceIntegrity.RiskLevel.COMPROMISED && txRisk == TransactionRisk.HIGH ->        Policy.Block(reason = "Device integrity check failed for high-value transaction")    integrity == DeviceIntegrity.RiskLevel.COMPROMISED ->        Policy.RequireStepUpPlusBackendReview    integrity == DeviceIntegrity.RiskLevel.SUSPICIOUS && txRisk == TransactionRisk.HIGH ->        Policy.RequireStepUpPlusBackendReview    integrity == DeviceIntegrity.RiskLevel.SUSPICIOUS ->        Policy.LogAndProceed    else ->        Policy.Proceed}

The integrity signal feeds into the same backend correlation engine that handles Layer 4 anomaly detection. A single compromised event isn’t a block-everywhere mandate; it’s an input to a risk decision the bank makes deliberately, layer by layer.

Modern root detection on Android: beyond /system/xbin/su

Naive root detection (File("/system/xbin/su").exists()) is bypassed by Magisk Hide with zero effort. Zygisk extends the same hiding to the process initialization phase, which means even checks that fire very early in app launch can be intercepted. The pattern that holds combines multiple signals, weights them, and feeds the aggregate into the policy decision above:

• Filesystem indicators: known root binary paths, writable system partitions, presence of root-management apps in the installed-package list.
• Build tags: Build.TAGS containing test-keys indicates a custom or development build that isn’t shipped through OEM signing.
• Play Integrity attestation: the server-verified signal Google has replaced SafetyNet with. The client requests a token, the server decodes it with Google’s API, and the verdict (“MEETS_DEVICE_INTEGRITY” plus “MEETS_STRONG_INTEGRITY” for the highest tier) determines what the bank does next.
• Native code probes: the same logic implemented in C/C++ through JNI, which is harder to Frida-hook than the Kotlin equivalent because Frida hooks bytecode by signature and native code by symbol, and stripped native symbols don’t surface easily.

The full implementation of multi-signal detection is covered in the platform deep dive; the banking-specific addition is feeding the result into the graduated policy rather than into a single boolean.

Modern jailbreak detection on iOS

The iOS counterpart is structurally identical and superficially different. Naive jailbreak detection (FileManager.default.fileExists(atPath: "/Applications/Cydia.app")) is bypassed by Liberty Lite, A-Bypass, Shadow, and any of half a dozen other jailbreak-hiding tweaks. The signals that compose into a meaningful detection on iOS:

• Sandbox escape attempts: try to write to /private/jailbreak.txt. On a stock device, the sandbox refuses. On a jailbroken device, the write succeeds.
• Dynamic library inspection: _dyld_image_count and _dyld_get_image_name give a list of every dylib loaded into the process. Suspicious entries (SubstrateLoader.dylib, MobileSubstrate.dylib, libsubstitute.dylib) indicate a jailbreak environment.
• sysctl(KERN_PROC, KERN_PROC_PID, getpid()) reads process flags; the P_TRACED flag indicates the process is being debugged.
• App Attest and DeviceCheck: Apple’s server-verified attestation, the iOS equivalent of Play Integrity, gives the same kind of trustworthy signal once the backend verifies the token.

The same combine-and-weight pattern applies. The full iOS-specific code is in the iOS app security deep dive; cross-link from this section there for the implementation.

Frida and Objection detection in banking apps

Frida is the dominant runtime instrumentation framework on both platforms. Objection is the banking-app-pen-test tooling built on top of Frida that automates the common attacks. Both work by injecting a JavaScript runtime into the target process and hooking methods at the bytecode (Android) or function (iOS) level.

Detection on the defender’s side comes from fingerprinting what Frida leaves in the process: a default port at 27042, a default agent thread named gum-js-loop, a memory-mapped region with a recognizable signature near the agent’s load address, and several other signals that change as Frida itself updates. The detection logic has to update on roughly the same cadence as Frida, which is why this is the part most clearly suited to a maintained runtime SDK rather than a one-off implementation. A Frida-detection snippet copy-pasted from a 2021 Stack Overflow answer detects Frida from 2021. Frida from 2026 ships with countermeasures against the 2021 detection technique.

Overlay attack detection on Android

Banking-specific to Android, because iOS sandboxing prevents the pattern outright. The malicious-overlay attack abuses AccessibilityService permissions to draw views on top of the legitimate banking app’s UI. The user types their credentials into the overlay believing it’s the bank’s login screen; the malware logs and dismisses.

Two defenses, both required:

import android.content.Contextimport android.view.accessibility.AccessibilityManagerimport android.view.WindowManagerfun suspiciousAccessibilityServices(context: Context): List<String> {    val mgr = context.getSystemService(Context.ACCESSIBILITY_SERVICE) as AccessibilityManager    val enabled = mgr.getEnabledAccessibilityServiceList(        android.accessibilityservice.AccessibilityServiceInfo.FEEDBACK_ALL_MASK    )    // Allowlist of legitimate accessibility services (screen readers, etc.)    val ALLOWED = setOf(        "com.google.android.marvin.talkback",        "com.samsung.accessibility",    )    return enabled        .map { it.resolveInfo.serviceInfo.packageName }        .filterNot { it in ALLOWED }}// On a transfer activity:override fun onCreate(savedInstanceState: Bundle?) {    super.onCreate(savedInstanceState)    window.setFlags(        WindowManager.LayoutParams.FLAG_SECURE,        WindowManager.LayoutParams.FLAG_SECURE,    )    val suspicious = suspiciousAccessibilityServices(this)    if (suspicious.isNotEmpty()) {        reportSecurityEvent(SecurityEvent.AccessibilityServiceDetected(suspicious))        showAccessibilityWarningAndExit()    }}

FLAG_SECURE is the second half: it prevents screen recording (the variant of the attack where malware doesn’t draw an overlay but just records what the user types into the legitimate UI), and on some Android versions it also blocks the overlay from being drawn over the secured window. Both controls together cover the realistic attack patterns.

Mobile ADR: Application Detection and Response for banking

Stepping back from the individual techniques. Every check covered above produces an event: root detected, Frida detected, integrity check failed, suspicious accessibility service, signature mismatch. Each event on its own is low-fidelity. A device with an accessibility service the user doesn’t recognize is suspicious but not necessarily compromised; a fresh install reporting EMULATOR plus DEBUGGER plus a high-value transaction attempt within sixty seconds is clearly fraud.

Mobile ADR is the layer that captures every security-relevant event from the app process, correlates them within a session, streams them to a backend that correlates across sessions, and gives the bank the information needed to act. Integration in code is a single SDK initialization that wires the detection policies and the event stream:

// Replace `com.bytehide:app-runtime-android:1.x.x` with the actual SDK package name when integrating.import com.bytehide.runtime.AppRuntimeimport com.bytehide.runtime.Policyimport com.bytehide.runtime.detection.Detectionclass BankingApp : Application() {    override fun onCreate() {        super.onCreate()        AppRuntime.init(this) {            apiKey = BuildConfig.APP_RUNTIME_KEY            policies = mapOf(                Detection.ROOT to Policy.BLOCK_HIGH_RISK_FLOWS,                Detection.JAILBREAK to Policy.BLOCK_HIGH_RISK_FLOWS,                Detection.DEBUGGER to Policy.BLOCK,                Detection.HOOKING_FRAMEWORK to Policy.BLOCK,                Detection.EMULATOR to Policy.LOG,                Detection.TAMPERED_SIGNATURE to Policy.BLOCK,                Detection.SUSPICIOUS_ACCESSIBILITY to Policy.WARN_AND_REPORT,                Detection.INTEGRITY_FAILURE to Policy.BLOCK,            )            onSecurityEvent = { event ->                FraudTelemetry.report(event)            }        }    }}

// Replace pod name with the actual SDK when integrating.import ByteHideAppRuntime@mainstruct BankingApp: App {    init() {        AppRuntime.initialize(            apiKey: Bundle.main.appRuntimeKey,            policies: [                .jailbreak: .blockHighRiskFlows,                .debugger: .block,                .hookingFramework: .block,                .tamperedSignature: .block,                .integrityFailure: .block,            ],            onSecurityEvent: { event in                FraudTelemetry.report(event)            }        )    }    var body: some Scene {        WindowGroup { ContentView() }    }}

The detection logic runs in instrumentation that’s harder to hook than the equivalent Kotlin or Swift code would be. The detection rules update as the threat landscape does, which is the value of the category being a maintained product rather than a one-time integration. And the events stream to a backend that closes the loop with Layer 4, which is where the rest of this guide turns next. The category framing is in Runtime Application Self-Protection (RASP); the banking-specific application of it is what this section has covered.

Layer 4: Backend, The Final Line for Banking

Mobile clients lie. They lie because they’ve been compromised, because they’ve been reverse-engineered, because someone with Objection running has been inside the process for an hour. Layer 4 is the layer that assumes everything coming from the client is potentially adversarial and decides accordingly. For banking apps, this layer is where the actual fraud-prevention decision lives.

Server-side authorization on every transaction

Non-negotiable for banking. Every transfer, every payment, every account change goes through a server-side authorization decision that doesn’t trust the client’s claim of who the user is or what they’re allowed to do. For transactions specifically: per-user amount limits enforced server-side, recipient allowlist with a new-recipient hold (first transfer to a never-seen-before recipient requires a 24-hour cooldown), time-of-day risk scoring, and geo-velocity rules.

The anti-pattern to avoid: a feature flag evaluated only client-side. “If user.isPremium then show the international transfer button” is fine for UI. “If user.isPremium then allow the international transfer” is a vulnerability one Frida hook deep. The server has to re-check on the request.

Server-side verification of Play Integrity and App Attest tokens

The tokens that Layer 3 collects from the client mean nothing if the server doesn’t verify them with Google or Apple. The standard pattern:

1. Server issues a single-use nonce when the client starts a sensitive flow.
2. Client requests a Play Integrity (Android) or App Attest (iOS) token with that nonce embedded.
3. Client sends the token along with the protected request.
4. Server calls the Play Integrity API or App Attest verification endpoint to decode the token.
5. Server checks: nonce matches, app package matches, integrity verdicts are at the required tier (“MEETS_DEVICE_INTEGRITY” for Android, valid attestation for iOS), token isn’t expired.
6. Server caches the decoded result per session for sensitive-flow endpoints; doesn’t pay the verification cost on every endpoint, just on the ones that matter (transfer, payment, account changes).

External reference for the full Android flow: developer.android.com/google/play/integrity. The iOS equivalent is at developer.apple.com under DeviceCheck and App Attest.

Behavioral anomaly detection on client telemetry

The events from Layer 3 feed Layer 4’s anomaly model. A single signal is noise; correlated signals across a session are signal. Three banking-specific patterns that have triggered real incident response:

• A session starts on a device that immediately reports INTEGRITY_FAILURE, the user then attempts to enumerate account features by visiting endpoints in alphabetical order over the next minute, and finally tries to initiate a transfer to a new recipient. Classic reconnaissance leading to action.
• A device claims a fresh install but its first request includes a refresh token that’s currently active in another country with an active session that hasn’t been logged out. Token theft.
• An app reports EMULATOR plus DEBUGGER plus a high-value transaction attempt within the first sixty seconds of the session, and the credentials match a known account that’s been targeted by phishing recently. Synthetic-identity attack from a fraud farm.

None of those is detectable from one signal. All are detectable from correlation across the layers, which is why streaming Layer 3 events to a backend that can also see what Layer 4 sees is what makes the architecture work. ByteHide Audit is the company’s product for the SIEM-and-forensics side of this loop; the value proposition is the same whether the SIEM is Audit, Splunk, Datadog, or an in-house Snowflake stack.

Per-session rate limiting and transaction velocity controls

Mobile traffic from a single legitimate user crosses three or four networks in an afternoon: corporate WiFi, LTE, home WiFi, public hotspot. IP-based rate limiting collapses legitimate users into the same bucket as bots. Session-based rate limiting, with the session token bound to a Play Integrity or App Attest attestation, gives a per-user budget that travels with the user across networks.

Transaction velocity is the banking-specific layer on top: maximum N transfers per hour, maximum total amount per day, maximum new-recipient transfers per week. Enforced server-side, per user, with the kind of override flow that lets a customer call support and lift a limit for a one-off large purchase. The velocity controls are also where the FFIEC and PSD2 monitoring requirements get operationalized: regulators ask not just whether the controls exist but whether they alert when triggered and whether there’s a documented response procedure.

PSD2 SCA integration

Strong Customer Authentication under PSD2 requires two factors out of three categories: knowledge (something the user knows, like a PIN), possession (something the user has, like a device), and inherence (something the user is, like a fingerprint or face). On a mobile banking app, the typical strong combination is possession (the device-bound key in Keystore or Secure Enclave, attested by Play Integrity or App Attest) plus inherence (biometric step-up bound to the signing operation).

Knowledge as the primary factor is discouraged where avoidable, because PIN-only factors are phishable and the SCA RTS independence requirement (article 9) is hardest to satisfy when the knowledge factor lives in the same app as the possession factor. The clean architecture uses biometric step-up on the device as inherence, the device-bound key as possession, and reserves PIN entry for fallback flows where biometric is unavailable.

Compliance Mapping: Regulations to Technical Controls

Auditors don’t accept “we follow best practices”. They accept evidence that specific controls exist, operate correctly, and are tested regularly. This table maps the major mobile banking regulatory and standards frameworks to the specific technical control inside the app or backend that satisfies the requirement. Use it as an audit reference: for each row, can you point to the file in your codebase, the configuration in your build pipeline, or the runbook on your incident-response wiki that implements the control?

The cross-platform OWASP framing of the same risk model is covered in our OWASP Mobile Top 10 framework post. The OWASP MASVS verification standard at mas.owasp.org/MASVS is the formal test plan the table maps against; auditors familiar with mobile security work directly from it.

iOS and Android: Side by Side for Banking

A quick-reference table for teams shipping both platforms. The control category is the same; the API names are different and the cross-platform consistency is what makes Layer 4’s backend logic uniform.

The platform-specific deep dives are in the complete Android security guide and the iOS security deep dive. This table is the bridge between the two for teams that have to keep the controls aligned across platforms.

Mobile Banking Security Checklist

A working audit checklist for shipping a mobile banking app, organized by the four layers. Items in bold are the ones that change specifically because the app is banking rather than generic mobile.

Layer 1: Code

• [ ] No Primary Account Number, no CVV, no full card data stored on the device beyond the transaction lifecycle.
• [ ] Hardware-backed key storage (Secure Enclave on iOS, StrongBox or TEE on Android) for tokens and signing keys.
• [ ] Biometric step-up bound to a transaction-signing CryptoObject (Android) or SecKey (iOS) for every transfer, payment, and account change.
• [ ] Certificate pinning with current and next-rotation backup pins; rotation procedure documented.
• [ ] Sealed transaction state (Kotlin) or non-frozen enum (Swift) with exhaustive matching; no half-states.
• [ ] Deep link parser allowlists recipients and amounts, pre-populates UI, and requires step-up authentication before any action.
• [ ] FLAG_SECURE on Android sensitive screens; iOS blur-on-backgrounding for the same.
• [ ] No secrets in strings.xml, BuildConfig, Info.plist, or anywhere else in the binary.
• [ ] CharArray (Android) or mutable buffer (iOS) for any password or token in memory; wipe immediately after use.

Layer 2: Build-time

• [ ] R8 enabled in Android release (isMinifyEnabled = true); strip all symbols in iOS release.
• [ ] String and resource encryption applied through Shield or an equivalent commercial hardening platform.
• [ ] Release signing certificate SHA-256 hash embedded for runtime verification.
• [ ] iOS code-sign self-verification via SecCodeCheckValidityWithErrors at startup.
• [ ] SBOM (CycloneDX or SPDX) generated, signed, and archived per release.
• [ ] SCA with reachability analysis running in CI on every PR.

Layer 3: Runtime

• [ ] Root and jailbreak detection with multiple signals (Magisk- and Zygisk-aware on Android; sandbox plus dyld plus sysctl on iOS).
• [ ] High-stakes flows (transfers, settings, account changes) block on detected root or jailbreak; lower-stakes flows step up.
• [ ] Anti-debugger checks active in release builds.
• [ ] Frida, Objection, and Cycript fingerprinting in process memory.
• [ ] Overlay attack detection on Android via AccessibilityManager.getEnabledAccessibilityServiceList.
• [ ] Integrity check on app launch and at the start of every sensitive flow.
• [ ] Mobile ADR or RASP SDK integrated (App Runtime or alternative).
• [ ] All security events streamed to backend with per-session correlation.

Layer 4: Backend

• [ ] Every transaction independently authorized server-side; no client-side authorization decisions.
• [ ] Play Integrity (Android) and App Attest (iOS) tokens verified against Google and Apple, not the client.
• [ ] PSD2 SCA flow operationalized: two factors out of (knowledge, possession, inherence), with independence verified.
• [ ] Per-session rate limiting bound to integrity-attested tokens, not IPs.
• [ ] Transaction velocity controls: per-user, per-hour, per-day, per-new-recipient.
• [ ] Behavioral anomaly detection on client telemetry, with alerting hooked to incident response.
• [ ] Geo-velocity, new-recipient hold, and impossible-travel rules enforced for transfers.

For the testing methodology that verifies all of the above, our mobile app security testing guide covers static analysis, dynamic analysis, and penetration testing workflows for mobile apps; the banking-specific testing patterns are the ones that focus on the controls in this checklist.

Frequently Asked Questions

Is it safe to have a mobile banking app on your phone?

For consumers, modern banking apps from major institutions are safer than the alternatives because they implement device attestation, biometric authentication, certificate pinning, and server-side fraud detection. For the people building the apps, “safe” depends on whether the four layers above are implemented to current standards. An app that ships only Layer 1 and trusts the device is not safe in the way a regulator means the word.

What is the most secure mobile banking app?

The most secure mobile banking app is the one whose architecture passes MASVS-L2 verification, whose runtime telemetry is monitored in real time, whose backend independently verifies every claim from the client, and whose security controls are audited regularly. The brand of the bank matters less than the architecture of the app. Banks that publish their security posture (some EU neobanks do this transparently) tend to be more rigorous than banks that don’t.

What bank is least likely to get hacked?

Reframe the question. The bank itself is rarely the target; the customer’s mobile session is. Banks whose apps implement defense-in-depth across all four layers, who block high-stakes flows on rooted or jailbroken devices, and who maintain strong Layer 4 anomaly detection are the ones whose customers are least likely to be defrauded. Brand recognition is a poor proxy for security maturity in mobile banking.

How to secure a mobile banking app?

Use the four-layer defense-in-depth model in this guide. Layer 1 ships hardware-backed crypto, biometric step-up tied to transaction signing, sealed transaction state, certificate pinning with backup pins, and deep link allowlisting. Layer 2 hardens the binary beyond compiler defaults with string encryption, signature verification, and a maintained SBOM. Layer 3 detects rooted or jailbroken devices, hooking frameworks, and tampering at runtime, with graduated response policies. Layer 4 verifies every transaction server-side, attests device integrity with Google or Apple, runs anomaly detection on client telemetry, and enforces transaction velocity controls.

What compliance frameworks apply to mobile banking apps?

PCI MPoC for mobile payments on commercial off-the-shelf devices, PSD2 RTS for strong customer authentication in the EU, DORA for ICT operational resilience in the EU financial sector, FFIEC’s Mobile Financial Services guidance in the US, GLBA’s Safeguards Rule for US financial privacy, and OWASP MASVS as the verification standard most auditors test against. Each maps to specific technical controls inside the app, mapped in the compliance table above.

What is Mobile ADR and why does it matter for banking apps?

Mobile ADR (Application Detection and Response) is in-process security telemetry for mobile apps. Every security-relevant event, including root detection, debugger attachment, hooking framework detection, and integrity failure, is captured at the source, correlated, and streamed to a backend with full context for fraud detection and incident response. Banking apps are the natural use case because the stakes justify the integration and regulations require demonstrable runtime controls. At the time of writing, ByteHide App Runtime is the only ADR product with Mobile ADR coverage; the major backend ADR vendors (Contrast, Oligo, Miggo) cover only server-side runtimes.

Should banking apps block rooted or jailbroken devices?

Yes for high-stakes flows, with a graduated response for lower-stakes ones. FFIEC’s Mobile Financial Services guidance is explicit about device integrity controls, and most major banks already block transfers, new-payee additions, and account changes on devices that report as rooted or jailbroken. Blocking outright at app launch is more aggressive than necessary for read-only flows; permitting balance checks while blocking transfers is the pattern that satisfies regulators and serves legitimate users who happen to be on developer devices.

How do I prevent overlay attacks like FluBot or BRATA in my banking app?

On Android, monitor AccessibilityManager.getEnabledAccessibilityServiceList() for suspicious services that aren’t on a known allowlist of screen readers and assistive tools, and set FLAG_SECURE on every sensitive screen to block screen recording and prevent overlay drawing on some Android versions. Stream the detection events to the backend so a device with an unexpected accessibility service gets flagged for higher scrutiny on subsequent transactions. Pair with runtime hooking detection so the malware’s instrumentation of your app’s process gets caught even if the overlay itself goes undetected.

Conclusion

Mobile banking app security isn’t a feature you bolt on. It’s an architecture you commit to. The four layers (code, build-time, runtime, backend) each defend against a different attack pattern, and the regulations that examine you (PCI MPoC, PSD2 SCA, DORA, FFIEC, OWASP MASVS) all map to specific controls inside the app. The apps that get compromised are the ones that picked one layer and called it done. The apps that survive a motivated attacker and pass examiner scrutiny are the ones that cover all four.

The work breaks down as ordinary engineering with high stakes: write Kotlin and Swift that use the platform security APIs correctly, harden the binary you ship so static analysis is expensive, watch the process at runtime so dynamic attacks are visible, and verify everything on a backend that doesn’t trust the client. None of those steps is optional. None of them is sufficient on its own. Each one closes off attack patterns the others miss.

For the runtime layer specifically, including Frida and Objection detection, jailbreak and root awareness, overlay attack detection, and integrity attestation across iOS and Android, ByteHide App Runtime is the only ADR built for mobile, and the Mobile ADR component is what gives banking apps the same caliber of in-process telemetry the backend ADR market has had for years. Shield handles the Layer 2 build-time hardening side. Vault handles the secrets-management side that PSD2 and PCI both care about. Together they cover the layers most banking teams underinvest in.