Computer Vision for Fraud and Anomaly Detection: Finding What Rules Miss
Rules catch what you already thought of. That is their strength and their ceiling. A rule that flags refunds over $200 will never catch the person processing forty refunds of $40, and a rule written after last year’s loss event will not describe next year’s. Anomaly detection — in computer vision as much as in transaction data — exists for the category of problems you have not written a rule for yet.
What Anomaly Detection Means in Practice
Anomaly detection learns what normal looks like for a specific site, then flags meaningful deviations from it. Instead of “alert if X,” the logic is “alert if this is unlike what usually happens here at this time.” The output is not a verdict — it is a prompt for a human to look.
The distinction from rule-based detection matters operationally:
| Rule-based detection | Anomaly detection | |
|---|---|---|
| Catches | Known patterns you defined | Deviations from learned normal, including novel ones |
| Output | A definite violation | An unusual event needing review |
| Setup | Write the rule | Collect a baseline period |
| Fails by | Missing anything unanticipated | Flagging unusual-but-legitimate activity |
| Best for | Compliance and clear thresholds | Loss, fraud and process drift |
Serious deployments run both. Rules handle the known; anomaly detection covers the space rules do not reach.
Visual Anomalies Worth Detecting
- Activity at the wrong time. The stockroom door opening during a shift when nobody is scheduled there, or a loading bay active at 03:00 on a day with no scheduled delivery.
- Sequence violations. A pallet leaving the dock without a preceding scan event; a vehicle exiting a yard with no matching arrival record.
- Duration outliers. A delivery that takes eight minutes when the same route normally takes three; a trailer at a dock for four hours against a typical forty minutes.
- Volume mismatches. Cartons counted leaving the dock not matching the shipment record — a simple comparison that requires the camera count and the system record to be in the same place.
- Repeated presence without transaction. The same pattern of movement in a high-value area at a consistent point in the shift.
- Unexpected access combinations. A badge used at a door minutes after the same badge was used at a site 40 kilometres away.
Notice that several of these are not purely visual. They compare what the camera saw against what a business system recorded, and that comparison is where most of the value lives.
The Cross-Signal Principle
A camera alone sees movement. A point-of-sale system alone sees transactions. An access control system alone sees badge events. Each is easy to explain away in isolation. Together they produce something considerably harder to dismiss: a timeline in which a gap is visible.
Two examples that illustrate the mechanism:
- Retail: a till drawer opening with no corresponding transaction at that timestamp is a rule. A specific till showing that pattern only during one shift, only on quiet afternoons, is a pattern — and the second one is not something anyone writes a rule for in advance.
- Logistics: a trailer departing with a camera-counted carton total below the manifest quantity. Neither the camera count nor the manifest is conclusive alone; the discrepancy between them is the signal.
This is the practical argument for consolidating cameras, sensors and access logs onto one platform. Cross-referencing is impossible when the three data sets live in three systems with three clocks and three export formats.
What “Learning Over Time” Actually Requires
Anomaly detection genuinely does improve with data, but the mechanism is less magical than the marketing suggests, and two conditions are easy to get wrong.
The baseline must represent normal. A model trained during an atypical period — a seasonal peak, a renovation, a staffing gap — learns that as normal and misjudges everything afterwards. A baseline should span enough time to include the site’s real weekly and seasonal rhythm, and any known-abnormal period should be excluded deliberately.
Feedback has to be captured. The improvement comes from someone marking flagged events as legitimate or genuinely problematic. Without a review loop, the system keeps flagging the same benign pattern indefinitely. Whoever reviews anomalies needs to be named at the design stage, along with roughly how much of their week it will take.
The Failure Mode: Treating a Flag as a Finding
The most damaging misuse of anomaly detection is treating an unusual event as evidence of wrongdoing. An anomaly means “this is statistically unlike normal.” Most anomalies have benign explanations — a new procedure, a covering employee doing things differently, a supplier changing delivery times, a stocktake.
In an employment context this carries real risk. A pattern flag is a reason to investigate through normal channels, never a conclusion about a person, and using detection counts as a basis for disciplinary action is both unfair and unsound, because the false-positive rate on individual events is meaningful by design. Systems introduced as process-improvement tools tend to be accepted by staff; systems experienced as automated accusation are resisted, and the resistance usually defeats the deployment.
Where to Start
Anomaly detection is not the first thing a business should deploy. A sensible sequence:
- Get the basic events instrumented — entries, exits, zone occupancy, access, deliveries. Anomaly detection needs a stream of events to learn from.
- Write the rules you already know — the obvious thresholds and compliance checks. These deliver value immediately and generate labelled examples.
- Collect a clean baseline across a representative period.
- Enable anomaly review on one high-value area — the stockroom, the dock, the cash-handling zone — rather than the whole site at once.
- Name the reviewer and the cadence, and treat the flag list as a weekly management report rather than a real-time alarm.
IoTiq’s role in this is the layer underneath: cameras, sensors and access control feeding a single event stream on one dashboard, processed locally, so that cross-signal comparison is possible in the first place. Retail, warehouse and multi-property deployments all produce the same shape of data, which is what makes patterns comparable across sites in a portfolio.
Quick Answers
What is anomaly detection in computer vision? It is an approach that learns what normal activity looks like at a specific site — timing, duration, sequence, volume — and flags meaningful deviations, including patterns nobody wrote a rule for. The output is an event worth reviewing, not a conclusion.
How is it different from rule-based alerts? Rules catch known patterns you defined in advance and produce definite violations. Anomaly detection catches deviations from learned normal, including novel ones, but produces events needing human review. Most effective deployments run both, with rules covering compliance thresholds and anomaly detection covering loss and process drift.
Can an anomaly flag be used as proof of theft or misconduct? No. An anomaly means an event is statistically unusual, and most unusual events have benign explanations. It is a trigger to investigate through normal channels, never a conclusion about an individual, and detection counts should not be used as a basis for disciplinary action.
Related Guides
Talk to IoTiq
If your cameras, till system and access logs are in three separate places, cross-referencing them is currently a manual job. Book a free assessment to see what consolidating them onto one event stream would show.
