Evolution of 58.com Risk Control Architecture: From Early Stages to Intelligent Auditing

Guest: Zhang Yue, Risk Control Architect at 58.com (DataFunTalk, AI Initiator)

Editor: Huang Leping

Platform: DataFunTalk, AI Initiator

Introduction: Since 2010, 58.com has built a risk control platform that became an essential middle‑platform serving billions of daily data points. The presentation analyzes risk governance across different business lines and eras, illustrating how various platforms were built.

58 Doing Risk Control – Origin

58.com is a classified information platform centered on content and traffic, serving two major user groups: B‑side (suppliers) who produce content and C‑side (consumers) who use it. Both sides face problems such as fraud, “wool‑party” abuse, fake orders, forged documents, invoice fraud, WeChat fan‑hunting, advertising spam, and other abnormal traffic behaviors.

Key Problems:

Fraud is the most severe issue; despite a decreasing number of incidents due to stricter regulation, individual losses have risen because fraud tactics become more sophisticated.

“Wool‑party” groups exploit marketing bugs (e.g., large‑scale coupon giveaways) causing massive financial losses.

Fake orders (刷单) are used either to boost e‑commerce metrics or as a fraud channel.

Gray‑area activities such as forged seals, illegal invoicing, and document falsification.

WeChat fan‑hunting via fake listings to attract users.

Advertising spam that mimics normal user behavior, making detection difficult.

58 Risk Control Development Process

The evolution consists of four stages:

Stage 1 – Prototype: tiny business, closed system.

Stage 2 – Development: modest business, enhanced operations.

Stage 3 – Mid‑platform transformation: capability reuse, business autonomy.

Stage 4 – Ecosystem construction: service‑oriented thinking.

Stage 1: Small‑scale Machine Review + Manual Review

Early platform services (information posting, enterprise listings, resume posting) relied on a combination of manual review and limited machine review. Content passed through online detection, then split into offline detection or manual review, with results merged for final action. To stay ahead of black‑market actors, the team infiltrated illicit groups and purchased underground tools to discover vulnerabilities.

Problems Exposed: Hard‑coded rules caused high development cost and slow policy rollout, unable to keep pace with rapidly evolving fraud techniques.

Stage 2: Configurable Machine Review + Manual Review

Building on Stage 1, this phase introduced a strategy layer based on features, rules, and regulations, and added algorithms for image, text, and behavior clustering. Three core modules emerged: feature‑development platform, operable strategy management, and centralized risk handling.

Problems Exposed:

Duplicate risk systems after the 58‑Ganji merger increased maintenance cost.

Rapidly growing risk scenarios raised technical and operational expenses.

Competitive pressure from peer risk platforms forced knowledge borrowing.

Shift toward a mid‑platform model required organizational changes.

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

This stage introduced three major capabilities:

Self‑service development – enabling business teams to co‑develop risk tools, test, deploy, and launch independently.

One‑stop operation – providing a complete operation suite, rapid business registration, and reusable components for new scenarios.

Business isolation – separating risk models per business, micro‑service decomposition, and adding circuit‑breaker and degradation mechanisms.

The result was millisecond‑level response times, support for thousands of business scenarios, coverage of all content services, a cluster of ten‑thousand nodes, and offline analysis at the hundred‑billion level.

Stage 4: Expert‑Driven, Intelligent Auditing (In‑Progress)

Future plans focus on:

Further isolation of databases, manual review systems, and configuration centers.

Algorithm‑centric automation to continuously raise the system’s self‑operating level.

Overall, risk control capability still has ample room for improvement, demanding strong technical reserves, cross‑functional collaboration, and rapid iteration to meet high‑concurrency, high‑availability requirements.

Q&A

1. Example of a 58.com black‑market attack‑defense case? The team faced a large‑scale housing‑listing abuse where bots posted massive fake entries. Detection relied on deviations in posting patterns and lack of genuine user behavior. Countermeasures evolved from simple captcha to sophisticated human‑machine interaction checks and group‑behavior analysis.

2. Current risk control architecture? The top layer is the business layer (information, enterprise listings, resumes, live streaming, etc.). Each business gets a one‑stop operation platform with tools, processing pipelines, and manual review layouts. Underneath, shared services provide risk processing, data enrichment, behavior clustering, text and image algorithms.

3. How does the risk team collaborate with business units and measure ROI? Initially, risk was a siloed function causing friction (e.g., perceived over‑blocking). By building a mid‑platform and sharing responsibility, cooperation improved. ROI is measured via online data inspection, analytics from the data team, third‑party metrics, and appeal feedback.

Thank you for listening.