Read this article with AI
Copy the article text into your chosen tool to inspect its sources and trade-offs.
Classify the harm, not just the profile
“Fake account” can describe several different problems: a newly registered spam profile, an impersonator, a seller using false claims or an unauthorized operator inside an established account. They should not all receive the same automatic response.
Begin with the reported harm and the event involved. A misleading listing needs content and transaction evidence. An account takeover needs recovery and access review. A disputed delivery needs fulfillment records. This distinction helps moderators request relevant material instead of collecting an unnecessary identity dossier.
| Case | Evidence to inspect | Possible owner |
|---|---|---|
| Impersonation | Claimed identity and misleading profile content | Trust and safety |
| Seller misconduct | Listing, messages and transaction history | Marketplace operations |
| Account takeover | Access and sensitive-change history | Security and support |
| Review manipulation | Reviewer relationships and qualifying activity | Review integrity team |
| Payment abuse | Provider and order events | Payments team |
Link events without collapsing accounts into people
Device, network and account associations can reveal useful patterns. Keep the kind of relationship visible: same environment, same contact detail or related transaction. These are different claims, with different uncertainty.
A hypothetical apartment building has buyers sharing a public Wi-Fi address. A network match should not merge their identities. Repeated seller-benefit claims linked through stronger account and transaction evidence can warrant a different review.
Use multi-accounting detection tools to evaluate relationship evidence. For abuse after a moderation action, see ban evasion detection, including its appeal and evidence limits.
Tie review privileges to marketplace activity
Define what makes a review eligible under your platform rules. If a completed purchase is required, check that record on the server rather than accepting a client’s claim. Keep canceled, refunded and disputed transactions distinguishable when policy depends on their status.
Account relationships can support investigation of coordinated reviews, but similar opinions or timing alone do not prove payment or control. Preserve the relevant posts, qualifying events and moderation reasons so a human can assess the pattern.
OWASP’s automated-threat project provides a broader framework for misuse of application functions. A marketplace still needs its own definitions of allowed behavior and sanctions.
Protect seller changes that redirect value
Changing payout information, account recovery details or access permissions can have a larger impact than editing a public profile. Apply appropriate authentication and review at these sensitive actions. OWASP’s Authentication Cheat Sheet discusses risk-aware reauthentication.
Do not let a positive signup verdict grant permanent trust. A real seller account can be compromised later. The account takeover signals guide follows the session beyond login.
Design an understandable case queue
Give each case a policy category, event timeline, supporting evidence, owner and due state. Keep automated suggestions distinguishable from moderator findings. Reviewers should be able to request missing evidence or mark a case unresolved.
An appeal should identify the action being challenged and the information that could change it. Support staff need a practical resolution route, not an instruction to tell every customer that an unnamed algorithm decided.
For external social impersonation or phishing sites outside your platform, use the brand impersonation and takedown workflow. Internal moderation cannot remove content hosted by another service.
Measure trust outcomes by case type
Track confirmed misconduct, account recoveries, appeal outcomes, repeat incidents and time to resolution. Keep payment loss separate from content removals. Counting every removed profile as a prevented transaction loss would overstate the result.
Run a pilot on one case type with a known policy and review owner. Expand only after the marketplace can show both how abuse was handled and how legitimate users were protected from mistaken enforcement.
FAQ
Does a shared device prove profiles are fake?
No. Shared environments can be legitimate. Review the relationship with behavior, policy and transaction evidence.
Can fraud software replace marketplace moderation?
It can supply signals and workflow support, but policy interpretation, customer resolution and external reporting still need owners.
Is every suspicious review a payment-fraud case?
No. Review manipulation and payment abuse can overlap, but they have different qualifying events and evidence needs.
Sources
Editorial basis: primary-source documentation and a practical evaluation framework. Examples are hypothetical unless explicitly identified otherwise. This article does not report an independent vendor benchmark.
For evaluation standards and corrections, see our methodology and contact page.