How Robust Risk Admission Strategies Power Platform Safety and Growth

1. Background

Risk‑control admission strategies serve as the first gate for evaluating whether drivers and passengers meet platform standards, forming the foundation for a fair supply‑demand relationship and ensuring safety. Admission is part of the broader risk‑control system, encompassing basic authentication, eligibility policies, background checks, and blacklist databases, primarily driven by product policy rules.

Before discussing admission, basic authentication must be addressed. This module verifies personal information—such as ID, facial data, bank‑card four‑element verification, and telecom three‑element verification—using widely accepted rules. Only after successful authentication does the system proceed to the admission module, which includes age, region, industry, and other criteria based on regulatory policy guidance.

Admission rules act like skin, the first line of defense in the overall risk workflow. Although many platforms now share similar, mature admission policies, the focus has shifted to fraud detection, blacklists, and credit strategies. Nevertheless, fine‑tuning admission thresholds remains crucial for risk mitigation, influencing business direction and fostering a stable ecosystem.

2. Solution

2.1 Architecture Overview

The architecture comprises client applications and a suite of operational tools covering franchising, deposits, invitations, vehicle subsidies, vehicle admission, behavior scoring, and other key modules, all unified through a person‑vehicle qualification verification service.

Admission architecture diagram:

The application layer includes operational tools and client apps, forming an operation‑configuration platform that manages evolving product configuration items. Three key points are emphasized:

Stability: From a backend perspective, the system must remain available under all conditions, with graceful degradation if failures occur.

Efficiency: The system should be user‑friendly for operators, avoiding direct SQL or database manipulation while supporting diverse scenarios.

Flexibility: As product requirements evolve, the platform must adapt to varied business needs.

To handle complex business demands, a simple yet flexible design is adopted. For example, data storage uses JSON format for dynamic key/value updates, complemented by a field‑management workflow that combines data and UI controls to render dynamic interfaces.

2.2 Business Systems

The core business system is divided into three major modules: person admission, vehicle admission, and exit platform.

Typical business modules are explored in detail later.

3. Order‑Cancellation Control

3.1 Control Objectives

Improve responsibility‑determination accuracy and driver experience.

Provide efficient responsibility‑handling capabilities for operators.

Enable traceable responsibility data to accelerate strategy optimization.

3.2 Responsibility Process & Solution

To ensure timely responsibility decisions during order peaks, the strategy reduces decision time to the minute level while guaranteeing strong data consistency. An AB‑order responsibility pipeline is employed, using the Pipeline design pattern to pass data through a sequence of processing stages, allowing dynamic filter addition and flexible handling of both new and legacy data.

Pipeline Model

4. Franchise & Invitation

4.1 Overview

Invitation business flow diagram:

4.2 Solution Practice

The solution leverages Elasticsearch (ES) for filtering, searching, and ranking in invitation and training scenarios, which involve complex query conditions. Compared with Solr, ES offers a richer ecosystem, simpler style, and built‑in distributed management.

Key differences:

Real‑time indexing in Solr can cause I/O blocking, whereas ES does not, resulting in higher query performance.

When dynamically adding data, Solr’s retrieval efficiency degrades, while ES remains stable.

Solr relies on Zookeeper for distributed management and typically runs on web servers like Tomcat; ES includes native distributed management.

Solr supports multiple data formats (XML, JSON, CSV); ES primarily supports JSON.

Solr excels in traditional search applications; ES is better suited for real‑time search needs.

For static data retrieval, Solr may be faster; for real‑time search, ES outperforms.

Current business data can be categorized into three types:

Structured data: fixed‑format data such as databases and metadata.

Unstructured data: free‑form content like emails and Word documents.

Semi‑structured data: less common, e.g., XML.

5. Qualification Verification

Qualification verification is crucial for setting platform entry thresholds, supporting data services, and improving operational efficiency. The “Tianyan” component provides strong risk‑control guarantees through background checks, real‑name verification, OCR, and facial recognition during driver registration. Architecture diagram:

6. Summary

Comprehensive admission is the cornerstone of a platform’s operational ecosystem, encompassing franchising, invitation, training, and control services. By integrating facial recognition, three‑element verification, and OCR, it significantly enhances both user experience and risk safety. Future developments will incorporate custom AI services—such as proprietary facial‑recognition algorithms—to deliver more precise and reliable admission, further strengthening ecosystem stability.