As facial recognition software for law enforcement, IREX monitors watchlists of pre-registered people in real time and cannot recognize or track anyone else. That constraint is enforced in the platform, not promised in a policy document, which is what makes the capability defensible in public.
The Engine
The IREX face recognition engine is trained on a proprietary dataset of 40 million images specifically optimized for CCTV conditions: adverse angles, partial occlusion, poor light, and the distances real cameras actually work at. It monitors watchlists of suspects across hundreds of thousands of cameras simultaneously, with configurable confidence thresholds, which is the scale police facial recognition software has to hold when the estate is a whole city rather than one building.
It has been independently benchmarked. In its March 2021 submission to the NIST Face Recognition Vendor Test, the algorithm was ranked #1 in accuracy among all US companies, and top 10 globally of 268 submitted algorithms, on the Border and Kiosk datasets of the FRVT 1:N Identification track.
Where a direct suspect photo does not exist, the engine also estimates facial attributes. There are eight of them, listed below, and every one is a filter over the archive. That turns a witness description into a searchable query rather than a dead end.
Attribute Search
Alongside the watchlist match, FaceTrack Pro estimates what a face looks like, and every estimate is a search filter. A witness account of a man in his thirties, with glasses, a beard and a cap, becomes a query over the archive instead of a dead end. These attributes describe a face; they do not identify anyone. They are computed only on cameras where Recognize appearance features is switched on, they come back as unknown when the image is too poor to call, and searching by them still needs a Case ID like any other person search.
Estimated from the face, never read off a record.
Six preset bands, or a from–to range of your own.
Four broad groups, and the attribute where measured bias matters most. It narrows a search; it never decides one.
The detail a witness remembers most reliably, and one of the few that survives a bad angle.
Facial hair as a yes or no, not a style. It changes between sightings, so it narrows rather than confirms.
Searchable both ways, which matters when the question is who covered their face at a particular hour.
Hats and hoods defeat many face engines. Here the fact of one is itself a filter.
A score on every face rather than a verdict: the same signal that stops a photograph opening a door.
In Operation
A confirmed match assembles the face crop, the camera identity and location, the timestamp, the confidence score, and the operator identity, all immutably logged and exportable. The alert reaches the right officer through the Sover secure messenger with a live video link, so nobody has to be sitting in front of a monitor for the system to work.
Liam Mercer 96.4% Watchlist match · CAM 04 · 09:14:08 The same face pipeline estimates a spoofing probability for every face it sees and reports it as a percentage on the event, beside the similarity score, so an operator weighing a match can see whether the camera was looking at a person or at a picture of one. The estimate is stored and searchable like any other attribute. Run against an entry point rather than a watchlist, that check becomes face-based access control, which has enough of its own settings, wiring and constraints to be its own page.
See Access Control & Anti-Spoofing →On Camera
Two matches in a crowded concourse, with everyone else in the frame blurred. The presentation attacks that used to sit beside them moved to access control and anti-spoofing, where they belong.
Amina Rahal 94.8% Watchlist match · CAM 11 · 09:22:31 A hit says that a pre-enrolled person is on this camera at this time. Nothing follows from it until an officer opens the clip and confirms it, and everyone else in the frame stays blurred and unidentified.
Sofia Byrne 97.1% Watchlist match · CAM 18 · 09:31:46 The same engine carries the missing-persons lists IREX runs with child-protection partners. A missing-person report is a lawful basis and is recorded as one, and only pre-registered people are recognized either way.
Watchlist Management
A watchlist is the unit the whole capability turns on. It decides who can be recognized at all, who is allowed to see a match, and how close a face has to be before the platform calls it one. None of this is a roadmap: it is what an operator does in the product today.
People are enrolled onto named lists such as missing persons, fugitives, or a biometric access roster. The list, not the person, carries the settings: its own similarity threshold, the priority its matches are raised at, and the user groups allowed to see it. A list is searched only if Recognition mode is enabled on it and your group has been granted it. Those are two separate switches on purpose, and a zero-result search can mean the cameras never saw the person, or that the list was never yours to search.
By name, or by any other text attribute on the record, including passport and driver’s license fields and date of birth. By an enrolled person, straight from their card. By whole list, to sweep every missing person at once. By appearance, when there is no photo at all. By uploaded photo or feature vector, picking one face out of a group shot if that is all there is. And from any event card, a photo search finds every other camera that saw the same face, which draws a route on the map rather than a single sighting.
The platform will not run a person search, or accept a change to the person database, without a Case ID recording the lawful grounds: a case file, a court order, a missing-person report. The log entry keeps the user name and IP, the subject searched, the referenced document ID, and the timestamp, appended where nobody can edit it. Adding someone to a watchlist is logged exactly as heavily as searching for them, which is the part most systems leave out.
Every record carries a recognition mode: Recognize, optionally inside a time window that lapses on its own, or Archived, which keeps the record but bars recognition against it. The entry form was cut to the data-minimization requirements of CJIS and GDPR rather than to what a database could hold, and enrollment photos are checked against ISO/IEC 19795-1. Deletion is one command, and the logbook can still show who enrolled someone, when, and on what grounds. That record is what answering a right-to-be-forgotten request actually takes.
A list loads from an archive in either of two shapes. A plain archive is nothing but photographs named Lastname Firstname.jpg, which is what a partner agency can usually produce in an afternoon. A full archive adds a faces.json of structured records: names, date and place of birth, passport and driver’s license fields, registered address, associated plates, a per-person similarity threshold, an external system ID. An existing register therefore arrives complete rather than as a folder of faces. Where the source database is live, we would rather build an interface to it through the platform API, so a missing-persons list is never as stale as its last import.
Export is the same shape in reverse: a TAR archive holding the photographs against each card and a faces.json of the records, prepared on request and downloaded. Migration between instances, handover to another agency, and an audit of what a list actually contained on a given day all rest on it. A watchlist you cannot get back out is a watchlist you cannot account for.
A monitor is a list plus the match event, and from then on the watchlist works without anyone watching a wall. The alarm opens with the time and place, the similarity score, the estimated appearance features, and a link to the full record. That is everything the verification needs, and verification is required before anyone acts on it. Where no photograph exists, the same monitor can be built on appearance features instead.
The Constraints
Where It Runs
One detector, asked a different question in each vertical. Facial recognition technology in law enforcement, at a border crossing, on a turnstile line and on a gaming floor is the same engine with a different list behind it: the watchlist is what changes, not the technology, and the constraint that only pre-registered people are recognized holds in every one of them.
Suspect and sex-offender watchlists inside an investigation, matched against the records a department already holds, in production across Southern California, Peru and Kazakhstan.
Read More →A match arrives at the desk verified, with the footage attached and the operator who ran it on the log, instead of on one of sixty screens nobody is watching.
Read More →Watchlist recognition at full passenger throughput, in production at Dublin Airport, where a match has to be raised without stopping the flow through the terminal.
Read More →Trafficking and wanted-person watchlists at the crossing, which is exactly where the FRVT Border and Kiosk benchmark result on this page is put to work.
Read More →Banned-fan watchlists on the turnstile line, run across every Premier League national stadium in Bosnia and Herzegovina alongside crowd management on match day.
Read More →Exclusion and self-exclusion lists on the gaming floor, run on infrastructure the property hosts itself and audited by two regulators.
Read More →No. Alert-based monitoring targets only pre-identified people on a watchlist, and the platform cannot recognize or track random individuals in public spaces. That narrow-constraints rule is one of the six Ethical AI pillars and is enforced architecturally.
The NIST Face Recognition Vendor Test. In the March 2021 FRVT 1:N Identification track, IREX was ranked #1 in accuracy among all US companies and top 10 globally of 268 submitted algorithms, on the Border and Kiosk datasets.
All face recognition algorithms show varying accuracy across demographic groups of gender, age, and skin color, and IREX treats that as a disclosed limitation rather than something to argue with. The engine is trained on a 40-million-image dataset balanced for CCTV conditions, tuning is continuous, IREX participates in NIST FRVT for independent evaluation, and a 2024 company study assessed bias in the suspect-recognition technology specifically.
Yes. Facial-attribute search covers gender, age band, ethnic appearance, facial hair, glasses, face masks, headwear and a spoofing probability, so a description becomes a query. The attributes are estimates and are returned as unknown when the image is too poor to call, and the search still requires a Case ID. Where the face is not visible at all, appearance-based person re-identification takes over.
Yes, from a TAR archive, in either of two shapes: photographs named "Lastname Firstname.jpg", or an archive with a faces.json file of structured records covering names, date and place of birth, passport and driver’s license fields, registered address, associated plates, and a per-person similarity threshold. Lists export the same way, photographs and records together. Where the source is a live database, we prefer to build an interface to it through the platform API so the list stays current rather than being re-imported.
Only the user groups that list has been granted to. Recognition is a second, separate switch: a list is matched against live video only when Recognition mode is enabled on it. So a person can be enrolled and still not recognized, and a match is visible only to users whose role covers both that list and that camera. Every change to either switch is logged against a Case ID.
It is built for public-safety operators: police departments and their real-time crime centers, border and customs authorities, airports and seaports, and the venues and properties that run their own security operations. What it is not is a tool for scanning the public. Law enforcement face recognition here runs against watchlists of pre-registered suspects, missing children and adults, and trafficking victims, and the platform cannot recognize or track anyone who is not enrolled on a list your users have been granted. The vertical decides the watchlist; it does not relax the constraint.
On uploaded footage, within exactly what the product documents. A clip recorded on a phone, or any other external video file, is added on the Gallery Uploads tab, the platform creates a channel for it, Analyze video runs the modules over it, and the results land in the ordinary events list under the same Case ID discipline as live video. FaceTrack Pro itself documents fixed, PTZ, phone-upload and drone sources. IREX does not document a body-worn camera integration and does not claim one: if a clip can be exported as a file, the upload path is what it gets.
Four mechanisms, all of them in the product rather than in a policy document. No privacy-sensitive search or watchlist change runs without a Case ID recording the lawful grounds, whether that is a case file, a court order, or a missing-person report. Every search, match and enrollment is written to an append-only, tamper-evident log, exported daily and readable by supervisors and by independent oversight bodies. A match is a signal for a person to verify, never an action the platform takes on its own. And demographic bias is disclosed rather than denied: all face recognition algorithms vary in accuracy across groups of gender, age and skin color, IREX ran a company study in 2024 to estimate that bias in its suspect-recognition technology, and policy is to state systematic bias and its estimated impact where it exists.
There is no IREX facial recognition camera to buy: the module runs on the cameras you already have, and the requirements are about the picture rather than the badge on the housing. FaceTrack Pro documents 1280 × 720 up to 2592 × 1944 at 10 to 30 fps, roughly 50 px between the eyes, over 500 px per meter inside the region of interest, and a mount 1.5 to 3 meters up, at head height or a little above, which is what keeps the tilt inside +5° and the pan and roll within ±5°. Lighting is part of the specification too: natural or artificial, without backlight or reflections. A site survey confirms each camera against the module it will run.
From four permitted sources and no others, each with a documented permission on file before first use: public open-source datasets whose license permits commercial use and model training, synthetic imagery that IREX’s own 3D artists and generative models produce and tag as synthetic, non-identifiable customer Data Sets provided under the training clause of a signed agreement, and development cameras operated by IREX or its partners outside public spaces. Customer production video, feeds from cameras in public spaces, images scraped from the web or social media, and imagery of unknown provenance may never be used. Every label a model learns from is written or reviewed by a person, every release is evaluated on a sealed real-imagery test set, and a model that identifies people is assessed for demographic bias across gender, age group and skin tone before release, with known limitations disclosed. The rules are public, in the AI Model Governance Policy.
Any camera that supports ONVIF or streams RTSP with H.264 or H.265 on a static IP can be connected, but connection is not the bar. Each module sets its own resolution, mount position, height, and angle-of-view requirements in the camera requirements, the flagship modules need higher-resolution imagery of the scene than a bare stream, and the recommended primary stream is 1920 × 1080 or 1920 × 1440. A site survey confirms every camera against the module it will run.
It runs on its own and alerts a person. Detections are signals for a human to verify: no response runs autonomously, and the verification and decision are logged against the same Case ID as the detection.
Keep Reading
The audit trail is the part worth inspecting. We would rather show it to the people who will hold you to it than explain it later.