Enterprise face recognition
Ayonix connects identity intelligence to the cameras, access systems, eGates, video management platforms and applications you already run — across edge, on-premise and controlled server environments.
Verified facts,
not claims
Founded in Tokyo, 2007
By Dr Sadi Vural, who remains CEO
NIST-evaluated algorithms
1:1 and 1:N matching
Plus watchlist, tracking and liveness
Runs where the data must stay
Edge, on-premise or fully air-gapped
What Ayonix does
Ayonix builds enterprise face recognition for access control, airport eGates, border checkpoints and watchlist monitoring. Founded in Tokyo in 2007, it connects identity events to cameras, doors, gates and video management systems, running on-premise, at the edge, or fully air-gapped rather than only in a cloud region.
Face recognition is rarely bought as an algorithm. It is bought because a queue is too long, a card keeps getting lent to the wrong person, an officer is comparing a passport photograph by eye at three in the morning, or a control room has more cameras than it has people to watch them. Those are operational problems, and an algorithm alone does not solve any of them.
What closes that gap is everything around the comparison: whether the camera sees enough of the face at the point people actually pass, whether the threshold is set for the cost of a miss rather than the cost of a false alarm, whether the result reaches the door controller or the operator's screen, and whether a person can overrule it. This site is organised around those decisions rather than around a feature list.
Five failures account for most of the face recognition projects that never reach production. None of them is an algorithm problem.
The cameras are already installed, but they do not produce anything actionable.
Recognition quality is decided by pixels across the face at the point people pass, not at the centre of the frame. A representative video assessment establishes which existing views are usable before anyone buys hardware.
Identity checks are manual, so throughput is bounded by staffing.
Automating the routine comparison and routing only exceptions to a person changes what a fixed headcount can process — and makes the exception rate the number worth measuring.
Cloud-only processing conflicts with privacy obligations or latency budgets.
On-premise, edge and air-gapped deployments keep face images and templates inside the customer’s network and remove the internet round trip from every decision.
Operators receive alerts without enough context to act on them.
An alert that carries the camera, the time, the candidate, the score, the threshold in force and the recorded video is reviewable. One that carries a name and a percentage is not.
Integration is treated as a phase after the algorithm is chosen.
The event has to reach the door controller, the VMS and the audit log. This site publishes the integration mechanism for each platform up front, because that is what decides whether a project is deliverable.
Solutions
The same recognition core behaves differently at a door, a gate, a checkpoint and a camera estate — because who is enrolled, what a mistake costs and who reviews it all change.
Let enrolled staff, residents and contractors through a door without a card, and keep an auditable record of every decision including the refusals.
Access control in detail 1:1 verificationCompare the portrait your document reader has already read against the face at the gate, and hand the officer the exceptions rather than the queue.
Airport eGates in detail 1:1 verificationVerify travellers at the checkpoint and search authorised identity records, across sites that may have no connectivity between them.
Border control in detail Watchlist (1:N against a managed list)Turn a camera estate nobody can watch into a small number of reviewable alerts, each carrying the evidence an operator needs to decide.
Watchlist monitoring in detail ArchitectureRun recognition on servers you own, in a room you control, with a data lifecycle you can show an auditor.
On-premise in detail ArchitectureProcess video beside the camera and send only the event, so the door still opens when the link to head office does not.
Edge in detailFrom camera to action
Every stage below can be the one that breaks a deployment. Each is listed with the failure it is prone to, because that is the part a design review has to cover.
A face arrives from an IP camera, a gate terminal or an application. Frame rate, compression and exposure are all decided here.
Fails when: The camera sees the top of a head, or the subject is backlit by a glass entrance.
Detection, quality scoring and tracking decide whether an image is worth comparing, and keep one person from generating twenty events.
Fails when: Quality gating is switched off to "catch more", and the alert queue becomes unreadable.
1:1 against one record, or 1:N against a gallery or watchlist, at a threshold chosen for what each error costs at this site.
Fails when: The threshold is left at a default nobody chose and nobody recorded.
The result reaches the door controller, the VMS, the operator and the audit log — with the evidence attached to it.
Fails when: The match is correct but arrives somewhere nobody is looking.
Deployment
Not by the preferred one. Where biometric data may not leave the premises, three of these five options are already eliminated before accuracy is discussed.
| Architecture | Recognition runs | Best when | If the link drops |
|---|---|---|---|
| Cloud service | Provider’s data centre | Volume is low or bursty, latency tolerance is generous, and there is no restriction on where biometric data may be processed. | Recognition stops until connectivity returns. |
| On-premise server | Customer’s server room or data centre | Biometric data cannot leave the site, the camera estate is concentrated, and there is an operations team to run it. | Unaffected — the cameras, the server and the doors are all on the same network. |
| Edge appliance | On the appliance, at the site | Sites are many and small, bandwidth is expensive or unreliable, and decisions must be local. | Recognition and local actions continue; events queue and forward when the link returns. |
| Edge plus central server | At the edge, with central enrolment and reporting | A multi-site estate needs both local autonomy and one governed identity record. | Sites keep recognising against their last synchronised gallery; changes reconcile on reconnection. |
| Air-gapped | Inside the isolated enclave | The environment is classified, sovereign, or contractually prohibited from external connectivity. | There is no link. This is the design, not a failure mode. |
Each architecture is covered in full, including its constraints and when it is the wrong choice, on the deployments page.
Integrations
What matters is how cleanly it joins the ones already there. Each integration below is described through the vendor’s own documented mechanism, with an honest status.
Put face matches in front of the operator inside Smart Client, attached to the camera and the recorded video, instead of in a second application.
Integration detailRaise a Security Center custom event on a match so existing event-to-action rules decide what happens next.
Integration detailSend recognition results into Nx as analytics metadata so matches are searchable on the timeline, not only alertable in the moment.
Integration detailDescribing an integration mechanism is not a claim of certification, marketplace listing or partner status with Milestone, Genetec or Network Optix. No such status is asserted anywhere on this site.
Evidence
Ayonix algorithms have been submitted to NIST face recognition evaluations. NIST publishes comparative results openly and endorses nobody — so the records are linked here rather than summarised.
A NIST result is strong evidence that a vendor submitted to outside scrutiny on data it did not choose. It is a weak predictor of how a system behaves at one particular door, in one particular building, with one particular population walking through it. Both statements are true at once, and vendors tend to quote only the first.
Ayonix algorithms have been submitted to NIST face recognition evaluations
What this does not establish
NIST publishes comparative evaluations and does not endorse, certify, approve or accredit vendors. Participation means an algorithm was measured on data the submitter did not choose. It is not a statement about performance at any particular site.
Deliberately absent from this site
No accuracy percentage, for Ayonix or any other vendor. No customer count, country count or deployment count. No NIST ranking. Each was reviewed, found unverifiable or unreproducible, and recorded as rejected with the reason.
Case studies
Both are described only as far as the permission extends. Where a number has not been released, no number appears — which is why neither of these carries a percentage.
Border control · United Nations
Ayonix face recognition was deployed across more than 20 cameras at border gates to support identity verification and passport-control operations, matching against authorised databases and watchlists.
Read the case study
Office access · ITOCHU Techno-Solutions
CTC adopted Ayonix FaceID across its offices in 2016, using iPads as facial-authentication terminals to give employees contactless entry without the cost of lost and replacement cards.
Read the case studyDevelopers
Embed recognition in your own process with the SDK, or call a service deployed inside your own environment through the HTTP API. Which one fits is usually decided by where the video already is.
In-process integration. Lowest latency, no network hop, and the video never leaves your application.
Service integration inside your environment. Language-agnostic, and one deployment serves many callers.
Neither page publishes invented function names or endpoint paths. Platform builds, language bindings and the interface reference are confirmed in writing when an evaluation begins.
Responsible deployment
And a decision path a person has to be able to overrule. Both are design work, not policy language — which is why they appear here rather than only in a terms document.
Name the population, the location, the trigger and the action. A purpose broad enough to justify anything cannot refuse the next reasonable-sounding request to reuse the system.
Discard captured images once the match resolves, keep templates only while access is entitled, and enforce the period in code rather than in policy.
Log the operator’s decision separately from the system’s and compare them. If the human essentially never disagrees, the review step is adding a signature, not oversight.
Children, wheelchair users, people in lawful head coverings and people who decline all need a path through. That path sizes the staffing, which sizes the business case.
Buyer resources
Both of these are written so that a buyer can hold any vendor to them, Ayonix included. That is the point: a checklist that only one supplier can pass is a sales document.
Pixels across the eyes, mounting height and angle, standoff, lighting and movement — the geometry that decides whether a deployment works, and what good placement still cannot fix.
What to agree before the vendor arrives, how many subjects a measurement actually needs, what to record, and how the result should be reported.
Which category of system fits the requirement — cloud API, device terminal, verification service, on-premise platform or edge appliance — before any vendor name comes up.
Enterprise face recognition compares a face captured by a camera or terminal against enrolled records, either to confirm one claimed identity (1:1 verification) or to find a match in a gallery (1:N identification). In an enterprise deployment the comparison is only part of the system: capture quality, threshold policy, integration with doors and video, operator review and audit all determine whether it works in practice.
1:1 verification answers "is this the person this document or record says it is?" and its error rates do not change with the size of the enrolled population. 1:N identification answers "which of the enrolled people is this, if any?" and its error rates rise with gallery size. A strong 1:1 result therefore predicts very little about 1:N behaviour, which is why the two are evaluated separately.
Yes. Ayonix supports on-premise, edge and fully air-gapped deployment in addition to conventional server installation. On-premise and edge deployments keep face images and biometric templates inside the customer’s own network, and an edge appliance continues to recognise and act locally while its wide-area link is down.
No, and no company is. NIST runs face recognition evaluations and publishes comparative reports on how submitted algorithms performed, but it does not certify, approve, accredit or endorse vendors — no such certification exists. What Ayonix can accurately say is that its algorithms have been submitted to NIST face recognition evaluations in both the 1:1 verification and 1:N identification tracks.
There is no single answer, which is why this site publishes no percentage. The same algorithm can truthfully be described as 99.9 per cent or 95 per cent accurate depending on the matching threshold, the dataset, the gallery size and whether the figure describes verification or identification. Accuracy for a specific site is established by a pilot on that site’s own cameras and population, measuring both error types.
Often, but it depends on measurable things rather than on the brand of camera. What matters is the number of pixels across the face at the point people actually pass, the angle between the camera and the face, the lighting direction, the compression the stream applies and how fast subjects are moving. A representative video assessment answers this before anyone commits to hardware.
Through each VMS vendor’s documented integration mechanism. For Milestone XProtect that is the MIP SDK analytics event protocol; for Genetec Security Center it is custom events consumed by event-to-action; for Network Optix it is the Metadata SDK, which carries object and event metadata packets the server stores against the timeline. Each has its own page on this site with the mechanism described in detail.
A controlled pilot runs on the customer’s own cameras with the population that will actually use the system, against acceptance criteria agreed before it starts. It records every comparison rather than only the alerts, counts both missed matches and wrong matches, notes where the threshold was left and why, and reports the failures as well as the successes.
Next step
A pilot measures the system on your cameras, with your population, against criteria agreed before it starts — and reports the failures alongside the matches. Tell us the environment and the decision the system has to make, and the reply comes from someone who can discuss capture geometry rather than only pricing.