Deepfake fraud is rising across APAC, with banks feeling the pressure in some of their most exposed mobile journeys. eKYC. Login. Account recovery. Step-up approval. That pressure is changing the way face authentication needs to be understood.
For years, the main question was whether a facial recognition stack could tell a real face from a fake one. This still matters. But it is no longer the biggest challenge. On mobile, attackers can also interfere with the device state, the camera source, and the app runtime that feed the biometric decision.
So, the new question is wider now. Can the bank trust the session in which the face is captured and verified? That is why deepfake resilience in mobile banking is a shared-responsibility issue. Strong face authentication still matters. Runtime protection matters too. They solve different parts of the same problem.
Why deepfake fraud hits APAC mobile banking so hard
APAC is an area where several pressures meet at once.
The region combines mobile-first banking, digital onboarding, wallets, superapps, and QR payments with device environments that already include rooted devices, app cloning, repackaging, virtualization, and mobile malware. Face authentication often sits inside high-value journeys while running in conditions attackers already know how to manipulate.
That broader threat environment is now being shaped by organized crime as well as by fraud tooling. In September 2025, UNODC warned that organized crime groups in Southeast Asia were rapidly adopting automation and AI to expand cybercrime operations, including AI-powered deepfakes, voice cloning, synthetic identities, and bots used to circumvent verification processes. Banks must realize that deepfake abuse is not an isolated edge case. It is part of a wider shift in how fraud is being scaled across the region.
Banking-specific cases in APAC show what that shift looks like in practice.
-
In Indonesia, fraudsters used virtual camera technology to feed AI-generated images into a digital KYC flow for loan applications.
-
In Vietnam and Thailand, malware stole photos, videos, and credentials from mobile devices, then used those assets to create deepfakes that beat facial biometric checks.
-
GoldPickaxe pushed the pattern further by stealing biometric data from mobile devices for later fraud against banking apps.
This is why APAC matters here: deepfake and biometric spoofing attacks are building on an existing mobile threat environment rather than appearing as a distinct attack method.
Learn more about Deepfakes, including risk factors, consequences, solutions and best practices
How camera injection and runtime tampering bypass mobile face authentication
A mobile deepfake attack usually works by compromising the conditions around the biometric check before the bank makes a trust decision.
The first step is often device control. A rooted or jailbroken phone, a virtual space, or a cloned app instance gives the attacker more freedom to observe and interfere with the flow. Those conditions can support privileged tools, bypass restrictions, and hide tampering from the app.
The next step is usually tampering around the capture pipeline. Instead of sending a genuine live camera feed into the face-auth flow, the attacker hooks the camera path and replaces the source with synthetic or pre-recorded content. Virtual camera tools such as VCAM and VCAMSX are useful here because they can inject manipulated video into the capture pipeline while making it appear to the app like normal input.
Learn more: Deepfake videos used to discredit people or organizations
Frameworks like Frida and LSPosed help enable this kind of runtime interference. They can, in theory, also be used to influence decisions inside a specific app, but that tends to be more targeted. In practice, the more common use is to tamper with the runtime so hostile input reaches the biometric flow. The biometric layer still matters. But it may now be operating inside a session the bank should not trust.
This is why passive liveness alone can leave a gap. It can assess the face or frame while still depending on a camera path, device state, or app runtime that could have already been manipulated.
Strong face authentication in mobile banking
The face-auth stack has a clear task. It is responsible for verifying the face itself. That means confirming identity, checking liveness, resisting presentation attacks, and reducing the chance that replayed, synthetic, or manipulated facial input is accepted as genuine.
Banks should continue to raise the assurance level of the biometric verification layer. They should expect strong match accuracy, strong presentation-attack resistance, clear evidence of improvement against synthetic media, and a clean understanding of where the biometric layer is strong and where it is not.
None of that becomes less important because runtime attacks are rising. In fact, it becomes more important. The biometric decision still needs to hold up when the session is clean.
Learn more: Biometric authentication attacks
What runtime protection does for mobile banking
Runtime protection performs a different but complementary function. Its purpose is not to decide whether the face is authentic. It is there to help the bank decide whether the app can trust the environment in which the face is being captured, processed, and acted on.
That means detecting hostile conditions around the flow, including rooted and jailbroken devices, virtualized or cloned environments, repackaged apps, hooking and instrumentation frameworks, and suspicious camera-path behavior. In practice, that is the layer that helps answer questions the biometric engine cannot answer on its own.
| Runtime question | Why it matters |
| Is the app running where it should? | Detects cloned, repackages, or virtualized environments |
| Is the capture source trustworthy? | Helps identify suspicious camera-path behavior |
| Is the flow bring observed or manipulated? | Flags hoking, instrumentation, and runtime tampering |
| Should this session reach face-match trust? | Gives banks a stronger basis for step-up, block, or review decisions |
That is where runtime protection earns its place in the control model.
Learn more: Runtime application self-protection (RASP)
Why banks need a shared control model for mobile face authentication
Banks run into trouble when they ask one layer to solve two different problems. If the bank relies only on the biometric stack, it may leave the mobile environment under-protected. If it relies only on runtime protection, it may underweight the quality of the biometric decision itself.
The better model is to treat the two layers as distinct but interdependent.
The face-auth stack verifies the face. The runtime protection layer defends the app, device, and camera path around that verification. The bank then brings those signals together in the journeys that matter most: eKYC, login, account recovery, and high-risk approvals.
The point of this is not to spread or shirk responsibility. It is to reflect how these attacks work in the real world.
Where Promon fits in the face-auth control stack
Promon fits in the mobile face-auth control stack as the always-on, in-app protection layer behind the biometric flow. Promon’s products help banks detect and block many of the hostile conditions these attacks rely on, including hooking frameworks, virtualization, repackaging, suspicious camera-path behavior, and rooted or jailbroken environments. They are designed to strengthen the mobile session around face authentication, not replace the biometric engine inside it.
This is an important distinction. Promon is not claiming to be the facial recognition layer. It is not claiming that every deepfake-related failure should now be handed to a runtime protection vendor. It is claiming a specific part of the problem: protecting the mobile environment where many of these attacks now execute.
That gives banks a practical path forward. They can strengthen the face-auth journeys they already use without replacing the SDKs already in production or adding more friction for customers.
What banks should review in eKYC, login and account recovery
Banks reviewing deepfake resilience in APAC should analyze the entire mobile app security flow, not just the face match element.
A useful review starts with four actions.
-
Identify where face authentication carries the most business risk. Start with eKYC, login, account recovery, and high-risk approvals.
-
Check what protects the session before the biometric decision is trusted. Review controls for compromised devices, tampered app instances, runtime instrumentation, and suspicious camera behavior.
-
Test the flow under hostile mobile conditions. Include rooted devices, virtualized environments, repackaged apps, runtime hooking, and manipulated camera input.
-
Bring biometric and runtime signals together in policy. A stronger control model uses both signal sets when deciding whether to trust, step up, block, or review a session.
That is the shift banks need now to move from blame to better control design.
The bottom line on deepfake resilience in APAC banking
Deepfake resilience in mobile banking is not owned by one vendor category. Banks need strong face authentication. They also need runtime protection around the app, device, and camera path that support that flow.
That is the message APAC banks need now because it matches the attack path more closely than either solution on its own. The biometric layer still matters, as does the runtime layer. Banks are in a stronger, safer position when both aspects are performing together and the bank is using both sets of signals in the journeys that matter.
