Hierarchical Risk Identification for Service Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The increasing complexity of risk scenarios in network business services leads to higher system resource consumption and computational time in risk monitoring systems, necessitating a more efficient risk monitoring method to improve risk analysis performance.

Innovation Solution

A hierarchical risk identification method is implemented, where fast risk identification uses less data and time, and deep risk identification is performed only when necessary, with comprehensive risk identification being performed asynchronously to optimize the entire risk identification algorithm, reducing system resource consumption and improving accuracy.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If deep risk identification is performed on all service processing requests, then risk identification accuracy is improved, but system resource consumption and processing time increase significantly

Engineering Contradiction:
Improverisk identification accuracyVSAvoidservice processing throughput
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The risk identification system is segmented into two distinct layers: a fast risk identification layer that processes all requests quickly with basic algorithms, and a deep risk identification layer that performs comprehensive analysis only on requests flagged as potentially risky by the fast layer. This segmentation allows the system to maintain high throughput for normal requests while ensuring thorough risk analysis for suspicious cases.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Instead of performing complete deep risk identification on all requests, the system applies partial action by using simplified fast identification algorithms for routine requests and reserving resource-intensive deep identification algorithms only for requests that require additional scrutiny based on risk indicators detected by the fast layer.

Inventive Principle:
Principle #16Partial or excessive action

2Reliability

If more rule models are used for risk identification, then risk monitoring coverage is improved, but computational complexity and system resource consumption increase

Engineering Contradiction:
Improverisk monitoring coverageVSAvoidsystem computational complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The rule models are segmented and organized into two categories corresponding to the two identification layers: simple rule models for fast risk identification that can be evaluated quickly, and complex rule models for deep risk identification that provide comprehensive coverage but require more computational resources. The system selectively applies appropriate rule model sets based on the risk assessment needs.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system applies partial action by not deploying all complex rule models simultaneously for every request. Instead, it uses a subset of lightweight rule models for fast identification and only invokes the full set of comprehensive rule models when the fast layer identifies potential risks, thus achieving complete risk coverage without constantly bearing the full computational burden.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS11252197B2Service processing method and apparatus
Publication Date: 2022.02.15 ADVANCED NEW TECHNOLOGIES CO LTD
  • US11252197B2 patent drawing
  • US11252197B2 patent drawing
  • US11252197B2 patent drawing

AI summary

User data from a received service processing request initiated by a user for processing a service is parsed. Whether the user data is included in a trusted user list or a risky user list stored in a server for processing the service is determined. Whether the user data matches historical behavior data associated with the user based on a behavioral profile comparison rule model if the user data is not included in the trusted user list or the risky user list is determined. A risk type associated with the user data is determined if the user data fails to match the historical behavior data. A risk identification rule model associated with the risk type is determined based on the service requested. Risk identification is performed based on the user data using the determined risk identification rule model. The service is processed by the server based on a result of the risk identification.