Method and system for visually configuring risk control rules

Abstract

The invention provides a risk control rule visualized configuration method and system, and the method comprises the steps: receiving a calculation function selected by a business analyst in a visualized editing interface, and enabling the calculation function to serve as a root node of an n-way tree; the calculation function has a plurality of parameter input bits, and for each parameter input bit, receiving a binding operation on a business data field or a sub-function to form a sub-node; constructing a complete n-way tree structure based on the root node and each child node, wherein the n-way tree structure represents an expression y = f (x1, x2,..., xn); receiving a selection of a risk disposal strategy associated based on the calculation result of the expression; combining the n-way tree structure with the selected strategy to generate a complete risk control rule; and converting the risk control rule into an expression which can be directly executed by the rule engine according to a script language supported by the target rule engine. According to the invention, the problems of high communication cost, long development period, low business participation degree, poor rule confidentiality and the like in a traditional risk control system are solved.

Description

Technical Field

[0001] This application relates to the field of risk control technology, and more specifically, to a method and system for visually configuring risk control rules. Background Technology

[0002] In high-risk business scenarios such as finance, e-commerce, and payment, real-time identification and interception of risk events such as fraudulent transactions and abnormal logins are crucial. To this end, enterprises generally adopt rule engines as a core risk control tool, using preset conditional judgment logic to trigger alerts, interceptions, or manual reviews.

[0003] However, in the traditional risk control rule configuration model, after business analysts identify risk characteristics, they need to describe the rule logic in natural language into a requirements document, which is then handed over to developers to translate into code. This process involves multiple cross-departmental communications, has a long development cycle, and is difficult to cope with rapidly evolving risk situations. In addition, the specific implementation of the rules is done by technical personnel, which poses a risk of leakage of rule details and is not conducive to the confidential management of sensitive policies. Summary of the Invention

[0004] In view of the deficiencies in the prior art, the purpose of this application is to provide a method and system for visually configuring risk control rules.

[0005] The first aspect of this application provides a method for visually configuring risk control rules, including: In the visual editing interface, in response to the business analyst's operation, a calculation function is selected from the function library and set as the root node of the n-ary tree; The calculation function has multiple parameter input positions. For each parameter input position, it receives the binding operation of business data fields or sub-functions by business analysts, forming a child node of an n-ary tree. Based on the root node and each child node, construct a complete n-ary tree structure, expressed as y = f(x1, x2,..., x...). n ), where f represents the computation function of the root node, x1 to x n These represent the output values ​​of the business data fields or sub-functions bound to each child node; In response to the risk level mapped by the business analyst's output y of the expression, select and associate at least one risk management strategy; The n-ary tree structure is combined with the risk management strategy to generate a complete risk control rule; Based on the scripting language supported by the target rule engine, the risk control rules are converted into code that the rule engine can directly execute.

[0006] Optionally, the calculation function is pre-encapsulated and registered in the system function library; The system function library supports multiple types of functions that meet the needs of risk control scenarios, including one or more of the following: aggregation functions, logical judgment functions, time window functions, and custom script functions.

[0007] Optionally, the business data fields are derived from predefined data types, including at least one of order probe data, login log stream, device fingerprint information, and user profile cache.

[0008] Optionally, if any of the child nodes is bound to a sub-function, the sub-function bound to the child node also constitutes an independent n-ary tree structure; multiple n-ary trees are nested and combined through parameter passing to form a compound expression.

[0009] Optionally, the risk handling strategy is a set of composable response actions, including at least one of alarm notification, account freezing, transaction interception, secondary verification, manual review triggering, and tagging; Among them, each disposal strategy supports multiple parallel configurations and can dynamically adjust execution priority and combination logic based on risk scoring results.

[0010] A second aspect of this application provides a system for visually configuring risk control rules, including a rule platform and a rule engine; The rule platform uses the visual configuration method for risk control rules as described in any one of claims 1-5 to construct a complete risk control rule and publish it to the rule engine. The rule engine is used to receive risk control rules published by the rule platform, and to parse and execute the rules to achieve risk identification and control.

[0011] Optionally, the risk control rules are modeled and managed through a multi-level model, which includes a model layer, a rule layer, and a factor layer from top to bottom. The model layer includes models, each of which is a collection of multiple views under the same business category; The rule layer includes views, each view containing LHS conditional branching logic and RHS execution logic. Both LHS and RHS are composed of one or more factors. The factor layer includes logical factors and execution factors. The logical factors consist of data nodes composed of probes, caches, and variables. The execution factors consist of operation-type components composed of functions and events. The views are associated with the same scene to achieve business isolation.

[0012] Optionally, the rule platform is characterized in that it collaboratively implements the construction and management of the multi-level model through the following modules: The strategy knowledge base module stores fixed resource units and data-type resource units, which are used to construct execution factors and logical factors. The resource management module combines multiple data nodes with an operation to form a factor based on the data resources of the strategy knowledge base module. The intuitive operation module provides a visual interface, creates views, binding modes and strategies based on factors provided by the resource management module, and combines multiple views into a model. The platform tool includes a first pattern parser and a pattern validator. The first pattern parser parses the n-ary tree structure of LHS into a script expression, and the pattern validator verifies the syntax, parameters and logical validity of the view. The rule engine includes a second pattern parser and multiple pattern executors. The second pattern parser compiles script expressions into executable code, and the pattern executors execute the code and return the execution result.

[0013] Optionally, the rule platform constructs factors in the following ways: In response to the operation of adding a root factor, the main computation function is selected as the root node of the n-ary tree; For each parameter input bit of the main calculation function, bind a business data field or a nested sub-function as a child node; After completing the n-ary tree structure configuration, fill in the factor names and submit them to the pattern validator in the platform tools; After the pattern validator verifies the logic as valid, the factor is saved to the resource management module as a standardized rule component that can be reused in multiple views.

[0014] A third aspect of this application provides an operating terminal for visually configuring risk control rules, including a processor and a memory, wherein the memory stores program instructions that can be executed by the processor, and the processor is used to execute the program instructions to implement the method.

[0015] The method for configuring risk control rules with visualization provided in this application solves the problems of high communication costs, long development cycles, low business participation, and poor rule confidentiality in traditional risk control systems by constructing a function-centered n-ary tree expression model, a visual interactive interface, and a strategy selection mechanism. It realizes the transformation of risk control rules from passive implementation to active configuration, and significantly improves the real-time performance, flexibility, and execution of risk identification.

[0016] Other technical effects resulting from the additional features will be further illustrated in the corresponding embodiments. Attached Figure Description

[0017] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a method for visually configuring risk control rules according to an exemplary embodiment; Figure 2 This is a schematic diagram illustrating the structure of a system for visually configuring risk control rules according to an exemplary embodiment; Figure 3 This is a risk control rule model diagram illustrated according to an exemplary embodiment; Figure 4 This is a flowchart illustrating the factor configuration process according to an exemplary embodiment; Figure 5 This is a schematic diagram illustrating resource management according to an exemplary embodiment; Figure 6 This is a schematic diagram illustrating a configuration rule according to an exemplary embodiment; Figure 7 A view configuration interface is shown according to an exemplary embodiment; Figure 8 The content of the script source code generated by the pattern parser according to an exemplary embodiment is shown. Figure 9 This is a model management interface shown according to an exemplary embodiment. Detailed Implementation

[0018] The present application will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application, and these all fall within the protection scope of the present application. Parts not described in detail in the following embodiments can be implemented using existing technology.

[0019] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations.

[0020] Traditional risk control systems suffer from high communication costs, long development cycles, low business participation, and poor rule confidentiality. To address these issues, this application provides a method for visually configuring risk control rules, suitable for real-time risk decision-making systems in scenarios such as financial transactions, account security, and anti-fraud.

[0021] like Figure 1 As shown in one embodiment of this application, a method for visually configuring risk control rules includes the following steps: S100, in the visual editing interface, responds to the business analyst's operation, selects a calculation function from the function library, and uses the calculation function as the root node of the n-ary tree; Specifically, visualization refers to web pages or client applications. An n-ary tree, as the core data structure for rule-based conditional logic, is used to represent complex judgment logic composed of multiple nested functions, parameters, and sub-expressions. Each node represents an operation unit (such as a function call, field reference, or logical operation), organized into a hierarchical expression structure through parent-child relationships, and ultimately parsed into script code executable by the rule engine.

[0022] S200, the calculation function has multiple parameter input positions. For each parameter input position, it receives the binding operation of business data fields or sub-functions by business analysts, forming the child nodes of an n-ary tree; S300, based on the root node and each child node, constructs a complete n-ary tree structure, expressed as y = f(x1, x2,..., x...). n ), where f represents the computation function of the root node, x1 to x n These represent the output values ​​of the business data fields or sub-functions bound to each child node; Specifically, in this expression, x1, x2…x n The corresponding rules calculate various types of business data, and f is a function that performs specific operations on this business data (such as determining numerical values, summing statistical data, etc.). Therefore, the functions and various data information predefined by the developers must fully cover all types of business data and be able to dynamically collect adaptive data according to changes in business attributes to ensure that x1, x2…x n The data source always meets the computational requirements.

[0023] S400: In response to the business analyst’s assessment of the risk level mapped by the expression output y, select and associate at least one risk management strategy. S500 combines an n-ary tree structure with risk management strategies to generate a complete risk control rule. S600 converts risk control rules into code that the rule engine can directly execute, based on the scripting language supported by the target rule engine.

[0024] Specifically, the parsing and execution of rules do not depend on rule scripts in a specific language, and can flexibly support various rule engines.

[0025] The embodiments described above in this application solve the problems of high communication costs, long development cycles, low business participation, and poor rule confidentiality in traditional risk control systems by constructing an n-ary tree expression model centered on functions, a visual interactive interface, and a strategy selection mechanism. This realizes the transformation of risk control rules from passive implementation to active configuration, and significantly improves the real-time performance, flexibility, and execution of risk identification.

[0026] It is worth noting that when there are special factors that analysts cannot configure through the visual interface, this method also allows developers to directly write corresponding rule scripts using programming languages, upload and publish them, thus balancing the convenience of visual configuration with the flexibility of special scenarios.

[0027] To meet various risk control scenarios, in some specific implementations of this application, the calculation functions are pre-encapsulated by developers and registered in the system function library. The function library supports aggregation functions, logical judgment functions, time window functions, and custom script functions.

[0028] For example, aggregation functions include data summation, counting, and average calculation; logical judgment functions include numerical comparison and AND / OR logic verification; and time window functions include statistics on business data from the past hour or the past seven days.

[0029] The above embodiments of this application can reduce repetitive development work by pre-encapsulating functions, accurately match risk control scenarios with multiple types of functions, support custom requirements, efficiently support business configuration, and improve rule adaptability and configuration efficiency.

[0030] Similarly, in order to meet the needs of multiple types of risk control, in some specific implementations of this application, the business data fields are derived from predefined data types, including at least one of order probe data, login log stream, device fingerprint information, and user profile cache.

[0031] Specifically, order probe data refers to real-time collected data recording order transaction details, including but not limited to order amount and payment method. Login log streams are time-series records of user login behavior, such as login time and login device IP address. Device fingerprint information refers to feature data used to uniquely identify terminal devices, including but not limited to login time, login device IP address, device model, and operating system version. User profile cache refers to a temporary data structure storing user historical behavior, preferences, and related tags, exemplified by user historical transaction preferences and frequently used login geographic region tags.

[0032] The above embodiments support diverse risk control rule configuration requirements by explicitly defining various business-related data types, which helps to improve the flexibility and accuracy of rule configuration.

[0033] In real-world risk control scenarios, a single condition is insufficient to meet complex decision-making needs. Therefore, in some implementations, each condition can be represented as an n-ary tree structure, where internal nodes represent operators or functions, and leaf nodes represent basic data sources (such as field values ​​or variables). Multiple n-ary trees can be nested and combined through parameter passing to form compound expressions that support logical relationships such as "AND," "OR," and "NOT."

[0034] For example, if you need to configure the following rule: "Trigger an alert when the same bank card makes more than 5 payments in the past 7 days, and the amount of each payment exceeds 1,000 yuan", you can construct the expression by following these steps: Construct the first n-ary tree A to count the number of times a certain bank card has made payments in the past 7 days. Its root node is the "time window count" function, whose parameters include "bank card number" and "last 7 days" time range. Construct a second n-ary tree B, and determine whether the output of n-ary tree A is greater than 5; Construct a third n-ary tree C to determine if the current transaction amount is greater than 1000 yuan; The Boolean results of n-ary trees B and C are used as inputs and passed to the "logical AND" operation node to form the final conditional expression.

[0035] The above embodiments of this application support multi-level and multi-condition composite logic modeling, which is suitable for complex risk control rule scenarios.

[0036] To minimize losses from potential risks, some specific implementations include risk management strategies such as: sending alert notifications, freezing user accounts, blocking suspicious transactions, triggering two-factor authentication, initiating manual review processes, and labeling users or devices as risky. These strategies can be used individually or in combination according to rules, and support setting execution priorities and conditional branches.

[0037] Specifically, the definitions and examples of various handling strategies are as follows: Alarm notification: This refers to a strategy that pushes risk alerts to designated individuals (such as risk control personnel or operations personnel) when a risk rule is triggered, in order to promptly synchronize risk information for intervention.

[0038] For example: If the same account logs in from different locations 3 times within 1 hour, the system will send an alert email containing the account ID and login IP to the risk control email address.

[0039] Account freezing: refers to the strategy of restricting some or all of the operational permissions (such as transfers and payments) of accounts that have triggered high-risk rules, in order to prevent the risk from escalating.

[0040] For example: If an account is detected as having been fraudulently used (such as making large purchases on an unfamiliar device), the system will freeze the account's payment function.

[0041] Transaction interception: refers to a strategy that terminates the transaction process directly before a risky transaction is completed, in order to avoid financial losses from the source.

[0042] For example: When a user attempts to transfer money to an account on a "fraud blacklist," the system intercepts the transaction in real time and displays a warning that "the transaction is risky."

[0043] Two-factor authentication: This refers to a strategy that requires users who meet medium-risk rules to complete additional identity verification in order to confirm the legitimacy of their identity.

[0044] For example: When a user logs into their account on a new device, an SMS verification code is triggered, and access to the account is only granted after successful verification.

[0045] Manual review trigger: This refers to the strategy of transferring complex risk scenarios (which are difficult for machines to accurately judge) to the human risk control team for review, in order to improve the accuracy of risk assessment.

[0046] For example: If a company account receives 5 new unfamiliar payments exceeding 500,000 yuan in a single day, the system will push the account's transaction records to the manual review queue.

[0047] Tagging: This refers to the strategy of adding risk tags to users / transactions that meet risk rules, for subsequent precise management (such as tiered risk control).

[0048] For example: If a user has two transactions with "fake delivery address" within six months, the system will label the user with "transaction authenticity questionable" and subsequent transactions will require stricter review.

[0049] The embodiments described above cover multiple risk management methods, support combined execution, can be adapted to different risk level scenarios, accurately manage risks, and effectively minimize the losses caused by risks.

[0050] Based on the same technological concept, such as Figure 2 As shown in other embodiments of this application, a system for visually configuring risk control rules is provided, including a rule platform and a rule engine; The rules platform uses the visual configuration method for risk control rules described in the above embodiments to build a complete risk control rule parallel rule engine for release. The rule engine is used to receive the risk control rules released by the rules platform, and to parse and execute the rules to achieve risk identification and control.

[0051] To more clearly understand the above rule structure, this application provides a risk control rule modeling and management mechanism based on a multi-level model in some specific embodiments, such as... Figure 3 As shown: The rules platform uses a multi-level model to model and manage risk control rules. The multi-level model includes, from top to bottom: model layer, rule layer, and factor layer.

[0052] The model layer includes models, each of which is a collection of multiple views under the same business category, used to uniformly manage and organize all risk control rules for that type of business; The rule layer includes views, each of which is the basic unit of rule configuration and contains LHS conditional branching logic and RHS execution logic. The LHS conditional branch logic consists of one or more factors, corresponding to the "If" judgment part in the rule, also known as the pattern. The RHS execution logic consists of one or more factors, corresponding to the "Then" response part in the rule, also known as strategy or event action. The factor layer includes factors, which are divided into logical factors and execution factors: Logical factors consist of data nodes made up of probes, buffers, variables, etc., and are used to acquire input data. The execution factor consists of operation-type components such as function calls and event triggers, and is used to perform calculations or actions; Each view needs to be associated with the same business scenario to achieve rule isolation between different business types.

[0053] Furthermore, in some implementations, the rules platform collaboratively constructs and manages the aforementioned multi-level model through the following modules, such as... Figure 2 As shown: The strategy knowledge base, as the basic resource support layer, stores the basic resources required for rule configuration, including two types: Fixed resource units: Composed of referenced objects and system functions, used to construct execution factors; Data-related resource units include probe data, cached data, and variable data, used to construct logical factors; The resource management module is used to define and reuse factors. It combines multiple data nodes with an operation into a factor and supports the cross-rule reference of the factor in multiple views, thereby improving configuration efficiency and consistency. The intuitive operation module provides a visual configuration interface, allowing users to perform the following operations: Create a view, and bind the schema (LHS) and policy (RHS) to form a complete rule; Grouping multiple views of the same type into one model enables systematic management of rules based on business dimensions; The platform tools include a first-mode parser and a mode validator: The first pattern parser is used to parse the n-ary tree structure corresponding to the pattern into an executable script expression; The schema validator is used to validate the view's syntactic, parameter matching, and logical validity before saving or publishing. The system also includes a rules engine, comprising a second pattern parser and multiple pattern executors: The second-mode parser compiles script expressions into executable code; The pattern executor is responsible for running the deployed rules. When a rule is matched, it returns the corresponding policy information to the upstream system, completing the closed loop from model definition to runtime control.

[0054] In some implementations, the rules platform also provides a standardized factor configuration process, such as Figure 4 As shown, it includes: In response to the operation of adding a root factor, the main computation function is selected as the root node of the n-ary tree; For each parameter input bit of the main calculation function, bind business data fields or nested sub-functions as child nodes; After completing the n-ary tree structure configuration, fill in the factor names and submit them to the pattern validator for logical verification; Once the verification is successful, the factor is saved to the resource management module as a standardized rule component that can be reused in multiple views.

[0055] In some specific embodiments of this application, in conjunction with the appendix Figure 5 The corresponding process (after risk strategy personnel complete the material configuration, the strategy knowledge base content is converted to the resource management module and then distributed to the rule engine), the resource management module settings include "dependency management" and "version management": Dependency Management: When converting to a specific scripting language, the corresponding dependency packages need to be referenced. Dependency management pre-configures the package paths; when the script is generated, these paths will be embedded in the script, and the mode executor can reference these dependencies when it starts to complete the compilation and execution of the script.

[0056] Version management: Supports viewing historical versions of modes and views; when online scripts do not execute as expected, the rule base for the corresponding time period can be restored by viewing the release history, which helps to quickly troubleshoot problems.

[0057] In some specific embodiments of this application, the dependency management of the resource management module ensures script compilation and execution by pre-configuring dependency package paths, thereby improving the adaptability of the rule engine to multiple languages ​​and the stability of execution; version management supports historical version tracing, quickly locates online issues, ensures the traceability of rule iterations, and improves troubleshooting efficiency.

[0058] The preferred features in the above embodiments can be used individually in any embodiment, or in any combination thereof, provided they do not conflict with each other. Furthermore, parts not described in detail in the embodiments can be implemented using existing technologies.

[0059] The following examples and comparative examples will be used to further illustrate this application in order to better understand the above-mentioned technical solutions. It should be understood that the following are only some examples and are not intended to limit this application.

[0060] Application Example 1: like Figure 6 As shown, the current configuration mode has the rule "the amount of money paid by the same merchant to a private card number per month is greater than x yuan". The number of times a merchant makes payments to a specified card (including physical cards and electronic cards) in a single month is obtained through a function pre-encapsulated by the developers.

[0061] like Figure 7 As shown, after selecting the above configuration mode through the view, you can set the threshold and risk handling strategy.

[0062] like Figure 8 As shown, the view page also allows you to view the script source code generated by the pattern parser.

[0063] like Figure 9 As shown, the status of each view under a certain model can be viewed in the model management interface. Only views that are enabled will be published to the rule engine for execution.

[0064] Based on the same technical concept, other embodiments of this application provide an operating terminal for visually configuring risk control rules, including a processor and a memory. The memory stores program instructions that can be executed by the processor, and the processor executes the program instructions to implement a method for visually configuring risk control rules.

[0065] Optionally, the memory is used to store programs; the memory may include volatile memory, such as random-access memory (RAM), such as static random-access memory (SRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM), etc.; the memory may also include non-volatile memory, such as flash memory. The memory is used to store computer programs (such as application programs and functional modules that implement the above methods), computer instructions, etc., and the aforementioned computer programs and computer instructions can be partitioned and stored in one or more memories. Furthermore, the aforementioned computer programs, computer instructions, data, etc., can be accessed by the processor.

[0066] The aforementioned computer programs, computer instructions, etc., can be stored in partitions within one or more memory locations. Furthermore, the aforementioned computer programs, computer instructions, data, etc., can be accessed by a processor.

[0067] A processor is used to execute a computer program stored in memory to implement the various steps of the methods involved in the above embodiments. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0068] The processor and memory can be separate structures or integrated structures. When the processor and memory are separate structures, they can be coupled together via a bus.

[0069] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0070] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0071] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0072] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0073] The foregoing has described some specific embodiments of this application. It should be understood that this application is not limited to the specific embodiments described above, and those skilled in the art can make various modifications or variations within the scope of the claims, which do not affect the substantive content of this application. The above-described preferred features can be used in any combination without conflict.

Claims

1. A method of visualizing configuration of risk control rules, characterized in that, Comprise: In the visual editing interface, in response to the operation of the business analyst, a calculation function is selected from a function library, and the calculation function is taken as a root node of an n-ary tree; The calculation function is provided with a plurality of parameter input bits, and for each parameter input bit, a binding operation of the business analyst on a business data field or a sub-function is received, forming a child node of the n-ary tree; Based on the root node and each child node, a complete n-ary tree structure is constructed, and the expression is y = f(x1, x2,...,x n ), wherein f represents a calculation function of the root node, x1 to x n represent the output values of the business data fields or sub functions bound by each child node respectively; In response to the risk level mapped by the business analyst to the expression output result y, at least one risk disposal strategy is selected and associated; The n-ary tree structure and the risk disposal strategy are combined to generate a complete risk control rule; According to the script language supported by the target rule engine, the risk control rule is converted into the code of the expression that can be directly executed by the rule engine. 2.The method of Claim 1, wherein, The calculation function is pre-encapsulated and registered in the system function library; The system function library supports multiple types of functions that meet the needs of risk control scenarios, including one or more of aggregation functions, logical judgment functions, time window functions, and custom script functions. 3.The method of Claim 1, wherein, The business data field is derived from a predefined data type, and the data type includes at least one of order probe data, login log stream, device fingerprint information, and user portrait cache. 4.The method of Claim 1, wherein, If any of the child nodes is bound to a sub-function, the bound sub-function in the child node also constitutes an independent n-ary tree structure; multiple n-ary trees are nested and combined through parameter passing to form a composite expression.

5. The method of Claim 1, wherein, The risk disposal strategy is a set of combinable response actions, including at least one of alarm notification, account freezing, transaction interception, secondary verification, manual review triggering, and label marking; Wherein, each disposal strategy supports multiple selection and parallel configuration, and can dynamically adjust the execution priority and combination logic according to the risk score result. 6.A system for visualizing configuration of risk control rules, characterized in that, Comprise a rule platform and a rule engine, wherein: The rule platform uses the method for visualizing configuring a risk control rule according to any one of claims 1-5 to build a complete risk control rule and publish it to the rule engine; The rule engine is used to receive the risk control rule published by the rule platform, and parse and execute the rule to realize risk identification and control. 7.The system of claim 6, wherein, The risk control rule is modeled and managed through a multi-level model, and the multi-level model comprises model layers, rule layers and factor layers from top to bottom; The model layer comprises models, and each model is a collection of multiple views under the same business category; Each view in the rule layer includes LHS condition branch logic and RHS execution logic, and LHS and RHS are composed of one or more factors; The factor layer includes logical factors and execution factors, the logical factors are composed of data nodes of probes, caches and variables, and the execution factors are composed of operation components of functions and events; The view is associated with the same scene to realize business isolation. 8.The system of claim 7, wherein: The rule platform cooperatively realizes the construction and management of the multi-level model through the following modules, specifically: ​ The strategy knowledge base module stores fixed resource units and data class resource units to construct execution factors and logical factors; The resource management module forms a factor by combining multiple data nodes with an operation based on the data resources of the strategy knowledge base module; The intuitive operation module provides a visual interface, creates views, binds patterns and strategies based on the factors provided by the resource management module, and collects multiple views into a model; The platform tool includes a first pattern parser and a pattern verifier, the first pattern parser parses the n-ary tree structure of LHS into a script expression, and the pattern verifier checks the syntax, parameters and logical legality of the view; The rule engine includes a second pattern parser and multiple pattern executors, the second pattern parser compiles the script expression into executable code, and the pattern executors execute the code and return the execution result. 9.The system of claim 8, wherein, The rule platform builds factors in the following ways, including: In response to an operation of adding a root factor, a main calculation function is selected as a root node of an n-ary tree; For each parameter input bit of the main calculation function, a business data field or a nested sub-function is bound as a child node; After the n-ary tree structure configuration is completed, a factor name is filled in, and submitted to the pattern verifier in the platform tool; After the logic is verified by the pattern verifier, the factor is saved to the resource management module as a standardized rule component that can be reused in multiple views.

10. An operation terminal for visualizing configuration of a risk control rule, characterized by, A processor and a memory, the memory stores program instructions executable by the processor, and the processor is configured to execute the program instructions to implement the method of any one of claims 1-5.

Images