Facial Recognition Technology

We never store
biometric templates.

Venue Axis's facial-recognition integration is built so we never become a biometric handler under the Privacy Act. The system rejects biometric templates at the boundary — the moment a vendor tries to send one, the payload is refused. Match decisions stay with your chosen FRT vendor; the record stays with you.

The Architectural Commitment

What gets received. What gets rejected.

FRT vendors send Venue Axis a normalised event payload. We accept event metadata. We do not accept — and actively reject — anything that could be a biometric template.

Accepted

Event metadata only

  • Your venue reference
  • The vendor's event reference
  • Which vendor sent the event
  • Optional camera reference
  • Match confidence score
  • A non-reversible hash of the captured image
  • A short-lived link to the vendor-hosted image (24-hour expiry)
  • The matched patron reference in your own venue
Rejected at boundary

Biometric template payloads

  • Template vectors
  • Face embeddings
  • Raw biometric data
  • Encoded face geometry
  • Any field carrying biometric content
Rejected payloads are refused at the door and the rejection is logged. The biometric content is never stored, ever.
How the integration works

Vendor-agnostic. Cryptographically signed. Strict at the door.

Every FRT vendor that integrates with Venue Axis posts events to a single secure endpoint. Each event is cryptographically signed, validated against a strict schema, and de-duplicated before it's accepted. Anything that looks like a biometric template is refused at the door.

  • Cryptographically signed events, tamper-evident
  • Strict field validation — malformed events refused
  • Duplicate events refused automatically
  • Vendor-hosted image links expire after 24 hours
  • Adapter pattern — every supported vendor plugs into the same boundary
FRT event received87% confidence
Event checks
Signature verified✓ accepted
Schema validated✓ accepted
Biometric content check✓ clean
Duplicate check✓ unique
Stored
Event metadata✓ logged
Biometric payloadnever stored
Two-phase resolve

Match received. Floor confirms.

An FRT alert is not a decision — it's a candidate for review. The Floor PWA presents the alert with confidence score and patron reference; the duty manager confirms one of three outcomes: confirmed match, cannot locate, false match. Each outcome triggers the appropriate downstream workflow and feeds the accuracy dashboard.

  • Alert delivered to Floor PWA + GM Desktop simultaneously
  • Three outcomes: confirmed · cannot locate · false match
  • False-match reason codes captured for vendor accuracy review
  • Confirmed match → refuse-entry record auto-created
  • Full audit trail: SE check → FRT alert → outcome
FRT Alert Resolve87% confidence
Workflow
01Vendor webhook receivedDONE
02HMAC + schema verifiedDONE
03Floor PWA notified — duty manager pagedDONE
04Floor confirms outcomeACTIVE
05Refuse-entry record + GM notificationPENDING
Outcome options
Confirmed match
Cannot locate
False match

Accuracy Dashboard

Per-vendor false-positive rate, confirmed-match rate, cannot-locate rate, by camera and by time of day. The GM portal surfaces these live so you can hold your FRT vendor accountable to the SLA they promised.

Dispute Workflow

When a patron disputes a match, the dispute pack assembles the webhook payload (without biometric data), the floor confirmation, the camera reference, and the FRT vendor's accuracy stats — ready for export to legal or to the patron.

Code-of-Practice Aligned

The two-phase resolve, audit-logged outcomes, false-match tracking, and never-store-templates architecture are designed to align with the Code of Practice for Facial Recognition in Hotels and Clubs. Confirm your venue's readiness with the self-assessment below.

Vendor Stance

Vendor-agnostic, with a boundary.

We work with FRT vendors whose integration model honours the never-store-templates boundary — match decisions stay on the vendor side, only event metadata crosses to us. Today we lead with the two vendors below.

Primary integration target

Vix Vizion

Australian-headquartered, mid-market focus, clean adapter fit. Adapter is in code; production contract scheduled for Q1 2027.

Evaluation / sandbox

CompreFace

Self-hosted open-source, used for local development and demo environments. Useful for venues that want to evaluate FRT before committing to a production vendor.

Already running a different FRT vendor — Corsight, Idemia, NEC, or other? Our adapter pattern can integrate any vendor whose events stay within the architectural boundary (event metadata accepted, biometric content rejected). Get in touch and we'll walk through the fit for your existing stack.

FRT Readiness

Take the FRT readiness self-assessment.

Public, free, no login required. 10 questions covering NSW FRT Code (Hotels and Clubs, 2026) alignment — PIA, signage, staff training, accuracy monitoring, vendor due diligence, and patron dispute process. Returns a personalised gap brief with specific clause references and remediation steps.

Open the FRT readiness assessment →
FRT Readiness Assessment~5 min
Questions8
Dimensions assessed5
Gap reportPDF
Code-of-Practice alignmentscored
Signage + consentscored
Dispute workflowscored

FRT done right. Or not at all.