How should testing programs verify candidate identity without making check in a nightmare?

What check in has to prove

Three things: the document is genuine, the person presenting it is the person it names, and that identity matches the registration that paid for and scheduled this exam. Each link can fail separately, and a strong check verifies all three rather than admiring a document photo in isolation.

Programs also need continuity. The identity verified at check in should be reasserted during the session through periodic face matching or proctor confirmation, because a verified start followed by a swap is the oldest trick in remote testing.

Where honest candidates get stuck

Name format mismatches cause a large share of failures: middle names, hyphens, transliteration, and recent name changes colliding with rigid exact match rules. Document quality is next: glare, old photos, worn cards, and low end webcams in poor light defeat automated comparison that a human reviewer would pass in seconds.

Every automated rejection needs a fast human path with authority to approve. A candidate in a timed check in window, watching a support queue estimate climb, experiences the program as broken regardless of how sound the security logic was.

Designing the flow candidates can actually complete

Tell candidates exactly what to bring, how their registered name must appear, and how to test their camera and lighting days before, not minutes. A pre exam identity dry run, where the system checks the document and photo match early, moves failures to a moment when they can still be fixed calmly.

Offer document options where regulations allow, and write the name matching rules to accept the variations real names come in, with manual review for the remainder. Security lives in the verification strength, not in formatting pedantry.

Privacy and data duties are part of the design

Identity checks collect sensitive material: document images and face data. Programs must state what is captured, how long it is kept, who can see it, and how a candidate can challenge an error. Retention should follow the dispute window, not a default of forever.

Vendor claims need the same scrutiny as candidate documents. Ask how match accuracy varies across demographic groups, where data is stored, and what happens to it at contract end. A biased or leaky identity system is a liability the program owns, whoever built it.

Measure check in like a product, not a gate

Track completion rate, time to verify, manual review rate, and failure reasons by candidate group. A check in that quietly fails one population more than others is a fairness problem with data attached, and it will not fix itself.

The target is a door that is hard for a proxy and boring for everyone else: verified document, matched person, matched registration, done in minutes, with humans ready for the exceptions. Programs that reach that standard rarely talk about check in at all, which is the point.

Keep reading: How are candidates using AI tools to cheat on remote exams, and what actually detects it?, How should testing programs secure an exam item bank before launch day?, and How do testing programs detect proxy test takers hired to sit an exam? cover the nearby cases in this series.

Frequently asked questions