Use vision to surface evidence, not to label a person
A frozen feed, chip outside its zone or repeated card movement may look unusual, but none establishes fraud or intent alone. Show the specific observation, preserve its source and let an authorised reviewer compare it with the game record before any customer or staff action.
Start fraud monitoring with a defined event and the harm it should prevent: for example, a recurring camera outage, a dealer action outside procedure, an object entering a restricted area or disagreement between video and service records. Avoid vague goals such as spotting suspicious players; they invite opaque scoring and alerts that are hard to validate.
Compare an alert with the game event, table procedure and account history before classifying it. A read-only sensor can inform the review but must not suspend an account or change a result by itself. Keep the evidence bundle linked to, yet separate from, the decision record.
Separate anomaly signals by what they measure
| Signal | What the model can report | What it cannot prove alone |
|---|---|---|
| Repeated stream freeze | Frame sequence stopped or exceeded a missing-frame threshold. | Why the stream stopped or whether someone caused it. |
| Unexpected card movement | Card track crossed a defined region outside the expected phase. | Whether the movement broke a rule or affected the result. |
| Chip-region mismatch | Visible chip estimate differs from the platform's event record. | The correct financial amount if the view is occluded or incomplete. |
| Camera configuration change | View geometry or image distribution differs from its approved baseline. | Whether the change was deliberate, authorised or harmful. |
| Unusual hand pose | Pose or position is outside a configured visual pattern. | Identity, intention, collusion or misconduct. |
Route technical faults, rule exceptions and conduct concerns separately. Send camera failures to operations, game mismatches to a reviewer and identity questions through an approved identity process. A shared dashboard may link cases, but each category needs its own evidence rules and access controls.
Build an alert that a reviewer can test
An alert should identify its time range, camera, model and threshold versions, detected region, source and processed image, game phase and related service event. Include input quality and confidence. Without source frames, do not label an anomaly verified. Reviewers need enough context to confirm, reject or escalate.
- Vision reports an event with a bounded time and table location.
- Monitoring checks camera status, stream age and expected game phase.
- A reconciliation service compares the observation with authoritative game events.
- A reviewer examines evidence when the conflict could affect a customer or case review.
- The case closes with a recorded reason, owner and link to any corrective action.
Set review thresholds using false-positive and missed-event costs, confidence calibration, image quality and corroborating evidence. A low-confidence alert may still help when review is cheap and consequences are minor. Interventions with high impact need stronger independent support.
False positives are a customer and staff risk
Glare can look like a chip, a shadow like movement and an ordinary dealer action like an exception. Repeated alerts can affect staff records or customer accounts as well as consume review time. Measure false positives by table, camera, event and environment, and assess the cost of errors alongside model accuracy.
Let reviewers correct an alert with a reason such as misalignment, changed game phase, occlusion or unsuitable model version. Preserve the original prediction. Later review should reveal what the system produced, what the person saw and why the case closed.
Run updated models in shadow mode on live or approved replay data before they alert staff. Compare disagreements, delay, false alarms and misses. Roll back a noisier or less reliable version, and check performance after hardware or table-layout changes.
Keep biometric features out of a general fraud model
Camera feeds can prompt requests for face matching, age estimates, voice analysis, gaze tracking or emotion inference. Those features carry privacy and fairness risks unlike detecting a card or frozen stream. A generic fraud model can obscure the difference. Separate their models, purposes, data paths, roles and approval gates.
Keep face, voice, gait and gaze signals out of the card-and-chip anomaly path. Show reviewers whether identity data influenced an alert; if so, send the case for authorised privacy review before account action. Record the feature owner, retention term and correction route.
Do not infer gambling risk or suspicious intent from someone's appearance or movement. For account security or identity checks, use a defined process and a less intrusive method when adequate. Set retention, overseas transfer, accuracy review and access rules before collecting biometric samples.
Protect platform integrity through system boundaries
Give vision access to relevant video and game-event metadata, then route its output to a review queue. It should have no connection to RNG, payment or restriction services. If an alert triggers account review, an authorised person must apply policy and record the reason. Model credentials must not settle games or change balances.
Investigators need platform references such as activation and change events, authentication, account history and interruption recovery. Link camera alerts to those records; a camera archive alone cannot establish what the game accepted.
Restrict footage by role and case. Encrypt it, log access and apply retention schedules that distinguish routine quality clips from incident records. Vendor contracts should cover data handling, security notices, model updates and deletion.
Measure case review quality and user impact
Track time to triage a genuine mismatch, reviewer agreement, false alerts per table-hour, sampled misses, evidence retrieval, queue age and customer-impacting corrections. Add a safeguard against incorrect restrictions or unsupported accusations. Higher alert volume may come from a camera fault, model revision or new procedure, not more fraud.
Fraud-monitoring performance dashboard
- Alert precision by class
- Question it answers:What share of signals is relevant to its stated review purpose?· Guardrail:Do not merge harmless technical events with conduct allegations.
- Missed-event sample
- Question it answers:Which known exceptions did the system fail to surface?· Guardrail:Run periodic replay review rather than using only alert samples.
- Case resolution time
- Question it answers:Can staff reach a grounded decision with the available evidence?· Guardrail:Monitor workload and overdue cases.
- Correction and appeal rate
- Question it answers:Do decisions need a better policy or evidence path?· Guardrail:Preserve the original alert and correction reason.
New Zealand release review
Before enabling a visual fraud signal, document its purpose, false-positive review, staff appeal route, video retention, authority for account action and operator approval. Do not connect it to wagering until the record is reviewed and case owners can inspect source evidence.
The release record should name the signal, purpose, data source, reviewer, decision authority, retention period, failure mode and metric. Assess privacy when footage identifies people or uses biometrics. Review game and account obligations independently of the model.
Close a case with its signal, source frame, independent game record, reviewer decision and action. Keep unresolved alerts visible at handover, while preventing the model from turning an open case into an accusation or restriction.