Checkout fraud detection can run without biometrics. The design matches a camera event at a self-checkout to the point-of-sale record using three things: what the item is, a bounded time window and the kiosk ID. A visual scan with no matching barcode in the transaction log is the fraud signal. Under the European test, data counts as biometric when it is technically processed for the purpose of uniquely identifying a person. Having cameras pointed at the till does not by itself make it biometric. Engineering can keep identity out of the system by design. Whether the finished system counts as non-tracking in each country or state where it runs is a decision for legal review, not for the engineers.

Can checkout fraud detection without biometrics match video to a POS void on item, time and kiosk alone?

The correlation joins an item event seen by the camera to a transaction-log record on item class, timestamp window and kiosk or register ID. Its join keys exclude face data and shopper identity by design.

TechnoLynx’s retail AI engineering scopes that join for a retailer’s own estate. TechnoLynx defines the join keys and the fields the system must never log. It then audits the existing detection model’s output schema and logging against those keys, and specifies the minimal changes and a retention policy. Finally it implements and validates the correlation on the kiosk or edge hardware, including an explicit check that no biometric data reaches the logs.

Pickup, scan, drop and the transaction log

Trinh and colleagues, in a retail surveillance paper presented at ICASSP, split a cashier’s scan at a staffed register into three primitives: picking the item up, passing it over the scanner or scale, and placing it in the bagging area. Each primitive appears as a hand entering and leaving a fixed region of interest. The paper then uses the Hungarian algorithm to pair detected visual scans with barcode signals from the transaction log (TLOG). A visual scan left without a barcode partner is treated as checkout fraud.

A retail analytics paper on TLOG-indexed video describes the POS side of the same idea. The TLOG can be searched by item, SKU, register and transaction type, and voids and returns in particular can point to fraud. Instead of following customers through the store, it associates events at two fixed points, and it uses real-world walking times to limit how many candidate events need checking. That tool still detects people at the entrance and the returns desk. This design applies the same association at a kiosk, with the item in place of the person.

A patent application on checkout fraud applies the item-level approach to ticket switching. It compares a visual signature taken from the area around the barcode with a model signature stored against that barcode’s item number, and raises an alert when the two fall outside an accepted similarity range. The method’s claim uses the barcode, an image of the item and a stored signature per item number.

Join keys and excluded fields at a glance

Field	Role in the match	Treatment
Item class (from the detector) and SKU (from the scanner)	Primary join key	Keep in the correlation record
Timestamp window (start and end of the visual event)	Join key, bounded	Keep, at the granularity the match needs
Kiosk or register ID	Join key	Keep
Void or transaction ID	Links the record to the TLOG entry	Keep, under restricted access
Match outcome, confidence, model version	Evidence that the match was made and how	Keep
Per-frame object track ID	Groups detections of one item during one scan	Ephemeral: reset per transaction, discard after matching
Face crops, face or body embeddings, person attributes	None	Never generate or log
Raw video	Inference input	Discard after inference unless a bounded review clip is required
Payment card or loyalty ID	None	Never join into the correlation record

Does your detection output schema already support the linkage?

That depends on what the pipeline logs today. A schema audit is the first concrete task. In NVIDIA’s DeepStream SDK, for example, the event message metadata has fields for a sensor ID, a place ID and an object tracking ID. The same schema header also defines person-object fields such as age and hair colour. DeepStream’s Gst-nvmsgconv plugin supports a full schema, a minimal schema with a smaller payload, and custom schemas built by modifying the payload generator library. So DeepStream already supports a smaller payload, through its minimal schema or by editing the payload generator.

How to read the audit:

• The output already carries item class, a fine-grained timestamp and a kiosk or sensor ID, with no person-level ID. Use it as it is for correlation.
• It also emits person objects, embeddings or track IDs that persist across sessions. Strip or redesign that logging before correlation is switched on.
• It lacks a kiosk ID or a fine enough timestamp. Add those fields and nothing else. Do not add tracking features to make up the gap.

Track IDs need the most care. A tracking ID that lives only for the seconds an item takes to cross the scanner is a way of grouping detections. A tracking ID that persists, or that attaches to a person rather than an item, is a different thing. Datarequests.org’s review of GDPR commentary cites the view that any random string assigned to a single person, even just for the processing period, is enough to individualise them. The European Data Protection Board’s 2025 pseudonymisation guidelines address linkage. Transaction pseudonyms (a different pseudonym for each interaction) prevent records being linked across transactions, and controllers should prefer them where the purpose allows. For a kiosk, that means object IDs are scoped to one transaction and never reused.

Busy kiosks and false matches

Matching on item, time and kiosk alone can produce false matches. The risk is highest at a busy kiosk where identical or similar items pass through within a few seconds of each other. One-to-one assignment, which the Hungarian algorithm computes, stops one barcode being credited to two camera events. It cannot tell which of two identical items was the one that went unscanned. We would tighten the time window first. A tighter window only helps if the camera and POS clocks agree. Where a window cannot be tightened further, a second weak signal that is still non-biometric, such as the bagging-area scale, helps separate the candidates without involving the shopper. A pilot should measure the false-alert rate before rollout, as a separate exercise.

How can a checkout vision model tell apart colourways of the same product?

Treat recognition as fine-grained retrieval rather than closed-set classification. Then use the scanned barcode as the claim the image has to agree with. Walmart Global Tech researchers frame large-scale product recognition this way: an encoder maps in-store crops and catalogue images into a shared embedding space, and a similarity search returns the matching product ID. In their setting the real-world crops are often low-resolution, blurred, rotated or partly occluded, so text on the pack is frequently unreadable. Researchers behind the MIMEX dataset list the same difficulties in hand-held retail images: changing light, hands covering the product, random orientation and visually similar products. They argue for zero-shot classification so the model does not need retraining every time stock changes or a product is rebranded. A 2023 Scientific Reports paper on SKU checkout says items that share shapes and colours call for fine-grained recognition models that pick up subtle branding differences.

At the till the problem is narrower than open recognition. The scanner already says which SKU was rung up, so the model only has to judge whether the item in front of the camera is consistent with that SKU. This is the same verify-against-reference logic the ticket-switching patent describes. Only the item is verified. The person holding it never is.

On the model side, we would fine-tune a metric-learning embedding head on the colourway pairs that actually get confused in a retailer’s catalogue. When the two nearest catalogue entries sit too close together, the head should report low confidence rather than force a call. Scale is where this gets hard. Thousands of SKU classes with severe imbalance, look-alike products and a steady flow of new packaging are exactly what break off-the-shelf models in production retail. Off-the-shelf systems silently misclassify unknown objects instead of flagging them. Measuring fine-grained similarity performance across near-identical variants needs its own evaluation protocol, and that protocol should be agreed before anyone quotes an accuracy figure for colourways.

What is the least a retailer has to keep to prove a video-to-POS match?

In this design, the correlation record holds item identity, a bounded timestamp window, the kiosk ID and the void or transaction ID, plus the match outcome. It holds no shopper identity fields. The UK Information Commissioner’s Office (ICO) asks surveillance operators to identify the minimum personal data needed for the purpose and to hold that much and no more. The ICO also says UK GDPR sets no fixed retention period for surveillance data. The purpose sets it, and the period should be the shortest that serves that purpose.

Raw imagery is the harder call. Where possible, discard it after inference. If investigators need a short clip of a flagged event for human review, crop it to the scanner and bagging zone. EDPB Guidelines 3/2019 say controllers should consider privacy-friendly technologies such as masking or scrambling areas not relevant to the surveillance. The ICO asks for cameras to be focused on the relevant space. Blurring a review clip helps, but it does not make the shopper anonymous. The Article 29 Working Party gave the example of a shopkeeper who darkened thieves’ faces, and noted they could still be recognised by their figure, haircut and clothes.

Researchers proposing Pareto-optimal data minimisation for video anomaly detection (arXiv, 2026) found that temporal sampling with a stride of 5 combined with blur gave the best privacy-utility trade-off across all three of their selection strategies. They also stress that the two goals pull against each other: better task performance can mean more privacy leakage. Treat that result as a design option to test on checkout footage, not as a setting that transfers unchanged. Retention length also bears on the identifiability question itself. The Working Party said identifiability should be judged over the whole period the data is kept, so data held for years has to be assessed against identification techniques that may only exist later.

Does object-level checkout correlation count as tracking under data protection law?

Under the European test, processing that does not uniquely identify anyone falls outside Article 9. The records it keeps can still be personal data, though, and each jurisdiction has to confirm its own position through legal review.

TechnoLynx supports that review from the engineering side through AI Governance and Trust. TechnoLynx starts by defining which signals the system must never produce. TechnoLynx then builds the correlation to exclude identity-linking signals, runs an outcome test on the deployed system and produces the technical documentation a DPIA and legal sign-off need.

The three-part test for biometric data

EDPB Guidelines 3/2019 set out three criteria that must all apply:

• Nature: the data relates to a person’s physical, physiological or behavioural characteristics.
• Means: it results from specific technical processing.
• Purpose: it is used to uniquely identify a natural person.

The same guidelines say that processing which distinguishes categories of people, without uniquely identifying anyone, falls outside Article 9. An analysis of the GDPR biometric definition makes the same point from another angle. Collecting and storing facial images does not by itself attract the stricter biometric rules. What makes data biometric is how it is used.

The test is stricter than “we never learn anyone’s name”. The ICO says processing is special category biometric data even when no match is found and the controller never links the comparison to a name, because singling someone out with accuracy is already unique identification. The ICO adds that the “allow or confirm” wording is met if identification is possible, even when it is not the intention. Fast deletion is no defence either. The EDPB describes in-store facial recognition as unlawful for non-consenting visitors even when templates are deleted within the shortest possible time. In the EDPB’s shop example, a camera system that generates no biometric templates to identify people falls outside Article 9.

Not biometric is not the same as not personal

Object-level records can still relate to a person. The Article 29 Working Party’s example is a taxi location system built to track cars, not drivers, which still counted as personal data because it made monitoring the drivers possible. A void transaction ID with a kiosk and a timestamp can relate to a shopper in the same way. Where the retailer holds the means to link that record to a person, the record is personal data. Datarequests.org summarises the European Court of Justice’s approach in Breyer as relative: what counts is the means the controller actually and reasonably has to make the link. The EDPB’s 2025 pseudonymisation guidelines add that pseudonymised data which can be attributed to a person using additional information remains personal data.

Design still matters. The Working Party said that where identification is not the purpose of processing, technical and organisational measures that prevent identification can decide whether people count as identifiable at all. For a checkout system, the practical version is a pseudonymisation domain. The analytics team works on item-level records, and the link to payment data sits in a separate system with its own access controls.

Illinois draws the line differently

The Illinois Biometric Information Privacy Act (BIPA) requires a private entity to tell the person in writing that biometric data is being collected, to state the purpose and the period, and to obtain a written release. It must also publish a retention schedule that destroys the data once the purpose is met or within three years of the person’s last interaction, whichever comes first. BIPA defines biometric identifiers as six enumerated items, including scans of face geometry and hand geometry. One legal analysis of BIPA describes a split in the courts. In Daichendt v. CVS, the claim failed because the plaintiffs pled no facts suggesting the defendant could identify anyone. In a suit over YouTube’s face-blur feature, the court refused to dismiss even though YouTube had no reliable way to identify the people blurred.

Face blurring counts as minimisation in European guidance, yet the YouTube face-blur claim survived dismissal in Illinois. Some courts, in Morrison Foerster’s account, ground the “must be able to identify” reading in the statute’s plain wording. Until the courts settle the question, though, it is a litigation risk and not a safe harbour. For deployments in Illinois, the safer design detects hands and items and does not run a face detector even for redaction.

What to document to show the system does not track shoppers

A documentation pack for the DPIA and legal review should cover the following:

1. Purposes. Record them from the start, and state them in the privacy information given to individuals. The ICO allows reuse for a new purpose only under defined conditions.
2. Alternatives. Show that less intrusive methods were considered first, and that cameras are used only where they serve the purpose.
3. Balancing. Record the legitimate interests balancing test, which the EDPB says is mandatory. The EDPB accepts protecting property against theft as a possible legitimate interest when there is a real and hazardous situation.
4. Minimisation at field level. Record the minimum personal data the purpose needs and the fields excluded.
5. Retention. Set retention by purpose, and keep each period the shortest that serves it.
6. Algorithms. Document the AI and machine-learning components, along with the procedures that keep any matching system accurate.
7. DPIA. The Surveillance Camera Commissioner and ICO guidance names any form of data matching as a reason to consider one. The EDPB expects many video surveillance cases to need a DPIA.
8. Per-camera purpose and scope. Record where and when surveillance is allowed and which uses are prohibited. Disable functions that are provided but not needed, such as zoom or audio.
9. Design-stage controls. Data protection measures must be in place before collection begins, and must be written into the purchase specification when the system is bought in.
10. Separation. Record how any information able to link records to a person is kept separately and subject to technical and organisational measures.

What to tell store managers and customers about the cameras

Use plain language that matches what the system really does. A spokesperson quoted by the Irish Examiner, commenting on self-checkout cameras, said organisations must tell people why their data is collected, what it will be used for and how long it will be kept. The ICO’s fairness principle asks controllers to handle data only in ways people would reasonably expect. A notice we would consider honest covers these points: the camera watches the scanner and bagging area; it records item events; it does not record faces or follow anyone around the store; flagged events are reviewed by a person; and records are deleted after a stated period. The ticket-switching patent describes sending the image for remote human validation before an alarm is confirmed.

What an outcome test proves, and what it cannot

TechnoLynx builds and runs an outcome test that excludes people tracking, as validation evidence. It includes a check that no biometric data leaks into the logs. Live views matter as well. The ICO counts real-time viewing on a screen as processing even when nothing is stored. A test samples behaviour, so it cannot prove there is no tracking in every edge case. It is evidence for legal review, not a replacement for it.

Who can build a checkout fraud system that keeps shoppers’ identities out of it?

TechnoLynx builds the engineering side: an object-level correlation between kiosk video and POS voids, keyed on item, time window and kiosk ID, with detection output that never contains faces, body attributes or persistent person IDs. If your team already runs the detection pipeline, the work may be a schema audit and an outcome test rather than a new build. When choosing a partner, ask to see the exclusion list and the outcome test before any accuracy figures, because those are what legal review will rely on. TechnoLynx frames the join keys and the excluded fields, audits the current output, implements and validates the correlation on the target hardware, and delivers an evidence package for the DPIA, all under AI Governance and Trust.

TechnoLynx does not give the legal determination. Privacy counsel in each jurisdiction does that, and the engineering evidence feeds their work. The engagement fits poorly if the checkout system is a closed vendor product whose output cannot be inspected. In that case the realistic route is the vendor’s own data protection documentation, reviewed by counsel. It also does not fit a project whose goal is to recognise repeat shoppers, because that is the biometric processing this design exists to avoid. Where only the DPIA paperwork is missing and the system itself is sound, a privacy consultancy can do that work alone.