Intelligent risk control automatic approval system integrated with FICO Blaze decision engine

Abstract

The invention relates to the technical field of financial science and technology, and discloses an intelligent risk control automatic approval system integrated with an FICO Blaze decision engine, and the system process is composed of a credit system, an acquisition system, an input center, a route scheduling system, a comprehensive decision system, Blaze, a model platform and a feature platform. The system is divided into a data collection module, a data processing module, a flow system transformation module and a data storage module, and manages system functions. The services of the system functions comprise an express entry request service, an express entry response service, flow control, a decision request service, a decision data service, a query service, a unified exception handling service, thread pool configuration and optimization, Kafka configuration, the above processes, function composition and module classification. The system solves the problem that market changes and complex business logic cannot be reflected in time in a traditional risk control system.

Description

Technical Field

[0001] The present invention relates to the technical field of fintech, and specifically to an intelligent risk control automated approval system integrating the FICO Blaze decision engine. Background Art

[0002] With the continuous development of fintech, the automation requirements of financial institutions in aspects such as credit approval and risk management are increasing day by day. Traditional risk control systems usually rely on static data and rule engines for decision-making. However, this method often fails to reflect market changes and complex business logics in a timely manner. Therefore, integrating advanced decision engines has become an important means to improve the performance of risk control systems. As an efficient rule management and execution tool, the FICO Blaze decision engine is widely used in financial risk control systems to achieve rapid response and processing of complex business logics. Summary of the Invention

[0003] (1) Technical Problems to be Solved

[0004] Aiming at the deficiencies of the prior art, the present invention provides an intelligent risk control automated approval system integrating the FICO Blaze decision engine, which has the advantages of rapid response and timely processing of complex business logics, and solves the problem that traditional risk control systems cannot reflect market changes and complex business logics in a timely manner.

[0005] (2) Technical Solutions

[0006] To achieve the above object, the present invention provides the following technical solutions: An intelligent risk control automated approval system integrating the FICO Blaze decision engine, the system process is composed of a credit system, a card acceptance system, an application intake center, a routing and scheduling system (DPS), a comprehensive decision-making system, Blaze, a model platform, and a feature platform;

[0007] The system is divided into a data collection module, a data processing module, a process system transformation module, and a data storage module, and manages the system functions;

[0008] The services of the system functions include: application intake request service, application intake response service, traffic control, decision request service, decision data service, query service, unified exception handling service, thread pool configuration and optimization, Kafka configuration.

[0009] Preferably, the overall framework of the system follows the reconstruction of external connections, adds or deletes dependencies, and splits services according to different business application intakes for consumption.

[0010] Preferably, the data collection module includes an incoming request service data unit, a decision request service data unit, and a Kafka configuration data unit. The request service data unit obtains request service data by directly calling the API interface of the module. The decision request service data unit obtains decision request service data through message passing and data packet transmission. The Kafka configuration data unit obtains Kafka configuration data through configuration files, code settings, and environment variables. After the incoming request service data unit, the decision request service data unit, and the Kafka configuration data unit perform statistics and numbering on the data within the unit, they send the data to the data processing module for calculation.

[0011] Preferably, the incoming request service data includes the time from the initiation of the incoming request to the receipt of the service request, the actual time for the service to process the request, and the preset time for the service to process the request. The time from the initiation of the incoming request to the receipt of the service request, the actual time for the service to process the request, and the preset time for the service to process the request are numbered as T 1 、T 2 、T 3 , the decision request service data includes the statistics of the request volume from 1 to n decision request service instances. The request volume from 1 to n decision request service instances is numbered as R 1 、R 2 、R 3 、…R n , the Kafka configuration data includes the total number of messages processed within time t, the observed time window, and the average size of a single message. The total number of messages processed within time t, the observed time window, and the average size of a single message are numbered as m, t,

[0012] Preferably, the data processing module includes an incoming response service unit, a load balancing control unit, and a Kafka throughput statistics unit. The incoming response service unit calculates the incoming response service efficiency Vs based on the incoming request service data. The load balancing control unit calculates the load balancing control index Ez based on the traffic control data and the decision request service data. The Kafka throughput statistics unit calculates the Kafka throughput control index Qj based on the Kafka configuration data. After the incoming response service unit, the load balancing control unit, and the Kafka throughput statistics unit perform calculations on the internal data of the unit, they are connected to the process system transformation module through the network.

[0013] Preferably, the incoming response service unit calculates the incoming response service efficiency Vs based on the incoming request service data, and its calculation formula is:

[0014]

[0015] In the formula, Vs represents, T1 and T 2 and T 3 respectively represent the time from the initiation of the incoming request to the receipt of the service request, the actual time for processing the service request, and the preset time for processing the service request.

[0016] Preferably, the load balancing control unit calculates a load balancing control index Ez based on traffic control data and decision request service data, and its calculation formula is:

[0017]

[0018] In the formula, Ez represents the load balancing control index, which is used to measure the load difference between instances, and R 1 and R 2 and R 3 ...R n represent the request volumes of decision request service instances from 1 to n, and R i represents the request volume of the i-th decision request service instance. represents the average request volume of all instances, and n represents the total number of decision request service instances.

[0019] Preferably, the Kafka throughput statistics unit calculates a Kafka throughput control index Qj according to Kafka configuration data, and its calculation formula is:

[0020]

[0021] In the formula, Qj represents the throughput of Kafka, m represents the total number of messages processed within time t, t represents the observed time window, represents the average size of a single message.

[0022] Preferably, the process system transformation module verifies whether the system function service is normal according to the calculation result, and the process system transformation module is connected to the data storage module through the network;

[0023] The data storage module determines the storage plan for risk data and determines the storage time point and system.

[0024] Preferably, an intelligent risk control automated approval system integrating the FICO Blaze decision engine includes the following work processes:

[0025] Step 1: Build a credit system, a card acceptance system, an incoming center, a routing and scheduling system, a comprehensive decision-making system, Blaze, a model platform, and a feature platform in the system;

[0026] Step 2: The credit system or the card acceptance system requests the incoming center;

[0027] Step 3: The intake center is responsible for matching specific Blaze approval decision flow codes according to different intake types, different channels, product codes, and customer label attribution variables.

[0028] Step 4: Use the drag-and-drop method to arrange the intake process between Blaze projects and bind the decision flow code of Blaze.

[0029] Step 5: The configuration of the decision flow code is performed in the product configuration of the comprehensive decision-making system. The online hot deployment of the strategy is also implemented in the comprehensive decision-making system. In addition, it includes the configuration of data source interface information.

[0030] Step 6: The intake center assembles the necessary input parameter fields and decision flow codes to request the routing and scheduling system. The routing and scheduling system will query the start node of this decision flow according to the product number in the product configuration of the comprehensive decision-making system associated with the decision flow code, assemble it into the input parameters, and initiate a call to Blaze. Generally, there is no policy at the first node inside Blaze, and Blaze outputs the next node.

[0031] Step 7: DPS queries the model platform or feature platform according to the data source code associated with the comprehensive decision-making system data source configuration and requests Blaze.

[0032] Step 8: When DPS receives that the NextStep field returned by Blaze is End, it considers that the Blaze approval has a conclusion and the approval ends.

[0033] Step 9: DPS no longer calls Blaze, processes the final result and returns it to the intake center, and the intake center returns it to the upstream system, and this approval ends.

[0034] Compared with the prior art, the present invention provides an intelligent risk control automated approval system integrating the FICO Blaze decision engine, having the following beneficial effects:

[0035] 1. By adding functions such as message queue, APIs, intake request service, intake response service, traffic control, decision request service, decision data service, query service, unified exception handling service, thread pool configuration and optimization, Kafka configuration, data source service, and exception handling service in the system, the present invention realizes the comprehensive management of the system. Through the application of the above functions, the system can achieve efficient data processing and fast transmission, thereby ensuring the accuracy and real-time nature of data. At the same time, the system also has strong scalability to meet the needs of different business scenarios.

[0036] 2. By integrating the FICO Blaze decision engine, the system has the advantages of fast response and timely processing of complex business logic. The function data is collected by the data collection module and calculated in the data processing module, enabling the system to achieve in-depth data mining. At the same time, the data is improved through the process system transformation module, and with the data storage module as the data storage center, the system can optimize the function performance. The above advantages enable the system of the present invention to have efficient and accurate risk control capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 is the approval flow chart of the present invention;

[0038] Figure 2 is the system architecture diagram of the present invention;

[0039] Figure 3 is the system timing diagram of the present invention;

[0040] Figure 4 is the process call diagram for the application request service;

[0041] Figure 5 is the process management and control diagram;

[0042] Figure 6 is the decision data service call flow chart;

[0043] Figure 7 is the query service call flow chart;

[0044] Figure 8 is the data source service call flow chart. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0046] Please refer to Figure 1 - Figure 8 , an intelligent risk control automated approval system integrating the FICO Blaze decision engine. The system process consists of a credit system, a card acceptance system, an application center, a routing and scheduling system (DPS), a comprehensive decision-making system, Blaze, a model platform, and a feature platform;

[0047] The system is divided into a data collection module, a data processing module, a process system transformation module, and a data storage module, and the system functions are managed;

[0048] Advantages: By integrating the FICO Blaze decision engine, the system of the present invention has the advantages of fast response and timely processing of complex business logics. Through the data collection module, functional data is collected, and in the data processing module, functional data is calculated. The system can achieve in-depth data mining. At the same time, by improving data through the process system transformation module and using the data storage module as the data storage center, the system can optimize functional performance. The above advantages enable the system of the present invention to have efficient and accurate risk control capabilities.

[0049] The services of the system functions include: application submission request service, application submission response service, traffic control, decision request service, decision data service, query service, unified exception handling service, thread pool configuration and optimization, Kafka configuration. Additionally, a message queue, APIs, data source service, and exception handling service are added to form the complete system responsibilities;

[0050] Advantages: By adding functions such as a message queue, APIs, application submission request service, application submission response service, traffic control, decision request service, decision data service, query service, unified exception handling service, thread pool configuration and optimization, Kafka configuration, data source service, and exception handling service to the system, comprehensive management of the system is achieved. Through the application of the above functions, the system can achieve efficient data processing and fast transmission, thereby ensuring the accuracy and real-time nature of data. At the same time, the system also has strong scalability to meet the requirements of different business scenarios.

[0051] The specific system responsibilities are divided as follows:

[0052] Message queue: Receives the application submission request service and the application submission response service;

[0053] APIs: Invokes the synchronous interface for application submission and the interface for querying decision results;

[0054] Application submission request service: Parses the message packet and assembles the decision packet request;

[0055] Application submission response service: Assembles the decision result packet and sends it to the message queue;

[0056] Traffic control: Invokes the traffic control of the decision engine and the traffic control for querying decision results;

[0057] Decision request service: Invokes the decision engine interface to obtain the decision engine return result. If NextStep is not completed, external data is obtained;

[0058] Decision data service: Obtains external data, aggregates and returns the result, assembles the packet and returns the result;

[0059] Data source service: Invoke the data source interface configured by the decision and obtain the return result.

[0060] The overall system framework follows the refactored external connection, adds or deletes dependencies, and splits services according to different business intake processes.

[0061] Construction of the system thread model:

[0062] The intake request service calls the decision request service in a multi-threaded manner, and the threads are obtained from the thread pool; when the decision data service obtains decision data and calls multiple external source interfaces, it uses a multi-threaded mode, and the threads are obtained from the thread pool. The threads used by the intake request service and the threads used by the decision data service are not the same thread; the threads used to call the storage service are independent asynchronous threads, different from the threads used by the decision request service and also different from the threads used by the decision data service. The configuration of the threads refers to the product requirements specification of the data processing service. The size of the thread pool is adjusted and optimized based on machine resources and test data.

[0063] Each of the above services records logs and handles various exceptions in the service; the function design other than log and service exception handling is as follows:

[0064] Intake request service:

[0065] The process call diagram of the intake request service is as follows Figure 4 :

[0066] Verify whether the entry_id is repeated. When transmitting through TRM, set the rerun_flag flag to distinguish whether to re-run the intake of the current entry_id; if there is an intake record for the entry_id, the current intake is for the entry_id. If the flag is set to re-run, execute the intake for the current entry_id. If the flag is not set to re-run, call the intake response service to return a message indicating that the intake is repeated. When storing the intake request and response, use the data table blrt_application. Some fields are not used, and a new intake re-run flag rerun_flag is added;

[0067] Intake response service:

[0068] Assemble the result message for the timeout result and return it to the message queue; when returning normally, obtain the fields from the Blaze return message based on the product output (product output parameters) template, convert it into an application approval return message. First, read the cache to obtain the product output template. If the cache cannot be read, then read the bl_product table. Asynchronous threads store the intake response record, return the result message to the message queue, and store the processed entry_id for duplicate checking in new intake requests.

[0069] Synchronous call response:

[0070] In case of timeout, the timeout result is assembled into a timeout result message and returned to the message queue. In case of normal return, an approval return message is assembled and then returned.

[0071] Process management and control:

[0072] Traffic management and control is carried out in a sliding window manner based on the configured TPS and QPS for overall traffic management and control. When the flow control reaches the upper limit for a request initiating a call, the request waits for execution; the request continues to execute when the traffic is available, and a timeout is set. If the call times out, the result is passed to the incoming response service.

[0073] For the process management and control diagram, please refer to Figure 5 .

[0074] Decision request service: The decision request service encapsulates the interface of the Blaze decision engine and performs different processing based on the return of the Blaze service. If the Blaze return times out, the incoming response service is called to send a message to TRM; if the Blaze does not time out, it is determined whether NextStep is an End end node. If it is not ended, the decision data service is called; if it is ended, the incoming response service is called to pass the result.

[0075] The decision request service is called in a way that reuses threads in the thread pool, and logs are recorded according to the general log processing. The call records are stored in an asynchronous thread manner. Various exceptions during the operation of the processing service are handled. The decision request service stores the call records and reuses the existing data table bl_blaze_record, with some fields not used.

[0076] Decision data service: Parse the message of the Blaze request data source, read the data input (data source input parameter) template, find the field values in the template from the Blaze return message, call the external data source interface in multiple threads, aggregate and process the result data and return it; handle various exceptions during the operation of the processing service. The call flow diagram of the decision data service is as follows Figure 6 as shown:

[0077] Query service: The functional requirements of the query service are used to query the decision results, including query requests based on flow control. The functional requirements of the query service with flow control include parsing the message request to obtain the entry_id, reading the decision result based on the entry_id, assembling the query result and returning it. The call flow diagram of the query service is as follows Figure 7 as shown:

[0078] Data source service:

[0079] The data source service calls external data according to the interface code and parameters in the data interface call table. An asynchronous thread stores the call records and results and performs timeout judgment processing. If it times out, it returns a timeout result. Based on the timeout in the variable center, flexible policies are processed. The default timeout is extended by 5% compared to the variable center, and the default value is adjusted according to the test situation. The basic data source service call flow chart is as follows Figure 8 as shown

[0080] Since the variable center does not retry when reading big data platform metrics in case of timeout or reading no value, set whether to retry in case of exception, the number of retries, and the retry interval when reading big data platform metrics in the configuration center, and adjust the configured values according to the business and test situations.

[0081] Exception handling service:

[0082] The system service performs unified exception handling for aspect-oriented exceptions and prints exception logs. The unified exception handling service processes IOException classes and RuntimeException classes.

[0083] The data collection module includes the application request service data unit, the decision request service data unit, and the Kafka configuration data unit. The request service data unit obtains request service data by directly calling the API interface of the module. The decision request service data unit obtains decision request service data through message passing and data packet transmission. The Kafka configuration data unit obtains Kafka configuration data through configuration files, code settings, and environment variables. After the application request service data unit, the decision request service data unit, and the Kafka configuration data unit count and number the data within the unit, they are sent to the data processing module for calculation.

[0084] The application request service data includes the time from the start of the application request to the service receiving the request, the actual time for the service to process the request, and the preset time for the service to process the request. The time from the start of the application request to the service receiving the request, the actual time for the service to process the request, and the preset time for the service to process the request are numbered as T 1 、T 2 、T 3 respectively. The decision request service data includes the count of requests from 1 to n decision request service instances. The count of requests from 1 to n decision request service instances is numbered as R 1 、R 2 、R 3 、…R n respectively. The Kafka configuration data includes the total number of messages processed within time t, the observed time window, and the average size of a single message. The total number of messages processed within time t, the observed time window, and the average size of a single message are numbered m, t, and

[0085] The data processing module includes an incoming application response service unit, a load balancing control unit, and a Kafka throughput statistics unit. The incoming application response service unit calculates the incoming application response service efficiency Vs based on the incoming application request service data. The load balancing control unit calculates the load balancing control index Ez based on the traffic control data and the decision request service data. The Kafka throughput statistics unit calculates the Kafka throughput control index Qj based on the Kafka configuration data. After calculating the internal data of the units, the incoming application response service unit, the load balancing control unit, and the Kafka throughput statistics unit are connected to the process system transformation module through the network.

[0086] The incoming application response service unit calculates the incoming application response service efficiency Vs based on the incoming application request service data, and its calculation formula is:

[0087]

[0088] In the formula, Vs represents, T 1 、T 2 、T 3 respectively represent the time from the initiation of the incoming application request to the receipt of the service request, the actual time for the service to process the request, and the preset time for the service to process the request.

[0089] The advantages are as follows: By calculating the incoming application response service efficiency Vs, it is not only possible to verify whether the incoming application request service and the incoming application response service are normal, but also to quickly identify and optimize the bottleneck links in the processing flow. When the incoming application response service efficiency Vs is greater than 1, it indicates that the response time exceeds the threshold range, and the system needs to take measures for optimization, thereby improving the overall response speed, which helps to quickly adapt to the financial risk control scenario that requires urgent decision-making, shortening the approval time. And real-time monitoring of the incoming application response service efficiency Vs helps to discover potential problems, so as to solve problems in a timely manner to ensure that the system still operates stably under high load, which contributes to the long-term stability of the system and avoids business interruption caused by system failures.

[0090] The load balancing control unit calculates the load balancing control index Ez based on the traffic control data and the decision request service data, and its calculation formula is:

[0091]

[0092] In the formula, Ez represents the load balancing control index, which is used to measure the load difference between instances, R 1 、R 2 、R 3 、…R n represents the request volume of the decision request service instances from 1 to n, and R i represents the request volume of the i-th decision request service instance. represents the average request volume of all instances, and n represents the total number of decision request service instances.

[0093] The advantage is that by calculating the load balancing control index Ez, it can be evaluated whether the decision request service can evenly distribute requests. When the load balancing control index Ez is closer to 0, it indicates that the load is more balanced.

[0094] The Kafka throughput statistics unit calculates the Kafka throughput control index Qj according to the Kafka configuration data, and its calculation formula is:

[0095]

[0096] In the formula, Qj represents the throughput of Kafka, m represents the total number of messages processed within time t, t represents the observed time window, represents the average size of a single message.

[0097] The advantage is that by calculating the Kafka throughput control index Qj, it can be evaluated whether the throughput of Kafka meets the system requirements. When the Kafka throughput control index Qj is lower than the system preset requirements, it is necessary to redesign or optimize the Kafka configuration.

[0098] The process system transformation module verifies whether the system function services (incoming request service, incoming response service, traffic control, decision request service, decision data service) are normal according to the calculation results. The process system transformation module is connected to the data storage module through the network;

[0099] The data storage module determines the storage plan for risk data, and determines the storage time point and system.

[0100] An intelligent risk control automated approval system integrating the FICO Blaze decision engine includes the following work processes:

[0101] Step 1: Build a credit system, a card acceptance system, an incoming center, a routing and scheduling system (DPS), a comprehensive decision-making system, Blaze, a model platform, and a feature platform in the system;

[0102] Step 2: The credit system or the card acceptance system requests the incoming center;

[0103] Step 3: The incoming center is responsible for matching specific Blaze approval decision flow codes according to different incoming types (general quota, special quota, drawdown, limit adjustment, price adjustment, temporary quota, temporary price), different channels, product codes, and customer label attribution variables;

[0104] Step 4: Use the method of towing and pulling to arrange the incoming process among Blaze projects; for example, for self-operated cash credit incoming, general quota, 19 channels, wildcard tags or no tags, and bind the decision flow code of Blaze;

[0105] Step 5: The configuration of the decision flow code is carried out in the product configuration of the comprehensive decision-making system, and the online hot deployment of the strategy is also realized in the comprehensive decision-making system. In addition, it also includes the configuration of the interface information of the data source;

[0106] Step 6: The incoming center assembles the necessary input parameter fields and the decision flow code to request the routing and scheduling system. The routing and scheduling system will query the start node of this decision flow (such as "ZYSX_N010") according to the product number associated with the decision flow code in the product configuration of the comprehensive decision-making system, assemble the field "callStep": "ZYSX_N010" into the input parameters, and initiate a call to Blaze. Generally, there is no policy for the first node inside Blaze. Blaze outputs the next node, "NextStep": "ZYSX_N020" and the data sources required for the next node, "RequiredDatasource": "tongye,os,bigData" (multiple data sources are separated by English commas). DPS receives these two fields and will separate the value of RequiredDatasource by English commas to obtain multiple data source codes;

[0107] Step 7: The DPS queries the model platform or feature platform based on the data source encoding associated with the comprehensive decision-making system data source configuration and requests Blaze; updates the data source return message and the callStep field to ZYSX_N020; if "callStep": "ZYSX_N020", assemble it into the input parameters and request Blaze again. Blaze will split the flow according to this callStep internally and can obtain some variables of the data source passed into the input parameters to perform the admission rule logic check. For example, ZYSX_N020 follows the admission rules for self-operated cash credit. If the rules are not hit, then Blaze will output "NextStep": "ZYSX_N030" and the data source required for the next node, such as "RequiredDatasource": "fqzS2011". The DPS queries the fqzS2011 data source, splices and appends it to the input parameters, and at this time "callStep": "ZYSX_N030", and continues to request Blaze. At this time, the internal split of Blaze for N030 follows the anti-fraud rules. If the rules are hit and rejected, Blaze outputs the rule decision result at this time, "FinalResult": "D", and the next node field outputs End, "NextStep": "End", and the data source required for the next node is empty: "RequiredDatasource": "".

[0109] Step 8: When the DPS receives that the NextStep field returned by Blaze is End, it considers that Blaze has reached a conclusion on the approval and the approval is over.

[0110] Step 9: The DPS no longer calls Blaze, processes the final result and returns it to the application center, and the application center returns it to the upstream system, and this approval is over.

[0111] Although the embodiments of the present invention have been shown and described, for those of ordinary skill in the art, it is understood that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. An intelligent risk control automated approval system integrated with the FICO Blaze decision engine, characterized in that: The system process consists of a credit system, a payment collection system, an application center, a routing and scheduling system, a comprehensive decision-making system, Blaze, a model platform, and a feature platform; The system is divided into a data collection module, a data processing module, a process system transformation module and a data storage module, and manages the system functions; The services of the system functions include: submission request service, submission response service, flow control, decision request service, decision data service, query service, unified exception handling service, thread pool configuration and optimization, and Kafka configuration.

2. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 1, characterized in that: The overall framework of the system continues to reconstruct external connections, add or delete dependencies, and split services according to the consumption of different business inputs.

3. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 1, characterized in that: The data collection module includes an incoming request service data unit, a decision request service data unit and a Kafka configuration data unit. The request service data unit obtains request service data by directly calling the module's API interface. The decision request service data unit obtains decision request service data through message passing and data packet transmission. The Kafka configuration data unit obtains Kafka configuration data through configuration files, code settings and environment variables. The incoming request service data unit, the decision request service data unit and the Kafka configuration data unit count and number the data in the units and then transmit them to the data processing module for calculation.

4. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 3, characterized in that: The incoming request service data includes statistics on the time from the initiation of the incoming request to the service receiving request, the actual time of the service processing request and the preset time of the service processing request, and the time from the initiation of the incoming request to the service receiving request, the actual time of the service processing request and the preset time of the service processing request are numbered T1, T2, and T3 respectively; the decision request service data includes statistics on the request volume of decision request service instances from 1 to n, and the request volume of decision request service instances from 1 to n are numbered R1, R2, R3, ... R n The Kafka configuration data includes statistics on the total number of messages processed within time t, the observed time window, and the average size of a single message. The total number of messages processed within time t, the observed time window, and the average size of a single message are numbered m, t, 5. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 3, characterized in that: The data processing module includes an incoming response service unit, a load balancing control unit and a Kafka throughput statistics unit. The incoming response service unit calculates the incoming response service efficiency Vs based on the incoming request service data. The load balancing control unit calculates the load balancing control index Ez based on the flow control data and the decision request service data. The Kafka throughput statistics unit calculates the Kafka throughput control index Qj based on the Kafka configuration data. After calculating the internal data of the unit, the incoming response service unit, the load balancing control unit and the Kafka throughput statistics unit are connected to the process system transformation module through the network.

6. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 5, characterized in that: The incoming document response service unit calculates the incoming document response service efficiency Vs according to the incoming document request service data, and the calculation formula is: In the formula, Vs represents, T1, T2, and T3 represent the time from the initiation of the application request to the service receiving the request, the actual time for the service to process the request, and the preset time for the service to process the request, respectively.

7. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 5, characterized in that: The load balancing control unit calculates the load balancing control index Ez according to the flow control data and the decision request service data, and the calculation formula is: In the formula, Ez represents the load balancing control index, which is used to measure the load difference between instances, R1, R2, R3, ... R n represents the number of requests from 1 to n decision request service instances, R i represents the request volume of the i-th decision request service instance, represents the average number of requests for all instances, and n represents the total number of decision request service instances.

8. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 5, characterized in that: The Kafka throughput statistics unit calculates the Kafka throughput control index Qj according to the Kafka configuration data, and the calculation formula is: In the formula, Qj represents the throughput of Kafka, m represents the total number of messages processed within time t, and t represents the observation time window. Indicates the average size of a single message.

9. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 8, characterized in that: The process system transformation module verifies whether the system function service is normal according to the calculation result, and the process system transformation module is connected with the data storage module through the network; The data preservation module determines a preservation plan for risk data and determines a preservation time point and system.

10. The intelligent risk control automated approval system integrated with the FICO Blaze decision engine according to claim 1, characterized in that: The workflow includes the following: Step 1: Build the credit system, acquiring system, application center, routing and scheduling system (DPS), comprehensive decision-making system, Blaze, model platform, and feature platform in the system; Step 2: The credit system or acquiring system requests the processing center; Step 3: The application center is responsible for matching specific Blaze approval decision flow codes according to different application types, channels, product codes, and customer tag attribution variables; Step 4: Use the drag-and-drop method to arrange the application flow between Blaze projects and bind the decision flow code of Blaze; Step 5: The decision flow encoding is configured in the product configuration of the comprehensive decision system. The online hot deployment of the strategy is also implemented in the comprehensive decision system. In addition, the interface information configuration of the data source is also included. Step 6: The application center assembles the necessary input parameter fields and decision flow codes to request the routing scheduling system. The routing scheduling system will use the decision flow code to associate the product number in the product configuration of the integrated decision system with the start node of this decision flow to assemble the input parameters and initiate a call to Blaze. Generally, there is no strategy when entering the first node inside Blaze, and Blaze outputs the next node. Step 7: DPS associates the data source of the comprehensive decision-making system with the data source code to configure the query model platform or feature platform and requests Blaze; Step 8: When DPS receives a message from Blaze with the NextStep field set to End, it assumes that Blaze has concluded the approval and the approval is complete. Step 9. DPS will no longer call Blaze and will process the final result and return it to the application center. The application center will return it to the upstream system and the approval is completed.

Images