QA Testing Blog | Global App Testing

Identity Verification Testing: Why KYC Scans Fail

Written by Veronica Yow | August 2026

Introduction

On a recent project, one of our crowd members held their passport exactly where the app told them to. They expected a quick scan and an immediate confirmation that their identity had been verified. Instead the scan failed. On other attempts the app timed out, or told them they had moved "too fast," even though they were following the instructions they had been given.

The verification feature technically existed. For that user, there was no way forward. No completed check, and therefore no way to continue onboarding.

This is episode three of Field Notes, a series where we take a closer look at the small details that decide whether software actually works for the people using it. Today: identity verification.


Field Notes, Episode 3: Identity verification — 4min 6 sec. Full transcript at the bottom of this page.

Why Does Identity Verification Look Simpler on Paper Than It Is?

On paper the process is straightforward. A user scans their ID or passport, completes the NFC check, and moves on with onboarding. Three steps, one screen, a few seconds.

What that description leaves out is everything the user brings to it. A specific phone, with a specific NFC antenna in a specific position. A document with its own chip, wear, and cover. A room with its own lighting. A pair of hands that may be steadier or less steady than the ones the flow was designed around.

The flow is not one interaction. It is the intersection of a device, a document, an environment, and a person, and it only takes one of those to fall outside expectations for the whole thing to stop.

What Does Failure Actually Look Like for the User?

The failures here are not error screens in the usual sense. They are dead ends dressed up as guidance.

A scan that fails without explaining what to change. A timeout after the user has done nothing wrong. And the one that gives this away most clearly: being told you moved too fast while you were doing exactly what the instructions said.

That last message is worth sitting with, because it tells the user the problem is them. They followed the guidance, the guidance did not work, and the app has responded by correcting their behaviour. There is nothing to adjust and nothing to retry differently, so the only remaining options are to try again and hope, or to leave.

Why Do Verification Failures Cost More Inside a KYC Flow?

When failures like this sit inside a KYC flow, they do not just create a frustrating moment. They directly affect how many people are able to complete verification in the first place.

Identity verification is usually mandatory and usually early. A user cannot skip it, cannot come back to it later, and has often not yet received anything of value from the product. There is no accumulated investment to make a second or third attempt feel worthwhile.

So the failure lands at the point of maximum damage: after acquisition cost has been spent, before any relationship exists. And from the inside it registers as onboarding drop-off, which is a metric with a dozen plausible explanations and no obvious pointer to a device-specific NFC problem.

Why Won't Standard Testing Catch This?

Identity verification is unusually resistant to the testing most teams already have in place.

Automated suites can confirm the SDK is called and the response is handled. They cannot confirm that a physical passport, held by a person, over a particular NFC antenna, produces a successful read. The part that fails is the part happening outside the software.

Emulators are no help either, because the failure lives in hardware and physics: antenna placement varies by handset, chip read range varies by document and country, and lighting varies by room. Test documents compound the problem, since a clean sample passport behaves nothing like a five-year-old one in a plastic cover.

Catching this requires the combination the failure itself requires: real documents, held by real people, on the real devices your customers use. That is the work we do. Global App Testing runs flows like this through testers using their own documents on their own handsets across the markets our customers operate in, which is how failures that only exist in the physical world become visible to teams working from a desk. You can see how that works on our people-powered testing platform, and our guide to fintech testing covers the adjacent flows.

The Question to Take Back to Your Team

The question is not just whether your identity checks are secure. It is whether a real person, using a real document, on any of the devices your customers rely on, can actually get through them.

Security and completion are usually discussed as a tradeoff. This is not that. A check nobody can pass is not more secure, it is just unused.

Full Transcript

Veronica, Marketing Manager at Global App Testing:

Hi, my name is Veronica, and this is Field Notes, where we take a closer look at the details that shape whether software actually works for the people using it.

In this episode, I wanted to share something we've seen in a recent project around identity verification flows.

On paper, the process is straightforward. A user scans their ID or passport, completes the NFC check, and moves on with onboarding.

But on this project, one of our crowd members held their passport exactly where the app tells them to. They expected a quick scan and an immediate confirmation that their identity has been verified.

Instead, the scan fails. And in other cases, the app timed out or the app told them they've moved "too fast," even though they're just following the instructions they were given.

At that point, the verification feature technically exists, but for that user, there's no way forward. They can't complete the check, hence they can't continue the onboarding process.

And when failures like that sit inside a KYC flow, they don't just create a frustrating moment. They directly affect how many people are able to complete verification in the first place.

So the question isn't just whether your identity checks are secure. It's whether a real person, using a real document on any of the devices your customers rely on, can actually get through them.

Conclusion

A verification flow that fails on certain devices is not broken in any way your dashboard can see. The SDK responded, the API returned, the session closed. The only record is a user who never finished onboarding, filed under drop-off.

Finding it means testing with real documents on real devices in the markets you operate in. Talk to us about putting your verification flow in front of people using the documents and handsets your customers actually have.

Field Notes is a series from Global App Testing on the details that determine whether software works in the real world. Catch up on Episode 1, on payment methods and Episode 2, on GenAI and language.