Your fraud stack blocks emulators. That's why you can't test it.
Identity-verification and anti-fraud SDKs reject virtual devices on purpose — which is exactly why your own onboarding flow is the hardest part of your product to put under automated test. Privara gives you a device that gets far enough into the flow to actually test it, plus a stock emulator to prove your detection still fires.
The testing gap nobody budgets for
Ask a fintech QA lead how their KYC onboarding is regression-tested and the answer is usually some version of: manually, on a phone in a drawer, before a release. Not because the team lacks discipline, but because the automation stops at the first screen. The device-integrity check in your own SDK sees an emulator, returns a rejection, and the suite never reaches document capture, liveness, or the risk-decision branch you wanted to verify.
So the most compliance-sensitive, highest-abandonment funnel in the product — the one where every extra second costs signups — ends up with the thinnest automated coverage in the codebase.
What a de-emulated test device gives you
Privara is a de-emulated Android 17 image: de-emulated at the property, file, sensor, CPU, GPU and kernel layers, running real ARM apps on ordinary x86 hardware. In a testing context, that means your suite reaches the screens that matter.
Test the approved path in CI
Drive your real onboarding build with Appium or Espresso all the way through capture, liveness and decisioning — on every commit, not once a quarter.
Test the blocked path on purpose
Run the identical suite on a stock emulator to confirm detection still fires, the rejection copy is right, and the event reaches your fraud analytics.
Exercise your fingerprinting SDK
Every instance carries its own serial, Android ID, advertising ID, IMEI and MAC — so you can verify device-ID stability, reset behaviour, and duplicate-device rules against distinct devices instead of one machine pretending.
Regression-test rule changes
A fraud-rule tweak that quietly starts rejecting good users is expensive and slow to notice. A fixed device fleet gives you a stable baseline to diff against.
Region and network conditions
Each device gets its own egress and configurable location, so market-specific onboarding variants and document types can be verified before launch.
Reset to a known-good state
First-run onboarding is only first-run once. Roll instances back to the golden image so every test starts from a genuinely fresh install.
Also useful to the red team
Fraud teams are expected to know how their own controls fail. Having a controlled, licensed, in-house device that behaves like a real handset lets your red team measure how far a determined actor gets against your stack — under your authorisation, with the results feeding your rule tuning — instead of that knowledge only existing on the other side.
Where the honest limit sits
No virtual device passes hardware-backed attestation. The strong and device verdicts in Play Integrity are rooted in a physical secure element that no VM has, and we don't claim otherwise. What Privara defeats is the software-based emulator and root detection layer — which is what the large majority of mobile SDKs actually check, and therefore what actually blocks your test suite. If one specific control in your stack hard-requires hardware attestation, that control still needs a physical device, and the rest of the funnel can still be automated.
How teams roll it out
- Pilot: one or two hosted devices, wired to your existing Appium suite, to confirm your onboarding flow completes end to end.
- Baseline: add a stock-emulator lane so both the approved and the rejected paths are asserted on every build.
- Scale: move to a per-device licence across your CI fleet — hosted by us, or self-hosted inside your own perimeter where regulated data requires it.
Put your onboarding funnel under test
A short technical session with your QA or fraud lead: bring your app build, and we'll run it on a live device and show you exactly where it gets to.
Request a demo →