Evolution and Architecture of Risk Control at 58.com

58.com operates a classified‑information platform that serves both supply‑side (B‑users) and demand‑side (C‑users). The platform constantly faces fraudulent activities such as scams, “wool‑party” abuse, fake orders, invoice fraud, mass posting, and advertising spam.

Why 58.com Started Risk Control

The platform’s rapid growth generated massive non‑normal traffic, prompting the need for a dedicated risk‑control system to safeguard billions of daily data points.

Stage 1: Prototype – Small‑scale Business, Closed System

Manual review combined with limited machine screening.

Two parallel paths after online detection: offline detection and human review.

Problems: hard‑coded rules, high development cost, and slow response to black‑market attacks.

Stage 2: Configurable Automation + Manual Review

Introduced feature‑based rules, text and image algorithms, and behavior clustering.

Three core modules: feature development platform, operable policy management, and centralized risk handling.

Problems: duplicated risk systems after the 58‑Ganji merger, rising operational cost, and pressure from competing platforms.

Stage 3: Fusion of Machine and Human Review, Scenario‑Based Governance

Self‑service development for business teams.

One‑stop operation platform providing tools, testing, deployment, and launch capabilities.

Business isolation through micro‑service separation, circuit‑breaker, and downgrade mechanisms.

Achieved millisecond‑level response, support for thousands of business scenarios, and petabyte‑scale offline analysis.

Stage 4: Expert‑Driven, Intelligent Auditing (Future Planning)

Further isolation of databases, human review, and configuration centers.

Shift to algorithm‑centric automation to raise system self‑operation levels.

Q&A Highlights

1. Example of a black‑market attack: High‑traffic real‑estate listings were posted in bulk using automated scripts; detection relied on abnormal posting patterns, captcha challenges, and behavior‑sequence analysis.

2. Current risk‑control architecture: A top‑level business layer (58 information, enterprise posts, resumes, etc.) feeds into a unified operation platform offering tools, risk‑processing pipelines, data enrichment, clustering, and AI models (text, image).

3. Collaboration with business units: Early friction over false‑positive rates was mitigated by building a middle‑platform that shares responsibility, using data audits and multi‑party feedback to calculate ROI.

In summary, 58.com’s risk‑control capability has evolved through four distinct phases, each addressing emerging fraud tactics and scaling requirements, while emphasizing cross‑functional cooperation and continuous algorithmic improvement.

Thank you for listening.