GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!
Watch the launch videoWatchMarketplace 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:
- Risk Factor Calculation: Computes key metrics including price deviation percentage, seller credibility scores, and category sensitivity indicators.
- Brand Authentication: Verifies if the brand belongs to a high-value category and compares pricing against market averages.
- Seller Evaluation: Analyzes seller history including account age, previous violations, and feedback rating.
- Risk Level Assignment: Applies decision rules to determine if the listing presents high, medium, or low risk based on combined factors.
- 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.
Request
inputThree 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
}
}Calculate Risk Factors
expressionRaw 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.
abs((listing.price - category.averagePrice) / category.averagePrice * 100)contains(['luxury', 'electronics', 'collectibles', 'designer'], category.type)contains(category.highValueBrands ?? [], listing.brand)seller.rating < 4.0seller.accountAgeDays < 90seller.previousViolations > 0Evaluate Risk Level
tableRisk 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.
| Brand Risk | Price Risk | Seller Risk | Risk LevelriskAssessment.level | Risk ReasonriskAssessment.reason |
|---|---|---|---|---|
| isHighValueBrand == true | priceDeviationScore > 30 | hasPreviousViolations == true | 'high' | 'Suspicious pricing for high-value brand with history of violations' |
| isHighValueBrand == true | priceDeviationScore > 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 == true | isSensitiveCategory == true | - | 'medium' | 'New seller listing sensitive category items' |
+2 more rows in the downloadable template
Determine Action
tableVerification 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.
| Risk LevelriskAssessment.level | Requires Verificationverification.required | Verification Typeverification.type | Verification 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' |
Other Retail templates
View all templatesSeller Approval Workflow
Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards.
RetailDynamic Marketplace Commission Calculator
Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods.
RetailProduct Listing Scoring
Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors.
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.