A visualized risk control variable online development method and device

Abstract

The application relates to the field of information technology, and provides a visual online development method and device for risk control variables. In the prior art, the variable logic needs to be written in code by a developer, the risk control variable development process is long, the online period is long, real-time updating cannot be achieved, and the maintenance workload of the developer is large. The main scheme comprises the following steps: obtaining the value of a metadata field, a basic function and a logic operator; combining the value of the basic metadata field, the basic function and the logic operator to define a new risk control variable; testing and checking the risk control variable to obtain a variable rule well combined by front-end editing; saving the variable rule well combined by front-end editing, compiling to generate an executable bytecode file; finding all cached variable rule servers to sequentially notify the variable rule updating of the bytecode file obtained through step 4, and updating the variable rule loaded in the memory by the variable rule server.

Description

Technical Field

[0001] This invention relates to the field of risk control technology applications in financial companies, and provides a method and apparatus for online development of visualized risk control variables. Background Technology

[0002] Risk control variables are an essential component in financial risk control for assessing customer creditworthiness. Financial companies require various data points to determine a customer's credit rating, and these data are processed according to business logic to become a risk control variable. The common practice is for strategy personnel to define the processing logic, submit development requirements to developers, who then develop, test, and deploy the variable before strategy personnel can use it. However, as business grows, company strategies become increasingly complex, requiring more and more risk control variables, and historical variables need frequent updates. The current approach involves strategy personnel submitting requirements, developers developing, deploying, and updating the risk control variable. This approach has the following drawbacks: First, the process is too lengthy and time-consuming; it takes at least a day from requirement submission to deployment for a single risk control variable, increasing development costs when there are many development requirements but a fixed timeframe. Second, if an emergency requires correcting a risk control variable's logic, the inability to do so in real time can significantly impact the accuracy of risk control. Finally, a large number of developers are bogged down in the tedious and repetitive work of developing and maintaining risk control variables, impacting team productivity. Summary of the Invention

[0003] This addresses the following issues: In existing technologies, each variable requires developers to hardcode the variable logic in code, resulting in a long development process, long deployment cycle, inability to achieve real-time updates, and a heavy workload for developers in maintaining risk control variables.

[0004] To achieve the above objectives, the present invention employs the following technical means:

[0005] A visual online method for developing risk control variables includes the following steps:

[0006] Step 1: Retrieve the values ​​of the metadata fields to be processed, basic functions, and logical operators from the database;

[0007] Step 2: Display the values ​​of the basic metadata fields, basic functions, and logical operators on the controls of the front-end page. The controls support drag-and-drop, drop-down selection, and text input to combine and define a new risk control variable.

[0008] Step 3: Testing and Verification. After the risk control variable logic is completed online, it needs to be tested and verified to see if it can achieve the desired effect. Here, test data will be required. The system will execute the risk control variable logic just created based on the test data and output the result strategy. Only after the verification is passed can it be submitted and saved, and the variable rules combined by the front-end editor will be obtained.

[0009] Step 4: Save the variable rules compiled by the front-end editor. During the saving process, the corresponding Java logic code is dynamically generated. The generation process includes automatically adding the required dependency packages, checking whether the text entered by the editor contains illegal executable code, and finally compiling to generate an executable bytecode file and saving it to the database.

[0010] Step 5: After creating or updating the risk control variables, you need to submit them for review. This review is to prevent unverified variable logic from being used in production due to operational errors.

[0011] Step 6: After the review is approved, the service that executed the review process will find all the cached variable rule servers and notify them in turn to update the cached variable rules by executing the bytecode file obtained in Step 4. The cached variable rule servers will then update the variable rules loaded in memory.

[0012] In the above technical solution, the basic functions include data processing functions, string processing functions, and date processing functions.

[0013] In the above technical solution, the basic functions are divided into two categories: modifiable user-defined functions and unmodifiable basic functions.

[0014] In the above technical solution, in step 6,

[0015] 6.1 After the program starts, all machines in the server cluster will subscribe to the data change events of the ZooKeeper nodes through the publish / subscribe function of the ZooKeeper middleware;

[0016] 6.2 In a distributed environment, the approval command is executed by one of the machines in the server cluster. This machine sends a message to ZooKeeper: "The rules for the variable have changed. The server cluster needs to update the variable rule cache."

[0017] 6.3 After receiving a rule change message, ZooKeeper will forward the message to all subscribed machines. After receiving the message, the server cluster will start to retrieve the compiled bytecode file from the MySQL table using the variable id in the message, load it into an object, and then cache it in the JVM.

[0018] This invention also provides a visual online development device for risk control variables, comprising:

[0019] Data acquisition module: Retrieves the values ​​of metadata fields to be processed, basic functions, and logical operators from the database;

[0020] Risk control variable operation module: Displays the values ​​of basic metadata fields, basic functions and logical operators on the controls of the front-end page. The controls support drag and drop, drop-down selection and text box input to combine and define a new risk control variable;

[0021] Test and Validation Module: After the risk control variable logic is completed online, it needs to be tested and validated to see if it can achieve the desired effect. Here, test data (simulating the value corresponding to a customer metadata field) will be required. The system will execute the risk control variable logic just created based on the test data and output the result strategy. Only after the strategy passes the validation (the person who defined the risk control variable knows the result that should be obtained after inputting the custom data) can it be submitted and saved, and the variable rules combined by the front-end editor will be obtained.

[0022] The compilation module saves the variable rules combined by the front-end editor. During the saving process, the corresponding Java logic code is dynamically generated. The generation process includes automatically adding the required dependency packages, checking whether the text entered by the editor contains illegal executable code, and finally compiling to generate an executable bytecode file and saving it to the database.

[0023] Review module: After creating or updating risk control variables, they need to be submitted for review. This review is to prevent unverified variable logic from being used in production due to operational errors.

[0024] Update module: After the review is approved, the service that executes the review process will find all the cached variable rule servers and notify them in turn to update the cached variable rules by executing the bytecode file obtained in step 4. The cached variable rule servers will then update the variable rules loaded in memory.

[0025] In the above technical solution, the basic functions include data processing functions, string processing functions, and date processing functions.

[0026] In the above technical solution, the basic functions are divided into two categories: modifiable user-defined functions and unmodifiable basic functions.

[0027] In the above technical solution, the update module implementation includes the following steps:

[0028] 6.1 After the program starts, all machines in the server cluster will subscribe to the data change events of the ZooKeeper nodes through the publish / subscribe function of the ZooKeeper middleware;

[0029] 6.2 In a distributed environment, the approval command is executed by one of the machines in the server cluster. This machine sends a message to ZooKeeper: "The rules for the variable have changed. The server cluster needs to update the variable rule cache."

[0030] 6.3 After receiving a rule change message, ZooKeeper will forward the message to all subscribed machines. After receiving the message, the server cluster will start to retrieve the compiled bytecode file from the MySQL table using the variable id in the message, load it into an object, and then cache it in the JVM.

[0031] Because the present invention adopts the above-described technical solution, it has the following beneficial effects:

[0032] 1. Variable creation and update are configured on the page, eliminating the need for development and deployment, thus improving the strategy iteration cycle.

[0033] 2. Supports strategy personnel to verify risk control variables online in real time.

[0034] 3. In a distributed cluster multi-machine environment, the rules cache is updated in real time after the risk control variables are added / updated. Attached Figure Description

[0035] Figure 1 For variable operation processes;

[0036] Figure 2 Create / update flowcharts for variables;

[0037] Figure 3 Update and publish the variable. Detailed Implementation

[0038] The embodiments of the present invention will be described in detail below. Although the present invention will be described and illustrated in conjunction with some specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, any modifications or equivalent substitutions made to the present invention should be covered within the scope of the claims of the present invention.

[0039] Furthermore, to better illustrate the present invention, numerous specific details are set forth in the following detailed embodiments. Those skilled in the art will understand that the present invention can be practiced without these specific details.

[0040] This invention provides a visual online method for developing risk control variables, comprising the following steps:

[0041] Step 1: Retrieve the fields (each customer has a different value), basic functions, and logical operators corresponding to the source data to be processed from the database;

[0042] Step 2: Display the basic source data fields, basic functions, and logical operators on the controls of the front-end page. The controls support drag-and-drop, drop-down selection, and text input to combine and define a new risk control variable.

[0043] Step 3: Testing and Verification. After the risk control variable logic is completed online, it needs to be tested and verified to ensure it achieves its intended effect. This requires inputting test data (simulating the value of a customer source data field). The system will execute the risk control variable logic created earlier based on the test data and output the result strategy. Only after the strategy passes verification (the person who defined the risk control variable knows the result that should be obtained after inputting the custom data) can it be submitted and saved.

[0044] Step 4: Save the variable rules compiled by the front-end editor. During the saving process, the corresponding Java logic code is dynamically generated. The generation process includes automatically adding the required dependency packages, checking whether the text entered by the editor contains illegal executable code, and finally compiling to generate an executable bytecode file and saving it to the database.

[0045] 4.1 Generating Java logic code

[0046] a. Java class names should use variable names + timestamps.

[0047] b. The method name is invoke, the return value is Object, and the input parameter is UserInfo (the metadata field in step 1 corresponds to the UserInfo attribute).

[0048] c. Import fixed dependency packages

[0049] d. Rules for inserting page editing

[0050] 4.2 After combining the Java code, use the code inspection component SourceForg-PDM to check for illegal code.

[0051] 4.3 Compile the code to generate bytecode and save it to the MySQL database. Specify a field in the risk control data MySQL table to store the source data to be processed;

[0052] Step 5: After creating or updating risk control variables, they need to be submitted for review. This review is to prevent unverified variable logic from being used in production due to operational errors. The review is to verify the variable rules. Only compiled rules can provide the ability to test rules. If the review is passed but the rule cannot be compiled, an exception will occur and become uncontrollable.

[0053] Step 6: After approval, the service executing the approval process will find all servers that cache variable rules and notify them to update the variable cache in turn. The servers that cache variable rules will then update the rules loaded in memory. At this point, the newly created or updated variable rules are ready for use in the production environment.

[0054] 6.1 After the program starts, all machines in the server cluster will subscribe to the data change events of the zookeepr nodes through the publish / subscribe function of the zookeepr middleware.

[0055] 6.2 In a distributed environment, the approval command is executed by one of the machines in the server cluster. This machine sends a message to ZooKeeper: "The rules for the variable have changed. The server cluster needs to update the variable rule cache."

[0056] 6.3 After receiving a rule change message, ZooKeeper will forward the message to all subscribed machines. After receiving the message, the server cluster will start to retrieve the compiled bytecode from the MySQL table using the variable id in the message, load it into an object, and then cache it in the JVM.

[0057] In the above technical solution, the basic functions include data processing functions, string processing functions, and date processing functions.

[0058] In the above technical solution, the basic functions are divided into two categories: modifiable user-defined functions and unmodifiable basic functions.

Claims

1. A method for developing visualized risk control variables online, characterized in that, Includes the following steps: Step 1: Retrieve the values ​​of the metadata fields to be processed, basic functions, and logical operators from the database; Step 2: Display the values ​​of the basic metadata fields, basic functions, and logical operators on the controls of the front-end page. The controls support drag-and-drop, drop-down selection, and text input to combine and define a new risk control variable. Step 3: Testing and Verification. After the risk control variable logic is completed online, it needs to be tested and verified to see if it can achieve the desired effect. Here, test data will be required. The system will execute the risk control variable logic just created based on the test data and output the result strategy. Only after the verification is passed can it be submitted and saved, and the variable rules combined by the front-end editor will be obtained. Step 4: Save the variable rules compiled by the front-end editor. During the saving process, the corresponding Java logic code is dynamically generated. The generation process includes automatically adding the required dependency packages, checking whether the text entered by the editor contains illegal executable code, and finally compiling to generate an executable bytecode file and saving it to the database. Step 5: After creating or updating the risk control variables, you need to submit them for review. This review is to prevent unverified variable logic from being used in production due to operational errors. Step 6: After the review is approved, the service that executed the review process will find all the cached variable rule servers and notify them in turn to update the cached variable rules by executing the bytecode file obtained in Step 4. The cached variable rule servers will then update the variable rules loaded in memory.

2. The method for online development of visualized risk control variables according to claim 1, characterized in that, In step 1, the basic functions include data processing functions, string processing functions, and date processing functions.

3. The method for online development of visualized risk control variables according to claim 2, characterized in that, In step 1, the basic functions are divided into two categories: custom functions that can be modified and basic functions that cannot be modified.

4. The method for online development of visualized risk control variables according to claim 2, characterized in that, In step 6, Step 6.1: After the program starts, all machines in the server cluster will subscribe to the data change events of the ZooKeeper nodes through the publish / subscribe function of the ZooKeeper middleware; Step 6.2: In a distributed environment, the approval command is executed by one of the machines in the server cluster. This machine sends a message to ZooKeeper: "The rules for the variable have changed. The server cluster needs to update the variable rule cache." Step 6.3: After receiving the rule change message, ZooKeeper will forward the message to all subscribed machines. After receiving the message, the server cluster will start to retrieve the compiled bytecode file from the MySQL table using the variable id in the message, load it into an object, and then cache it in the JVM.

5. A visual online development device for risk control variables, characterized in that, include: Data acquisition module: Retrieves the values ​​of metadata fields to be processed, basic functions, and logical operators from the database; Risk control variable operation module: Displays the values ​​of basic metadata fields, basic functions and logical operators on the controls of the front-end page. The controls support drag and drop, drop-down selection and text box input to combine and define a new risk control variable; Test and Verification Module: After the risk control variable logic is completed online, it needs to be tested and verified to see if it can achieve the desired effect. This will require inputting test data. The system will execute the risk control variable logic just created based on the test data and output the result strategy. Only after the verification is passed can it be submitted and saved, and the variable rules combined by the front-end editor are obtained. The compilation module saves the variable rules combined by the front-end editor. During the saving process, the corresponding Java logic code is dynamically generated. The generation process includes automatically adding the required dependency packages, checking whether the text entered by the editor contains illegal executable code, and finally compiling to generate an executable bytecode file and saving it to the database. Review module: After creating or updating risk control variables, they need to be submitted for review. This review is to prevent unverified variable logic from being used in production due to operational errors. Update module: After the review is approved, the service that executes the review process will find all the cached variable rule servers and notify them in turn to update the cached variable rules by executing the bytecode file obtained in step 4. The cached variable rule servers will then update the variable rules loaded in memory.

6. The visualized online development device for risk control variables according to claim 5, characterized in that, In the data acquisition module, the basic functions include data processing functions, string processing functions, and date processing functions.

7. The visualized online development device for risk control variables according to claim 6, characterized in that, In the data acquisition module, basic functions are divided into two categories: custom functions that can be modified and basic functions that cannot be modified.

8. The visualized online development device for risk control variables according to claim 6, characterized in that, The update module implementation includes the following steps: Step 6.1: After the program starts, all machines in the server cluster will subscribe to the data change events of the ZooKeeper nodes through the publish / subscribe function of the ZooKeeper middleware; Step 6.2: In a distributed environment, the approval command is executed by one of the machines in the server cluster. This machine sends a message to ZooKeeper: "The rules for the variable have changed. The server cluster needs to update the variable rule cache." Step 6.3: After receiving the rule change message, ZooKeeper will forward the message to all subscribed machines. After receiving the message, the server cluster will start to retrieve the compiled bytecode file from the MySQL table using the variable id in the message, load it into an object, and then cache it in the JVM.

Images