Emulators in FinCrime: How Virtual Devices Are Industrialising Fraud

Emulators are a classic dual-use technology. In legitimate software engineering, they are used to simulate mobile devices and application environments without requiring fleets of physical handsets. Android’s own tooling allows developers to run virtual devices, simulate location and routes, and even emulate phone calls and SMS; Appium exists specifically to automate mobile app testing across platforms. IBM’s Trusteer team likewise describes mobile emulators as software that can mimic device type, manufacturer, model, screen characteristics, location, and touch interactions at scale. Those same capabilities make emulators highly attractive to fraud operators who want repeatability, concealment, and low-cost automation.

For a FinCrime audience, the important point is that emulator abuse is not a narrow mobile-security issue. It sits at the intersection of fraud, remote onboarding, account takeover, synthetic identity abuse, mule-account provisioning, biometric bypass, and cyber-enabled money movement. Read across NIST’s identity-proofing guidance, the EBA’s remote onboarding standards, Federal Reserve material on synthetic identities, and recent casework from the Netherlands, and a common pattern emerges: criminals are attacking the trust assumptions behind digital onboarding and authentication, and emulators are one of the enabling layers that make those attacks scalable.

Key Takeaways

• Emulators Are Industrialising Financial Crime
• Fraud Is Moving Beyond Physical Devices
• Digital Identity Assumptions Are Being Challenged
• Automation Is Increasing Fraud Scale and Speed
• Deepfakes Amplify Emulator-Enabled Fraud
• Device Fingerprinting Alone Is No Longer Enough
• Emulator Detection Should Be Risk-Based
• Cross-Functional Collaboration Is Essential
• Emulation Can Also Strengthen Defensive Testing

Listen the podcast

Watch the video

Why emulators matter now

Financial institutions increasingly rely on remote, app-based acquisition and servicing. That shift has obvious commercial benefits, but it also creates a technical asymmetry: a bank has to trust that a device is real, that a camera feed is genuine, that an account applicant is present, and that activity comes from a consistent human-operated environment. An emulator attacks all four assumptions at once by replacing a real endpoint with a controllable software environment. NIST’s latest remote identity-proofing guidance explicitly recognises this problem, requiring technical controls that raise confidence media comes from a genuine sensor and specifically calling out the need to detect virtual cameras, device emulators, and jailbroken devices.

This is why emulator risk now belongs in mainstream financial-crime governance rather than only in mobile-app security teams. The EBA’s remote onboarding guidelines were written precisely because divergent and unclear digital onboarding practices can create gaps that expose the EU single market to money-laundering and terrorist-financing risk; the guidelines specifically require institutions to test fraud risks, including impersonation fraud risks, when they adopt remote onboarding solutions. In other words, emulator abuse is not just a fraud-loss problem. It is a customer due diligence, operational resilience, and AML/CFT control-design problem.

How criminal actors weaponise emulation

The clearest criminal use case is application fraud at scale. The Federal Reserve defines synthetic identity fraud as the use of fictitious and sometimes real information to create new identities that can then be used to defraud institutions, and notes that fraudsters repeatedly apply for credit until approved and often operate across multiple linked accounts. Industry reporting on device farms and emulator attacks shows why emulators are so useful here: they let operators automate mass account creation while rotating the apparent device, location, and interaction profile, making repeated applications look less obviously connected. This is best understood as a force multiplier for synthetic identity abuse rather than a separate fraud typology in its own right.

The same infrastructure is equally powerful in account takeover. IBM Trusteer documented large-scale emulator-driven operations that used designated emulated devices to access thousands of customer accounts and attempt thousands of fraudulent transactions; IBM later described a major retail-bank attack in which more than 15 emulated devices accessed more than 6,000 end-user accounts, while coverage of earlier IBM research reported an emulator farm mimicking more than 16,000 compromised customer phones. The strategic lesson is straightforward: once criminals can reproduce a victim’s apparent mobile environment, they can industrialise login attempts and transaction activity without physically possessing the original device.

Emulators are also useful because they let fraudsters manipulate geography and device trust signals. Android’s own emulator controls allow a virtual handset to simulate “my location” data, save routes, replay journeys, and emulate phone calls and text messages. IBM similarly notes that emulators can mimic location and touch behaviour. In a financial-crime setting, that means a criminal can present a session that appears to come from a plausible place, follow a plausible route, and interact with the app in a controlled, repeatable way. This is especially relevant where firms still lean heavily on basic device fingerprinting, coarse geo-consistency checks, or one-off step-up triggers tied to “new device” events.

The most acute concern is the combination of emulation with liveness bypass and digital injection. NIST SP 800-63A-4 warns that remote identity-proofing processes are vulnerable to digital injection attacks and forged media attacks, and says live document capture and presentation-attack controls alone are not sufficient in all cases. NIST’s 2025 injection-attack workshop materials go further, listing software virtual cameras, hardware virtual cameras, and mobile device emulators as examples of attack instruments. ENISA’s remote identity-proofing workshop summarised the security problem plainly: injection attacks can be automated, scripted, and launched more cheaply than presentation attacks, which makes them inherently scalable.

That threat is no longer theoretical. In June 2026, the District Court of Amsterdam reported that a 34-year-old man used manipulated images with biometric characteristics and deepfake-style photographs to deceive ABN AMRO’s identification and verification process and open 47 bank accounts in other people’s names. The court noted that the bank’s onboarding process was misled between March and November 2025 and that some of the fraudulently opened accounts were then used to enable further crimes, including bank-helpdesk fraud and cash withdrawals. That case does not prove emulator use in every deepfake KYC attack, but it does show how digital identity proofing can be defeated at the point where biometric comparison is treated as a sufficient indicator of presence and authenticity.

On OTP and MFA, emulators should be understood as part of a wider attack chain rather than as a complete bypass by themselves. Modern emulator environments can simulate SMS-capable and call-capable device conditions, which is useful for testing and automating OTP workflows. But live OTP theft in financial crime typically depends on upstream compromise such as smishing, vishing, device malware, or access to cloud-phone infrastructure that can receive or relay authentication messages. Group-IB’s 2026 reporting on cloud phones explicitly includes techniques involving phone numbers with SMS banking enabled and ongoing access from fraudster-controlled virtual phones, while BioCatch describes scam flows in which criminals gain control of victims’ devices, intercept OTPs, and access banking apps in real time.

Why emulated fraud scales so efficiently

The first reason is technical commoditisation. The same ecosystem that helps developers ship better software also makes it easier for criminals to industrialise attacks. Android emulators are standard development tools, Appium makes it straightforward to run scripted mobile interactions, and Firebase’s App Check documentation explicitly recognises that emulators are normal in development and CI by providing a debug provider for those environments. That legitimate footprint matters. It means institutions cannot treat the mere existence of an emulator-like artefact as automatic proof of malicious intent; they need a richer, contextual risk model.

The second reason is economics. ENISA’s 2023 workshop notes that injection attacks do not require physical artefacts, can be automated, and are cheaper to launch than traditional presentation attacks. That removes labour and logistics from the attacker’s cost base. The result is not only more attempts, but more experimentation: fraudsters can test different device profiles, different onboarding routes, different timing patterns, and different media-injection methods until they find a path of least resistance.

The third reason is evolutionary pressure. Basic emulator detection has improved substantially, so criminals are already moving up the realism curve. Group-IB’s 2026 work on cloud phones describes remotely accessible Android environments that behave much more like real devices than traditional emulators and argues that static device fingerprinting struggles against them. This is an important strategic warning for financial institutions: blocking known emulator signatures narrows the attack surface, but it does not close it. The likely trajectory is from obvious emulators, to hardened “anti-detect” virtual environments, to cloud phones and remotely controlled real-device farms.

What a resilient control stack looks like

The control baseline is already visible in regulation and standards. The EBA requires firms to assess fraud risks, including impersonation fraud, when deploying remote onboarding solutions, and concluded that liveness detection should be mandatory in unattended onboarding situations. The same guidelines require a secure environment for execution of customer-side software code on multi-purpose devices and additional security measures for the software and collected data. NIST, for its part, requires technical controls to increase confidence that media in the proofing process is being produced by a genuine sensor and explicitly mentions detecting virtual cameras, device emulators, and jailbroken devices.

In practical terms, that means institutions need more than one line of defence. Device and app attestation should sit near the front of the stack. Google’s Play Integrity API is designed to help determine whether requests come from a genuine app on a genuine and certified Android device, and it explicitly says it can help detect tampered apps, untrustworthy devices, and emulated environments. It also exposes signals such as recent device activity and device recall that can help spot anomalously high request volumes and repeat abuse. Just as importantly, Google cautions that the API works best alongside other signals and should not be the sole anti-abuse mechanism. OWASP’s mobile security framework aligns with that view by treating missing emulator detection, missing device-attestation controls, and missing anti-virtualisation controls as resilience weaknesses.

A second layer is media-provenance and anti-injection control. NIST’s identity-proofing guidance makes clear that forged or injected media can attack the device, the biometric processing component, or the server-side comparison element; a simple biometric comparison against a captured sample does not stop that on its own. For financial institutions, the right response is to combine challenge-response randomness, virtual-camera and emulator checks, document-capture integrity checks, and—where risk justifies it—human review with operator authority to stop the session. ENISA’s remote identity-proofing work reinforces the same point by recommending hybrid approaches and noting that fully automatic systems are not enough for critical use cases.

A third layer is portfolio-level graph and infrastructure analysis. The Federal Reserve’s synthetic-identity work stresses that institutions need to analyse and connect multiple data points on individual account holders and across all accounts in a portfolio, rather than rely on isolated point-in-time checks. Its examples of common synthetic-identity characteristics include multiple applicants linked to the same address or phone number and multiple accounts from the same IP address. That guidance translates naturally into emulator-risk analytics: the institution should ask not only whether this device is suspicious, but whether this device, network, identity set, route pattern, and behavioural cluster are suspicious when viewed together across account-opening, account-warming, and payment events.

Finally, firms need operational response discipline. NIST recommends independent testing of identity-evidence validation technologies and public availability of results. ENISA recommends risk-based controls, operator safeguards, and even bounty-style programmes that reward successful evasion attempts so weaknesses surface before criminals exploit them. For FinCrime teams, that means emulator defence should not live as a static ruleset buried in a vendor console. It should be part of an ongoing control-validation programme that includes red-team exercises, fraud-ops feedback loops, QA, and model recalibration.

How institutions use emulation on the defensive

It would be a mistake to frame emulators only as criminal infrastructure. Financial institutions and their suppliers use them legitimately for quality assurance, resilience testing, and security validation. Android’s official emulator exists so applications can be tested across device types and API levels without every physical handset; Firebase provides a debug provider precisely because emulator use is normal in development and CI; AWS Device Farm offers large-scale testing across real devices and configurable environments, while specifically noting that real devices can expose factors that emulators cannot fully reproduce. For mature financial institutions, the sensible pattern is to use emulators for breadth and speed, then validate high-risk flows on real devices for fidelity.

The same dual-use principle applies to criminal-behaviour simulation. The FCA’s 2024 report on synthetic data in financial services explicitly identifies synthetic transaction sequences for fraud-detection machine-learning models as a valid use case, noting that generating synthetic data that replicates fraudulent transaction patterns can improve detection rates and reduce false positives when real fraud examples are scarce. Academic work has extended that logic further: AML-CFSim uses agent-based modelling informed by real crime cases to simulate cyber-fraud laundering scenarios and assess supervisory strategies, while more recent “multiverse” and multi-agent frameworks generate synthetic AML datasets in adversarial environments so detectors can learn against changing laundering behaviours. Earlier work such as PaySim and RetSim was motivated by the same core problem: real data are sensitive and incomplete, so simulators are needed to develop, test, experiment with, and compare fraud-detection methods.

There is also a defensive reason to simulate the attacker, not just the crime. Research presented at RAID 2020 found that adversarial evasion attacks against banking fraud-detection systems achieved evasion rates ranging from 60% to 100% depending on model type and attacker knowledge. That finding matters because too many fraud programmes still test only whether a model detects yesterday’s fraud pattern, not whether it withstands adaptive behaviour. Emulator-enabled fraud is, by nature, adaptive and test-driven. Institutions that use emulators and simulations defensively should therefore focus not only on generating synthetic fraud labels, but on stress-testing the whole stack against evasive, iterative, human-guided attack behaviour.

What this means for financial crime leaders

The right way to think about emulators is as a high-value risk signal, not a self-contained verdict. They are highly associated with abuse in mobile banking, remote onboarding, synthetic identities, and biometric bypass, but they also have legitimate uses in engineering, QA, and authorised testing. That is why both Google and the standards landscape push in the same direction: combine environment trust with behavioural analytics, media integrity, attestation, portfolio linkage, and contextual decisioning rather than relying on any single signal.

For FinCrime leaders, the strategic implication is clear. Emulator abuse is part of the industrialisation of fraud. It lowers the cost of experimentation, enables repeatable onboarding and login attacks, supports location and device spoofing, and pairs naturally with deepfake and injection tooling. A serious response therefore needs to be cross-functional: fraud, AML, cyber, mobile engineering, and identity teams should share telemetry, standards, testing obligations, and escalation rules. Institutions that do this well will not just block obvious emulator traffic; they will understand how emulation fits into criminal operating models, how those models migrate into cloud-phone and real-device infrastructure, and how to use legitimate simulation themselves to keep pace.

What Financial Institutions Should Consider

• Strengthen Device Intelligence
• Protect Remote Onboarding Against Injection Attacks
• Move Beyond Basic Liveness Detection
• Connect Device, Identity and Transaction Risk
• Detect Infrastructure-Level Fraud Patterns
• Apply Contextual Risk-Based Decisioning
• Prepare for Cloud Phones and Real-Device Farms
• Extend Monitoring Beyond Onboarding
• Improve Fraud, AML and Cyber Intelligence Sharing
• Conduct Regular Adversarial Testing
• Use Emulation for Defensive Simulation
• Measure Control Resilience
• Treat Emulator Fraud as an Evolving Threat Model

Download the briefing

Emulators in FinCrime: The Industrialisation of Fraud via Virtual Devices