Airport eGates
Airport eGate face verification
Compare the portrait your document reader has already read against the face at the gate — and hand the officer the exceptions rather than the queue.
- 1:1 verification, not identification
- Liveness available in supported capture workflows
- Exception routing to an officer position
- Throughput measured, not asserted
In short
Airport eGate face verification compares the portrait read from a traveller's document by the authorised reader against the face captured at the gate. It is a 1:1 verification problem, not identification, and its job is to send the officer the exceptions rather than the queue.
An eGate is a queue-management machine that happens to contain a biometric comparison. The comparison is the part vendors talk about and the smallest part of the transaction; the parts that determine whether a hall flows are capture geometry, retry behaviour and how fast an exception reaches a person who can resolve it.
This page is written for that reality. It states what Ayonix supplies and what it does not, describes the workflow including the steps that belong to other systems, and sets out how throughput should be measured so that a pilot produces a number an operations team can plan against.
What slows a gate down
Throughput at an eGate is rarely limited by the comparison. It is limited by the exceptions, the capture geometry and how quickly a person can be helped when the gate says no.
Queues build at peak and the hall was not designed for the current passenger volume.
Automating the routine comparison moves the constraint from officer availability to gate count and exception rate — both of which can be measured and planned for, unlike staffing at 05:00.
Officers compare a passport photograph to a face by eye, hundreds of times a shift.
The routine comparison becomes consistent and tireless. The officer’s attention moves to the cases the system flags, which is where human judgement is actually worth something.
Identity substitution — the document is genuine but the bearer is not.
The comparison is between the chip portrait and the live face, so a genuine document presented by someone else fails the check that a document-authenticity test alone would pass.
Passengers vary in height by more than a metre, and children arrive in arms.
Capture has to work across the real height distribution, which is a camera and gate-geometry decision. Where it cannot, the assisted lane is the answer rather than a tuned threshold.
Glasses, head coverings, masks, poor lighting and motion all degrade capture.
Quality assessment rejects an unusable capture and asks again rather than comparing it and producing a result nobody should trust. A retry is faster than an exception.
Exception handling is slow, so one difficult passenger stalls a whole lane.
Exceptions route to a staffed position beside the gates rather than back into the main queue. The walk-forward distance to that position is a throughput parameter.
Integration with existing border systems is unclear and owned by nobody.
Ayonix supplies the face verification component and integrates with the systems that own the document read and the border decision. What each party owns is written down before work starts.
Privacy and data-residency requirements constrain where processing may happen.
On-premise and air-gapped deployment keeps the live capture, the portrait and the comparison inside the operator’s own infrastructure, which is usually what the requirement actually demands.
How it works
What happens between the document and the gate opening
Eight steps. Ayonix supplies steps three to seven; the document read and the border decision belong to the systems already authorised to perform them.
-
Present document
The traveller places the document on the reader. This step, and the reader itself, belong to the border or gate system, not to Ayonix.
Fails when: The document is placed incorrectly and the read fails before face verification is reached at all.
-
Read trusted portrait
The authorised system reads the portrait from the document and passes it to the verification component. The chain of custody for that image is the operator’s to define.
Fails when: A damaged or unreadable chip means there is no trusted portrait to compare against.
-
Capture live face
The gate camera captures the traveller’s face, accounting for the height range and the movement of a person who is still walking.
Fails when: Camera height is fixed for an average adult, and everyone outside that range becomes an exception.
-
Assess quality
The capture is scored before comparison. Below the floor, the gate asks again rather than comparing an image that cannot support a decision.
Fails when: The quality floor is lowered to reduce retries, and the exception rate rises instead.
-
Verify 1:1
The live face is compared against the document portrait at a threshold set for this deployment and recorded.
Fails when: The threshold is tuned to hit a throughput target rather than an error target.
-
Apply liveness
Where configured, presentation-attack detection resists a photograph, a screen or a mask presented to the gate camera.
Fails when: Liveness is specified as a feature rather than against the attack instruments it was tested on.
-
Return decision and evidence
The result, the score, the threshold in force and the captured image go to the gate system and the audit record.
Fails when: The decision is returned without the evidence, so a later dispute cannot be resolved.
-
Route exceptions
Anything that is not a clean pass goes to an officer position with the evidence attached, not back to the start of the queue.
Fails when: The exception path is the main queue, and one difficult case blocks the lane.
Scope boundary
Steps one and two — presenting the document and reading the trusted portrait — are performed by the border or gate system and its authorised reader. Ayonix does not supply document readers, and no claim is made here about chip authentication, document validation or the border decision itself. Ayonix supplies the face verification component and integrates with the systems that own the rest.
Architecture
Where the face verification component sits
The gate owns the passenger interaction. The border system owns the decision. Verification sits between them and returns a result with its evidence.
Passenger-facing
Supplied by the gate manufacturer-
Document reader
Reads the trusted portrait
-
Gate camera
Captures the live face
-
Gate mechanism and signage
Opens, holds or refers
Verification
Ayonix component, on operator infrastructure-
Quality assessment
Accept, or ask again
-
1:1 comparison
Live face against document portrait
-
Liveness / PAD
Where configured for this gate
Border systems
Operator-owned, authorised-
Border decision system
Owns the entry decision
-
Officer position
Receives exceptions with evidence
-
Audit record
Transaction, score, threshold, outcome
A reference arrangement. The exact division depends on the gate manufacturer and the border system already in place; the boundary is agreed in the integration design rather than assumed.
Accessibility
Assisted travellers are a design input, not an edge case
A gate programme that works for the modal passenger and fails everyone else has not reduced the officer workload; it has relocated it.
Capture geometry designed for an average adult standing still excludes wheelchair users, children, very tall and very short travellers, and anyone being assisted. Each of those groups is predictable in advance and each can be designed for — a second camera at a lower height, a wider capture volume, or an explicitly assisted lane with the same processing behind it.
Lawful head coverings, religious dress and medical face coverings need a defined procedure that does not require a public negotiation at the gate. So does a traveller who simply declines. The measure of whether this has been designed properly is whether using the alternative is quick and unremarkable, or whether it marks someone out.
These decisions size the staffing at the exception position, and the staffing sizes the business case. Treating them as a late detail is how gate programmes end up with a throughput figure that does not survive the first busy morning.
Measurement
What a throughput number has to include to mean anything
Two vendors can quote the same figure and describe entirely different gates. These are the components that must be stated alongside it.
| Component | What it measures | What is hidden if it is omitted |
|---|---|---|
| Comparison time | How long the 1:1 match takes | Almost the whole transaction. This is the smallest component and the one most often quoted alone. |
| Capture and retry rate | How often the gate has to ask again | A high retry rate can double the effective transaction time while every individual comparison stays fast. |
| Exception rate | Proportion referred to an officer | The officer staffing the gate programme was supposed to reduce. |
| Exception resolution time | How long a referral takes to clear | Whether the exception position becomes the new bottleneck. |
| Gate mechanism time | Physical open, pass and close cycle | A hard floor on throughput that no software change affects. |
| End-to-end passengers per gate per hour | The number an operations team can plan against | Nothing — this is the figure that should be quoted, and the only one that is. |
A pilot should report the end-to-end figure and each component separately, so that a shortfall can be attributed rather than argued about.
1:1 verification, 1:N identification, watchlist matching, face tracking, and liveness and presentation-attack detection
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Presentation-attack resistance is specific to the attack instruments tested for. Liveness is available in supported capture workflows, not universally.
On-premise, edge and fully air-gapped deployment
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
eGate readiness checklist
The questions that decide whether a gate programme is deliverable. Most of them are about the hall and the exception path rather than about the algorithm.
-
Confirm who owns the document read
Ayonix supplies face verification. The document reader, the chip authentication and the border decision belong to systems already authorised to perform them, and the boundary should be written down before procurement.
-
Measure the passenger height distribution you actually have
Design capture for the range, not the mean. The tails of that distribution are where the exception rate comes from, and they are predictable in advance.
-
Establish lighting at the gate, including at night
Terminal lighting changes with the time of day and the season. Capture must survive the worst case, not the commissioning visit.
-
Define the exception position and its walk-forward distance
Where an exception is handled, by whom, and how far the traveller walks to get there. This is a throughput parameter and belongs in the hall design.
-
Specify liveness against named attack instruments
Which instruments, at what level, tested by whom, on what date. ISO/IEC 30107-3 defines how such testing is reported; it defines no pass mark and issues no certificate.
-
Agree the throughput measurement before the pilot
Passengers per gate per hour, measured end to end including exceptions — not the comparison time. A comparison-time figure describes a component, not a gate.
-
Plan accessibility and assisted travellers explicitly
Wheelchair users, children, travellers needing assistance and lawful head coverings all need a defined route. Designing it late means designing it badly.
-
Settle data residency and retention in writing
Where the live capture and the portrait are processed, how long each is retained, and what deletes them. On-premise and air-gapped options exist precisely for this requirement.
-
Define the audit record
What is retained for each transaction, who may access it, for how long, and how access is logged. A border deployment will be audited; the question is whether the record supports it.
-
Agree the pilot acceptance criteria
Both error types, the exception rate, the retry rate and the end-to-end throughput, over a defined window with a defined population, reported whatever the result.
Frequently asked questions
Does Ayonix supply the passport reader?
No. Ayonix supplies the face verification component. The document reader, the chip authentication and the border decision belong to the systems already authorised to perform them in that environment. This boundary matters commercially and operationally, and stating it clearly is more useful to a buyer than implying a turnkey scope that would have to be corrected later.
Is an eGate doing 1:1 verification or 1:N identification?
Verification. The document supplies a claimed identity and a trusted portrait, so the system answers "is this the same person?" against exactly one record. That is a materially easier problem than searching a gallery, and its error rates do not change with the size of any database. Any eGate description that talks about searching millions of records has confused the two.
How is eGate throughput actually measured?
End to end, in passengers per gate per hour, including every retry and every exception. The comparison itself is a small fraction of the transaction; document placement, capture retries, the gate mechanism and the walk-through dominate. A vendor quoting a matching time in milliseconds has answered a different question from the one an airport is asking.
What happens when verification fails?
The traveller is routed to a staffed officer position with the captured evidence attached — the live image, the score, the threshold in force and the reason for the referral. It is not a refusal of entry; it is a referral to a person, and the system should be designed so that a referral is quick and unremarkable rather than an ordeal.
Can children use an eGate?
That is a policy decision for the border authority rather than a technical one, and jurisdictions differ. Technically, capture geometry designed only for adult height will not serve a child, so where children are in scope the gate must be designed for the full height range from the start. Where they are out of scope, the assisted lane must be sized for them.
Where does the biometric data go?
Wherever the operator’s architecture puts it. On-premise deployment keeps the live capture, the document portrait and the comparison inside the operator’s own infrastructure, and air-gapped deployment removes external connectivity entirely. For most border programmes this is not a preference but a requirement, which is why it is available.
What does a controlled eGate pilot involve?
A defined number of gates, a defined population, a defined measurement window, and acceptance criteria agreed in writing before it starts. It records every transaction rather than only the failures, counts both error types, tracks the retry and exception rates separately, and reports the throughput achieved rather than the throughput hoped for.
Is liveness required at a gate?
It depends on the threat model the operator is defending against, and it should be specified rather than assumed. Where a gate is unattended, presentation-attack detection materially raises the cost of substituting a photograph or a screen. Where it is in direct view of an officer position, the marginal value is lower. Either way, a liveness claim means nothing unless the attack instruments it was tested against are named.
Related
Where to go next
Border control face recognition
Checkpoint verification and authorised search across multi-site, low-connectivity environments.
Liveness and presentation-attack detection
What a liveness claim has to state before it means anything.
On-premise deployment
Keeping the capture, the portrait and the comparison inside your own infrastructure.
Accuracy and testing
Why no percentage appears here, and how to establish one for your gates.
United Nations border project
Face recognition across more than 20 border-gate cameras.
Pilot checklist
The acceptance criteria to agree before any vendor arrives.
Next step
Design an eGate pilot
Tell us the hall, the gate count, the passenger profile and which system owns the document read. The first conversation is about capture geometry, the exception path and how throughput will be measured — because those three decide whether the programme works.