Understanding Feature Engineering for Risk Control Systems and Building an Easy-to-Use Feature Platform

1. Concept of Features

In traditional expert rule systems, the term "variable" was used for model inputs, but with the rise of machine learning the term "feature" has become the standard name for input variables. This article adopts "feature" as the unified term.

1.1 Feature, Variable, Metric

Variables refer to generic inputs, while metrics carry strong business meaning (e.g., blood‑pressure metric, credit metric). In the tech domain, metric platforms are considered a higher‑level BI product, moving from static reporting to metric‑centric intelligent data usage.

1.2 Features in Risk‑Control Systems

Bank risk control is the core of banking business management, using strategies, processes, and technologies to prevent, identify, assess, and control various risks across the entire loan lifecycle (pre‑loan, in‑loan, post‑loan), anti‑fraud, and security operations. Features are the data representations that support risk‑control models.

The bank’s internal features can be roughly divided into several categories (illustrated in the figure below).

1.3 Pain Points of Real‑Time Feature Engineering

The main difficulties are high feature development complexity and deployment challenges, such as feature leakage, inconsistencies between offline and online logic, and the need to translate Python code to SQL for production. Monitoring is insufficient and sharing/reuse is hard.

Another issue is offline back‑tracking: balancing stability and cost when restoring historical features, often requiring periodic data backups or limited‑rate API calls with strict monitoring.

2. How to Build an Easy‑to‑Use Feature System

2.1 Positioning of a Feature Platform and Supply‑Demand Relationship

The platform’s purpose is to process features and provide them to risk‑control systems and machine‑learning platforms. Feature delivery can follow three patterns (illustrated below).

A Method: Not commonly adopted because it fetches all external data in advance, leading to high operational costs.

B and C Methods: Split the model according to data cost, significantly reducing operational expenses. B may increase risk‑control system load; switching between B and C without justification is discouraged due to extensive model reconstruction and testing overhead.

2.2 Scenario Support of the Feature Platform

2.2.1 Business and Functional Positioning

The platform should include credit features, third‑party external data, internal enterprise data, and graph data, and provide drag‑and‑drop, low‑code, or DSL (dynamic scripting language) capabilities for agile iteration.

2.2.2 Demand for Rich Processing Capabilities

When calling anti‑fraud models, business systems often set fallback mechanisms. Similarly, external data acquisition during feature computation may encounter failures. According to the decision scenario, three support modes are described:

Real‑time decision support: Prioritizes performance; failures can be tolerated with degradation strategies.

Near‑real‑time decision support: Emphasizes accuracy; retries and circuit‑breakers are used to ensure data reliability.

Offline decision support: Combines real‑time data with batch processing for post‑loan, collection, and credit‑limit management.

2.3 Ways to Compute Features

Real‑time computation: The feature engine pulls data and calculates results on demand (read‑time modeling). It offers fresh data with low engineering complexity but limited concurrency.

Pre‑computation: Features are calculated proactively when business events occur, then stored for later use. This can suffer if the pre‑computed result is not ready when requested.

Batch computation: Suitable for data that changes slowly; offline batch jobs provide high precision without real‑time noise, though the latest data may be missing.

Hybrid computation: Combines the above methods to meet cost and utility requirements for different scenarios.

2.4 Common Open‑Source and Commercial Feature Platforms

The author shares a comparative image of several platforms that can serve as references for building a feature system.

This diagram can help enterprises planning a feature platform.

3. Long‑Term Outlook

Feature computation ultimately serves API interfaces and data sources; function‑as‑a‑service is an ideal model.

A good feature platform must integrate credit systems, external data sources, and internal enterprise data, support both risk‑control and machine‑learning models, enable online‑offline integration, agile releases, comprehensive management, governance, and configurable feature processing.