v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch

Marketplace Listing Verification System

Automated risk assessment system that flags suspicious marketplace listings based on brand authenticity, pricing anomalies, and seller credibility factors.

Solution

This marketplace verification system protects buyers and platform integrity by automatically identifying high-risk listings that require manual review. The system evaluates multiple risk signals including price deviation from market averages, seller reputation metrics, account history, and category sensitivity. For luxury and high-value items, it verifies brand authenticity against known premium labels and flags suspicious underpricing that could indicate counterfeit merchandise.

Listings are assessed against seller credibility factors including feedback rating, account age, and previous policy violations. The system assigns risk levels based on combinations of these factors, with more severe flags triggered when multiple risk indicators appear together. Each flagged listing receives specific verification requirements - either immediate manual review for high-risk cases or batch verification for medium-risk items - ensuring marketplace quality while maintaining operational efficiency.

How it works

The decision graph evaluates listings through a sequential risk assessment process:

  1. Risk Factor Calculation: Computes key metrics including price deviation percentage, seller credibility scores, and category sensitivity indicators.
  2. Brand Authentication: Verifies if the brand belongs to a high-value category and compares pricing against market averages.
  3. Seller Evaluation: Analyzes seller history including account age, previous violations, and feedback rating.
  4. Risk Level Assignment: Applies decision rules to determine if the listing presents high, medium, or low risk based on combined factors.
  5. Verification Routing: Routes high-risk listings for immediate manual review, medium-risk listings to batch verification queues, and approves low-risk listings automatically.

Where teams use it

  • Luxury goods marketplaces
  • Electronics and technology resale platforms
  • Collectibles and rare item exchanges
  • Designer fashion marketplaces
  • Multi-vendor retail platforms
  • Auction and bidding sites
  • Peer-to-peer selling applications
  • Global commerce platforms with third-party sellers

Inside the decision model

Marketplace Listing Verification System ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine.

Decision graph4 nodes · read-only
input requestexpression calculateRiskFactorstable evaluateRiskLeveltable determineAction
01

Request

input

Three request blocks feed the assessment: listing with its brand, price, and condition, category with type, averagePrice, and the highValueBrands list, and seller with rating, accountAgeDays, and previousViolations. Every downstream risk factor derives from these fields.

Sample requestJSON
{
  "listing": {
    "id": "LIST12345",
    "title": "Designer Handbag - Limited Edition",
    "brand": "LuxuryBrand",
    "price": 950,
    "condition": "New",
    "description": "Authentic designer handbag, limited edition, comes with certificate"
  },
  "category": {
    "id": "CAT789",
    "type": "luxury",
    "name": "Designer Handbags",
    "averagePrice": 1500,
    "highValueBrands": [
      "LuxuryBrand",
      "PremiumDesigner",
      "ExclusiveFashion"
    ]
  },
  "seller": {
    "id": "SELL456",
    "name": "FashionReseller",
    "rating": 3.8,
    "accountAgeDays": 45,
    "previousViolations": 1,
    "listingsCount": 27
  }
}
02

Calculate Risk Factors

expression

Raw signals become named booleans and one number before any rules run: priceDeviationScore is the absolute percentage gap between listing.price and category.averagePrice, isSensitiveCategory checks category.type against ['luxury', 'electronics', 'collectibles', 'designer'], and isHighValueBrand looks the brand up in category.highValueBrands. Three seller flags complete the set: hasLowRating for ratings under 4.0, isNewSeller for accounts under 90 days, and hasPreviousViolations for any violation on record, so the risk table can combine plain flags instead of repeating arithmetic.

Expressions6 fields
priceDeviationScoreabs((listing.price - category.averagePrice) / category.averagePrice * 100)
isSensitiveCategorycontains(['luxury', 'electronics', 'collectibles', 'designer'], category.type)
isHighValueBrandcontains(category.highValueBrands ?? [], listing.brand)
hasLowRatingseller.rating < 4.0
isNewSellerseller.accountAgeDays < 90
hasPreviousViolationsseller.previousViolations > 0
03

Evaluate Risk Level

table

Risk levels come from combining those flags under a first hit policy. The two 'high' rows both require isHighValueBrand with priceDeviationScore > 30, with and without hasPreviousViolations; the 'medium' rows then cover a high-value brand with a violation history, a priceDeviationScore > 40 on its own, sellers with 'Multiple previous seller violations', and isNewSeller or hasLowRating paired with isSensitiveCategory. The blank fallback row assigns 'low' with 'Standard risk level', and each hit writes both riskAssessment.level and a human-readable reason.

A recognized luxury label priced 30 percent or more away from category.averagePrice is the classic counterfeit signal in brand-name resale, which is why that combination alone reaches 'high' while a 40 percent deviation on an unbranded item only reaches 'medium'. Pairing account age and rating with category sensitivity also reflects where fraud actually concentrates, since new or poorly rated sellers in luxury and electronics are the usual entry point, and single weak signals stay below the review threshold to keep false positives down.

Decision tablefirst hit policy
Brand RiskPrice RiskSeller RiskRisk LevelriskAssessment.levelRisk ReasonriskAssessment.reason
isHighValueBrand == truepriceDeviationScore > 30hasPreviousViolations == true'high''Suspicious pricing for high-value brand with history of violations'
isHighValueBrand == truepriceDeviationScore > 30-'high''Suspicious pricing for high-value brand'
isHighValueBrand == true-hasPreviousViolations == true'medium''High-value brand with seller violation history'
-priceDeviationScore > 40-'medium''Significant price deviation from market average'
--hasPreviousViolations > 2'medium''Multiple previous seller violations'
isNewSeller == trueisSensitiveCategory == true-'medium''New seller listing sensitive category items'

+2 more rows in the downloadable template

04

Determine Action

table

Verification workload is routed by a three-row first hit table on riskAssessment.level: 'high' sets verification.required to true with type 'manual', 'medium' also requires verification but through the 'batch' queue, and 'low' sets required to false with type 'none'. Each row carries a verification.message explaining the outcome.

Reserving immediate manual review for 'high' risk while batching 'medium' cases is standard trust-and-safety operations, since reviewer time is the scarce resource and batch queues keep coverage on mid-risk listings without blocking their publication. Auto-approving 'low' risk keeps the vast majority of listings flowing with no added friction.

Decision tablefirst hit policy
Risk LevelriskAssessment.levelRequires Verificationverification.requiredVerification Typeverification.typeVerification Messageverification.message
'high'true'manual''High risk listing requires immediate manual verification'
'medium'true'batch''Medium risk listing added to batch verification queue'
'low'false'none''No verification required'

Make this template
your own.

Load Marketplace Listing Verification System into GoRules, adjust the rules to your policy, and ship it behind your own API.