Face recognition for airports and border control

What does an eGate actually compare?

An eGate performs verification, not identification. The traveller presents a passport or a boarding reference, the system retrieves the photograph already associated with that document, and it compares a live capture against that single record. The gallery for the comparison has one entry in it, which is why gate throughput does not degrade as the number of travellers grows.

1. Document read: the chip or the machine-readable zone identifies which record to retrieve.
2. Gallery retrieval: the stored photograph for that record is fetched, from a government holding or an airline manifest.
3. Live capture: the camera acquires a frame of the traveller as they approach or stand at the gate.
4. Comparison: one live template against one stored template, producing a score.
5. Decision: above threshold the barrier opens; below it the traveller is directed to an officer, not refused.

The last step is the one that decides whether a deployment works in practice. A gate that refuses rather than referring turns every false rejection into an incident; a gate that refers turns it into a few seconds and a human check, which is what the queue can absorb.

How large is face recognition at borders today?

CBP additionally reports facial biometrics at 39 seaports and at all pedestrian lanes on both the Southwest and Northern borders. These are operational counts from the agency running the system, which makes them the firmest public figures for the scale of one national deployment. They are cumulative totals rather than rates.

What capture conditions does a gate need?

Everything that decides performance at a gate is a decision about optics and placement, made before any software is selected. The most common cause of a disappointing pilot is a camera positioned for scene coverage rather than for faces, and no threshold adjustment recovers a frame that never contained enough detail.

Why does throughput decide the architecture?

A border hall is a queueing system, and a biometric gate is one server in it. The figure that matters is not the time to compare two templates - which is milliseconds - but the time from a traveller arriving at the gate to the barrier releasing, including the document read, the retrieval and any retry.

• A round trip to a remote service adds latency to every transaction, in a place where seconds per traveller multiply into the length of the hall.
• An outage stops a cloud-dependent gate entirely; an on-premise gate keeps operating on local hardware while connectivity is restored.
• Retry behaviour matters more than first-attempt performance: two fast attempts often beat one slow one for total throughput.
• The referral lane has to be sized for the real referral rate, or it becomes the bottleneck the gates were installed to remove.

This is why border and aviation deployments are overwhelmingly on-premise or edge. It is a throughput and availability decision before it is a data protection one, though the data protection argument points the same way.

What about travellers a gate cannot serve?

Every biometric border deployment has a population it cannot process, and the size of that population decides how much staffed capacity the hall needs. Designing for the median traveller and treating everyone else as an exception is how a gate hall ends up with a queue in front of the one manned desk.

• Children, whose faces change fast enough that an older enrolment photograph may no longer match, and who often fall below the captured height band.
• Wheelchair users and travellers of unusual height, for whom a fixed camera angle produces a partial or downward view.
• Travellers wearing religious head coverings, which are lawful and must not become a refusal.
• People with facial differences, injuries or recent surgery, where the enrolled photograph is genuinely no longer them.
• Travellers who decline biometric processing where the law gives them that choice, and who must have a route through that is not punitive.

None of these is an accuracy failure and none is fixed by a better algorithm. They are capacity and process questions: how many staffed positions, sized against the real referral rate measured during the pilot, and what an officer is instructed to do when the gate declines to open. A deployment that measures only its match rate has not measured the part passengers experience.

The referral rate observed in a pilot is a design input, not a defect report. It should be measured across the full travelling population the site serves, in the season and at the hours when that population is least like the pilot group.

What has to be decided before procurement?

1. State whether the system verifies against a presented document or identifies against a gallery. The two carry different legal obligations and the word 'biometrics' in a specification distinguishes neither.
2. Survey the actual gate positions and measure pixels across a face where travellers will stand.
3. Define the referral path, its staffing and its expected volume, before the gate count.
4. Define the failure mode for a network or power loss, including whether barriers hold closed or release.
5. Agree what is retained: the live capture, the comparison score, the decision, and for how long each.
6. Run a pilot on the site's own cameras and require both error types in the report, not only successful matches.

Independent algorithm evidence comes from NIST, which measures submitted algorithms on sequestered data and publishes the results. NIST does not endorse vendors and issues no certification, so a strong result narrows a shortlist and the pilot decides the deployment.