Risk identification system, method, server and storage medium

Abstract

This invention discloses a risk identification system, method, server, and storage medium, relating to the field of automated programming technology. The system includes: a rule engine module; the rule engine module further includes: a syntax tree construction submodule, used to construct an initial syntax tree based on a preset risk control model, wherein the initial syntax tree includes at least two nodes; a syntax tree optimization submodule, used to optimize the initial syntax tree constructed by the syntax tree construction module and generate a target syntax tree, wherein the optimization process includes syntax tree pruning and / or node priority reordering; and a risk identification submodule, used to determine the risk identification result based on basic service information and the target syntax tree. Through the technical solution of this invention, a lightweight rule engine is constructed, thereby making risk identification more efficient.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of automatic programming technology, and in particular to a risk identification system, method, server and storage medium. Background Technology

[0002] As banking services become more complex and diversified, risks associated with banking channels are also emerging. Therefore, it is necessary to identify risks arising during business transactions at the banking channel level in real time.

[0003] Furthermore, because banking channel business encompasses various types of online and offline transactions and is widely distributed across regions, there is a high requirement for the banking channel risk rules to support online configurability and parameterization. For example, the risk rule trigger thresholds for online channels (such as mobile apps and mini-programs) and physical channels (such as branches and ATMs) often differ when handling the same type of business. The trigger conditions and parameters for rules may also vary between different regions and branches. For instance, a risk rule for judging transactions conducted outside of business hours might be applicable to branches in most regions where business hours are generally from 8:00 to 18:00, but for branches in regions like Xinjiang, the opening time is one hour later.

[0004] Currently, rule-based risk control systems are suitable for risk assessment in banking channels due to their superior real-time performance. However, existing rule engines are primarily based on open-source engines such as Drools and JRules. While these engines are powerful, their rule syntax is relatively complex, resulting in a high learning curve and requiring developers to specifically learn the relevant rule syntax. Furthermore, rule-based risk control systems struggle to adjust and manage rules to adapt to the numerous and complex risk indicators present in banking applications. Consequently, this leads to higher requirements for technical personnel and poor maintainability and flexibility of the risk control system. Summary of the Invention

[0005] This invention provides a risk identification system, method, server, and storage medium to achieve the construction of a lightweight rule engine, thereby making risk identification more efficient.

[0006] In a first aspect, embodiments of the present invention provide a risk identification system, including: a rules engine module;

[0007] The rule engine module includes:

[0008] The syntax tree construction submodule is used to construct an initial syntax tree based on a preset risk control model, wherein the initial syntax tree includes at least two nodes;

[0009] The syntax tree optimization submodule is used to optimize the initial syntax tree constructed by the syntax tree construction module and generate the target syntax tree. The optimization process includes syntax tree pruning and / or node priority rearrangement.

[0010] The risk identification submodule is used to determine the risk identification result based on the basic service information and the target syntax tree.

[0011] Secondly, embodiments of the present invention also provide a risk identification method, including:

[0012] The syntax tree construction submodule constructs an initial syntax tree based on the risk control model; the initial syntax tree includes at least two nodes.

[0013] The syntax tree optimization submodule optimizes the initial syntax tree constructed by the syntax tree construction module and generates the target syntax tree. The optimization process includes syntax tree pruning and / or node priority rearrangement.

[0014] The risk identification submodule determines the risk identification result based on the basic service information and the target syntax tree.

[0015] Thirdly, embodiments of the present invention also provide a server, the server comprising:

[0016] One or more processors;

[0017] Storage device for storing one or more programs.

[0018] When the one or more programs are executed by the one or more processors, the one or more processors implement the risk identification method as described in any of the embodiments of the present invention.

[0019] Fourthly, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the risk identification method as described in any of the embodiments of the present invention.

[0020] The technical solution of this invention constructs an initial syntax tree through a syntax tree construction submodule in the rule engine module, optimizes the initial syntax tree based on the syntax tree optimization submodule to generate a target syntax tree, and then determines the risk identification result through a risk identification submodule. This solves the problem of complex rule syntax and high learning cost in existing rule engine modules, and achieves the technical effect of reducing the learning cost of the rule engine and improving the recognition efficiency of the rule engine. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of exemplary embodiments of the present invention, the accompanying drawings used in describing the embodiments are briefly introduced below. Obviously, the accompanying drawings described are only a portion of the drawings of the embodiments to be described in this invention, and not all of the drawings. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 1 of the present invention;

[0023] Figure 2 This is a schematic diagram of the word composition provided in Embodiment 1 of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 2 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 3 of the present invention;

[0026] Figure 5 This is a schematic diagram of another risk identification system provided in Embodiment 3 of the present invention;

[0027] Figure 6 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 4 of the present invention;

[0028] Figure 7 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 5 of the present invention;

[0029] Figure 8 This is a flowchart illustrating a risk identification method provided in Embodiment Six of the present invention;

[0030] Figure 9 This is a schematic diagram of the structure of a server provided in Embodiment 7 of the present invention. Detailed Implementation

[0031] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0032] Example 1

[0033] Figure 1 This is a schematic diagram of the structure of a risk identification system provided in Embodiment 1 of the present invention, as shown below. Figure 1 The risk identification system shown includes a rules engine module 1;

[0034] The rules engine module 1 includes: a syntax tree construction submodule 11, a syntax tree optimization submodule 12, and a risk identification submodule 13. The syntax tree construction submodule 11 constructs an initial syntax tree based on a preset risk control model. The syntax tree optimization submodule 12 optimizes the initial syntax tree constructed by the syntax tree construction submodule 11 and generates a target syntax tree. The risk identification submodule 13 determines the risk identification result based on basic service information and the target syntax tree.

[0035] The initial syntax tree includes at least two nodes. The risk control model can be a model pre-loaded into the rules engine module 1, used to determine whether the current service poses a risk, such as a model for multiple password attempts for private deposits or a model for an individual incorrectly opening an account using a Chinese passport. The current service can be a bank-operated service such as withdrawal or transfer services. The initial syntax tree can be an abstract syntax tree derived according to the risk control rules in the risk control model.

[0036] It should be noted that an Abstract Syntax Tree (AST) is a tree-like representation of the abstract syntactic structure of source code, where each node in the tree represents a structure in the source code.

[0037] Specifically, the syntax tree construction submodule 11 can obtain a preset risk control model, parse the risk control model to obtain the risk control rules involved in the risk control model, and then construct an abstract syntax tree based on the risk control rules, using this abstract syntax tree as the initial syntax tree.

[0038] It should be noted that the process of constructing the initial syntax tree can be achieved by transforming the risk control rules into an abstract syntax tree composed of tokens and token parameters. A diagram illustrating the token structure is shown below. Figure 2As shown, tokens can be divided into operator tokens (OperToken), data type tokens (PrimeToken), and function tokens (CallToken). OperToken includes operator-related tokens such as AddToken, EqToken, and InToken, primarily responsible for operations like addition, equality, and belonging as defined in risk control rules. PrimeToken represents the relevant data types defined in risk control rules, including IntToken, BoolToken, and DecToken, used to represent integer, Boolean, and floating-point types, respectively. CallToken represents complex data transformation operations defined in risk control rules, similar to a "function" in a programming language. It includes judgment tokens (StrInToken), count-by-day tokens (CountByDayToken), and string truncation tokens (StrCatToken), used to represent string inclusion judgment, count-by-day, and string truncation, respectively.

[0039] The syntax tree optimization submodule 12 is used to optimize the initial syntax tree constructed by the syntax tree construction module 11 and generate the target syntax tree.

[0040] The optimization process includes syntax tree pruning and / or node priority reordering. Syntax tree pruning can involve deleting useless parts of the syntax tree, while node priority reordering can adjust the execution order of the decision-making processes of each node in the syntax tree based on their execution time.

[0041] Specifically, the syntax tree optimization submodule 12 can obtain the initial syntax tree from the syntax tree construction module 11, optimize the initial syntax tree, and then use the optimized syntax tree as the target syntax tree for subsequent risk identification.

[0042] It should be noted that the purpose of optimizing the initial syntax tree is to reduce the time spent on discrimination using the syntax tree, thereby improving the efficiency of risk identification.

[0043] Risk identification submodule 13 is used to determine the risk identification result based on basic service information and target syntax tree.

[0044] The basic service information can include user information and business information. User information can include user name, user identifier, account information, account identifier, etc., while business information can include business execution time, business type, amount information, etc. The risk identification result can be whether there is a risk, and if so, the risk identification result can also include the risk level, etc.

[0045] For example, the user information in the basic service information may include the user's name, ID number, bank account type, and bank card number, while the business information may include the time of the transaction, the type of transaction, and the amount involved. For instance, the business information could be: March 17, 2021, 15:00, withdrawal transaction, amount 5000 yuan.

[0046] Specifically, by inputting basic service information into the target syntax tree, it is possible to determine whether the current service corresponding to the basic service information is at risk based on the discrimination conditions in the target syntax tree.

[0047] The technical solution of this invention constructs an initial syntax tree through a syntax tree construction submodule in the rule engine module, optimizes the initial syntax tree based on the syntax tree optimization submodule to generate a target syntax tree, and then determines the risk identification result through a risk identification submodule. This solves the problem of complex rule syntax and high learning cost in existing rule engine modules, and achieves the technical effect of reducing the learning cost of the rule engine and improving the recognition efficiency of the rule engine.

[0048] Example 2

[0049] Figure 3 This is a schematic diagram of a risk identification system provided in Embodiment 2 of the present invention. The explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0050] like Figure 3 As shown, the syntax tree optimization submodule 12 also includes a syntax tree pruning unit 121.

[0051] The syntax tree pruning unit 121 is used to process the empty input based on the initial syntax tree constructed by the syntax tree construction submodule 11, and prune the initial syntax tree based on the processing result to generate the target syntax tree.

[0052] Specifically, the input to the initial syntax tree is set to empty. If the initial syntax tree can output a True or False result, the branch corresponding to that result is deleted. Alternatively, the parameters corresponding to each node in the initial syntax tree can be calculated based on an empty input. For example, some information needed for the judgment can be pre-calculated and stored in a cache so that it can be retrieved and used in subsequent judgments.

[0053] like Figure 3 As shown, the syntax tree optimization submodule 12 also includes a node priority rearrangement unit 122.

[0054] The node priority rearrangement unit 122 is used to adjust the processing order of each node in the initial syntax tree based on the word conversion time of each node in the initial syntax tree constructed by the syntax tree construction submodule 11, so as to generate the target syntax tree.

[0055] Specifically, since different data take different amounts of time to convert into tokens, nodes corresponding to tokens with shorter conversion times can be arranged first, while nodes corresponding to tokens with longer conversion times can be arranged later.

[0056] Understandably, if the risk of the current service can be determined based on the tokens with shorter conversion times, the recognition result can be returned immediately, effectively shortening the execution time. For example, the average execution time of the CountByDayToken (count by day) token is generally thousands of times longer than that of the StrCatToken (string truncation) token. Therefore, the string truncation token with shorter execution time can be prioritized in the calculation.

[0057] It should be noted that both the syntax tree pruning unit 121 and the node priority reordering unit 122 can be used to optimize the initial syntax tree. In specific use, either unit can be used to generate the target syntax tree, or both units can be used. The order of the two units is not specifically limited in this embodiment.

[0058] Optionally, to improve the execution speed of the rule engine, rule engine module 1 also includes: bytecode optimization submodule 14, such as... Figure 3 As shown.

[0059] Bytecode optimization submodule 14 is used to compile the target syntax tree generated by syntax tree optimization submodule 12 into a bytecode syntax tree.

[0060] Among them, the bytecode syntax tree is a syntax tree constructed by converting the grammatical structure in the target syntax tree into bytecode.

[0061] Specifically, the target syntax tree is obtained from the syntax tree optimization submodule 12, and the target syntax tree is compiled into bytecode to generate a bytecode syntax tree.

[0062] It's important to note that the advantage of using bytecode is that you only need to learn the code once to be applicable to all Java-supported platforms. This is because bytecode is an intermediate representation of the code, not the actual executable code of the underlying CPU (Central Processing Unit). Furthermore, bytecode has a simpler architecture than standard code. Therefore, execution based on bytecode syntax trees is faster than execution based on target syntax trees.

[0063] At this point, the risk identification submodule 13 is used to determine the risk identification result based on the basic service information and the bytecode syntax tree.

[0064] Optionally, to reduce the time spent executing the target syntax tree in the rules engine module 1, the syntax tree optimization submodule 12 includes: a cache unit 123, such as... Figure 3 As shown.

[0065] Cache unit 123 is used to cache the target parameters obtained during the processing of basic service information of the target syntax tree.

[0066] The target parameter can be a computational function, parameters, and / or results determined during the execution of the target syntax tree.

[0067] Specifically, target parameters calculated based on the target syntax tree can be stored in a cache for easy retrieval and use. For example, the calculation function, parameters, and results can be cached. When the same calculation function, parameters, or results need to be calculated, the required information can be retrieved directly from the cache, saving computation time.

[0068] Optional, such as Figure 3 As shown, the syntax tree construction submodule 11 includes: a rule loading unit 111, a rule parsing unit 112, and an abstract syntax tree unit 113. The rule loading unit 111 loads the risk control model and determines risk identification rules based on the risk control model. The rule parsing unit 112 obtains the risk identification rules determined by the rule loading unit 111 and parses the risk identification rules to generate at least two lexical units. The abstract syntax tree unit 113 obtains each lexical unit from the rule parsing unit 112 and constructs an initial syntax tree based on each lexical unit.

[0069] Specifically, the rule loading unit 111 can load the risk control model from storage spaces such as databases and cloud platforms where the risk control model is stored. After obtaining the risk control model, at least one risk identification rule can be obtained from the risk control model. For example, the risk identification rule is that the password for withdrawing funds from a private fixed-term account has been incorrect more than 9 times within three days, and the branch cannot configure it itself.

[0070] Specifically, the rule parsing unit 112 can parse the risk identification rule into multiple tokens. For example, it can parse the rule calculated by day into the CountByDayToken token, and parse the operation into the InToken token, etc.

[0071] Specifically, the abstract syntax tree unit 113 can obtain multiple words from the rule parsing unit 112, and concatenate and combine the obtained words to construct an initial syntax tree to achieve the function of risk identification.

[0072] The technical solution of this invention optimizes the initial syntax tree through a syntax tree pruning unit and a node priority reordering unit to reduce the execution time of the syntax tree. It improves the execution efficiency of the syntax tree through a bytecode optimization submodule. Furthermore, it constructs the initial syntax tree through a rule loading unit, a rule parsing unit, and an abstract syntax tree unit to reduce the learning cost of rules in the rule engine. This solves the problem of complex rule syntax and high learning cost in existing rule engine modules, and achieves the technical effect of reducing the learning cost of the rule engine and improving the recognition efficiency of the rule engine.

[0073] Example 3

[0074] Figure 4 This is a schematic diagram of a risk identification system provided in Embodiment 3 of the present invention. The explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0075] like Figure 4 As shown, the risk identification system includes a rule engine module 1, an information collection module 2, and a risk prediction module 3.

[0076] Information collection module 2 is used to obtain basic service information from various channels and send the basic service information to the risk prediction and judgment module. Risk prediction and judgment module 3 is used to obtain basic service information from information collection module 2 and determine whether to send the basic service information to rule engine module 1.

[0077] The channels can be physical bank branches, self-service terminals, mobile clients, WeChat mini-programs, and ATMs, among other ways to conduct business.

[0078] Specifically, when a user conducts business through a certain channel, the information collection module 2 can obtain the user information and business information involved in the business through that channel, and add the channel information to the business information so as to combine the channel information for subsequent risk identification.

[0079] Specifically, the risk assessment module 3 can obtain basic service information from the information collection module 2, and then determine whether the current service belongs to the category of services that should be directly rejected or directly allowed based on the basic service information. If so, the current service can be processed directly; otherwise, the basic service information needs to be sent to the rule engine module 1 so that the rule engine module 1 can identify the risk of the current service based on the basic service information.

[0080] Optional, such as Figure 4 As shown, the risk prediction module 3 includes: feature extraction submodule 31 and blacklist / whitelist submodule 32.

[0081] The feature extraction submodule 31 is used to obtain basic service information from the information collection module 2 and generate a risk feature mapping table based on the basic service information. The blacklist / whitelist submodule 32 is used to obtain the risk feature mapping table from the feature extraction submodule 31, and determine whether the current service belongs to the blacklist or whitelist based on the risk feature mapping table. If the current service does not belong to the blacklist or whitelist, the risk feature mapping table is sent to the rule engine module 1.

[0082] The risk feature mapping table can be a table that stores the basic service information. To save storage space, the risk feature mapping table can be a hash mapping table.

[0083] Specifically, the feature extraction submodule 31 can obtain basic service information from the information collection module 2, and obtain information from the basic service information to construct the risk feature mapping table, so as to generate the risk feature mapping table.

[0084] It should be noted that a risk feature mapping table can be generated based on some or all of the basic service information. The specific information included in the risk feature mapping table can be set according to actual needs, and is not specifically limited in this embodiment.

[0085] For example, the information collection module 2 can uniformly format basic service information into XML (eXtensible Markup Language) format and send the basic service information to the feature extraction submodule 31 via HTTP (Hypertext Transfer Protocol) request. Furthermore, it can extract information constituting the risk feature mapping table based on SpEL (Spring Expression Language) expressions, such as transaction number, channel number, source address (IP address, MAC address, etc.), and transaction entity information, and generate the risk feature mapping table in the server's memory.

[0086] The blacklist / whitelist submodule 32 is used to obtain the risk feature mapping table from the feature extraction submodule 31, and determine whether the current service belongs to the blacklist or whitelist based on the risk feature mapping table. If the current service does not belong to the blacklist or whitelist, the risk feature mapping table is sent to the rule engine module 1.

[0087] The blacklist can be a list of services that are refused service without risk identification, such as a bank card being recorded on the blacklist. The whitelist can be a list of services that are executed service without risk identification.

[0088] Specifically, a risk feature mapping table is obtained from the feature extraction submodule 31. Then, it is determined whether the information in the risk feature mapping table corresponds to the information stored in the blacklist or whitelist. That is, it is determined whether the current service belongs to the blacklist or whitelist. If the current service belongs to the blacklist, the current service is rejected. If the current service belongs to the whitelist, the current service is executed. If the current service does not belong to either the blacklist or the whitelist, the risk feature mapping table is sent to the rule engine module 1 to identify the risk of the current service.

[0089] At this time, the risk identification submodule 13 can be used to obtain the risk feature mapping table from the blacklist / whitelist submodule 32, parse the basic service information based on the risk feature mapping table, and determine the risk identification result based on the basic service information and the target syntax tree.

[0090] To improve the recognition rate of the blacklist / whitelist submodule 32, feature identifiers can be generated in advance based on basic service information, and the current service can be determined as to be blacklisted or whitelisted based on the feature identifiers.

[0091] Optionally, the feature extraction submodule 31 is further configured to generate feature identifiers based on the basic service information from the information collection module 2, and generate a risk feature mapping table based on the basic service information and the feature identifiers. The blacklist / whitelist submodule 32 is further configured to obtain the risk feature mapping table from the feature extraction submodule 31, and determine whether the current service belongs to the blacklist or whitelist based on the feature identifiers in the risk feature mapping table.

[0092] The feature identifier can be an identifier assigned to the current service based on basic service information; if the basic service information is the same, then the feature identifiers are the same. Similarly, the feature identifier can be an identifier assigned to similar services based on basic service information; if the basic service information is similar, then the feature identifiers are the same.

[0093] It should be noted that assigning different feature identifiers to different basic service information can avoid processing the same basic service information multiple times. For example, if basic service information A is sent three times consecutively due to system or network issues, the same feature identifier can be assigned to all three received instances of basic service information A to delete the duplicate identifiers. Assigning the same identifier to similar services can also avoid processing similar basic service information multiple times. The method for determining similarity can be based on actual needs; for example, assigning the same feature identifier to basic service information involving transfers exceeding 1000 yuan using the same bank card within 5 minutes.

[0094] The blacklist can store feature identifiers that allow direct denial of services without risk identification, while the whitelist can store feature identifiers that allow direct access to services without risk identification.

[0095] Specifically, if the feature identifier in the risk feature mapping table corresponds to the feature identifier stored in the blacklist, the current service can be rejected; if the feature identifier in the risk feature mapping table corresponds to the feature identifier stored in the whitelist, the current service can be allowed; if the feature identifier in the risk feature mapping table does not correspond to the feature identifiers stored in both the blacklist and the whitelist, the risk feature mapping table can be sent to the rule engine module 1 to identify the risk of the current service.

[0096] Figure 5 This is a schematic diagram of another risk identification system provided in Embodiment 3 of the present invention. The explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0097] like Figure 5 As shown, the risk identification system also includes a visualization model configuration module 4 and a risk control model generation and storage module 5.

[0098] The visualization model configuration module 4 is used to obtain configured service information, channel information, risk control conditions, and control rules based on a visual interface. The risk control model generation and storage module 5 is used to generate and store a risk control model based on the service information, channel information, risk control conditions, and control rules obtained from the visualization model configuration module 4.

[0099] The visual interface can be used to configure the risk control model. This interface may include service information configuration areas, channel information configuration areas, risk control condition configuration areas, and control rule configuration areas. Service information may include user information and / or business information. Risk control conditions can be judgment criteria, i.e., combinations of different service information and / or channel information, such as: transaction type is positive, account length is 16 or 19 digits, and the same account has been verified more than 3 times within 3 days. Control rules can be the handling methods corresponding to the risk control conditions.

[0100] Specifically, developers can configure service information, channel information, risk control conditions, and control rules through the visual interface in the visual model configuration module 4, in order to build a risk control model based on the service information, channel information, risk control conditions, and control rules.

[0101] Specifically, the risk control model generation and storage module 5 can obtain information such as service information, channel information, risk control conditions, and control rules from the visualization model configuration module 4, and can construct a risk control model based on the above information. Furthermore, the constructed risk control model can be stored for subsequent use by the rule engine module 1.

[0102] Optionally, the risk identification system can also take action on the current service based on the risk identification results. For example... Figure 5 As shown, the risk identification system also includes: process control module 6.

[0103] The process control module 6 is used to determine the target handling method based on the risk identification results output by the rule engine module 1 and the correspondence between the risk identification results and the handling methods, and to handle the current service based on the target handling method.

[0104] The target handling method can be a way of handling the current service, such as real-time warning, logging, real-time blocking, or sending to the business management department.

[0105] Specifically, after obtaining the risk identification results, the corresponding handling method can be found in the pre-established correspondence between risk identification results and handling methods, and this handling method can be used as the target handling method. Furthermore, the current service can be handled according to the target handling method.

[0106] For example, the pre-established correspondence between risk identification results and handling methods is as follows: No risk - execute the current service, Level 1 risk - log recording, Level 2 risk - log recording and real-time blocking, Level 3 risk - log recording, real-time blocking and sending to the business management department.

[0107] Optionally, the risk identification system can also provide feedback on the handling methods and results. For example... Figure 5 As shown, the risk identification system also includes: risk identification result feedback module 7.

[0108] The risk identification result feedback module 7 is used to feed back the handling results of the process control module 6 to the terminal device corresponding to the channel information.

[0109] The terminal equipment can be the terminal equipment for risk aggregation across various channels. For example, the terminal equipment for a branch's counters and ATMs could be the terminal equipment of the branch's competent authority. The handling result can include the handling method, and whether the handling was successful or unsuccessful.

[0110] Specifically, the process control module 6 can feed back the handling method and whether the handling was successful for each service to the terminal device corresponding to the channel information, so that the managers of each channel can make changes to the handling of errors, and also allow the managers of each channel to manually handle services that were not handled successfully.

[0111] Optionally, the risk identification system can also record the risk identification process. For example... Figure 5 As shown, the risk identification system also includes: risk log module 8.

[0112] Risk log module 8 is used to record the execution process of rule engine module 1.

[0113] Specifically, the execution process of the rule engine module 1 can be recorded through the risk log module 8, which facilitates subsequent troubleshooting.

[0114] The technical solution of this invention filters services that do not require risk identification through an information collection module and a risk prediction module, reducing the number of risk identifications. It also visualizes and configures risk control rules through a visualization model configuration module and a risk control model generation and storage module, configuring channel information to make risk control rules easy to manage. This solves the problems of difficult configuration, adjustment and management of risk control rules in the prior art, as well as the problem that rule engines cannot be applied to multiple channels. It achieves the technical effect of visually configuring risk control rules, making risk control rules easy to manage, and making the risk identification system applicable to multiple channels.

[0115] Example 4

[0116] Figure 6 This is a schematic diagram of a risk identification system provided in Embodiment 4 of the present invention. The explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0117] like Figure 6 As shown, the risk identification system includes a rules engine module 1 and a risk indicator calculation module 9.

[0118] Risk indicator calculation module 9 is used to process historical business information corresponding to basic service information based on a distributed cluster to obtain risk identification information.

[0119] A distributed cluster can consist of multiple servers, each performing the same or different business functions. "Distributed" refers to bringing multiple servers together, each performing a different business function; "clustered" refers to bringing multiple servers together, each performing the same business function. Historical business information can correspond to one or more pieces of information in the basic service information, representing business information over a past period, such as transaction information for account A over the past two days. Risk identification information can be the information required by rule engine module 1, or information obtained by processing historical business information.

[0120] For example, risk identification information may include frequency indicators of risk factors, floating-point cumulative indicators, event statistics indicators, and event sequence indicators. Taking trading as an example, the frequency indicator of risk factors may be the number of transactions, the floating-point cumulative indicator may be the cumulative value of transaction amounts, the event statistics indicator may be a statistical summary of all transactions that have occurred, and the event sequence indicator may be the transaction order of all transactions that have occurred.

[0121] Specifically, based on a distributed cluster, historical business information corresponding to basic service information is obtained from basic service information, and then the historical business information is processed to obtain risk identification information.

[0122] It should be noted that it can obtain all risk identification information, or obtain the corresponding risk identification information according to the requirements of the rule engine module 1.

[0123] Optionally, the distributed cluster is built on Hazelcast.

[0124] Compared to distributed clusters built using Storm or Flink, distributed clusters built on Hazelcast have the advantages of consuming fewer resources and having lower deployment costs when acquiring risk identification information.

[0125] Optional, such as Figure 6 As shown, the risk indicator calculation module 9 includes: a data access submodule 91 and an indicator calculation submodule 92.

[0126] The data access submodule 91 is used to acquire basic service information, corresponding historical business information, and target identification information types. The indicator calculation submodule 92 is used to calculate risk identification information based on the basic service information, historical business information, and target risk information types.

[0127] The target identification information type can be any type of risk identification information required by the rule engine module 1. For example, the target identification information type can include at least one of the following: frequency indicators of risk factors, floating-point accumulation indicators, event statistics indicators, and event sequence indicators.

[0128] Specifically, the data access submodule 91 can obtain the request sent by the rule engine module 1, parse the request, obtain basic service information and target identification information type, and then determine the historical business information required to calculate risk identification information based on the basic service information and target identification information type, and obtain the required information from all historical business information.

[0129] For example, by using HTTP protocol and Spring Boot technology, the system receives the indicator calculation request sent by the rule engine module 1 during the execution process, parses out the target identification information type, determines the historical business information required for calculation based on the target identification information type, puts the historical business information into the data stream to be calculated, waits for the indicator calculation submodule 92 to pull the data, and returns the calculation result of the indicator calculation submodule 92 through an HTTP response.

[0130] Specifically, the indicator calculation submodule 92 can determine the calculation method of the required risk identification information based on the type of target risk information, and then calculate the risk identification information based on the basic service information, historical business information and the calculation method.

[0131] Optional, such as Figure 6 As shown, the indicator calculation submodule 92 includes: cluster management unit 921.

[0132] Cluster management unit 921 is used to determine the nodes of the distributed cluster that calculates risk identification information.

[0133] For example, the cluster management unit can be built based on Hazelcast cluster management technology, which can realize node broadcasting, node discovery and high availability of the computing cluster.

[0134] Optional, such as Figure 6 As shown, the indicator calculation submodule 92 may also include a memory management unit 922.

[0135] The memory management unit 922 is used to store configuration parameters of the distributed cluster and / or backup information of each node in the distributed cluster.

[0136] Optional, such as Figure 6 As shown, the indicator calculation submodule 92 includes: time window calculation unit 923.

[0137] The time window calculation unit 923 is used to construct a time window based on an adaptive time window algorithm and data stream processing tools, and to perform statistics and processing on historical business data based on the time window.

[0138] The time window can be a window used to statistically analyze historical business information over a period of time, such as 3 days.

[0139] For example, based on the adaptive time window algorithm and the Hazelcast Jet streaming toolkit, streaming processing and statistics of various historical business information can be achieved.

[0140] Optional, such as Figure 6 As shown, the indicator calculation submodule 92 may also include: window management algorithm unit 924.

[0141] The window management algorithm unit 924 is used to clean up expired time windows and / or adjust unexpired time windows.

[0142] The technical solution of this invention controls a distributed cluster to calculate the information required by the rule engine module through a risk indicator calculation module, which solves the problem of low calculation speed caused by calculation based on a single server in the prior art and achieves the technical effect of improving the information calculation speed.

[0143] It is worth noting that the various units and modules included in the risk identification system involved in the above embodiments are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of the present invention.

[0144] Example 5

[0145] Figure 7 This is a schematic diagram of a risk identification system provided in Embodiment 5 of the present invention. The explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0146] like Figure 7 As shown, the risk identification system includes a risk indicator flow calculation subsystem (risk indicator calculation module) and a channel risk transaction identification subsystem.

[0147] The risk indicator stream calculation subsystem includes an indicator stream calculation module (indicator calculation submodule) and a stream data access module (data access submodule).

[0148] The streaming data access module, based on the HTTP protocol and Spring Boot technology, receives historical metric calculation requests sent by the rule engine during execution and parses out the necessary parameters for metric calculation. It then retrieves these parameters and places them into the data stream to be calculated, waiting for the metric stream calculation module to pull the data and return the calculated result via an HTTP response.

[0149] The indicator stream calculation module is responsible for calculating historical events such as transaction frequency, amount accumulation, and event sequence. It mainly includes the cluster management submodule (cluster management unit), the shared memory management submodule (memory management unit), the time window calculation submodule (time window calculation unit), and the window management submodule (window management algorithm unit).

[0150] The channel risk transaction identification subsystem includes a transaction and channel information collection module (information collection module), a risk feature extraction module (feature extraction sub-module), a blacklist / whitelist module (blacklist / whitelist sub-module), a rule engine module, a risk configuration and storage module (visual model configuration module and risk control model generation and storage module), a process control module, a risk log module, and a risk identification result feedback module.

[0151] The transaction and channel information collection module is integrated across various channels to collect transaction and channel information for each transaction from sources such as branches, ATMs, and WeChat mini-programs. Furthermore, it formats the transaction and channel information into XML format and sends this information to the risk feature extraction module via HTTP requests.

[0152] The risk feature extraction module extracts information such as transaction number, channel number, source address, and transaction entity from HTTP requests based on SPEL expressions, and generates a risk feature hash mapping table and feature identifiers in the server memory based on the above information.

[0153] The blacklist / whitelist module retrieves fields such as feature identifier, channel number, and transaction number from the risk feature hash table to determine whether a transaction needs to be processed by the rules engine module. If the transaction exists in the blacklist, it is filtered out. If it exists in the whitelist, the transaction is executed directly. For transactions that do not meet the criteria of either the blacklist or whitelist, the risk feature hash table is sent to the rules engine module for processing.

[0154] The rules engine module is responsible for reading risk identification rules from the risk configuration and storage module, abstracting a syntax tree based on the risk identification rules, and performing rule matching on the input risk feature hash table according to the abstract syntax tree to obtain the identification results. If the rule execution process involves the calculation of historical indicators, the indicator stream calculation module is invoked via RPC (Remote Procedure Call) to perform the calculation.

[0155] The risk configuration and storage module is responsible for configuring risk identification rules through a visual interface and building and storing risk identification models.

[0156] The indicator flow calculation module is responsible for calculating the frequency indicators of risk factors (such as the number of transactions), floating-point accumulation indicators (such as the accumulation of transaction amounts), event statistics indicators (such as transactions A, B, and C occurring in any order), and event sequence indicators (such as transactions A, B, and C occurring in a sequential order) in real time based on the input data flow (historical business information).

[0157] The process control module is responsible for processing the recognition results of the rule engine, such as issuing real-time warnings to clients, logging, blocking in real time, and reporting to business supervisors.

[0158] The risk log module is responsible for recording the execution process of the rule engine, which facilitates subsequent troubleshooting.

[0159] The identification result feedback module is used to package the identification and handling results into an HTTP response and feed them back to various channels so that staff in each channel can handle the issues themselves based on the identification and handling results.

[0160] Optionally, the rule engine module includes: a rule loader submodule (rule loading unit), a rule parser submodule (rule parsing unit), an abstract syntax tree submodule (abstract syntax tree unit), a syntax tree optimization submodule, and a bytecode optimization submodule.

[0161] The system comprises several submodules: a rule loader submodule, a rule parser submodule, and an abstract syntax tree submodule. The rule parser submodule parses these rules into terms and their parameters. The abstract syntax tree submodule, a parent-child submodule, forms an abstract syntax tree based on terms and their parameters. The syntax tree optimization submodule handles pre-computation, priority reordering, and caching. Pre-computation reduces the number of execution instructions and lowers response time by pre-calculating risk identification rules. Priority reordering prioritizes shorter-running terms; if a shorter term is sufficient to determine the risk expression's truth value, longer-running terms are returned immediately without further computation, effectively shortening execution time. Caching caches calculated functions, parameters, and results; if the same function or parameters have already been calculated, the result is retrieved directly from the cache.

[0162] The technical solution of this invention constructs a lightweight rule engine based on bytecode dynamic loading technology and shared caching technology. It solves the problems of complex rule syntax, high learning cost, and difficulty in management and configuration in existing rule engine modules. It realizes efficient identification of risk identification rules and visual configuration of risk identification rules, reduces the learning cost of the rule engine, makes risk identification rules easy to manage, and is suitable for complex real-time risk control application scenarios in business systems of various channels, thereby enhancing the maintainability of the risk identification system.

[0163] Example 6

[0164] Figure 8 This is a flowchart illustrating a risk identification method provided in Embodiment Six of the present invention. This embodiment is applicable to situations where risk identification is performed on business operations at various channel ends using the technical solutions of the above embodiments. The method can be executed by a risk identification system, which can be implemented in software and / or hardware and integrated into a device with computing and control functions. Explanations of terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0165] See Figure 8 The method provided in this embodiment specifically includes the following steps:

[0166] S810, Construct the initial syntax tree based on the risk control model through the syntax tree construction submodule.

[0167] The initial syntax tree consists of at least two nodes.

[0168] Specifically, the syntax tree construction submodule can obtain a preset risk control model, parse the risk control model to obtain the risk control rules involved in the risk control model, and then construct an abstract syntax tree based on the risk control rules, using this abstract syntax tree as the initial syntax tree.

[0169] S820. The syntax tree constructed by the syntax tree construction module is optimized by the syntax tree optimization submodule, and the target syntax tree is generated.

[0170] The optimization process includes syntax tree pruning and / or node priority rearrangement.

[0171] Specifically, the syntax tree optimization submodule can obtain the initial syntax tree from the syntax tree construction module, optimize the initial syntax tree, and use the optimized syntax tree as the target syntax tree for subsequent risk identification.

[0172] S830: The risk identification submodule determines the risk identification result based on the basic service information and the target syntax tree.

[0173] Specifically, by inputting basic service information into the target syntax tree, it is possible to determine whether the current service corresponding to the basic service information is at risk based on the discrimination conditions in the target syntax tree.

[0174] The technical solution of this invention constructs an initial syntax tree through a syntax tree construction submodule in the rule engine module, optimizes the initial syntax tree based on the syntax tree optimization submodule to generate a target syntax tree, and then determines the risk identification result through a risk identification submodule. This solves the problem of complex rule syntax and high learning cost in existing rule engine modules, and achieves the technical effect of reducing the learning cost of the rule engine and improving the recognition efficiency of the rule engine.

[0175] Example 7

[0176] Figure 9 This is a schematic diagram of the structure of a server provided in Embodiment 7 of the present invention. Figure 9 A block diagram is shown that is suitable for implementing an exemplary server 100 according to embodiments of the present invention. Figure 9 The server 100 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0177] like Figure 9 As shown, server 100 is presented in the form of a general-purpose computing device. The components of server 100 may include, but are not limited to: one or more processors or processing units 1001, system memory 1002, and bus 1003 connecting different system components (including system memory 1002 and processing unit 1001).

[0178] Bus 1003 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0179] Server 100 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by server 100, including volatile and non-volatile media, removable and non-removable media.

[0180] System memory 1002 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1004 and / or cache memory 1005. Server 100 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1006 may be used to read and write non-removable, non-volatile magnetic media (… Figure 9 Not shown; usually referred to as a "hard drive"). Although Figure 9 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 1003 via one or more data media interfaces. System memory 1002 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0181] A program / utility 1008 having a set (at least one) of program modules 1007 may be stored, for example, in system memory 1002. Such program modules 1007 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 1007 typically perform the functions and / or methods described in the embodiments of the present invention.

[0182] Server 100 can also communicate with one or more external devices 1009 (e.g., keyboard, pointing device, display 1010, etc.), and with one or more devices that enable users to interact with server 100, and / or with any device that enables server 100 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 1011. Furthermore, server 100 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1012. As shown, network adapter 1012 communicates with other modules of server 100 via bus 1003. It should be understood that, although... Figure 9 As not shown, other hardware and / or software modules can be used in conjunction with server 100, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0183] The processing unit 1001 executes various functional applications and data processing by running programs stored in the system memory 1002, such as implementing the risk identification method provided in the embodiments of the present invention.

[0184] Example 8

[0185] Embodiment 8 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a risk identification method, the method comprising:

[0186] The syntax tree construction submodule constructs an initial syntax tree based on the risk control model; the initial syntax tree includes at least two nodes.

[0187] The syntax tree optimization submodule optimizes the initial syntax tree constructed by the syntax tree construction module and generates the target syntax tree. The optimization process includes syntax tree pruning and / or node priority rearrangement.

[0188] The risk identification submodule determines the risk identification result based on the basic service information and the target syntax tree.

[0189] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0190] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0191] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0192] Computer program code for performing the operations of embodiments of the present invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0193] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A risk identification system, characterized in that, include: Rules engine module; The rule engine module includes: The syntax tree construction submodule is used to construct an initial syntax tree based on a preset risk control model, wherein the initial syntax tree includes at least two nodes; The syntax tree optimization submodule is used to optimize the initial syntax tree constructed by the syntax tree construction submodule and generate the target syntax tree. The optimization process includes syntax tree pruning and / or node priority rearrangement. The risk identification submodule is used to determine the risk identification result based on the basic service information and the target syntax tree; wherein, the basic service information includes: user information and business information, the user information includes user name, user identifier, account information, and account identifier, and the business information includes business execution time, business type, and amount information; The rule engine module further includes: a bytecode optimization submodule, used to compile the target syntax tree generated by the syntax tree optimization submodule into a bytecode syntax tree; The risk identification submodule is used to determine the risk identification result based on the basic service information and the bytecode syntax tree; The system also includes: The risk indicator calculation module is used to process historical business information corresponding to the basic service information based on a distributed cluster to obtain risk identification information. The risk indicator calculation module includes: a data access submodule, used to obtain the basic service information, historical business information corresponding to the basic service information, and target identification information type; wherein, the target identification information type is the type of risk identification information required by the rule engine module, and the target identification information type includes at least one of the following: frequency index of risk factors, floating-point accumulation index, event statistics index, and event sequence index; The indicator calculation submodule is used to calculate risk identification information based on the basic service information, the historical business information, and the target risk information type.

2. The system according to claim 1, characterized in that, The syntax tree optimization submodule includes: The syntax tree pruning unit is used to process the empty input based on the initial syntax tree constructed by the syntax tree construction submodule, and prune the initial syntax tree based on the processing result to generate the target syntax tree.

3. The system according to claim 1, characterized in that, The syntax tree optimization submodule includes: The node priority reordering unit is used to adjust the processing order of each node in the initial syntax tree based on the lexical conversion time of each node in the initial syntax tree constructed by the syntax tree construction submodule, so as to generate the target syntax tree.

4. The system according to claim 1, characterized in that, The syntax tree optimization submodule includes: The caching unit is used to cache the target parameters obtained during the processing of basic service information of the target syntax tree.

5. The system according to claim 1, characterized in that, The syntax tree construction submodule includes: A rule loading unit is used to load the risk control model and determine risk identification rules based on the risk control model. The rule parsing unit is used to obtain the risk identification rules determined by the rule loading unit, and parse the risk identification rules to generate at least two tokens; Abstract syntax tree unit is used to obtain each word in the rule parsing unit and construct an initial syntax tree based on each word.

6. The system according to claim 1, characterized in that, Also includes: The information collection module is used to obtain basic service information from various channels and send the basic service information to the risk prediction module; The risk prediction module is used to obtain basic service information from the information collection module and determine whether to send the basic service information to the rule engine module.

7. The system according to claim 6, characterized in that, The risk prediction module includes: The feature extraction submodule is used to obtain the basic service information from the information collection module and generate a risk feature mapping table based on the basic service information. The blacklist / whitelist submodule is used to obtain the risk feature mapping table from the feature extraction submodule, determine whether the current service belongs to the blacklist or the whitelist based on the risk feature mapping table, and if the current service does not belong to the blacklist or the whitelist, then the risk feature mapping table is sent to the rule engine module. The risk identification submodule is used to obtain the risk feature mapping table from the blacklist / whitelist submodule, parse the basic service information based on the risk feature mapping table, and determine the risk identification result based on the basic service information and the target syntax tree.

8. The system according to claim 6, characterized in that, The risk prediction module includes: The feature extraction submodule is used to obtain the basic service information from the information collection module, generate feature identifiers based on the basic service information, and generate a risk feature mapping table based on the basic service information and the feature identifiers. The blacklist / whitelist submodule is used to obtain the risk feature mapping table from the feature extraction submodule and determine whether the current service belongs to the blacklist or whitelist based on the feature identifiers in the risk feature mapping table.

9. The system according to claim 1, characterized in that, Also includes: The visualization model configuration module is used to obtain configuration service information, channel information, risk control conditions, and control rules based on a visual interface. The risk control model generation and storage module is used to generate a risk control model based on service information, channel information, risk control conditions and control rules obtained from the visualization model configuration module, and to store the risk control model.

10. The system according to claim 1, characterized in that, The indicator calculation submodule includes: A cluster management unit is used to determine the nodes of the distributed cluster that calculate the risk identification information.

11. The system according to claim 10, characterized in that, The indicator calculation submodule also includes: The memory management unit is used to store the configuration parameters of the distributed cluster and / or the backup information of each node in the distributed cluster.

12. The system according to claim 1, characterized in that, The indicator calculation submodule includes: The time window calculation unit is used to construct a time window based on an adaptive time window algorithm and data stream processing tools, and to perform statistics and processing on historical business data based on the time window.

13. The system according to claim 12, characterized in that, The indicator calculation submodule also includes: The window management algorithm unit is used to clean up expired time windows and / or adjust unexpired time windows.

14. The system according to claim 1, characterized in that, Also includes: The process control module is used to determine the target handling method based on the risk identification results output by the rule engine module and the correspondence between the risk identification results and the handling methods, and to handle the current service based on the target handling method.

15. The system according to claim 14, characterized in that, Also includes: The risk identification result feedback module is used to feed back the handling results of the process control module to the terminal device corresponding to the channel information.

16. The system according to claim 1, characterized in that, Also includes: The risk log module is used to record the execution process of the rule engine module.

17. The system according to claim 1, characterized in that, The distributed cluster is built on Hazelcast.

18. A risk identification method, characterized in that, include: The initial syntax tree is constructed based on the risk control model through the syntax tree construction submodule; The initial syntax tree includes at least two nodes; The syntax tree optimization submodule optimizes the initial syntax tree constructed by the syntax tree construction module and generates the target syntax tree. The optimization process includes syntax tree pruning and / or node priority rearrangement. The risk identification submodule determines the risk identification result based on the basic service information and the target syntax tree; wherein, the basic service information includes: user information and business information, the user information includes user name, user identifier, account information, and account identifier, and the business information includes business execution time, business type, and amount information; The risk identification method further includes: a bytecode optimization submodule, used to compile the target syntax tree generated by the syntax tree optimization submodule into a bytecode syntax tree; The risk identification submodule is used to determine the risk identification result based on the basic service information and the bytecode syntax tree; The risk indicator calculation module is used to process historical business information corresponding to the basic service information based on a distributed cluster to obtain risk identification information. The risk indicator calculation module includes: a data access submodule, used to obtain the basic service information, historical business information corresponding to the basic service information, and target identification information type; wherein, the target identification information type is the type of risk identification information required by the rule engine module, and the target identification information type includes at least one of the following: frequency index of risk factors, floating-point accumulation index, event statistics index, and event sequence index; The indicator calculation submodule is used to calculate risk identification information based on the basic service information, the historical business information, and the target risk information type.

19. A server, characterized in that, The server includes: one or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the risk identification method as described in claim 18.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the risk identification method as described in claim 18.

Images