Retail returns fraud & POS exception analytics

Returns are a large cost line for retailers, and a measurable part of them is abusive: wardrobing, receipt fraud, empty-box returns, false "item not received" claims, and employee-assisted refunds. Models score each return at the moment of request and mine POS logs for unusual cashier and store behaviour. Most customers are never affected, a small share is routed to inspection or denial, and loss-prevention staff work a ranked queue instead of paper reports. In the EU this must be built around withdrawal rights, GDPR profiling rules and works-council co-determination.

Problem & value

• Today: returns policies are enforced with static rules (time window, receipt required, max returns per month) plus periodic exception reports on POS data. Rules are easy to learn and evade, and generate false positives that annoy good customers. Employee fraud (fake refunds to own card, sweethearting, void abuse) is found late, by audit or tip-off.
• AI value: combine return, order, delivery and cashier data into a per-event risk score, detect organised rings via shared identifiers (graph analysis), and rank POS exceptions against a store's and cashier's peer baseline.
• Sourced scale (US, 2023): NRF with Appriss Retail estimated returns at 14.5% of sales (USD 743 bn), of which about 13.7% were fraudulent or abusive (about USD 101 bn); Appriss describes claims and appeasements (e.g. "not received", "damaged") as the fastest-growing online abuse category [1][2][3]. These are US figures built on Appriss customer data; EU equivalents are not published at comparable quality, so treat them as order-of-magnitude only.

Variants

• Return authorisation at the counter/online portal: real-time score decides accept / store credit / inspect / deny. Strictest GDPR and consumer-law impact.
• Online claims abuse: "item not received", "damaged", empty-box and swapped-item claims, matched against carrier scans and delivery photos.
• POS exception analytics (internal theft): voids, no-sale drawer opens, discount and price overrides, refund-to-card patterns per cashier; peer-group outlier ranking.
• Self-checkout loss prevention: missed scans and ticket switching detected from camera events fused with POS data. The vision part is covered in VIS-047; here it contributes only a feature to the exception score.
• Re-commerce / condition grading: see VIS-037 for inspecting returned goods.
• Franchise/SMB: a hosted rules-plus-ML service in the shop system; no data science team needed.

How it works

1. returns/POS/order/carrier events (streaming)
2. identity & item resolution (receipt, serial no., pseudonymised customer key)
3. features (return rate vs. peers, time-to-return, price band, SKU risk, reason-code mix, address/device/payment links, cashier-store baselines)
4. scoring (gradient-boosted trees + anomaly models + graph features)
5. policy engine (thresholds per segment, legal guard-rails, allow-list)
6. action + reason codes
7. agent screen / case queue (human decides on adverse outcomes)
8. feedback (inspection result, chargeback, investigation outcome)
9. retraining

• Models: supervised gradient boosting on labelled outcomes where available; isolation-forest or autoencoder-style anomaly scores for POS exceptions where labels are scarce; graph features to reveal rings sharing addresses, devices or cards.
• LLM role: summarise a case (timeline of returns, receipts, camera clips metadata) for the investigator, draft the customer-facing message, and explain reason codes in plain language. The LLM does not make the decision.
• Human-in-the-loop: any denial, account restriction or employee action requires human review; customers get a route to contest the decision.

Data preparation

Data needed: return and refund transactions, POS event logs (voids, overrides, no-sale opens), orders, carrier scans and customer or loyalty history. In an SMB this sits in the shop system, POS or ERP and in the carrier portal; cashier IDs are often shared logins, receipts are sometimes paper only.

Typical gaps: return reasons as free text or missing, no link between receipt, serial number and original order, duplicate customer records, few labelled outcomes (inspection results, chargebacks), and no consistent store or cashier identifiers.

Preparation steps: - Export the data and join it on a pseudonymised customer and item key (see PREP-005 and PREP-022). - Standardise reason codes and define the categories before modelling (PREP-019). - Harvest labels from inspection results, chargebacks and confirmed investigations (PREP-020). - Give every cashier a personal login so exceptions can be attributed; clarify purpose and retention first (PREP-025). - Keep a test set of cases checked by loss-prevention staff (PREP-018).

Rough share of effort: about 30-40 percent of a Path B/C project goes into data engineering and labelling; with Path A mostly the connector and master-data clean-up remain. Check readiness with GUIDE-003.

Implementation paths

Which path for whom

• SMB (A): shop and POS vendors and returns platforms offer ready-made abuse rules at SMB prices, and returns handling is a standard process.
• Enterprise (B): returns policy is a core margin lever and volumes make per-transaction fees high; own features and policies avoid cross-retailer data sharing.
• Developer (C): open-source tabular and graph stacks (XGBoost, PyOD, Neo4j) run on HW1 and keep sensitive customer and cashier data in-house.

Path A — Buy (recommended for most retailers)

• Returns-focused: Appriss Retail (Verify / Returns Authorization, US-based, widely used by large US chains), Happy Returns (UPS), Loop and Narvar (returns management with fraud rules), Optoro (re-commerce).
• Broader fraud platforms with returns/claims modules: Forter, Riskified, Signifyd (policy abuse and return-abuse protection), Sift. Check EU data residency and DPA terms.
• POS/loss prevention analytics: Everseen (Ireland, EU), Zebra Technologies (Prescriptive Analytics), Checkpoint Systems, Sensormatic (Johnson Controls).
• Choose A when: no in-house data science, POS/e-commerce platform has a connector, and a vendor's cross-retailer data network is a benefit (and legally acceptable, see below).

Path B — Build on cloud APIs

• Land events in a warehouse/streaming platform (Kafka, Snowflake, BigQuery, Databricks in EU regions); train tabular models with managed ML (Azure ML, Vertex AI, SageMaker, all with EU regions).
• Use an EU-hosted LLM (Mistral, or a frontier model via an EU region) for case summaries and explanations only; pseudonymise customer fields before the call.
• Choose B when: you need full control of policies and features and want to avoid cross-retailer data sharing.

Path C — Self-host (open source)

• Tabular/anomaly: XGBoost/LightGBM/CatBoost, scikit-learn, PyOD, Isolation Forest; graph analysis with NetworkX, Neo4j or PyG; feature store Feast; serving with MLflow or BentoML.
• Streaming/orchestration: Kafka or Redpanda, Flink; n8n or Camunda for case workflows.
• LLM summaries: a ≤30B open-weight model (e.g. Qwen3, Mistral Small, Llama) via vLLM or Ollama.
• Hardware: HW1 (CPU server) is enough for scoring; HW2 only if you add local LLM summaries or on-prem video analytics.

Path D — Custom training

Worth it for chains with millions of returns per year and enough labelled outcomes (inspection results, chargebacks, confirmed investigations). Train per-category models and calibrate by segment; keep labels honest (do not train only on cases you already denied, which creates feedback loops).

State of the art (2026)

• Network effects: the strongest signal remains cross-retailer behaviour data (as used by Appriss), which is difficult to replicate in-house and legally delicate in the EU.
• Shift from blanket rules to segment-level friction: low-risk customers get instant, label-free returns; medium-risk get store credit or drop-off inspection; only high-risk are denied, with reason codes.
• Claims abuse and organised rings are the growth areas: online "not received" and reshipment-then-return-in-store schemes [3].
• Graph + tabular models outperform pure rules; LLMs help with case narratives, not scoring.
• Limits: labels are noisy and biased by past policy; honest high-return shoppers (fashion, multiple sizes) look like wardrobers; fairness drift across customer groups; adversaries adapt. Published vendor accuracy claims are not independently benchmarked.

Shared resources & combinations

• Same stack (tabular-ml + anomaly-detection + graph-ml): ANOM-001 payment fraud, ANOM-004 platform abuse, ANOM-009 expense/procurement fraud, ANOM-022 mule accounts. One feature store and case-management layer serves all.
• Vision: VIS-047 self-checkout loss prevention, VIS-017 visual product recognition and VIS-037 returned-item condition grading supply evidence features.
• Downstream: ANOM-030 KPI/revenue anomaly detection for shrink dashboards.

Effort, cost & KPIs

• Path A: weeks to a few months (connector, policy tuning, pilot stores); fees typically per transaction or percentage of avoided loss.
• Path B/C: 3–6 months with a small data team; cost drivers are data engineering, labelling, and monitoring rather than compute.
• KPIs: fraud/abuse loss rate (% of refunds), false-positive rate and customer-complaint rate, good-customer friction (share of legitimate returns delayed), return-to-resale cycle time, investigator hit rate, shrink % of sales, time to detect internal exceptions.

People & change

Involve early: management (policy: what may be denied), the returns or store lead as process owner, the DPO and the works council before any pilot, then IT and customer service. Store staff must hear about the project from the company, not from rumours.

Works council: yes. Cashier exception analytics evaluates individual employees' behaviour; under §87(1) no. 6 BetrVG objective suitability for monitoring is enough, so co-determination applies. Also inform it under §90(1) no. 3, and consider an expert under §80(3). Agree a works agreement: purpose, no performance ranking of individuals, retention, who sees what. Public bodies: staff council.

Data protection: customer profiling and cashier analysis need a DPIA (Art. 35 GDPR), a documented legitimate-interest test, an AVV with every vendor and DPO involvement; Art. 22 means humans decide on denials.

AI literacy: train investigators and store managers to read reason codes and recognise false positives (AI Act Art. 4: support measures, no guaranteed level).

Pilot and concerns: run shadow mode in 5-10 stores. Staff fear surveillance and honest customers fear unfair denials: communicate that scores only prioritise cases, graduated actions come before denials, and customers can contest decisions. Humans always decide on adverse outcomes.

Guides: GUIDE-004, GUIDE-005, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk; fraud detection is excluded from the high-risk credit-scoring category only for financial-fraud detection (Annex III 5(b)), and retail returns scoring is not an Annex III use. Art. 5 prohibitions: no social-scoring or exploitation of vulnerabilities, and do not feed biometric identification (face recognition of "known abusers") into decisions; real-time remote biometric identification is restricted. Employee emotion inference is prohibited at work [4]. AI literacy (Art. 4) applies.
• Consumer law: Directive 2011/83/EU gives consumers a 14-day withdrawal right for distance sales without giving reasons; a score must not be used to block statutory withdrawal, only to handle abuse (e.g. returned items diminished in value, refund timing) [5]. Store returns beyond that are goodwill policies and can be restricted if communicated clearly.
• GDPR: profiling of customers requires a legal basis (usually legitimate interest, Art. 6(1)(f), with documented balancing test), transparency in the privacy notice, a DPIA, data minimisation and short retention. Art. 22 applies if a decision is solely automated with significant effects (e.g. account blocking); keep a human decision step and a contest route [6]. Sharing blacklists across retailers needs a strong legal basis and is usually problematic in the EU.
• Employment: POS monitoring of cashiers is employee monitoring: works-council co-determination (e.g. Section 87(1) no. 6 BetrVG in Germany), proportionality, no covert surveillance.
• Mitigations: reason codes, bias testing across segments, allow-lists for loyalty tiers, audit logs, periodic false-positive review, human sign-off on adverse outcomes.

Getting started

1. Baseline: return rate by channel and category, refund-to-card share, known abuse losses and current rule hit rates. Agree the legal basis, DPIA and works-council agreement first.
2. Join returns, order, carrier and POS data on a pseudonymised key; label inspection outcomes.
3. Pilot a vendor (Path A) or a gradient-boosted model in shadow mode in 5–10 stores; compare against existing rules without changing customer outcomes.
4. Introduce graduated actions (store credit, inspection) before any denial; monitor complaints.
5. Review monthly: loss rate, false positives, fairness slices, and retrain.

Sources

1. Retail TouchPoints — NRF: Returns Reach 14.5% of Sales in 2023, Fraud Contributed $101 Billion in Losses — https://www.retailtouchpoints.com/news/nrf-returns-reach-14-5-of-sales-in-2023-fraud-contributed-101-billion-in-losses/139806/
2. Appriss Retail — 2023 Consumer Returns in the Retail Industry — https://apprissretail.com/resource/2023-co
3. Appriss Retail — Claims and Appeasements Report 2024 — https://info.apprissretail.com/hubfs/Resource-Center/AR4041-WhitePaper-Claims-and-Appeasements-Report-2024.pdf
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Directive 2011/83/EU on consumer rights — https://eur-lex.europa.eu/eli/dir/2011/83/oj
6. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
7. Appriss Retail / Retail Dive returns report — https://info.apprissretail.com/hubfs/Resource-Center/2024-016-Retail-Dive-Returns-Report.pdf