How Ziroom’s Risk Control Platform Detects and Prevents Account Fraud

Background

After launching the tenth‑season “Seagull Plan”, Ziroom discovered that many non‑returning users could not be contacted for overdue payments because the occupant and the contract signer were inconsistent, creating bad‑debt and legal compliance risks.

Business Risk Analysis

Case studies and third‑party platform tracking revealed two main fraud scenarios:

Scenario 1: Verified accounts are sold to a third party, which then resells them (see Fig 1).

Scenario 2: Overseas degree certificates are forged to fake foreign student identities and pass qualification checks.

Fig 1: Core process of account resale.

Risk‑Control Platform Design

The platform is built around business scenarios such as marketing activities, offline operations, anti‑scraping, and UGC content safety. It ingests behavior‑tracking data, basic user info, and third‑party risk databases, feeding them into a decision engine that performs real‑time, asynchronous, or offline analysis to output risk judgments, scores, and mitigation suggestions (see Fig 2).

Fig 2: Technical architecture of the risk‑control platform.

What Is a Decision Engine?

A risk decision engine abstracts complex business logic into combinable rules, scoring cards, models, and expressions, executing layered calculations to produce a final decision.

Traditional engines handle simple rule checks (e.g., gender‑based access). Modern engines support richer constructs—rules, scorecards, models, expressions—allowing hierarchical logic suitable for internet‑scale services. Advanced engines integrate NLP and stream‑processing platforms to boost compute power and latency, typically offering modules for rules, risk scoring, models, expressions, and decision flows.

Fig 3: Decision‑engine workflow diagram.

Decision‑Engine Computing Modes

Both offline and real‑time/async modes are required. For example, “new‑user assistance” combines registration, login, rental history, and property‑viewing behaviors to detect “coupon‑abuse” or other gray‑market activities. When a risk is discovered later, historical data must be re‑processed, and rule strategies updated—tasks best handled offline.

Solution Approach for “Seagull” Fraud

The platform strengthens authentication, signing, and occupancy stages, focusing on using the decision engine to label existing risky users.

Raw Business Data Analysis

Historical logs show that anomalous users frequently change phone numbers, switch numbers before signing, log in from disparate locations, and lack valid property‑view or rental actions.

Feature Extraction

From business‑tracking data, features such as signing identity, signing time, login location, and phone‑number change count are derived.

Rule‑Strategy Formulation

Using extracted features, logical operators, thresholds, and time windows, rules are crafted. Example plaintext rules:

30‑day phone‑number change count > n; Historical property‑view count < n; …

Offline Hit‑Data Analysis

After deploying the new risk rules, the proportion of risky legacy users dropped significantly, confirming the effectiveness of the risk‑control measures.

Fig 4: Proportion of risky legacy users.

Conclusion

The decision‑engine is still being codified, moving toward configuration‑driven and automated stages, while integrating deeper risk capabilities such as account‑risk detection, device‑risk detection, scoring, feature engines, and tiered disposition, to empower more business scenarios.