Abnormality processing method and device, electronic equipment and computer readable medium
By determining the risk control type identifier and business identifier, obtaining and verifying core module data to identify and handle business operation anomalies, the problems of low efficiency and low accuracy in existing technologies are solved, and more efficient exception handling is achieved.
Patent Information
- Application Number
- CN202410288375.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-03-13
- Publication Date
- 2025-09-19
AI Technical Summary
The efficiency and accuracy of anomaly identification and processing in existing business operations are low, resulting in increased operating costs and losses.
By responding to the exception handling request, determining the risk control type identifier and business identifier, determining the risk control processing core module and calling sequence based on the risk control type identifier, obtaining the corresponding core module data, and performing risk control verification to determine the business operation abnormal node and abnormal type.
It improves the efficiency and accuracy of anomaly identification and processing during business operations and reduces operating costs.
Smart Images
Figure CN120671022A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to an exception handling method, device, electronic device, and computer-readable medium. Background Art
[0002] Currently, various fraudulent operations occur during business operations, such as: frequent dispatch of small vehicles in the same wave (sending multiple small vehicles when a single large vehicle should be dispatched), virtual positioning (operational requirements require vehicles to be dispatched within an electronic fence, but drivers use virtual positioning software to modify their locations), and unreasonable billing (reserving or receiving a small vehicle but being charged for a large vehicle). These fraudulent operations increase operating costs and even cause losses. Identifying and handling anomalies that may arise during business operations is inefficient and inaccurate. Summary of the Invention
[0003] In view of this, the embodiments of the present application provide an exception handling method, device, electronic device and computer-readable medium, which can solve the problems of low efficiency and low accuracy in identifying and handling exceptions that may occur during business operations.
[0004] To achieve the above objectives, according to one aspect of an embodiment of the present application, a method for handling an exception is provided, comprising:
[0005] In response to the exception handling request, determine the corresponding risk control type identifier and business identifier;
[0006] Based on the risk control type identifier, determine the corresponding risk control processing core module and calling sequence;
[0007] Obtain data source configuration information for the core risk control processing module based on the business identifier;
[0008] Based on the calling sequence, the corresponding risk control processing core module is called to obtain the corresponding core module data according to the data source configuration information;
[0009] Perform risk control checks based on core module data to determine abnormal business operation nodes and abnormal types.
[0010] Optionally, determine the corresponding risk control processing core modules and call sequence, including:
[0011] Determine the corresponding risk control processing flow based on the risk control type identifier;
[0012] According to the risk control processing flow, determine the core risk control processing modules involved and determine the order in which the core risk control processing modules are called.
[0013] Optionally, determine the order in which the risk control processing core modules are called, including:
[0014] Determine the data dependencies of the core risk control modules based on the risk control process;
[0015] Determine the order of calling the core risk control processing modules based on data dependencies.
[0016] Optionally, determine the corresponding risk control process, including:
[0017] In response to the risk control type identifier corresponding to scheduled risk control, the corresponding risk control processing flow is determined as follows:
[0018] After detecting that the timer risk control receiver receives the timer trigger signal, it calls the timer risk control data processing service to obtain the risk control model information and passes it to the risk control model configuration service;
[0019] Call the risk control model configuration service to obtain model configuration data based on the risk control model information;
[0020] Based on the data source configuration information, the scheduled risk control data processing processor is called to automatically obtain business operation data;
[0021] Send business operation data, risk control model information, and model configuration data to the asynchronous message queue;
[0022] Call the asynchronous message service to consume each asynchronous message in the asynchronous message queue to perform risk control verification, and then determine the abnormal nodes and abnormal types of business operations.
[0023] Optionally, determine the corresponding risk control process, including:
[0024] In response to the risk control type identifier corresponding to scheduled risk control asynchronous execution or real-time risk control, the corresponding risk control processing flow is determined as follows:
[0025] Call the risk control analysis service to obtain the incoming business operation data, risk control model information, and model configuration data, and then call the risk control indicator configuration service to obtain indicator configuration data based on the risk control model information;
[0026] Call the corresponding risk control indicator processing processor according to the indicator configuration data to obtain the indicator value;
[0027] Call the risk control rule configuration service to obtain the corresponding risk control rule configuration data based on the risk control model information;
[0028] Call the risk control engine to calculate whether to trigger risk control based on business operation data, model configuration data, indicator values, and risk control rule configuration data, and call the risk control result service after risk control is triggered to determine the business operation abnormal node and abnormal type.
[0029] Optionally, call the risk control rule configuration service to obtain corresponding risk control rule configuration data based on the risk control model information, including:
[0030] Call the risk control rule configuration service to extract the risk control verification dimension from the risk control model information;
[0031] The corresponding risk control rule configuration data is obtained based on the risk control verification dimension, wherein the risk control verification dimension includes any one or more of vehicle type, virtual positioning and billing.
[0032] Optionally, based on the calling order, the corresponding risk control processing core module is called to obtain the corresponding core module data according to the data source configuration information, including:
[0033] Determine the upstream core modules and downstream core modules associated with each risk control processing core module;
[0034] According to the calling order, the upstream core modules are called in sequence to obtain the corresponding upstream core module data. In response to the successful acquisition of the upstream core module data, the downstream core module data corresponding to the downstream core module is acquired based on the upstream core module data.
[0035] Optionally, perform risk control checks based on core module data to identify abnormal business operation nodes and abnormality types, including:
[0036] Match the core module data with the risk control rule configuration data to obtain matching result data;
[0037] Based on the matching result data, determine the business abnormality nodes that trigger risk control;
[0038] The matching result data is input into the classification model to predict the corresponding abnormality type based on the decision tree in the classification model.
[0039] In addition, the present application also provides an exception handling device, including:
[0040] A first determining unit is configured to determine a corresponding risk control type identifier and a business identifier in response to the exception handling request;
[0041] A second determining unit is configured to determine a corresponding risk control processing core module and a calling sequence based on the risk control type identifier;
[0042] A first acquisition unit is configured to acquire data source configuration information of the risk control processing core module according to the business identifier;
[0043] The second acquisition unit is configured to call the corresponding risk control processing core module based on the calling order to obtain the corresponding core module data according to the data source configuration information;
[0044] The exception handling unit is configured to perform risk control checks based on the core module data to determine the abnormal nodes and types of business operations.
[0045] Optionally, the second determining unit is further configured to:
[0046] Determine the corresponding risk control processing flow based on the risk control type identifier;
[0047] According to the risk control processing flow, determine the core risk control processing modules involved and determine the order in which the core risk control processing modules are called.
[0048] Optionally, the second determining unit is further configured to:
[0049] Determine the data dependencies of the core risk control modules based on the risk control process;
[0050] Determine the order of calling the core risk control processing modules based on data dependencies.
[0051] Optionally, the second determining unit is further configured to:
[0052] In response to the risk control type identifier corresponding to scheduled risk control, the corresponding risk control processing flow is determined as follows:
[0053] After detecting that the timer risk control receiver receives the timer trigger signal, it calls the timer risk control data processing service to obtain the risk control model information and passes it to the risk control model configuration service;
[0054] Call the risk control model configuration service to obtain model configuration data based on the risk control model information;
[0055] Based on the data source configuration information, the scheduled risk control data processing processor is called to automatically obtain business operation data;
[0056] Send business operation data, risk control model information, and model configuration data to the asynchronous message queue;
[0057] Call the asynchronous message service to consume each asynchronous message in the asynchronous message queue to perform risk control verification, and then determine the abnormal nodes and abnormal types of business operations.
[0058] Optionally, the second determining unit is further configured to:
[0059] In response to the risk control type identifier corresponding to scheduled risk control asynchronous execution or real-time risk control, the corresponding risk control processing flow is determined as follows:
[0060] Call the risk control analysis service to obtain the incoming business operation data, risk control model information, and model configuration data, and then call the risk control indicator configuration service to obtain indicator configuration data based on the risk control model information;
[0061] Call the corresponding risk control indicator processing processor according to the indicator configuration data to obtain the indicator value;
[0062] Call the risk control rule configuration service to obtain the corresponding risk control rule configuration data based on the risk control model information;
[0063] Call the risk control engine to calculate whether to trigger risk control based on business operation data, model configuration data, indicator values, and risk control rule configuration data, and call the risk control result service after risk control is triggered to determine the business operation abnormal node and abnormal type.
[0064] Optionally, the second determining unit is further configured to:
[0065] Call the risk control rule configuration service to extract the risk control verification dimension from the risk control model information;
[0066] The corresponding risk control rule configuration data is obtained based on the risk control verification dimension, wherein the risk control verification dimension includes any one or more of vehicle type, virtual positioning and billing.
[0067] Optionally, the second acquiring unit is further configured to:
[0068] Determine the upstream core modules and downstream core modules associated with each risk control processing core module;
[0069] According to the calling order, the upstream core modules are called in sequence to obtain the corresponding upstream core module data. In response to the successful acquisition of the upstream core module data, the downstream core module data corresponding to the downstream core module is acquired based on the upstream core module data.
[0070] Optionally, the exception handling unit is further configured to:
[0071] Match the core module data with the risk control rule configuration data to obtain matching result data;
[0072] Based on the matching result data, determine the business abnormality nodes that trigger risk control;
[0073] The matching result data is input into the classification model to predict the corresponding abnormality type based on the decision tree in the classification model.
[0074] In addition, the present application also provides an exception handling electronic device, comprising: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by one or more processors, the one or more processors implement the above-mentioned exception handling method.
[0075] In addition, the present application also provides a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned exception handling method is implemented.
[0076] One embodiment of the above invention has the following advantages or beneficial effects: the present application determines the corresponding risk control type identifier and business identifier in response to an exception handling request; determines the corresponding risk control processing core module and calling sequence based on the risk control type identifier; obtains data source configuration information of the risk control processing core module based on the business identifier; calls the corresponding risk control processing core module based on the calling sequence to obtain corresponding core module data based on the data source configuration information; and performs risk control verification based on the core module data to determine the business operation abnormality node and abnormality type. This improves the efficiency and accuracy of identifying and handling abnormalities that may occur during business operations.
[0077] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0078] The accompanying drawings are provided to facilitate a better understanding of the present application and do not constitute an undue limitation on the present application.
[0079] Figure 1 This is a schematic diagram of the main process of the exception handling method provided according to one embodiment of the present application;
[0080] Figure 2 This is a schematic diagram of the main process of the exception handling method provided according to one embodiment of the present application;
[0081] Figure 3 This is a schematic diagram of a rule-based risk control architecture for an exception handling method provided in accordance with one embodiment of the present application;
[0082] Figure 4 is a schematic diagram of the main units of the exception handling device according to an embodiment of the present application;
[0083] Figure 5 is an exemplary system architecture diagram to which embodiments of the present application may be applied;
[0084] Figure 6 It is a structural diagram of a computer system of a terminal device or server suitable for implementing an embodiment of the present application. DETAILED DESCRIPTION
[0085] The following is an explanation of exemplary embodiments of the present application in conjunction with the accompanying drawings, which include various details of the embodiments of the present application to facilitate understanding, and they should be considered as merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the technical solutions disclosed herein, the collection, collection, updating, analysis, processing, use, transmission, storage and other aspects of user personal information involved are in compliance with the provisions of relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Take necessary measures for user personal information to prevent illegal access to user personal information data and maintain user personal information security, network security and national security.
[0086] Figure 1 FIG. 1 is a schematic diagram of the main process of the exception handling method provided in one embodiment of the present application. Figure 1 As shown, the exception handling method includes:
[0087] Step S101: In response to an exception handling request, determine the corresponding risk control type identifier and business identifier.
[0088] The execution subject of the exception handling method of the embodiment of the present application may be a server. The risk control type identifier is used to represent the type of risk control selected by the user. For example, the risk control type selected by the user may include: scheduled risk control asynchronous execution or real-time risk control, or scheduled risk control.
[0089] For example, asynchronous execution of scheduled risk control can be understood as executing scheduled risk control as an asynchronous task. Scheduled risk control refers to periodically scanning operational data through a timer to trigger rule calculations, while real-time risk control refers to triggering rule calculations based on real-time operational data input.
[0090] The asynchronous task in the embodiment of the present application refers to a task that does not enter the main thread but enters the task queue. After the main thread task is completed, the task queue begins to notify the main thread and request to execute the task. Only then will the task enter the main thread for execution.
[0091] The service identifier can be used to represent the number or name of the service to be handled. For example, the service identifier can be YS, representing a transportation service, or XS, representing a sales service. The embodiment of the present application does not specifically limit the form and content of the service identifier.
[0092] Step S102: Based on the risk control type identifier, determine the corresponding risk control processing core module and calling sequence.
[0093] The execution entity can determine the corresponding risk control type based on the risk control type identifier, such as asynchronous execution of scheduled risk control, real-time risk control, or scheduled risk control. Based on the determined risk control type, the corresponding risk control processing core module and the order in which each risk control processing core module is called are determined.
[0094] Step S103: Obtain data source configuration information of the risk control processing core module according to the business identifier.
[0095] The service identifier may be associated with data source configuration information, which is used to indicate the source of the data to be processed for exception handling.
[0096] Step S104: Based on the calling sequence, the corresponding risk control processing core module is called to obtain the corresponding core module data according to the data source configuration information.
[0097] Specifically, based on the calling order, the corresponding risk control processing core module is called to obtain the corresponding core module data according to the data source configuration information, including: determining the upstream core module in each risk control processing core module and the downstream core module associated with the upstream core module; according to the calling order, calling the upstream core modules in turn to obtain the corresponding upstream core module data, and in response to the successful acquisition of the upstream core module data, obtaining the downstream core module data corresponding to the downstream core module based on the upstream core module data.
[0098] The core module data of the downstream core module depends on the corresponding core module data obtained by the upstream core module. The execution entity can call the upstream core modules (such as the risk control analysis service) in sequence according to the calling order and obtain the corresponding core module data. Only after the core module data of the upstream core module is successfully obtained, will the execution entity obtain the core module data of the corresponding downstream core module (such as the risk control indicator configuration service) to ensure the real-time and accuracy of the core module data obtained by the downstream core module.
[0099] Step S105: Perform risk control verification based on the core module data to determine the abnormal nodes and abnormal types of business operations.
[0100] Specifically, risk control verification is performed based on the core module data to determine the abnormal nodes and abnormal types of business operations, including: matching the core module data with the risk control rule configuration data to obtain matching result data; based on the matching result data, determining the business abnormal nodes that trigger risk control; inputting the matching result data into the classification model to obtain the corresponding abnormal type based on the decision tree prediction in the classification model.
[0101] For example, the risk control rule configuration data can be, for example, the correspondence between the actual positioning position of the vehicle and the electronic fence. Specifically, in the transportation business, the electronic fence can be the range within which the dispatched vehicle can travel. The execution entity can match the actual positioning position of the dispatched vehicle with the electronic fence. When the actual positioning position of the dispatched vehicle is within the corresponding electronic fence, the risk control warning is not triggered. When the actual positioning position of the dispatched vehicle is not within the corresponding electronic fence and the user locates the vehicle within the electronic fence through virtual positioning, the risk control warning is triggered, and it is determined that the business operation abnormality node can be a vehicle positioning node, and the abnormality type is a vehicle positioning abnormality.
[0102] For example, risk control rule configuration data can also be the correspondence between the required vehicle type and the actually dispatched vehicle type in a transportation business. If a large vehicle is required, but multiple smaller vehicles are dispatched, a risk control alert is triggered, and the business operation abnormality node can be determined as a vehicle dispatch node, and the abnormality type can be a vehicle type dispatch abnormality.
[0103] For example, risk control rule configuration data can also be the correspondence between the reserved vehicle type and the actual billed vehicle type in the transportation business. If a small vehicle type is reserved or dispatched, but the vehicle type is billed as a large vehicle type, a risk control alert is triggered, and the abnormal business operation node can be determined to be a billing node, and the abnormality type can be a vehicle type billing abnormality.
[0104] This embodiment responds to an exception handling request by determining the corresponding risk control type identifier and business identifier; based on the risk control type identifier, determining the corresponding risk control processing core module and calling sequence; obtaining data source configuration information for the risk control processing core module based on the business identifier; based on the calling sequence, calling the corresponding risk control processing core module to obtain corresponding core module data based on the data source configuration information; and performing risk control verification based on the core module data to determine the business operation abnormality node and abnormality type. This improves the efficiency and accuracy of identifying and handling abnormalities that may arise during business operations.
[0105] Figure 2 FIG. 1 is a schematic diagram of the main flow of an exception handling method provided according to an embodiment of the present application. Figure 2 As shown, the exception handling method includes:
[0106] Step S201: In response to the exception handling request, determine the corresponding risk control type identifier and business identifier.
[0107] Step S202: Determine the corresponding risk control processing flow based on the risk control type identifier.
[0108] The embodiment of the present application is based on the abnormality handling method executed by the risk control system. Among them, the risk control system includes the following core modules: risk control model configuration service: the risk control model defines the structure of the operation data; scheduled risk control model data source configuration: used for scheduled risk control, defines the data processing service to automatically obtain the source of the operation data and the acquisition parameters, etc.; scheduled risk control data processing processor: according to the data source configuration, automatically use different data processors to process and obtain the operation data; risk control indicator configuration service: configure the source and processing method of the indicators in the risk control model, for the automatic acquisition of the indicator value; risk control indicator processing processor: according to the risk control indicator configuration, automatically use different indicator processors to process and obtain the indicator value; risk control rule configuration service: configure the rules for triggering risk control in combination with the risk control model; risk control engine: calculate whether to trigger risk control by combining the operation data, risk control indicators and risk control rules; risk control result service: save the details of the risk control results, send notification messages, recycle and dispose feedback, etc.
[0109] Specifically, determining the corresponding risk control processing flow includes: in response to the risk control type identifier corresponding to the timed risk control, determining the corresponding risk control processing flow as follows: after detecting that the timed risk control receiver receives the timer trigger signal, calling the timed risk control data processing service to obtain the risk control model information and pass it to the risk control model configuration service; calling the risk control model configuration service to obtain the model configuration data according to the risk control model information; calling the timed risk control data processing processor to automatically obtain the business operation data according to the data source configuration information; sending the business operation data, risk control model information and model configuration data to the asynchronous message queue; calling the asynchronous message service to consume each asynchronous message in the asynchronous message queue to perform risk control verification, and then determining the abnormal nodes and abnormal types of business operations.
[0110] For example, through the timer trigger, the scheduled risk control data processing service is called, the risk control model information is passed in, the model configuration data is obtained according to the risk control model information, and the scheduled risk control data processing processor is called according to the data source configuration information to automatically obtain business operation data. The business operation data and risk control model information are sent as asynchronous messages to execute the scheduled asynchronous risk control process. Specifically, the scheduled asynchronous risk control process can be found in the following scheduled risk control asynchronous execution and real-time risk control process.
[0111] Specifically, determining the corresponding risk control processing flow includes: in response to the risk control type identifier corresponding to scheduled risk control asynchronous execution or real-time risk control, determining the corresponding risk control processing flow (i.e., scheduled risk control asynchronous execution, real-time risk control flow) as follows: calling the risk control analysis service to obtain the incoming business operation data, risk control model information and model configuration data, and then calling the risk control indicator configuration service to obtain the indicator configuration data based on the risk control model information; calling the corresponding risk control indicator processing processor based on the indicator configuration data to obtain the indicator value; calling the risk control rule configuration service to obtain the corresponding risk control rule configuration data based on the risk control model information; calling the risk control engine to calculate whether to trigger risk control based on the business operation data, model configuration data, indicator value and risk control rule configuration data, and calling the risk control result service after triggering the risk control to determine the business operation abnormal node and abnormal type.
[0112] For example, scheduled risk control is executed asynchronously, and real-time risk control calls the risk control analysis service, inputs business operation data and risk control model information, obtains the model and indicator configuration data based on the risk control model information, calls different risk control indicator processing processors based on the indicator configuration data to obtain the indicator value, obtains the risk control rule configuration data based on the risk control model information, and then calls the risk control engine to calculate whether to trigger risk control based on the business operation data, indicator value, and risk control rule configuration data. If risk control is triggered, the corresponding business operation exception node and exception type are determined, and the result after the risk control is triggered is processed.
[0113] Specifically, calling the risk control rule configuration service to obtain corresponding risk control rule configuration data based on the risk control model information includes: calling the risk control rule configuration service to extract the risk control verification dimension in the risk control model information; obtaining the corresponding risk control rule configuration data based on the risk control verification dimension, wherein the risk control verification dimension includes any one or more of vehicle model, virtual positioning and billing.
[0114] For example, the risk control verification dimensions may include one or more of vehicle type, virtual positioning, and billing. The embodiments of the present application do not specifically limit the risk control verification dimensions.
[0115] For example, in the transportation business, there are frequent small vehicles in the same wave (single vehicle could be dispatched, but multiple small vehicles are actually dispatched), virtual positioning (operational requirements require that vehicles be dispatched within an electronic fence, but the actual driver modifies the location using virtual positioning software), and unreasonable billing (a small vehicle is reserved or actually arrives, but the vehicle is billed as a large vehicle). These false operations can trigger risk control, which can be identified through a series of domain-specific language (DSL) configurations: risk control model configuration, data acquisition DSL configuration, indicator DSL configuration, rule DSL configuration, etc., to identify risks and false operations in business operations.
[0116] Step S203: Determine the involved risk control processing core module according to the risk control processing flow.
[0117] Each risk control type can correspond to a risk control processing flow, which can include one or more risk control processing core modules to assist in risk control processing such as anomaly detection.
[0118] For example, when the risk control type is scheduled risk control, the risk control processing core modules involved may include a scheduled risk control receiver, a scheduled risk control data processing service, a risk control model configuration service, a scheduled risk control data processing processor, and an asynchronous message service.
[0119] When the risk control type is scheduled risk control asynchronous execution or real-time risk control, the risk control processing core modules involved may include risk control analysis service, risk control indicator configuration service, risk control indicator processing, risk control rule configuration service, risk control engine and risk control result service.
[0120] Step S204: Determine the data dependency of the risk control processing core module according to the risk control processing flow.
[0121] The executing entity can determine the upstream and downstream dependencies of the risk control processing core modules according to the workflow of the risk control processing process (from upstream to downstream), and determine the data dependencies of each risk control processing core module of the risk control processing process based on the upstream and downstream dependencies.
[0122] Step S205: Determine the order of calling the risk control processing core modules based on the data dependency relationship.
[0123] The priority of the dependent party of each risk control processing core module is set higher than that of the dependent party. This determines the calling order of each risk control processing core module, and the calling order of the module with higher calling priority is sorted first. This can make the identification of anomalies in business operation data more accurate.
[0124] Step S206: Obtain data source configuration information of the risk control processing core module according to the business identifier.
[0125] The business identifier can represent the source of the business operation data used for anomaly identification, that is, the business identifier is associated with the data source configuration information of the risk control processing core module, which is used to represent the source of the data to be processed for anomaly.
[0126] Step S207: Based on the calling sequence, the corresponding risk control processing core module is called to obtain the corresponding core module data according to the data source configuration information.
[0127] The execution entity can first call the risk control processing core module with high priority according to the calling order to obtain the corresponding core module data, and then call the risk control processing core module with lower priority in sequence to obtain the core module data of the risk control processing core module with lower priority based on the obtained core module data, so as to perform subsequent exception processing, thereby improving the accuracy of exception processing of business operation data.
[0128] Step S208: Perform risk control verification based on the core module data to determine the abnormal nodes and abnormal types of business operations.
[0129] Business operation data can be, for example, the actual vehicle model data, positioning data, billing data, etc. The index value can be, for example, the data structure defined by the risk control model and the index configuration data (for example, it can be a numerical unit or a numerical range, etc.), the model model distributed, the specific vehicle positioning position, the billing amount of the distributed vehicle, etc. For example, the model of the embodiment of the present application can be a risk control model, in which the structure of the operation data in the business data is defined. By converting the operation data according to the structure defined in the risk control model, it is convenient to judge whether to trigger the risk control warning based on the converted operation data, thereby improving the efficiency and accuracy of the warning timing judgment. The core module data contains the data required for risk control verification, such as business operation data, model configuration data of the risk control model, various indicator values, and risk control rule configuration data. The model parameters are set to the model configuration data of the risk control model, and then the risk control model is called and the risk control rule configuration data is used as a benchmark to perform risk control verification with the business operation data and various indicator values. The corresponding node when the verification fails is determined as a business operation abnormal node, and the abnormality corresponding to the abnormality generated by the node is determined.
[0130] Figure 3It is a schematic diagram of the rule-based risk control architecture of the exception handling method provided in one embodiment of the present application. The execution subject of the risk handling method of the embodiment of the present application can handle exception handling based on the rule-based risk control architecture. The rule-based risk control architecture may include a front-end, a risk control system, a risk control storage, an external system, and a data provider. The front-end interacts with the risk control system, the risk control system interacts with the risk control storage, the external system interacts with the risk control system, and the data provider interacts with the risk control system. The front-end includes a risk control model module, a rule module, and a display module. The risk control model can dynamically access the model and update the model parameters in real time. The rule module can perform rule configuration and policy management. The display module can display model data and risk control results. The risk control system may include a risk control model management module, a rule management module, a scheduled task module, a risk control engine module, an external service module, and a data acquisition service module. The risk control model management module manages basic model information and model field configurations. The rule management module interacts with the risk control model management module to manage rules and policies. The risk control engine module interacts with the rule management module to extract features and interpret and execute rules. The external service module interacts with the risk control engine module to access model data through the risk control API. The data collection service module interacts with the risk control engine module to collect indicator data. External systems can include procurement, scheduling, execution, and settlement systems, which can be readily accessed by the risk control core module. Data providers can provide big data, control indicators, and other data to the data collection service module. The risk control storage module interacts with the risk control system to store rules, model information, risk control model data, indicator data, and risk control results data. By invoking the risk control core module, the executing entity can obtain the risk control model, strategy, indicator, rule configuration, and other data required for business data verification based on the aforementioned rule-based risk control architecture, thereby improving the efficiency and accuracy of exception handling.
[0131] In an embodiment of the present application, exception handling may include scheduled risk control and real-time risk control. Scheduled risk control uses a timer to periodically scan operational data, triggering the corresponding workflow for calculation. Real-time risk control uses incoming operational data to trigger the corresponding workflow for calculation. The execution body of the exception handling method in this embodiment of the present application may include a risk control model configuration module, a scheduled risk control model data source configuration module, a scheduled risk control data processing service, a risk control indicator configuration module, a risk control indicator processing processor module, a risk control rule configuration module, a risk control engine module, and a risk control result module. The risk control model configuration module defines the structure of operational data for the risk control model. The scheduled risk control model data source configuration module is used for scheduled risk control and defines the source and acquisition parameters for the data processing service to automatically obtain operational data. The scheduled risk control data processing service module automatically processes and obtains operational data using different data processors based on the data source configuration. The risk control indicator configuration module configures the source and processing method of indicators in the risk control model for the automatic acquisition of indicator values. The risk control indicator processing processor module automatically processes and obtains indicator values using different indicator processors based on the risk control indicator configuration. Risk control rule configuration module: configures the rules for triggering risk control in combination with the risk control model. Risk control engine module: combines operational data, risk control indicators, and risk control rules to calculate whether risk control is triggered. Risk control result module: saves the details of risk control results, sends notification messages, recycles and disposes feedback, etc. In the embodiment of the present application, scheduled risk control asynchronous execution and real-time risk control process: real-time risk control and scheduled asynchronous risk control call the risk control analysis service, pass in operational data and model information; obtain the model and indicator configuration according to the model information; call different indicator processing processors according to the indicator configuration to obtain the indicator value; obtain the risk control rule configuration according to the model information; call the risk control engine to calculate whether to trigger risk control based on the operational data, indicators, and rules; process the results after triggering risk control. Scheduled risk control trigger process: timer triggers, calls the scheduled risk control data processing service, passes in the model information; obtains the model configuration according to the model information; calls the scheduled risk control data processing processor according to the model data source configuration to automatically obtain operational data; sends asynchronous messages to the operational data and model information; scheduled asynchronous risk control process.The risk control model's data acquisition logic, Digital Subscriber Line (DSL), is configured to retrieve data from multiple data sources based on the configuration. The risk control model's indicator field processing DSL is configured to perform various calculations based on the configuration. The rule DSL configures thresholds and condition combinations for operational data and indicators, and translates them into scripts executable by the rule engine. Overall, it is a recursive structure that supports multi-level configuration. The rule engine can identify rule logic and calculate results based on operational data and indicators. The rule-based risk control architecture in the execution entity implements a new risk control requirement. It can be put into operation online after only model configuration, model data source DSL configuration, model field configuration, model indicator DSL configuration, and rule DSL configuration, improving the efficiency and accuracy of exception handling and reducing operating costs.
[0132] Figure 4 Schematic diagram of the main units of the exception handling device according to the embodiment of the present application. Figure 4 As shown, the exception handling device 400 includes a first determining unit 401 , a second determining unit 402 , a first acquiring unit 403 , a second acquiring unit 404 and an exception handling unit 405 .
[0133] The first determining unit 401 is configured to determine a corresponding risk control type identifier and a service identifier in response to an exception handling request.
[0134] The second determining unit 402 is configured to determine the corresponding risk control processing core module and calling sequence based on the risk control type identifier.
[0135] The first acquisition unit 403 is configured to acquire data source configuration information of the risk control processing core module according to the business identifier.
[0136] The second acquisition unit 404 is configured to call the corresponding risk control processing core module based on the calling order to obtain the corresponding core module data according to the data source configuration information.
[0137] The exception handling unit 405 is configured to perform risk control verification based on the core module data to determine the business operation abnormal nodes and abnormality types.
[0138] In some embodiments, the second determination unit 402 is further configured to: determine the corresponding risk control processing flow based on the risk control type identifier; determine the involved risk control processing core modules according to the risk control processing flow, and determine the calling order of the risk control processing core modules.
[0139] In some embodiments, the second determining unit 402 is further configured to: determine the data dependency of the risk control processing core modules according to the risk control processing flow; and determine the calling order of the risk control processing core modules according to the data dependency.
[0140] In some embodiments, the second determination unit 402 is further configured to: in response to the risk control type identifier corresponding to the timed risk control, determine the corresponding risk control processing flow as follows: after detecting that the timed risk control receiver receives the timer trigger signal, call the timed risk control data processing service to obtain the risk control model information and pass it to the risk control model configuration service; call the risk control model configuration service to obtain the model configuration data according to the risk control model information; according to the data source configuration information, call the timed risk control data processing processor to automatically obtain the business operation data; send the business operation data, risk control model information and model configuration data to the asynchronous message queue; call the asynchronous message service to consume each asynchronous message in the asynchronous message queue to perform risk control verification, and then determine the abnormal nodes and abnormal types of business operations.
[0141] In some embodiments, the second determination unit 402 is further configured to: in response to the risk control type identifier corresponding to scheduled risk control asynchronous execution or real-time risk control, determine the corresponding risk control processing flow as follows: call the risk control analysis service to obtain the incoming business operation data, risk control model information and model configuration data, and then call the risk control indicator configuration service to obtain the indicator configuration data based on the risk control model information; call the corresponding risk control indicator processing processor based on the indicator configuration data to obtain the indicator value; call the risk control rule configuration service to obtain the corresponding risk control rule configuration data based on the risk control model information; call the risk control engine to calculate whether to trigger risk control based on the business operation data, model configuration data, indicator value and risk control rule configuration data, and call the risk control result service after triggering the risk control to determine the business operation abnormal node and abnormal type.
[0142] In some embodiments, the second determination unit 402 is further configured to: call the risk control rule configuration service to extract the risk control verification dimension in the risk control model information; obtain the corresponding risk control rule configuration data based on the risk control verification dimension, wherein the risk control verification dimension includes any one or more of vehicle type, virtual positioning and billing.
[0143] In some embodiments, the second acquisition unit 402 is further configured to: determine the upstream core module in each risk control processing core module and the downstream core module associated with the upstream core module; call the upstream core modules in sequence according to the calling order to obtain the corresponding upstream core module data, and in response to the successful acquisition of the upstream core module data, obtain the downstream core module data corresponding to the downstream core module based on the upstream core module data.
[0144] In some embodiments, the exception handling unit 405 is further configured to: match the core module data with the risk control rule configuration data to obtain matching result data; determine the business exception node that triggers risk control based on the matching result data; input the matching result data into the classification model to obtain the corresponding exception type based on the decision tree prediction in the classification model.
[0145] It should be noted that the exception handling method and the exception handling device of the present application have corresponding relationships in terms of specific implementation contents, so the repeated contents will not be described again.
[0146] Figure 5 An exemplary system architecture 500 is shown to which the exception handling method or exception handling apparatus according to the embodiment of the present application can be applied.
[0147] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, 503, a network 504, and a server 505. Network 504 is used to provide a medium for communication links between terminal devices 501, 502, 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links or fiber optic cables.
[0148] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, and 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).
[0149] The terminal devices 501 , 502 , and 503 may be various electronic devices that have an exception processing screen and support web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.
[0150] Server 505 can be a server that provides various services, such as a background management server (for example only) that supports exception handling requests submitted by users using terminal devices 501, 502, and 503. The background management server can respond to the exception handling request by determining the corresponding risk control type identifier and business identifier; based on the risk control type identifier, determine the corresponding risk control processing core module and call sequence; obtain data source configuration information for the risk control processing core module based on the business identifier; based on the call sequence, call the corresponding risk control processing core module to obtain corresponding core module data based on the data source configuration information; and perform risk control verification based on the core module data to determine business operation abnormality nodes and abnormality types. This improves the efficiency and accuracy of identifying and handling abnormalities that may arise during business operations.
[0151] It should be noted that the exception handling method provided in the embodiment of the present application is generally executed by the server 505 , and accordingly, the exception handling device is generally set in the server 505 .
[0152] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.
[0153] Reference below Figure 6 , which shows a structural diagram of a computer system 600 of a terminal device suitable for implementing an embodiment of the present application. Figure 6 The terminal device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.
[0154] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the computer system 600 are also stored in the RAM 603. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0155] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, and the like; an output section 607 including displays such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 608 including a hard disk; and a communication section 609 including a network interface card such as a LAN card or a modem. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. Removable media 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read therefrom can be installed into the storage section 608 as needed.
[0156] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from a removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present application are executed.
[0157] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can include, for example, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.
[0158] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0159] The units involved in the embodiments described in this application can be implemented by software or hardware. The units described can also be set in a processor. For example, it can be described as follows: a processor includes a first determination unit, a second determination unit, a first acquisition unit, a second acquisition unit, and an exception handling unit. In some cases, the names of these units do not constitute limitations on the units themselves.
[0160] As another aspect, the present application also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently and not be assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device determines the corresponding risk control type identifier and business identifier in response to the exception handling request; based on the risk control type identifier, determines the corresponding risk control processing core module and the calling sequence; obtains the data source configuration information of the risk control processing core module according to the business identifier; based on the calling sequence, calls the corresponding risk control processing core module to obtain the corresponding core module data according to the data source configuration information; performs risk control verification based on the core module data to determine the abnormal node and abnormal type of business operation.
[0161] According to the technical solutions of the embodiments of the present application, the efficiency and accuracy of identifying and handling anomalies that may occur during business operations can be improved.
[0162] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.
Claims
1. An exception handling method, characterized in that: include: In response to the exception handling request, determine the corresponding risk control type identifier and business identifier; Based on the risk control type identifier, determine the corresponding risk control processing core module and calling sequence; According to the business identifier, obtaining data source configuration information of the risk control processing core module; Based on the calling sequence, calling the corresponding risk control processing core module to obtain the corresponding core module data according to the data source configuration information; Perform risk control checks based on the core module data to determine abnormal business operation nodes and abnormal types.
2. The method according to claim 1, characterized in that Determining the corresponding risk control processing core modules and calling sequence includes: Determine the corresponding risk control processing flow based on the risk control type identifier; According to the risk control processing flow, the involved risk control processing core modules are determined, and the calling order of the risk control processing core modules is determined.
3. The method according to claim 2, characterized in that Determining the order of calling the risk control processing core module includes: Determine the data dependency of the core risk control processing module according to the risk control processing flow; The calling order of the risk control processing core module is determined according to the data dependency relationship.
4. The method according to claim 2, characterized in that Determining the corresponding risk control process includes: In response to the risk control type identifier corresponding to scheduled risk control, the corresponding risk control processing flow is determined as follows: After detecting that the timer risk control receiver receives the timer trigger signal, it calls the timer risk control data processing service to obtain the risk control model information and passes it to the risk control model configuration service; Calling the risk control model configuration service to obtain model configuration data based on the risk control model information; Based on the data source configuration information, a timed risk control data processing processor is called to automatically obtain business operation data; Sending the business operation data, the risk control model information, and the model configuration data to an asynchronous message queue; The asynchronous message service is called to consume each asynchronous message in the asynchronous message queue to perform risk control verification, thereby determining the abnormal nodes and abnormal types of business operations.
5. The method according to claim 2, characterized in that Determining the corresponding risk control process includes: In response to the risk control type identifier corresponding to scheduled risk control asynchronous execution or real-time risk control, the corresponding risk control processing flow is determined as follows: Call the risk control analysis service to obtain the incoming business operation data, risk control model information and model configuration data, and then call the risk control indicator configuration service to obtain indicator configuration data based on the risk control model information; Calling the corresponding risk control indicator processing processor according to the indicator configuration data to obtain the indicator value; Calling the risk control rule configuration service to obtain corresponding risk control rule configuration data based on the risk control model information; The risk control engine is called to calculate whether risk control is triggered based on the business operation data, the model configuration data, the indicator value and the risk control rule configuration data, and after risk control is triggered, the risk control result service is called to determine the business operation abnormal node and abnormal type.
6. The method according to claim 5, characterized in that The calling of the risk control rule configuration service to obtain corresponding risk control rule configuration data based on the risk control model information includes: Invoke the risk control rule configuration service to extract the risk control verification dimension in the risk control model information; Corresponding risk control rule configuration data is obtained based on the risk control verification dimension, wherein the risk control verification dimension includes any one or more of vehicle type, virtual positioning and billing.
7. The method according to any one of claims 1 to 5, characterized in that The calling of the corresponding risk control processing core module based on the calling sequence to obtain the corresponding core module data according to the data source configuration information includes: Determining an upstream core module in each of the risk control processing core modules and a downstream core module associated with the upstream core module; According to the calling sequence, the upstream core modules are called in sequence to obtain corresponding upstream core module data. In response to successful acquisition of the upstream core module data, downstream core module data corresponding to the downstream core module is acquired based on the upstream core module data.
8. The method according to any one of claims 1 to 5, characterized in that The risk control check is performed based on the core module data to determine abnormal business operation nodes and abnormal types, including: Matching the core module data with the risk control rule configuration data to obtain matching result data; Based on the matching result data, determine the business abnormality node that triggers risk control; The matching result data is input into a classification model to predict the corresponding abnormality type based on the decision tree in the classification model.
9. An exception handling device, characterized in that: include: A first determining unit is configured to determine a corresponding risk control type identifier and a business identifier in response to the exception handling request; A second determining unit is configured to determine a corresponding risk control processing core module and a calling sequence based on the risk control type identifier; A first acquisition unit is configured to acquire data source configuration information of the risk control processing core module according to the business identifier; a second acquiring unit configured to call the corresponding risk control processing core module based on the calling order, so as to acquire corresponding core module data according to the data source configuration information; The exception handling unit is configured to perform risk control verification based on the core module data to determine the business operation abnormal nodes and abnormal types.
10. The device according to claim 9, characterized in that The second determining unit is further configured to: Determine the corresponding risk control processing flow based on the risk control type identifier; According to the risk control processing flow, the involved risk control processing core modules are determined, and the calling order of the risk control processing core modules is determined.
11. An abnormality handling electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 8.
12. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.