AI Fraud Detection for Retail Loss Prevention
Industry: Retail, large European chain with 50+ stores
Project type: Retail loss prevention, AI transaction monitoring, LLM-based anomaly detection
The Problem: Retail Fraud Found by Accident
Before the project, fraud detection in the retail chain was weak. Fraud was found by accident: an analyst digging through data happened to spot an odd transaction, or a conscientious store employee reported to headquarters that something was off. Some schemes ran for about a year before anyone stumbled on them — a gap no retail loss prevention program can afford.
Retail fraud patterns
Large cash payments. A €5,000 transaction paid in cash. EU rules prohibit accepting more than €1,000 in cash. The wording is loose, but in practice it's not allowed — and some stores accept it anyway. If a European audit reviews the transactions, the company is in violation.
Cashier skimming. A cashier rings up a sale, records it as paid in cash, and pockets part of the money. The register comes up short by exactly that amount.
Gift cards missing from the warehouse. The chain sells gift cards in €50 and €100 denominations. Cards were stolen from the warehouse and later turned up on eBay and Vinted, sold below face value to cash them out.
Fraud rules and patterns are highly specific to each business, which is why effective fraud detection in the retail industry has to be built around the company's own data.
The Solution
Data
The solution was built on data that was already prepared. Data engineers and analysts had previously assembled a structured transaction dataset: ticket amount, payment method, and other fields. Simpler than a scoring model, but similar logic.
Preparing and testing the data so it could be reliably passed to an LLM took about two weeks.
How the AI fraud detection bot works
Anomaly detection script. SQL and Python, connected to an LLM API. The model analyzes transactions, compares them against a moving average, and flags "outstanding transactions": anything that falls outside the normal range.
Daily transaction monitoring. The script runs which executes it on a set schedule — daily in this case. It takes in the data, analyzes and structures it, and identifies suspicious transactions, including which store they came from.
Alerts. The output is a message with a list of flagged transactions. A separate component sends it to any messenger works — Telegram, WhatsApp. . A typical alert: "Analyzed today's data — ten suspicious transactions at stores, please review," followed by the order IDs.
Response. The alert goes to the store director or the fraud director, who sees where potential fraud occurred and triggers a detailed investigation.
Previously this meant writing scripts and reviewing transactions by hand. Now both detection and alerting are fully automated: an AI agent that monitors transactions every day and escalates only what needs a human.
How the bot knows what to look for
Mostly, the model is taught known patterns. A prompt or a separate Markdown file describes the fraud cases and how to detect them. For example: build a normal distribution across all tickets, check which ones look off, review the largest tickets and confirm nothing is wrong with them.
The model is also asked to report anything else that looks unusual. That sometimes surfaces results, though it depends heavily on how the prompt is written.
A variant was also tested where the model searches for new schemes on its own — online, on Reddit, in professional fraud communities, in industry reports.
Prompt engineering and labeling
This is precise work: the wording has to be right for the model to understand the terminology.
A definition for every column. Each field gets an explicit definition: order date, invoice date, return date, revenue, VAT. In effect, data labeling.
External dictionary. In one task, the model needed to know which brands the chain doesn't carry. Instead of having the model search the web every time — which also burns tokens — the team found an external Google Sheets list of roughly 3,000 brands with categories such as luxury, and instructed the model to check that list first. That's an external dictionary.
Testing and correction. A few days of testing, followed by adjustments — similar in spirit to fine-tuning.
Results
- Fraud detection became 30x faster. In some cases, from "found by accident after a year" to caught immediately.
- The biggest win is response speed: fraud gets stopped before it scales.
- Detection and alerting are fully automated. Previously, everything was manual.
Team, Timeline, Budget
- Team: 3 people — a senior lead, a data engineer, and a data analyst.
- Timeline: about 3 months inside a large company. It could have gone faster; time went to approvals and parallel onboarding, with the fraud team walking through its cases.
- Project cost: about €50,000, including data preparation.
Challenges
- Dirty data. For example, a €1,000 transaction gets duplicated three or four times because of a provider bug — and the average ticket looks great when it's actually an error. Data comes in through Google Analytics or Adobe Analytics, cookie issues happen, and data can fail to collect or transfer. There is always some margin of uncertainty around data quality.
- Management reluctance. There are always cases where someone has no interest in something coming to light.
- The client's existing stack. If there is no data infrastructure at all, the client will need to implement tooling and buy licenses — costs on their side.
Where This Retail Loss Prevention Technology Applies
This works as a standalone retail fraud prevention service: the client has data, a script is built to find anomalies and send alerts. It fits mid-sized and smaller businesses too, even with less data — including online retailers looking for ecommerce fraud detection on their order and payment data.
Many companies still run loss prevention in retail stores by hand. One example: a well-known retail chain with about 50 stores where every store still fills out an Excel file and sends it to headquarters. Even large, established brands work this way.
Automation like this also reduces manual workload. For instance, a store may have an employee whose entire job is processing return paperwork — that can now be handled automatically.
Related Case Studies
- Return Fraud Detection: Cutting Fraudulent Returns 38% for a DTC Retailer
- An AI Detector for Fraudulent and Damaged Returns at an Online Beauty Retailer
About the Author
Vladislav Volovik — Data & Analytics Lead, Building Agentic
E-commerce data analyst Previously five years at in-house consulting t, where he built BI solutions on SAP Analytics for IT cost optimization across the group. EDHEC Business School, MSc in Consulting & Digital Transformation. At Building Agentic he designs the data models and BI layer on every engagement — the part that decides whether reporting takes one click or one analyst.
