BOH 609: Facial Recognition in Casinos

Facial recognition in a casino is best understood as an alerting tool inside an identity-control process. A camera image is compared with approved reference images, and the system may report that a person resembles someone on a watchlist. That alert can help staff find a possible excluded, trespassed, self-excluded, fraudulent, or otherwise relevant person. It does not prove identity and should not trigger an automatic accusation or removal.

The most serious operational mistake is buying the software before designing the policy. A casino can have an accurate algorithm and still create a poor system through weak watchlists, excessive retention, careless staff access, unclear legal authority, or overconfident responses.

This page focuses on how a casino should govern and use face matching on the floor. For the technical architecture—cameras, templates, comparison engines, thresholds and integrations—see Facial Recognition Systems.

What the system is actually comparing

A facial-recognition workflow does not usually compare two ordinary photographs by asking whether they “look alike” in the human sense. Software detects a face, extracts measurable features into a mathematical representation, and compares that representation with one or more stored templates.

There are two different tasks:

One-to-many searching is operationally harder. The system is looking across many candidates, often from imperfect live video, and must decide which similarities are strong enough to alert staff. A lower alert threshold may find more true matches but create more false alerts. A higher threshold may reduce false alerts but miss people the casino hoped to identify.

The score displayed by a vendor is not automatically “the probability that this is the same person.” It is a similarity score interpreted under the vendor’s model and configured threshold. Staff need training on what that score means in their own system.

A controlled casino workflow

A defensible process separates detection, review, verification and action.

1. Capture
   An approved camera obtains an image suitable for comparison. Lighting, angle, motion, obstructions and image resolution affect quality.

2. Automated comparison
   The system searches an authorized reference list and produces either no alert or a possible match.

3. First human review
   An authorized surveillance or security employee checks image quality, the reference record, the reason for watchlist inclusion and the current context.

4. Independent confirmation
   For a sensitive action, a second trained reviewer or supervisor confirms the basis. This reduces snap decisions and confirmation bias.

5. Policy-based verification
   Staff use lawful, proportionate information to verify identity. The correct method depends on the situation and jurisdiction; it may include account records, an identification request, a known prior record or direct security contact.

6. Floor response
   Security, responsible-gaming staff or management act under the applicable exclusion, trespass, fraud or guest-service procedure.

7. Documentation and correction
   The casino records the alert, review, verification, action and outcome. A rejected alert should be labeled as such so it does not quietly become a permanent allegation.

A face alert should therefore be treated like a lead from another surveillance analytic: useful enough to inspect, never strong enough to skip verification.

The watchlist is often the highest-risk component

Poor watchlist governance can damage an otherwise capable system. Before a face is enrolled, the property should know:

• the lawful and operational reason for inclusion;
• who approved the enrollment;
• the source and quality of the reference image;
• the person’s status and any start or expiry date;
• the action staff are authorized to take after confirmation;
• whether the record may be shared with another property or vendor;
• how correction, appeal or removal is handled;
• how long the biometric template and associated record will be retained.

Different statuses should not be blended into one vague “person of interest” list. A self-excluded patron, a person formally trespassed after violence, a suspected advantage player, a VIP who requested recognition, and an employee under an investigation involve different legal bases, different responses and different privacy expectations.

A casino also needs a removal process. A temporary exclusion can expire. A trespass order can be rescinded. A fraud suspicion can prove wrong. A reference image can belong to the wrong person. If records only enter the system and never leave, the watchlist becomes less accurate and more dangerous over time.

Self-exclusion requires special care

Facial recognition may support a self-exclusion program by helping staff identify an enrolled person who enters a prohibited gaming area. It cannot replace the program’s human and procedural controls.

A self-exclusion alert should lead to the approved responsible-gaming response, not public confrontation or casual discussion across the floor. Staff need to know:

• which locations and activities the exclusion covers;
• whether the record is active;
• which team is responsible for verification;
• how to approach the person discreetly;
• whether play, chips, credits or winnings require a particular process;
• what report and regulator notification are required;
• how personal information must be protected.

The technology should reduce missed interventions without increasing humiliation. The applicable procedure belongs with Self-Excluded Player Procedures, not with a generic security improvisation.

Accuracy is more than one vendor percentage

A sales presentation may advertise a very high recognition rate. That number is meaningless unless the test resembles the casino’s actual use.

Performance can change with:

• front-facing enrollment photos versus angled surveillance images;
• bright test lighting versus entrances with backlight or shadows;
• still images versus moving crowds;
• glasses, hats, masks, facial hair and aging;
• camera height and lens choice;
• watchlist size;
• the alert threshold;
• demographic differences;
• the time between the reference and live images;
• duplicate or low-quality records.

The casino should measure separate outcomes rather than one headline “accuracy” figure.

False-positive rate = Incorrect matches ÷ Comparisons involving different people

False-negative rate = Missed matches ÷ Comparisons involving the same person

Alert precision = Confirmed true matches ÷ All alerts reviewed

Precision matters operationally because it tells staff how much of the alert queue is useful.

Why a tiny false-positive rate can still create many wrong alerts

Consider an illustrative entrance system reviewing 100,000 visits. Assume:

• 50 visits involve people who are truly on the active watchlist;
• the system finds 90% of them;
• the false-positive rate on everyone else is 0.05%.

True alerts:

50 × 0.90 = 45

False alerts:

99,950 × 0.0005 ≈ 50

Alert precision:

45 ÷ (45 + 50) ≈ 47.4%

Even with a false-positive rate that sounds small, more than half of the alerts in this example would be wrong. These are not claimed casino performance figures; they demonstrate the base-rate problem. When the sought person is rare and the screened population is large, every alert still needs review.

NIST’s ongoing face-technology evaluations distinguish false-positive and false-negative behavior and show that performance depends on the algorithm, image conditions and demographic group. A casino evaluating a vendor should use the NIST demographic-effects evaluation as a reminder that an overall average can hide meaningful differences.

Human review can fail too

Adding a person to the loop is not enough if staff are untrained or rushed. Reviewers can anchor on the system’s suggestion and see a resemblance they would not have noticed independently.

Useful controls include:

• hiding the vendor’s strongest language and showing a neutral “possible match” label;
• requiring reviewers to document visible similarities and differences;
• using a second review before an adverse action;
• separating enrollment approval from alert adjudication;
• measuring which employees accept or reject alerts unusually often;
• testing reviewers with known samples;
• prohibiting public radio traffic containing sensitive status details;
• recording final outcomes so false matches can be analyzed.

A reviewer should be allowed to say “insufficient image” or “not confirmed.” If management expects every alert to become a case, the review step is decorative rather than real.

Privacy, security and purpose limitation

A face template can be difficult or impossible for a person to replace in the way a password can be changed. That makes biometric data a high-consequence asset.

The casino’s privacy and compliance review should address:

• the legal basis for collection and comparison;
• required notice or consent;
• whether security, responsible-gaming and marketing uses are legally and ethically separate;
• data minimization;
• encryption and access logging;
• vendor and subcontractor access;
• cross-property or cross-border sharing;
• retention and secure deletion;
• incident-response obligations;
• rights to access, correct, object or challenge where applicable;
• whether automated decisions are permitted.

A security deployment should not silently become a marketing-recognition database. Reusing an excluded-person system to identify ordinary patrons for promotions changes the purpose and risk. That decision requires its own legal basis, notice, policy and governance.

The U.S. Federal Trade Commission has warned that unsupported accuracy claims, inadequate risk assessment, poor monitoring and failures to prevent foreseeable biometric harm may create consumer-protection concerns. Its policy statement on biometric information is useful operational guidance even though casino obligations still depend on the applicable jurisdiction.

This page is not legal advice. A casino operating across states or countries should not copy one property’s policy because biometric law, gaming regulation and employment rules can differ sharply.

How to evaluate a system before deployment

A pilot should use the casino’s own conditions, not only the vendor’s demonstration images.

Test at representative entrances, gaming areas and times of day. Include crowding, poor angles, changing light, common headwear and older reference images. Measure:

Thresholds should be set for the real harm balance. Missing a low-risk VIP recognition is not the same as wrongly confronting a patron as a trespassed person. The response severity should influence the evidence required.

A practical entrance scenario

An alert suggests that an arriving guest resembles a person trespassed two years earlier. The live image is partly obscured by a cap, and the stored photograph is low resolution.

A weak operation dispatches security with the message, “The system identified him.”

A controlled operation records a low-quality alert, asks a second reviewer to compare the images, checks whether the trespass remains active, and chooses a lawful method of verification. If identity is not confirmed, the outcome is documented as an unconfirmed alert. The guest is not entered into a new incident record as though the allegation were true.

The difference is not politeness alone. It protects the guest, the employees and the evidence trail.

What success should look like

A successful facial-recognition program is not the one with the largest watchlist or the most alerts. It is the one that:

• supports a clearly defined legitimate purpose;
• finds enough true cases to justify its burden;
• keeps false interventions low;
• treats alerts as leads;
• protects sensitive data;
• removes stale records;
• documents decisions;
• measures performance continuously;
• pauses or changes the system when harm exceeds benefit.

For the technical system view, continue with Facial Recognition Systems. For broader limits on observation and data use, read Surveillance and Privacy and Player Data and Privacy. Operational responses should follow Patron Trespass and Back-Off Decisions, not a software alert alone.