Fake review detection

Online reviews drive purchase and booking decisions, so there is a market for fabricated praise, paid five-star campaigns and sabotage of competitors. Generative AI made fake text cheap, fluent and varied, which weakens classic "writing style" detectors. Current defences combine text models with account, behaviour, timing and network evidence, often with an LLM for explanation and triage, and keep a human decision for contested removals. Platforms use this to protect trust; businesses use it to audit their own channels and to document attacks.

Problem & value

• Who has it: review platforms (Trustpilot, Google Maps, Tripadvisor, Yelp-type services), marketplaces and shops, booking and app stores, but also SMBs (hotels, clinics, craftspeople, restaurants) whose ratings are attacked by competitors or boosted by agencies they hired. Regulators and consumer organisations are a further user group.
• Today: rule-based filters, keyword lists, verified-purchase flags and manual moderation, often reactive and complaint-driven. Fake reviews are produced by paid broker networks, incentivised groups and, increasingly, by LLMs.
• Scale evidence: Trustpilot reports that 7.8 million reviews were detected as fake and removed in 2025 and that every submitted review passes automated fake-review checks [3]. Treat platform self-reports as indicative: definitions and base rates differ per platform.
• Legal pressure: the US FTC rule on consumer reviews and testimonials has applied since 21 October 2024 and covers fake reviews including AI-generated ones, paid sentiment-conditioned reviews, undisclosed insider reviews and review suppression [1][2]. In the EU the Omnibus Directive 2019/2161 added fake reviews to the blacklist of unfair commercial practices and requires traders to take reasonable steps to check that reviews come from real purchasers; the UK DMCC Act gives the CMA direct fining powers since April 2025 (legal background from the directive texts, see Risks).
• AI value: consistent screening of all incoming reviews, discovery of coordinated campaigns that no single review reveals, and evidence packs that shorten takedown and legal processes.

Variants

• Platform-side integrity: large-scale scoring of every submission with graph analysis of reviewer networks and broker detection (see ANOM-004 for fake accounts).
• Marketplace seller/ASIN view: review-to-order matching, "review hijacking" (reviews moved onto unrelated products), incentivised review detection.
• Business self-audit (SMB): periodically scrape or export own Google/Tripadvisor/Trustpilot reviews, detect suspicious bursts or competitor sabotage and prepare takedown requests.
• Compliance check of own practices: make sure that review-collection campaigns do not condition incentives on positive sentiment, that insiders disclose, and that no negative reviews are suppressed [2]. LLM-drafted replies to reviews are covered by LANG-038.
• Consumer tool: browser extension or app that estimates review reliability of a product page; commercial consumer tools have come and gone (Fakespot was a well-known example that was discontinued by Mozilla in 2025), so check availability.
• Regulator / consumer-organisation monitoring: sampling studies and sweeps; note that classification of "fake" for enforcement needs human evidence review.
• AI-generated content angle: linking to ANOM-015 (detection of synthetic text); detector scores alone must never be the sole removal basis.

How it works

1. review submission / crawl / export
2. normalisation, language ID, dedup (exact + near-duplicate via embeddings)
3. feature extraction: text (embeddings, stylometry, LLM judgement), reviewer history, verified-purchase match, timing/burst, device/IP signals, rating deviation
4. models: text classifier (fine-tuned encoder) + tabular gradient boosting + anomaly detection
5. graph layer: reviewer–product–IP/device graph, community detection for campaigns
6. risk score + reason codes (LLM drafts a short rationale from the evidence)
7. policy: publish / delay / label / remove / escalate to human moderator
8. notice to reviewer (appeal path), evidence pack, feedback labels back into training

• Text signal: fine-tuned multilingual encoders (XLM-RoBERTa class) for review classification; the classic academic result is that n-gram plus psychologically motivated features reach nearly 90 % accuracy on a gold-standard deceptive-opinion dataset [4]. That dataset is small, synthetic-crowdsourced and old, so real-world accuracy is lower and drifts.
• Behavioural and network signals (account age, review bursts, shared devices or IPs, reciprocal review groups) are usually stronger than text once LLMs write the text. They need platform-side data; an outside business has only public data.
• LLM role: zero-/few-shot judgement of suspicious patterns, explaining decisions, clustering narratives, multilingual handling. LLMs are weak as stand-alone detectors of machine-written text and give false positives on non-native writers.
• Human-in-the-loop: removal of a contested review, legal action and any decision against a named reviewer/business is made by a trained moderator; appeals must be possible.

Data preparation

Needed are review texts, ratings and timestamps, reviewer account metadata, order data for verified-purchase matching, technical signals (IP, device) and past moderation decisions. In an SMB shop these sit in the shop system (Shopify, Shopware, WooCommerce), the review plug-in or third-party platforms, the ERP/order system and the moderator's mailbox or spreadsheets. Typical gaps: no link between review and order, reviews spread over several platforms, no labels (past removals were never recorded), inconsistent languages, and device or IP data that is not kept or may not legally be kept.

Preparation steps: export reviews from all channels into one table; join them with orders via customer or order ID (PREP-005); harvest labels from earlier moderation decisions and takedowns (PREP-020); build a small test set of 200-500 reviews labelled by staff (PREP-018); decide which technical signals may be stored under GDPR and for how long (PREP-025); pseudonymise reviewer data for analysis (PREP-022). Tools: spreadsheet or SQL, the platform's export or API, n8n for scheduled pulls. Expect roughly 25-35 % of the effort in data work. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A, because shop and review-platform plug-ins and moderation services are mature, EU-hostable and cheap for a standard problem.
• Enterprise: Path B, because large review volumes and own account, order and device signals favour a tailored scoring pipeline over per-seat products.
• Developer: Path C, because open multilingual text models plus graph and burst analysis run well on HW2 and avoid per-review API costs.
• Public: Path C, because publicly run rating or feedback portals need sovereign hosting and transparent, auditable rules.

Path A — Buy (recommended for most SMBs)

• Review platforms with built-in integrity: Trustpilot (Copenhagen, EU), Trusted Shops (Cologne, EU), eKomi (Berlin, EU), Kiyoh (NL, EU), Bazaarvoice, Yotpo, Reviews.io; they verify invoices/orders and run their own detection. Choosing a platform with verified-purchase reviews is the cheapest defence.
• Bot and abuse defence: Cloudflare, DataDome, hCaptcha-style vendors, and fraud tools (e.g. Sift, Arkose Labs) for the account layer feeding ANOM-004.
• Reputation monitoring services that alert on rating spikes and help file takedown requests.
• Choose A when: you host reviews on your shop and need verified collection, or you are a business that mainly needs monitoring and takedown support. Check EU hosting, data processing agreement and whether the vendor explains its moderation criteria.

Path B — Build on cloud APIs

• LLM triage: frontier models via EU regions (Mistral AI, Azure OpenAI EU, Google Vertex EU, Anthropic via AWS Bedrock/Vertex EU) to classify, cluster and explain flagged reviews with structured outputs. Use cheap small models for the bulk pass and a stronger model only on flagged cases.
• Embeddings (Mistral Embed, Cohere Embed, OpenAI/Google embeddings) for near-duplicate and template detection.
• Gradient boosting (LightGBM/XGBoost) on features in your warehouse (BigQuery, Snowflake, Azure) is typically the core scorer; the LLM is an add-on.
• Orchestration: n8n / Power Automate / own service; case queue in the existing ticketing tool.
• Choose B when: you operate a shop or marketplace and have order and account data to join.

Path C — Self-host (open source)

• Models: fine-tune multilingual encoders (XLM-RoBERTa, mDeBERTa, German BERT variants) via Hugging Face Transformers [5]; sentence-transformers for embeddings; open-weight LLMs in the 7–32B class (e.g. Qwen3, Mistral Small, Llama family) served with vLLM or Ollama for rationales.
• Graph and anomaly stack: NetworkX / igraph, Neo4j or Memgraph, PyOD or scikit-learn isolation forest, LightGBM.
• Crawling for self-audits: only where the terms of the source and law allow it; prefer official APIs (Google Business Profile API).
• Hardware: HW2 is sufficient (one 24–32 GB GPU); the encoder and graph parts run on CPU. Needed when review text and reviewer data must not leave the premises.

Path D — Custom training

Worth it for platforms with large volumes and their own moderation labels. Data: tens of thousands of moderator-labelled reviews per language, with account and network features, plus counterfactual AI-generated fakes created for training and red-teaming. Re-train regularly because attackers adapt; hold out a time-based test set. SMBs should not train from scratch.

State of the art (2026)

• Shift from text to context: with LLM-written fakes, detection relies on provenance (verified purchase, order link), behaviour and network evidence. Pure text detectors lose accuracy against paraphrased AI text.
• Industrial practice: platforms combine automated scoring of every review with human investigation teams and legal action against brokers; Trustpilot states that all reviews pass automated checks [3].
• Benchmarks: public datasets (Ott et al. deceptive-opinion corpus [4], Yelp-filtered data) are small and outdated; reported accuracies on them overstate real performance. There is no widely accepted 2026 benchmark for LLM-generated review detection; evaluate on your own labelled sample.
• Regulatory shift: the FTC rule gives the first US per-violation civil-penalty route and treats AI-generated fake reviews explicitly, but exempts mere review hosts from a duty to investigate [1][2]. EU and UK rules put more duties on traders and platforms.
• Limits and failure modes: false positives on genuine enthusiastic or non-native reviewers; adversaries aged accounts and mix real purchases ("review farming with refunds"); differing definitions of "fake" (incentivised vs fabricated); cross-language drift; evidence from public data alone is rarely enough for legal action. Unknown precision at your base rate: always measure with manual audit samples.

Shared resources & combinations

• ANOM-004 (fake accounts, bots): same device/IP graph, risk-scoring service and streaming features; reviewer risk feeds account risk and vice versa.
• ANOM-015 (AI-generated content marking and detection) and ANOM-025/ANOM-028 (related integrity and counterfeit/marketplace abuse): shared text-classifier and embedding infrastructure, takedown workflow.
• LANG-013 (sentiment & feedback analysis): run on the cleaned review set only, otherwise fake reviews distort insights. LANG-038 (review response): shares the review ingestion pipeline.
• ANOM-014 (document forgery & liveness): identity checks for review brokers or verified reviewers where used.
• Shared building blocks: multilingual encoder + embedding service (HW2), gradient-boosting scorer, graph store, workflow engine for moderation queues and appeals; one self-hosted LLM server can also serve rationales, takedown drafts and case summaries.

Effort, cost & KPIs

• Path A: days to a few weeks (configure verification, alerts); subscription-based.
• Path B: 1–3 months for scoring pipeline with moderation queue; cost driven by data engineering and moderator time, API cost for flagged items is small if bulk pass uses cheap models.
• Path C: 2–4 months, one GPU server (HW2) plus MLOps effort.
• Path D: 4–9 months incl. labelling programme; only at platform scale.
• KPIs: precision of removed reviews (from audit sample), estimated prevalence of fakes remaining, time-to-removal, share of campaigns detected before publication, appeal overturn rate, moderator minutes per case, effect on rating trust (verified-review share).

People & change

Involve management for the stance on reviews (what is removed, what is only flagged), the marketing or e-commerce lead as process owner, IT for shop and platform integration and legal for the rules on removing reviews and for consumer-law duties on review authenticity. The DPO should be consulted because reviewer accounts, IP and device data are personal data: check the legal basis, retention and the AVV with any vendor (Art. 28 GDPR). A DPIA is usually not needed for small-scale text screening but becomes likely with large-scale profiling of reviewers.

Works council: depends. If the tool only analyses customer reviews, no staff monitoring occurs and §87(1) no. 6 BetrVG is not triggered; it applies if moderators' work is logged and evaluated or if employee-written reviews are checked. Still inform the works council under §90(1) no. 3 when the process changes.

AI literacy: train moderators on false positives (genuine enthusiastic or very angry customers) and on appeal handling (Art. 4 AI Act supports this). Start with one product category or platform in flag-only mode. Let moderators make every removal decision and give reviewers a way to appeal. Guides: GUIDE-005, GUIDE-009, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk; it is neither an Annex III use case nor an Art. 5 practice. Reclassify if scores are used for employment or credit decisions about reviewers, which is not the intended use. Art. 4 AI literacy applies. If you generate or label synthetic text, Art. 50 transparency may apply in other use cases (ANOM-015).
• GDPR: reviewer data is personal data (account IDs, IP, device, review history); legitimate interest (Art. 6(1)(f)) with balancing test, data minimisation and retention limits; automated removal with legal or similarly significant effect should be avoided, and Art. 22 safeguards (human review, explanation, appeal) built in. Do not scrape and profile private persons beyond need.
• Consumer law: EU Directive 2019/2161 (Omnibus) bans submitting or commissioning fake reviews and requires information on whether and how a trader ensures reviews come from real consumers; in Germany implemented in UWG and PAngV. The UK DMCC Act (in force April 2025) and the US FTC rule [1][2] add penalties. The EU Digital Services Act adds notice-and-action and trader-traceability duties for marketplaces; very large platforms have systemic-risk duties.
• Risks: wrongful removal of genuine criticism (defamation and censorship claims, loss of trust), accusing a competitor on thin evidence, bias against non-native speakers, adversarial adaptation. Mitigations: multiple evidence types, thresholds that route to humans, transparent policy, appeal route, documented audits.

Getting started

1. Define "fake" for your context (fabricated, incentivised, insider, competitor sabotage) and label 500–1,000 reviews manually as a baseline.
2. Collect verified-purchase links and reviewer metadata; add simple bursts, duplicate and account-age features and measure a LightGBM baseline.
3. Add an embedding-based near-duplicate check and an LLM triage pass for flagged items only; keep rationales short and auditable.
4. Set the moderation workflow: thresholds, human review, notice and appeal text, takedown evidence template.
5. Check your own review-collection practices against the FTC/Omnibus rules [1][2] and review precision monthly with an audit sample.

Sources

Accessed 2026-10. Search tools were limited during research, so only the following were opened directly; legal statements on the EU Omnibus Directive, UK DMCC Act and DSA come from the official texts known to the author and should be re-verified on EUR-Lex and gov.uk before publication. 1. FTC — Trade Regulation Rule on the Use of Consumer Reviews and Testimonials (final rule, Federal Register, 22 Aug 2024) — https://www.federalregister.gov/documents/2024/08/22/2024-18519/trade-regulation-rule-on-the-use-of-consumer-reviews-and-testimonials 2. FTC — 16 CFR Part 465, Consumer Reviews and Testimonials (eCFR) — https://www.ecfr.gov/current/title-16/chapter-I/subchapter-D/part-465 3. Trustpilot — Trust and transparency (fake review detection statistics) — https://corporate.trustpilot.com/trust 4. Ott, Choi, Cardie, Hancock — Finding Deceptive Opinion Spam by Any Stretch of the Imagination — https://arxiv.org/abs/1107.4557 5. Hugging Face Transformers — https://github.com/huggingface/transformers 6. European Commission — Unfair Commercial Practices Directive and guidance (incl. consumer reviews) — https://commission.europa.eu/law/law-topic/consumer-protection-law/unfair-commercial-practices-law/unfair-commercial-practices-directive_en