Rule engine configuration method and device, risk control method and device, computer equipment and storage medium

Abstract

The invention provides a rule engine configuration method. And in the interface configuration link, an optional interface is set according to the configuration metadata in the interface configuration request. A strategy factor is configured for a target event, risk assessment on the event from different dimensions is supported, and then a factor condition containing an interface expression is configured for the strategy factor so as to accurately judge the hit condition of the strategy factor. And finally, in response to a rule online request, deploying the rule to a rule engine. According to the scheme, high flexibility of rule configuration is realized, complex logic calculation can be carried out, unstructured data is effectively utilized, and a more accurate risk control strategy is realized. The pluggable interface expression can realize the effect of introducing a multi-party interface through configuration, so that the strategy factor requirement of a complex scene can be more flexibly realized while the more complex business logic problem is solved.

Description

Technical Field

[0001] This application relates to the technical field of rule engines, and particularly to a risk control, rule engine configuration method, device, computer device, and storage medium. Background Art

[0002] In the field of Internet risk control, as a core decision-making tool, the rule engine is widely used in scenarios such as anti-fraud, impact assessment, and transaction monitoring. Traditional rule engines perform logical judgments on input data through a predefined rule library, with the advantages of fast response and strong parsability. However, with the explosive growth of scenarios such as finance and social networking, risk patterns have become dynamic, hidden, and highly adversarial. The strategy update of traditional rule engines depends on code or configuration file changes, making it difficult to respond to new risks in real time and to describe multi-level association rules. Summary of the Invention

[0003] The purpose of this application is to at least solve one of the above technical defects, especially the defect that the rule engine in the prior art is difficult to respond to new risks in real time and is also difficult to describe multi-level association rules.

[0004] In a first aspect, this application provides a rule engine configuration method, including:

[0005] In response to an interface configuration request, set optional interfaces according to the configuration metadata carried in the interface configuration request, where the optional interfaces include at least one interface dimension;

[0006] In response to a rule configuration request for a target event, configure at least one policy factor; the hit situation of the policy factor is used to determine the rule hit situation of the target event;

[0007] In response to a condition configuration request for any policy factor, configure at least one factor condition; the hit situation of the factor condition determines the hit situation of the corresponding policy factor, and the factor condition includes an interface expression, the interface expression corresponds to the optional interface, and includes at least one multi-dimensional sub-expression, and the multi-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data obtained from at least one interface dimension of the corresponding optional interface meets a set first condition;

[0008] In response to a rule online request for a target event, put the rule of the target event online to the rule engine, so that when the target event is triggered, it is judged whether the target event hits the rule in turn according to whether the configured factor condition and policy factor are hit.

[0009] In one embodiment, the factor condition further includes a regular expression, and the regular expression includes at least one single-dimensional sub-expression, and the single-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data in a single dimension meets a set second condition.

[0010] In one embodiment, the configuration metadata includes interface metadata, interface request metadata, and interface response metadata; the interface metadata declares information required to access an optional interface, the interface request metadata declares information on the interface dimensions supported by the optional interface, and the interface response metadata declares information on the fields supported for query in the response message of the optional interface.

[0011] In one embodiment, in response to a rule configuration request for a target event, at least one policy factor is configured, including:

[0012] In response to a factor establishment request, a policy factor is established;

[0013] In response to a first relationship establishment request, a first logical hit relationship is established between at least two policy factors; the first logical hit relationship is used to determine the relationship between the hit situation of the policy factor and the rule hit situation of the target event.

[0014] In one embodiment, in response to a condition configuration request for any policy factor, at least one factor condition is configured, including:

[0015] In response to an interface expression establishment request for any policy factor, a single factor condition is established within the interface expression or at least two factor conditions connected by a second logical hit relationship are established; the second logical hit relationship is used to determine the relationship between the hit situation of the factor condition and the hit situation of the interface expression;

[0016] In response to a configuration request for a factor condition within any interface expression, a target interface is determined from the optional interfaces, a target dimension is determined from the interface dimensions of the target interface, and a first condition corresponding to the target dimension is determined.

[0017] In one embodiment, in response to an interface expression establishment request for any policy factor, a single factor condition is established within the interface expression or at least two factor conditions connected by a second logical hit relationship are established, including:

[0018] Display multiple condition combination templates containing multi-level nested second logical hit relationships;

[0019] In response to a selection request for any condition combination template, at least two factor conditions connected by a second logical hit relationship are established according to the condition combination template.

[0020] In a second aspect, the present application provides a risk control method, including:

[0021] For any event to be monitored, rules are configured according to the rule engine configuration method in any of the above embodiments;

[0022] After the event to be monitored is triggered, it is determined whether the event to be monitored hits the rule by successively judging whether the factor conditions corresponding to the event to be monitored and the policy factors hit.

[0023] Determine the corresponding risk control strategy according to the rule hit situation of the event to be monitored.

[0024] Perform risk control on the event to be monitored according to the risk control strategy.

[0025] In a third aspect, the present application provides a rule engine configuration device, including:

[0026] A first response module, configured to respond to an interface configuration request and set an optional interface according to the configuration metadata carried in the interface configuration request, where the optional interface includes at least one interface dimension;

[0027] A second response module, configured to respond to a rule configuration request for a target event and configure at least one policy factor; the hit situation of the policy factor is used to determine the rule hit situation of the target event;

[0028] A third response module, configured to respond to a condition configuration request for any policy factor and configure at least one factor condition; the hit situation of the factor condition determines the hit situation of the corresponding policy factor, and the factor condition includes an interface expression, the interface expression corresponds to the optional interface, and includes at least one multi-dimensional sub-expression, and the multi-dimensional sub-expression is used to determine whether the corresponding factor condition hits according to whether the data obtained from at least one interface dimension of the corresponding optional interface meets a set first condition;

[0029] A fourth response module, configured to respond to a rule online request for a target event and online the rule of the target event to the rule engine, so that when the target event is triggered, it is determined whether the target event hits the rule by successively judging whether the configured factor conditions and policy factors hit.

[0030] In a fourth aspect, the present application provides a computer device, including one or more processors and a memory, where computer-readable instructions are stored in the memory, and when the computer-readable instructions are executed by one or more processors, the steps of the rule engine configuration method in any of the above embodiments are executed.

[0031] In a fifth aspect, the present application provides a storage medium, in which computer-readable instructions are stored, and when the computer-readable instructions are executed by one or more processors, one or more processors are caused to execute the steps of the motion video generation method in any of the above embodiments.

[0032] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0033] This solution focuses on the configuration of the rules engine, covering key steps such as interface configuration, policy factor configuration, factor condition configuration, and rule deployment. In the interface configuration step, optional interfaces are set according to the configuration metadata in the interface configuration request, providing a data source for subsequent rule configuration. Policy factors are configured for target events, supporting risk assessment of events from different dimensions. Then, factor conditions containing interface expressions are configured for the policy factors to accurately judge the hit situation of the policy factors. Finally, in response to the rule deployment request, the rules are deployed to the rules engine. This solution realizes a high degree of flexibility in rule configuration. Operational personnel can easily complete complex policy configurations, improving operational efficiency. At the same time, the functions of the rules engine are enhanced, enabling complex logical calculations, effectively utilizing unstructured data, and implementing more accurate risk control strategies. The pluggable interface expressions can reduce the work of R & D personnel through configuration and achieve the effect of introducing multiple interfaces. Different teams (multiple languages and heterogeneous systems) can be referenced to provide interfaces to implement and solve more complex business logic problems, and at the same time, the policy factor requirements in complex scenarios can be realized more flexibly. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0035] Figure 1 Flow chart of the rules engine configuration method provided by an embodiment of the present application;

[0036] Figure 2 Flow chart of configuring policy factors in an embodiment of the present application;

[0037] Figure 3 Flow chart of configuring factor conditions in an embodiment of the present application;

[0038] Figure 4 Flow chart of configuring factor conditions in another embodiment of the present application;

[0039] Figure 5 Flow chart of the risk control method provided by an embodiment of the present application;

[0040] Figure 6 Internal structure diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts belong to the scope of protection of the present application.

[0042] The present application provides a method for configuring a rule engine. Please refer to Figure 1 , which includes steps S102 to S108.

[0043] S102. In response to an interface configuration request, set optional interfaces according to the configuration metadata carried in the interface configuration request. The optional interfaces include at least one interface dimension.

[0044] It can be understood that the interface configuration request refers to a request sent by a user to the rule engine for configuring interface-related parameters and attributes, and its purpose is to set interface resources available for subsequent rule configuration. The configuration metadata contains information related to the use of the interface, and this information is used to accurately define and describe the characteristics and functions of the interface, so that the computer device can call the interface according to the configuration metadata. The optional interfaces are interfaces set according to the configuration metadata and available for selection during rule configuration. Each optional interface includes at least one interface dimension. The interface dimension is a classification of the data that can be produced by the interface from different perspectives. For example, data is obtained from the interface according to at least one field, and each field corresponds to an interface dimension. It can also be data obtained after processing the original data obtained from the interface according to more than one processing logic, and each processing logic corresponds to an interface dimension. For example, if a certain optional interface is related to the situation of face recognition, the interface dimensions may include a specified device, a specified account, a face scenario, a time period, etc. The optional interfaces here can be internal interfaces or external interfaces, as long as data can be obtained by sending a request.

[0045] To achieve precise risk identification and prevention and control, the rules engine needs to access various types of interface data. The role of the interface configuration request is to initiate the interface configuration process. By clarifying the various attributes and dimensions of the interface, the rules engine can flexibly select appropriate interface data for analysis and judgment according to different risk control strategy requirements during the subsequent rule configuration process, laying a foundation for implementing complex risk control logics. After receiving the interface configuration request, the configuration metadata therein is parsed. For example, using the Spring Cloud framework in the Java language, by defining relevant interface configuration controllers and services, the configuration metadata is obtained from the request and stored in the database. When storing, it is structured and stored according to fields such as interface id and request method, facilitating subsequent query and invocation. For the setting of optional interfaces, corresponding table structures can be created in the database, with each optional interface as a record, and the interface dimensions can be recorded by means of field extension or establishing an associated table.

[0046] S104, in response to a rule configuration request for a target event, configure at least one policy factor. The hit situation of the policy factor is used to determine the rule hit situation of the target event.

[0047] It can be understood that the target event refers to a specific business event that requires risk assessment and rule judgment in the Internet risk control scenario, such as a user's login behavior, transaction behavior, etc. The rule configuration request is a request sent by the user to the rules engine for configuring risk control rules for the target event. The rules engine is composed of multiple configured risk control rules. When the rules engine runs, it will determine whether the risk control rules therein are satisfied, thereby deciding how to perform risk control. The policy factor is a basic component of the risk control rule. Each policy factor conducts a risk assessment of the target event from a specific perspective. Therefore, the hit situation of each policy factor will affect the rule hit situation of the target event. For example, when judging whether there is a risk in a user's login, "the number of abnormal logins in the past 7 days" can be used as a policy factor. When there is only one policy factor, the hit situation of this policy factor is the hit situation of the corresponding risk control rule. When there are two or more policy factors, there can be a default logical relationship, such as when all policy factors are hit, the corresponding risk control rule is hit, or it can be a logical relationship configured by the user. The total result calculated by combining all policy factors with the logical relationship determines the hit situation of the corresponding risk control rule.

[0048] Different target events require different rules for risk assessment. The rule configuration request provides an entry for users to configure rules, while configuring policy factors is a key step in building rules. By setting at least one policy factor, it supports the analysis and judgment of target events from different perspectives. Each policy factor cooperates with each other to form a multi-dimensional filtering policy for comprehensive risk screening of target events. For example, in the anti-fraud scenario, one policy factor can focus on the abnormal changes in transaction amounts, and another policy factor can focus on the risk level of transaction addresses. By integrating the judgment results of multiple policy factors, it can more accurately determine whether there is a risk in the target event. A visual rule configuration tool can be provided on the front-end interface of the rule engine. Users can create or select a certain event as the target event on the front-end page, and then create at least one policy factor in the target event. The historical policy factors used by each successfully configured event can be recorded in the storage unit. Events can be labeled according to fields, departments, etc. When configuring a target event, the historical policy factors used by events with the same label as the target event can be displayed to the user according to the usage frequency, so that users can save the trouble of repeated configuration.

[0049] S106. In response to a condition configuration request for any policy factor, configure at least one factor condition. The hit situation of the factor condition determines the hit situation of the corresponding policy factor. The factor condition includes an interface expression, and the interface expression corresponds to an optional interface and includes at least one multi-dimensional sub-expression. The multi-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data obtained from at least one interface dimension of the corresponding optional interface meets the set first condition.

[0050] It can be understood that the conditional configuration request for a policy factor is a request from a user to set specific judgment conditions for a specific policy factor. The factor condition is the specific judgment criterion for determining whether a policy factor is hit. A policy factor can include one or more factor conditions. The interface expression is a type of factor condition, which corresponds to an optional interface and consists of at least one multi-dimensional sub-expression. The multi-dimensional sub-expression obtains data from at least one interface dimension of the corresponding optional interface and determines whether the factor condition is hit according to the set first condition. The first condition can include logical operators and thresholds. The multi-dimensional sub-expression can connect the data that attempts to be read from the interface with the threshold through logical operators and perform a logical judgment to determine whether the corresponding multi-dimensional sub-expression is hit. For example, query the number of successful times of the specified device A in the face scenario 1-1 in the past 24 hours from the interface related to the face recognition example above, and the corresponding first condition can be less than 3. If the query result is 2, then this multi-dimensional sub-expression is hit. When a factor condition of the interface expression type includes only one multi-dimensional sub-expression, if the multi-dimensional sub-expression meets the corresponding first condition, the corresponding factor condition is hit. When a factor condition of the interface expression type includes two or more multi-dimensional sub-expressions, there can be a default logical relationship. For example, when all multi-dimensional sub-expressions are hit, the corresponding factor condition is hit, or it can be a logical relationship configured by the user. The total result calculated by combining all multi-dimensional sub-expressions with the logical relationship determines the hit situation of the corresponding factor condition.

[0051] The interface expression interacts with the optional interface to extract key information from the interface data for judgment. The multi-dimensional sub-expression obtains data from multiple dimensions, and comprehensively considering these data can more accurately determine whether the factor condition is established. Different factor conditions cooperate with each other to jointly determine the final hit result of the policy factor. For example, when judging whether there is a risk in the user registration behavior, one factor condition can obtain through the interface expression whether the email used by the user during registration is in the known list of spam emails, and another factor condition obtains the risk level of the user registration address. By combining the judgment results of these factor conditions, it can be more accurately determined whether the policy factor of "user registration risk" is hit.

[0052] S108, in response to the rule online request for the target event, put the rule of the target event on the rule engine, so that when the target event is triggered, it is judged whether the target event hits the rule according to the configured factor condition and whether the policy factor is hit in sequence.

[0053] It can be understood that the rule online request is an instruction sent by the user to the rule engine to put the configured rules into actual operation after completing the rule configuration of the target event (including the configuration of policy factors and their factor conditions). The rule engine is a system that performs logical judgments on input data according to preset rules and is used to identify potential risks in the field of Internet risk control. When the target event is triggered, the rule engine gradually determines whether the target event conforms to the preset rules based on the configured factor conditions and the hit situation of the policy factors. For example, when a user initiates a transfer operation, the rule engine first judges the hit situation of the factor conditions, determines the hit situation of the policy factors, and then determines the hit situation of the transfer risk control rules based on the hit situation of the measurement factors.

[0054] The role of the rule online request is to deploy the configured rules into the rule engine so that it is ready to handle the target event at any time. When the target event occurs, the rule engine makes judgments according to specific logic. In this process, a parser can be configured in the rule engine. The parser is used to convert the rule configuration into an executable code form. Specifically, a code template can be set, and relevant parameters related to interface requests such as request methods, request parameters, operators, and class paths are extracted from the configuration metadata of the optional interface according to the target interface and target dimension corresponding to the factor conditions and filled into the code template. By executing the code generated in the parser, the data required for each factor condition can be obtained, filled into the rule matching code generated based on the first condition set for each factor condition for logical operations, and the hit situation of the factor conditions can be obtained. Further logical operations are performed on the hit situations of all factor conditions to obtain the hit situation of the policy factors. Finally, logical operations are performed based on the hit situations of all policy factors to obtain the hit situation of the rules.

[0055] This solution focuses on the configuration of the rule engine and covers key steps such as interface configuration, policy factor configuration, factor condition configuration, and rule online. In the interface configuration section, the optional interface is set according to the configuration metadata in the interface configuration request, providing a data source for subsequent rule configuration. Policy factors are configured for the target event to support risk assessment of the event from different dimensions, and then factor conditions containing interface expressions are configured for the policy factors to accurately judge the hit situation of the policy factors. Finally, in response to the rule online request, the rules are deployed to the rule engine. This solution realizes a high degree of flexibility in rule configuration. Operation personnel can easily complete complex strategy configurations, improving operation efficiency. At the same time, the function of the rule engine is enhanced, enabling complex logical calculations, effectively utilizing unstructured data, and realizing more accurate risk control strategies. The pluggable interface expression can reduce the work of R & D personnel through configuration and achieve the effect of introducing multiple-party interfaces. It can reference interfaces provided by different teams (multiple parties with different languages and heterogeneous systems) to implement and solve more complex business logic problems while more flexibly meeting the requirements of policy factors in complex scenarios.

[0056] In one embodiment, the factor condition further includes a regular expression, which includes at least one one-dimensional sub-expression. The one-dimensional sub-expression is used to determine whether the corresponding factor condition is met according to whether the data of a single dimension meets the set second condition.

[0057] It can be understood that the regular expression is another component of the factor condition, including at least one one-dimensional sub-expression. The one-dimensional sub-expression determines whether the factor condition is met based on the comparison result between the data of a single dimension and the set second condition. The data involved in the one-dimensional sub-expression is only simple one-dimensional labels, context parameters, etc., and it does not support multi-dimensional data acquisition methods. For example, when judging the risk of underage recharge of a user, the interface expression "the number of successful face recognition times of the current device in scenario 1-1 in the recent 30 days is less than 3 times", where "the current device" is the data defined from the "specified device" dimension, "scenario 1-1" is the data defined from the "face scenario" dimension, and "the recent 30 days" is the data defined from the "time period" dimension. "The number of successful times is less than 3 times" corresponds to the first condition. In the regular expression "the real-name level of the account is equal to 2", "the real-name level" is a simple label value when the account logs in, which is only a single dimension. Another example is the regular expression "the recharge amount is greater than or equal to x yuan", where the recharge amount here is the original context parameter obtained from the user request, which is also only a single dimension.

[0058] To accurately judge the hit situation of the policy factor, it is necessary to configure detailed factor conditions for it. The interface expression and the regular expression cooperate with each other to obtain and analyze data from different levels. The multi-dimensional sub-expression of the interface expression comprehensively considers the interface data from multiple dimensions and can more comprehensively reflect the complex business logic relationship; the one-dimensional sub-expression of the regular expression uses simple and intuitive one-dimensional data for judgment and can quickly play a role in some simple and clear risk judgment scenarios. The combination of the two can more comprehensively and accurately judge whether the factor condition is established. Different factor conditions cooperate with each other to jointly determine the final hit result of the policy factor.

[0059] In one embodiment, the configuration metadata includes interface metadata, interface request metadata, and interface response metadata. The interface metadata declares the information required to access the optional interface, the interface request metadata declares the information of the interface dimensions supported by the optional interface, and the interface response metadata declares the information of the fields supported for query in the response message of the optional interface.

[0060] It can be understood that interface metadata covers various types of information necessary to access optional interfaces. For example, the unique identifier of the interface (interface ID) is used to accurately distinguish different interfaces in the system; the request method of the interface, such as GET, POST, PUT, etc. under the common HTTP protocol, determines the data transmission mode when interacting with the interface; the interface address is the access path of the interface in the network, similar to a specific address in real life, used to locate the position of the interface; the class path and method name determine the specific implementation class and method corresponding to the interface at the program code level and are the key identifiers for invoking the interface function. Interface request metadata mainly declares the interface dimension information supported by the optional interface. Interface dimension is a way to classify interface data, dividing interface data from different perspectives, such as the field dimension, calculation logic dimension, etc. described above. Interface response metadata specifies the field information that can be queried in the response message of the optional interface. The response message is the data carrier returned after the interface receives a request. Interface response metadata stipulates which key information can be extracted from this data carrier. For example, in the response message of the user login interface, the fields that may support querying include "login status", "user ID", "login time", etc. These fields can help the system read the required data from the interface's response message.

[0061] For the rule engine to achieve accurate risk identification and prevention and control, it is inseparable from rich and accurate data support, and interfaces are an important channel for obtaining this data. The interface configuration request, as the start instruction for interface configuration, sets the optional interface according to the configuration metadata. Interface metadata ensures that the rule engine can correctly access the required interfaces; interface request metadata helps the rule engine clarify the dimensions for obtaining data from the interface, making the obtained data more targeted, avoiding obtaining a large amount of irrelevant data, and improving data processing efficiency; interface response metadata further stipulates the scope of extracting key information from the data returned by the interface, ensuring that the obtained data can be directly applied to subsequent risk judgment rules. These three cooperate with each other to build a complete data acquisition and processing framework for the subsequent rule configuration and risk judgment of the rule engine.

[0062] In one embodiment, please refer to Figure 2 , in response to a rule configuration request for a target event, configure at least one policy factor, including steps S202 to S204.

[0063] S202, in response to a factor establishment request, establish a policy factor.

[0064] It can be understood that the factor establishment request is an instruction initiated by a user or the system during the rule configuration process to set risk assessment elements for a specific target event. The purpose of this request is to trigger the rule engine to create new policy factors. The factor establishment request provides a way for users to create personalized policy factors, enabling the rule engine to customize risk assessment metrics according to actual business needs. Each policy factor independently evaluates a certain aspect of the target event, providing basic data for subsequent comprehensive risk judgment. Multiple policy factors cooperate with each other to comprehensively scan the risks of the target event from different angles, improving the accuracy and reliability of risk assessment. When receiving the factor establishment request, first collect the policy factor information input by the user through a form on the front-end page, including the name, description, etc. of the policy factor. For example, in the transaction risk control scenario of an e-commerce platform, the user can input "whether the unit price of the traded goods is higher than the historical average unit price" as the name of the policy factor, and at the same time describe the role of this factor as judging whether the transaction price is abnormal.

[0065] S204, in response to the first relationship establishment request, establish a first logical hit relationship between at least two policy factors. The first logical hit relationship is used to determine the relationship between the hit situation of the policy factor and the rule hit situation of the target event.

[0066] It can be understood that the first relationship establishment request is an instruction initiated by a user or the system after the creation of policy factors to determine the logical relationship between policy factors. The first logical hit relationship is a logical rule that stipulates how the hit situations of multiple policy factors are combined to determine the rule hit situation of the target event. Common first logical hit relationships include "AND", "OR", "NOT", etc. For example, in the promotion activity risk control scenario of an e-commerce platform, there are two policy factors: "whether the quantity of goods purchased by the user exceeds the threshold" and "whether the total price of goods purchased by the user exceeds the threshold". If the first logical hit relationship between these two policy factors is set to "AND", then the rule for the target event (whether this transaction is abnormal) will only be hit when both of these two policy factors are hit; if it is an "OR" relationship, then as long as one of the policy factors is hit, the rule will be hit. A single policy factor can only evaluate the risks of the target event from one angle, while actual risk judgment often requires considering multiple factors comprehensively. The first logical hit relationship provides a way for the rule engine to integrate the evaluation results of multiple policy factors, enabling the rule engine to flexibly set risk judgment rules according to different business needs and risk preferences. By reasonably setting the first logical hit relationship, the accuracy and flexibility of risk assessment can be improved, avoiding misjudgment or missed judgment caused by the limitations of a single policy factor.

[0067] In one embodiment, refer to Figure 3, in response to a conditional configuration request for any policy factor, configure at least one factor condition, including steps S302 to S304.

[0068] S302, in response to an interface expression establishment request for any policy factor, establish a single factor condition within the interface expression or establish at least two factor conditions connected by a second logical hit relationship. The second logical hit relationship is used to determine the relationship between the hit situation of the factor condition and the hit situation of the interface expression.

[0069] It can be understood that the interface expression establishment request refers to an instruction issued when constructing an interface expression for a specific policy factor in the rule configuration process. The second logical hit relationship is a rule used to describe the logical combination method between multiple factor conditions, which determines how the hit situations of each factor condition jointly affect the hit situation of the interface expression. Common second logical hit relationships include "AND", "OR", "NOT", etc. For example, in the user behavior risk control scenario of an e-commerce platform, for the policy factor of "abnormal recent purchase behavior of the user", the interface expression can be "the data obtained from the user purchase record interface meets condition A and meets condition B", where condition A and condition B are factor conditions, and "and" is the second logical hit relationship. A policy factor often needs to evaluate the target event from multiple aspects, and this is achieved through the interface expression. A single interface expression type of factor condition supports judging interface data from multiple dimensions, and multiple interface expression type of factor conditions combined through the second logical hit relationship can achieve more complex logical strategy evaluation and improve the accuracy of risk assessment. When receiving the interface expression establishment request, the front-end page provides a visual interface for the user to input factor conditions and select the second logical hit relationship. The user can select the logical relationship type (such as "AND", "OR", "NOT") through a drop-down menu and enter the description of the factor condition in a text box. The front-end sends this information to the back-end in JSON format, and the view function of the back-end receives and parses the request. For a single factor condition, directly store it in the factor condition table of the database (such as SQLite) and associate it with the corresponding interface expression. For multiple factor conditions connected by the second logical hit relationship, create a logical relationship table in the database to record the logical relationship between the factor conditions, and at the same time associate the logical relationship with the corresponding interface expression.

[0070] S304, in response to a configuration request for a factor condition within any interface expression, determine a target interface from the optional interfaces, determine a target dimension from the interface dimensions of the target interface, and determine the first condition corresponding to the target dimension.

[0071] It can be understood that the configuration request for the factor conditions within any interface expression is an instruction issued by the user or the system to further clarify the specific data source and judgment criteria of the factor conditions on the basis of the established interface expression and factor conditions. The optional interfaces are a set of interfaces that are pre-set during the configuration process of the rule engine and can be selected for data acquisition. The target interface is selected from the optional interfaces and is the specific interface that can provide the data required by the factor conditions. The target dimension is a specific data dimension within the target interface, and it is the specific object for the factor conditions to perform data acquisition and judgment. The first condition is the judgment criterion set for the target dimension and is used to determine whether the data obtained from the target dimension meets the factor conditions. During the risk assessment process of the rule engine, the factor conditions require specific data support to make accurate judgments. Determining the target interface from the optional interfaces can ensure that the data related to the factor conditions is obtained; determining the target dimension from the interface dimensions of the target interface can clarify the specific data source; determining the first condition corresponding to the target dimension can provide a clear judgment criterion for the factor conditions. These three steps cooperate with each other, enabling the factor conditions to accurately assess the risks of the target events.

[0072] In one embodiment, please refer to Figure 4 , in response to the interface expression establishment request for any policy factor, establish a single factor condition or at least two factor conditions connected by a second logical hit relationship within the interface expression, including step S402 and step S404.

[0073] S402, display multiple condition combination templates containing multi-level nested second logical hit relationships.

[0074] It can be understood that the condition combination templates are pre-designed factor condition combination styles containing multi-level nested second logical hit relationships, which provide a convenient way for users to construct complex interface expressions. Multi-level nesting means that within a condition combination, the second logical hit relationships can be nested with each other to form a more complex logical structure. For example, a condition combination template may be "(condition A AND condition B) OR (condition C AND (condition D OR condition E))", where the "AND" and "OR" relationships are multi-level nested. Risk assessment often requires considering multiple factors comprehensively, and a single factor condition may not meet the complex risk judgment requirements. By providing condition combination templates containing multi-level nested second logical hit relationships, users can more conveniently construct complex interface expressions, thereby more comprehensively and accurately assessing risks. These templates are designed based on common risk assessment scenarios and logics, and can help users quickly build rules that meet actual needs, improving the efficiency and accuracy of rule configuration.

[0075] The user interface can be built using HTML, CSS, and JavaScript on the front end. On the back end, the Python Django framework is used to manage conditional combination templates. First, the conditional combination template is stored in the template table of a database (such as MySQL). The template table contains fields such as the template's unique identifier, the template's logical expression, and the template's description. When a user initiates an interface expression creation request for any policy factor, the front end page obtains all conditional combination templates from the back end through an AJAX request. The back end queries the database and returns the template information to the front end in JSON format. After receiving the data, the front end displays the templates to the user in the form of a list, with each template accompanied by a brief description to help the user understand the logical structure and applicable scenarios of the template. Each factor condition with a multi-level nested second logic hit relationship can be stored with the label of the event to which it belongs as the key and itself as the value, and the frequency of use of each factor condition will also be recorded. When the frequency of use exceeds the set threshold, the factor condition is used as a conditional combination template. When configuring any target event, the conditional combination templates corresponding to the same label are displayed to the user in descending order of frequency of use.

[0076] S404: In response to a selection request for any condition combination template, at least two factor conditions connected by a second logical hit relationship are established according to the condition combination template.

[0077] It can be understood that the selection request for any condition combination template refers to an instruction for the user to select one of the templates to construct an interface expression after seeing the condition combination templates displayed by the system. To establish at least two factor conditions connected by the second logical hit relationship according to the condition combination template is to fill the specific factor conditions into the template according to the logical structure of the template selected by the user to form a complete interface expression. For example, the user selects the template "(Condition A and Condition B) or (Condition C and (Condition D or Condition E))", and then uses "Product price is higher than the average price" as Condition A, "Product sales volume is higher than the threshold" as Condition B, etc., and finally constructs a complete interface expression.

[0078] The conditional combination template provides users with a standardized logical structure. When users select a template, they only need to fill in specific factor conditions into the template to quickly build a complex interface expression. This method reduces the workload of users to manually write complex logic while ensuring the logical correctness of the interface expression. By connecting multiple factor conditions through the second logic hit relationship, it is possible to comprehensively consider the impact of multiple factors on the strategy factor and improve the accuracy of risk assessment.

[0079] See also Figure 5, this application provides a risk control method, including steps S502 to S508.

[0080] S502, for any event to be monitored, configure rules according to the rule engine configuration method in any of the above embodiments.

[0081] It can be understood that the event to be monitored refers to various business behaviors that require the use of a rule engine for risk assessment in the Internet business process, such as a user's order placement behavior on an e-commerce platform, a user's recharge behavior on a game client, a registration behavior on a social platform, etc. The rule engine configuration method covers a series of processes from interface configuration, policy factor configuration, factor condition configuration to rule online, including operations such as setting optional interfaces, establishing policy factors and the logical relationships between them, and determining factor conditions (including interface expressions and regular expressions). Different business behaviors face different types of risks. In order to achieve precise risk control, corresponding rules need to be configured according to the characteristics of each business behavior. Through the above rule engine configuration method, a risk assessment system can be constructed from multiple dimensions.

[0082] S504, after the event to be monitored is triggered, determine whether the event to be monitored hits the rule in sequence according to whether the factor conditions and policy factors corresponding to the event to be monitored are hit.

[0083] It can be understood that in the business process, when the event to be monitored occurs, the risk control strategy will be triggered. The risk control strategy is implemented according to the rules configured in the rule engine for the event to be monitored, and policy factors and factor conditions are configured in the rules. When a factor condition includes only one multi-dimensional sub-expression or one-dimensional sub-expression, the multi-dimensional sub-expression meets the corresponding first condition or the one-dimensional sub-expression meets the corresponding second condition, and the factor condition is hit. When a factor condition of the interface expression type includes more than two multi-dimensional sub-expressions, there can be a default logical relationship, such as when all multi-dimensional sub-expressions are hit, the corresponding factor condition is hit, or it can be a logical relationship configured by the user, and the total result calculated by combining all multi-dimensional sub-expressions with the logical relationship determines the hit situation of the corresponding factor condition. When a factor condition of the regular expression type includes more than two one-dimensional sub-expressions, there can be a default logical relationship, such as when all one-dimensional sub-expressions are hit, the corresponding factor condition is hit, or it can be a logical relationship configured by the user, and the total result calculated by combining all one-dimensional sub-expressions with the logical relationship determines the hit situation of the corresponding factor condition. Then, the rule engine will further perform a logical operation on the hit situations of all factor conditions to obtain the hit situation of the policy factor. Finally, based on the hit situations of all policy factors, a logical operation is performed to obtain the hit situation of the rule.

[0084] S506, determine the corresponding risk control strategy according to the rule hit situation of the event to be monitored.

[0085] It can be understood that the risk control strategy is a series of countermeasures formulated for different rule hit situations, aiming to reduce or eliminate potential risks. For example, in an e-commerce platform, if an order is determined to hit a rule, the risk control strategy may include suspending order processing, requiring the user to perform additional identity verification, manually reviewing the order, etc.; if the order does not hit the rule, the order may be directly released to continue the subsequent business process. Different rule hit situations reflect different risk levels of the events to be monitored. Determining the corresponding risk control strategy according to these situations is the key to achieving effective risk control. By formulating multiple risk control strategies in advance and associating them with the rule hit situations, it can be ensured that appropriate measures can be taken promptly when risks occur. In a risk control system based on a rule engine, a database (such as MongoDB) is used to store risk control strategies. Taking an e-commerce platform as an example, a risk control strategy table is created in the database, and the table contains fields such as the identifier of the rule hit situation, the corresponding risk control strategy (such as order processing method, verification method, etc.), and the priority of the strategy. When the rule hit situation of the event to be monitored is determined, the system queries the corresponding risk control strategy from the database according to the identifier of the rule hit situation. For example, if an order is determined to be high-risk, the system queries the corresponding strategy as "suspend order processing and notify manual review", and then performs the corresponding operations according to this strategy.

[0086] S508, perform risk control on the event to be monitored according to the risk control strategy.

[0087] It can be understood that performing risk control on the event to be monitored is to take corresponding operations on the occurring business behaviors according to the determined risk control strategy to reduce or eliminate potential risks. This step is the final execution link of the risk control process. By implementing the risk control strategy, the risk is controlled within an acceptable range. Different risk control strategies adopt different processing methods for different levels of risks. For low-risk events, a relatively loose control strategy is adopted to minimize the impact on normal business; for high-risk events, strict control measures are taken to ensure that the risks are effectively contained. For example, in the commodity trading scenario of an e-commerce platform, for orders with relatively low risks, only simple trading reminders may be given; while for orders with relatively high risks, the transactions may be directly cancelled to protect the interests of the platform and users.

[0088] The present application provides a rule engine configuration device, including a first response module, a second response module, a third response module, and a fourth response module. The first response module is configured to respond to an interface configuration request and set an optional interface according to the configuration metadata carried in the interface configuration request. The optional interface includes at least one interface dimension. The second response module is configured to respond to a rule configuration request for a target event and configure at least one policy factor. The hit condition of the policy factor is used to determine the rule hit condition of the target event. The third response module is configured to respond to a condition configuration request for any policy factor and configure at least one factor condition. The hit condition of the factor condition determines the hit condition of the corresponding policy factor. The factor condition includes an interface expression, which corresponds to the optional interface and includes at least one multi-dimensional sub-expression. The multi-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data obtained from at least one interface dimension of the corresponding optional interface meets a set first condition. The fourth response module is configured to respond to a rule online request for a target event and put the rule of the target event online to the rule engine, so that when the target event is triggered, it is determined whether the target event hits the rule by sequentially judging whether the configured factor condition and policy factor are hit.

[0089] For the specific limitations of the rule engine configuration device, reference can be made to the limitations of the rule engine configuration method in the above text, which will not be elaborated here. Each module in the above rule engine configuration device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory of the computer device in the form of software, so as to facilitate the processor to call and execute the operations corresponding to the above modules. It should be noted that the division of modules in the embodiments of the present application is illustrative, only a logical function division, and there may be other division methods in actual implementation.

[0090] The present application provides a computer device, including one or more processors, and a memory. Computer-readable instructions are stored in the memory. When the computer-readable instructions are executed by one or more processors, the steps of the rule engine configuration method and the risk control method in any of the above embodiments are executed.

[0091] Schematically, as Figure 6 shown, Figure 6 is an internal structure diagram of a computer device provided by an embodiment of the present application. Referring to Figure 6, the computer device 600 includes a processing component 602, which further includes one or more processors, and memory resources represented by a memory 601 for storing instructions executable by the processing component 602, such as application programs. The application programs stored in the memory 601 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 602 is configured to execute instructions to perform the steps of the rule engine configuration method and the risk control method in any of the above embodiments.

[0092] The computer device 600 may further include a power component 603 configured to perform power management of the computer device 600, a wired or wireless model interface 604 configured to connect the computer device 600 to a model, and an input / output (I / O) interface 605.

[0093] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the rule engine configuration method and the risk control method in any of the above embodiments.

[0094] Finally, it should also be noted that in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising a..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0096] The above description of the disclosed embodiments enables those skilled in the art to implement or use this application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application will not be limited to the embodiments shown herein, but rather to the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A rule engine configuration method, characterized in that, Including: In response to an interface configuration request, set an optional interface according to configuration metadata carried in the interface configuration request, where the optional interface includes at least one interface dimension; In response to a rule configuration request for a target event, configure at least one policy factor; the hit situation of the policy factor is used to determine the rule hit situation of the target event; In response to a condition configuration request for any one of the policy factors, configure at least one factor condition; The hit situation of the factor condition determines the hit situation of the corresponding policy factor. The factor condition includes an interface expression, the interface expression corresponds to the optional interface, and includes at least one multi-dimensional sub-expression. The multi-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data obtained from at least one of the interface dimensions corresponding to the optional interface meets a set first condition; In response to a rule online request for the target event, put the rule of the target event online to a rule engine, so that when the target event is triggered, it is judged whether the target event hits the rule in sequence according to whether the configured factor condition and the policy factor are hit.

2. The rule engine configuration method according to claim 1, wherein The factor condition further includes a regular expression, and the regular expression includes at least one single-dimensional sub-expression. The single-dimensional sub-expression is used to determine whether the corresponding factor condition is hit according to whether the data of a single dimension meets a set second condition.

3. The rule engine configuration method according to claim 1, wherein The configuration metadata includes interface metadata, interface request metadata, and interface response metadata; information required to access the optional interface is declared in the interface metadata, information about the interface dimensions supported for use by the optional interface is declared in the interface request metadata, and information about the fields supported for query in the response message of the optional interface is declared in the interface response metadata.

4. The rule engine configuration method according to claim 1, wherein The configuring at least one policy factor in response to a rule configuration request for a target event includes: In response to a factor establishment request, establish the policy factor; In response to a first relationship establishment request, establish a first logical hit relationship between at least two of the policy factors; the first logical hit relationship is used to determine the relationship between the hit situation of the policy factor and the rule hit situation of the target event.

5. The rule engine configuration method according to claim 1, wherein The configuring at least one factor condition in response to a condition configuration request for any one of the policy factors includes: In response to an interface expression establishment request for any one of the policy factors, establish a single factor condition within the interface expression or establish at least two factor conditions connected by a second logical hit relationship; the second logical hit relationship is used to determine the relationship between the hit situation of the factor condition and the hit situation of the interface expression; In response to a configuration request for the factor condition within any one of the interface expressions, determine a target interface from the optional interfaces, determine a target dimension from the interface dimensions of the target interface, and determine the first condition corresponding to the target dimension.

6. The rule engine configuration method according to claim 5, characterized in that In response to a request for establishing an interface expression for any one of the policy factors, establishing a single factor condition within the interface expression or establishing at least two factor conditions connected by a second logical hit relationship includes: Displaying a plurality of condition combination templates including multi-level nested second logical hit relationships; In response to a selection request for any one of the condition combination templates, establishing at least two factor conditions connected by a second logical hit relationship according to the condition combination template.

7. A risk control method, characterized in that, Including: For any event to be monitored, configuring rules according to the rule engine configuration method according to any one of claims 1-6; After the event to be monitored is triggered, successively determining whether the event to be monitored hits the rule according to whether the factor conditions corresponding to the event to be monitored and the policy factors hit; Determining a corresponding risk control strategy according to the rule hit situation of the event to be monitored; Performing risk control on the event to be monitored according to the risk control strategy.

8. A rule engine configuration device, characterized in that, Including: A first response module, configured to, in response to an interface configuration request, set an optional interface according to configuration metadata carried in the interface configuration request, where the optional interface includes at least one interface dimension; A second response module, configured to, in response to a rule configuration request for a target event, configure at least one policy factor; the hit situation of the policy factor is used to determine the rule hit situation of the target event; A third response module, configured to, in response to a condition configuration request for any one of the policy factors, configure at least one factor condition; The hit situation of the factor condition determines the hit situation of the corresponding policy factor. The factor condition includes an interface expression, and the interface expression corresponds to the optional interface and includes at least one multi-dimensional sub-expression. The multi-dimensional sub-expression is used to determine whether the corresponding factor condition hits according to whether data obtained from at least one of the interface dimensions of the corresponding optional interface satisfies a set first condition; A fourth response module, configured to, in response to a rule online request for the target event, put the rule of the target event online to a rule engine, so that when the target event is triggered, it is successively determined whether the target event hits the rule according to whether the configured factor condition and the policy factor hit.

9. A computer device, characterized in that, Including one or more processors and a memory, where computer-readable instructions are stored in the memory, and when the computer-readable instructions are executed by the one or more processors, the steps of the rule engine configuration method according to any one of claims 1-6 or the risk control method according to claim 7 are executed.

10. A storage medium, characterized in that, Computer-readable instructions are stored in the storage medium, and when the computer-readable instructions are executed by one or more processors, the one or more processors are caused to execute the steps of the rule engine configuration method according to any one of claims 1-6 or the risk control method according to claim 7.

Images