Risk control method, node and system

Abstract

The present application provides a risk control method, a node and a system. The method is applied to a remote service node, and comprises: obtaining the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group comprises a plurality of nodes, and whether each node is a trusted node is determined on the basis of trusted status information stored by the present node; and on the basis of the number of trusted nodes in each node group and a pre-stored first preset threshold, correspondingly determining each node group to be a risky group or a trusted group. Risky groups can be simply and efficiently identified, providing a safer and more efficient risk control service.

Description

Risk control methods, nodes and systems Technical Field

[0001] The present application relates to the field of risk control, and in particular to a risk control method, node, and system. Background Art

[0002] With the continuous development of technology in various industries, risk control is an effective means to maintain the stability and security of business in various industries. Risk control refers to risk managers taking various measures and methods to eliminate or reduce the possibility of risk events, or reduce the losses caused by risks.

[0003] For example, in the financial sector, there are losses caused by market risk, credit risk, and operational risk, such as defaulted credit and group-based risky behaviors. Among them, the losses caused by group-based risky behaviors are extremely severe and have a wide impact. How to simply and efficiently identify these high-risk risk groups, such as those with risky behaviors, in order to provide safer and more efficient risk control services, has become a pressing issue.

[0004] Summary of the Invention

[0005] This application provides a risk control method, node, and system that can simply and efficiently identify risk groups to provide safer and more efficient risk control services.

[0006] In the first aspect, the present application provides a risk control method applied to a remote service node, the method comprising: obtaining the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each of the nodes is a trusted node is determined based on the trusted status information stored by the node; based on the number of trusted nodes in each of the node groups and a pre-stored first preset threshold, determining each of the node groups as a risk group or a trusted group.

[0007] The risk control method provided in this application can determine whether a node group as a whole is a risky or trustworthy group based on the trustworthiness of each node within the group. Specifically, based on the trust status information stored by each node, the number of trusted nodes in different node groups is determined to identify risky groups. Services are denied to risky groups, thereby ensuring the security of financial services. The trustworthiness of each node is determined based on whether it is an authenticated, trusted node. This eliminates the need to collect user information from each node, preventing issues such as user data leaks. This enhances privacy while reducing the network transmission pressure and storage pressure on remote service nodes caused by the transmission of large amounts of user information.

[0008] In this application, the determination of whether a node group is a risk group or a trusted group can be performed by either a remote service node or a root node in the node group. For example, the root node can determine whether to make the determination based on its processing power or to report the collected trusted node information to the remote service node for determination. The identification of risk groups can be completed by either the remote service node or by the root node in each node group and then reported to the remote service node. This effectively alleviates the network and computing overhead of the remote service node while reducing service latency.

[0009] In one possible implementation, obtaining the number of trusted nodes in at least one node group connected to the remote service node includes: receiving a trusted status information set reported by each root node, the trusted status information set reported by each root node including the trusted status information of each node in the node group to which it belongs, the root node refers to the node in each node group that is directly connected to the remote service node; and determining the number of trusted nodes in the node group according to each trusted status information set.

[0010] Optionally, the remote service node can divide each node in the local network into a node group, determine the total number of nodes in each node group based on the number of root nodes and child nodes in each node group, and determine the number of trusted nodes in the node group to which it belongs based on the trusted status information reported step by step by the child nodes and the trusted status information of the root node.

[0011] In one possible implementation, it also includes: receiving a trusted message reported by a root node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group; based on the trusted message reported by the root node, determining whether the node group to which the root node belongs is a risk group or a trusted group.

[0012] When the root node is able to judge and process the business, it can report to the remote service node whether the node group it judges belongs to a risk group or a trusted group, or it can inform the remote service node of the number of trusted nodes and let the remote service node judge it by itself.

[0013] In one possible implementation, determining whether the node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a first preset threshold includes: if the proportion of trusted nodes in a node group is greater than the first preset threshold, determining that the node group is a trusted group; if the proportion of trusted nodes in a node group is not greater than the first preset threshold, determining that the node group is a risk group.

[0014] Optionally, the remote service node sets a first preset threshold based on the number of nodes in the node group. Alternatively, the remote service node may also set a first preset threshold based on the number of trusted nodes in the node group and their proportion of the total number of nodes. This setting method is not affected by the number of nodes in the node group and is more flexible and convenient to apply. Calculating the number or proportion of trusted nodes based on the trusted status information of each node does not require relying on complex algorithms to mine risk groups or determine the attributes of their risk events. It only needs to determine whether to provide services based on whether the node group is trustworthy, significantly reducing the difficulty and overhead of computational implementation and improving overall response speed.

[0015] In one possible implementation, the triggering conditions for obtaining the number of trusted nodes in at least one node group connected to the remote service node include one or both of the following: triggered by a risk control event, or triggered at a preset time interval.

[0016] Optionally, after each service request, the trust status of each node may change if the service request is a risk control event. Therefore, the trust status information is updated and statistics are recalculated based on the risk control event trigger. Alternatively, the remote service node can initiate risk group identification at irregular or scheduled intervals. This further enhances the real-time protection capabilities of security.

[0017] In one possible implementation, if a node is determined to be untrusted, all downstream nodes of the untrusted node are also determined to be untrusted. Setting all downstream nodes of an untrusted node as untrusted can further enhance the probability of identifying risk groups, making protection more precise.

[0018] In the second aspect, the present application provides a risk control method applied to a root node, wherein the root node refers to a node that is directly connected to a remote service node in each node group connected to the remote service node, and the method includes: collecting trusted status information of each node in the node group to which it belongs, wherein the trusted status information is saved by each node and reported step by step by each child node; reporting the trusted status information to the remote service node so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0019] This application can identify risk groups based on the trusted node status of different nodes in each local network, such as trusted nodes, common nodes, and untrusted nodes. This eliminates the need to use graph computing, knowledge graphs, community mining, and other techniques to identify risk groups, such as the primary risk behavior group. This significantly simplifies computational complexity, increases the potential for real-time identification, and eliminates the need to rely on abundant user data. Risk groups can be identified simply and efficiently, providing more secure, real-time, and efficient risk control services.

[0020] In one possible implementation, after collecting the trusted status information of each node in the node group, it also includes: determining the number of trusted nodes based on the collected trusted status information of each node in the node group; reporting the trusted status information to the remote service node includes: if the total number of each node in the node group is greater than a pre-stored second preset threshold, then reporting the collected trusted status information of each node as a trusted status information set to the remote service node.

[0021] In one possible implementation, it also includes: determining the number of trusted nodes based on the trusted status information of each node in the node group to which the collection belongs; if the total number of the nodes in the node group to which the collection belongs is not greater than the second pre-stored preset threshold, determining whether the node group to which the collection belongs is a risk group or a trusted group based on the number of trusted nodes in the node group to which the collection belongs and the first pre-stored preset threshold; reporting a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0022] In one possible implementation, determining whether the node group to which the node belongs is a risk group or a trusted group based on the number of trusted nodes in the node group to which the node belongs and the first pre-stored threshold value includes: if the proportion of trusted nodes in the node group to which the node belongs is greater than the first preset threshold value, determining that the node group is a trusted group; if the proportion of trusted nodes in the node group to which the node belongs is not greater than the first preset threshold value, determining that the node group is a risk group.

[0023] In one possible implementation, the triggering conditions for reporting the trustworthy status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0024] In a possible implementation, the method further includes: if one of the nodes is determined to be an untrusted node, all downstream nodes of the untrusted node are determined to be untrusted nodes.

[0025] In the third aspect, the present application provides a risk control method applied to a child node, wherein the child node refers to a node in each node group connected to the remote service node that is indirectly connected to the remote service node, and the method includes: reporting the saved trusted status information step by step, and the trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of the trusted nodes and its pre-stored first preset threshold. The root node refers to a node in each node group connected to the remote service node that is directly connected to the remote service node.

[0026] In one possible implementation, the triggering conditions for reporting the trustworthy status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0027] In the fourth aspect, the present application provides a remote service node, including: a transceiver module, used to obtain the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each of the nodes is a trusted node is determined based on the trusted status information stored by the node; a risk group identification module, used to determine whether each of the node groups is a risk group or a trusted group according to the number of trusted nodes in each of the node groups and a pre-stored first preset threshold.

[0028] In one possible implementation, the transceiver module is specifically used to receive a trusted status information set reported by each root node, and the trusted status information set reported by each root node includes the trusted status information of each node in the node group to which it belongs, and the root node refers to the node in each node group that is directly connected to the remote service node; the risk group identification module is specifically used to determine the number of trusted nodes in the node group according to each trusted status information set.

[0029] In one possible implementation, the transceiver module is further used to receive a trusted message reported by the root node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group; the risk group identification module is further used to determine whether the node group to which the root node belongs is a risk group or a trusted group based on the trusted message reported by the root node.

[0030] In one possible implementation, the risk group identification module is specifically used to determine that a node group is a trusted group if the proportion of trusted nodes in a node group is greater than the first preset threshold; and to determine that the node group is a risk group if the proportion of trusted nodes in a node group is not greater than the first preset threshold.

[0031] In one possible implementation, the triggering conditions for the transceiver module to obtain the number of trusted nodes in at least one node group connected to the remote service node include one or both of the following: triggered by a risk control event, or triggered at a preset time interval.

[0032] In a possible implementation, the risk group identification module is further configured to, if one of the nodes is determined to be an untrusted node, determine all downstream nodes of the untrusted node as untrusted nodes.

[0033] In the fifth aspect, the present application provides a root node, which refers to a node that is directly connected to the remote service node in each node group connected to the remote service node, and the root node includes: a risk group identification module, which is used to collect the trusted status information of each node in the node group to which it belongs, wherein the trusted status information is saved by each node and reported step by step by each child node; a transceiver module, which is used to report the trusted status information to the remote service node, so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0034] In one possible implementation, the risk group identification module is specifically used to determine the number of trusted nodes based on the collected trusted status information of each node in the node group to which it belongs. If the total number of the nodes in the node group to which it belongs is greater than a pre-stored second preset threshold, the collected trusted status information of each node is used as a trusted status information set; the transceiver module is also used to report the trusted status information set to the remote service node.

[0035] In one possible implementation, the risk group identification module is specifically used to determine the number of trusted nodes based on the collected trusted status information of each node in the node group to which it belongs. If the total number of the nodes in the node group to which it belongs is not greater than the second pre-stored preset threshold, then based on the number of trusted nodes in the node group to which it belongs and the first pre-stored preset threshold, it is determined that the node group to which it belongs is a risk group or a trusted group; the transceiver module is also used to report a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0036] In one possible implementation, the risk group identification module is specifically used to determine that the node group is a trusted group if the proportion of trusted nodes in the node group to which it belongs is greater than the first preset threshold; if the proportion of trusted nodes in the node group to which it belongs is not greater than the first preset threshold, then determine that the node group is a risk group.

[0037] In a possible implementation, the triggering conditions for the transceiver module to report the trust status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0038] In a possible implementation, the risk group identification module is further configured to, if one of the nodes is determined to be an untrusted node, determine all downstream nodes of the untrusted node as untrusted nodes.

[0039] In the sixth aspect, the present application provides a child node, which refers to a node in each node group connected to the remote service node that is indirectly connected to the remote service node. The child node includes: a transceiver module for reporting the saved trusted status information step by step, and the trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of the trusted nodes and its pre-stored first preset threshold. The root node refers to a node in each node group connected to the remote service node that is directly connected to the remote service node.

[0040] In a possible implementation, the triggering conditions for the transceiver module to report the trust status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0041] In a seventh aspect, the present application provides an electronic device comprising at least one processor and a communication port, such as a transceiver, wherein the at least one processor and the transceiver are coupled, and when the at least one transceiver executes a program or instruction, the electronic device implements part or all of the operations of the first aspect and any possible implementation of the first aspect. The electronic device may be a terminal device or a chip in the terminal device.

[0042] In an eighth aspect, the present application provides an electronic device comprising at least one processor and a communication port, such as a transceiver, wherein the at least one processor and the transceiver are coupled, and when the at least one transceiver executes a program or instruction, the electronic device implements part or all of the operations of the second aspect and any possible implementation of the second aspect. The electronic device may be an edge device or a chip in an edge device.

[0043] In a ninth aspect, the present application provides an electronic device comprising at least one processor and a communication port, such as a transceiver. The at least one processor and the transceiver are coupled. When the at least one transceiver executes a program or instruction, the electronic device implements part or all of the operations of the third aspect and any possible implementation of the third aspect. The electronic device may be a server or a chip in a server.

[0044] In the tenth aspect, the present application provides a risk control system, comprising: a remote service node, at least one root node and at least one child node, wherein the remote service node is used to implement part or all of the operations of any possible implementation method of the first aspect; the root node is used to implement part or all of the operations of any possible implementation method of the second aspect, and the child node is used to implement part or all of the operations of any possible implementation method of the third aspect.

[0045] In the eleventh aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements part or all of the operations included in the method described in any of the aforementioned aspects and any possible implementation method of any of the aforementioned aspects.

[0046] In a twelfth aspect, the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements part or all of the operations included in the method described in any of the aforementioned aspects and any possible implementation method of any of the aforementioned aspects.

[0047] In a thirteenth aspect, the present application provides a chip comprising: an interface circuit and a processor. The interface circuit is connected to the processor, and the processor is configured to cause the chip to perform some or all of the operations included in the method described in any of the preceding aspects and any possible implementation of any of the preceding aspects.

[0048] It should be understood that the second to thirteenth aspects of the present application are consistent with or correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0050] FIG1 is an architecture diagram of a risk control system provided in an embodiment of the present application;

[0051] FIG2 is a flow chart of a risk control method according to an embodiment of the present application;

[0052] FIG3 is a second flow chart of a risk control method provided in an embodiment of the present application;

[0053] FIG4 is a second flow chart of a risk control method provided in an embodiment of the present application;

[0054] FIG5 is an example diagram of the trust status of each node in a node group A provided in an embodiment of the present application;

[0055] FIG6 is an architecture diagram of another risk control system provided in an embodiment of the present application;

[0056] FIG7 is a fourth flow chart of a risk control method provided in an embodiment of the present application;

[0057] FIG8 is a fifth flow chart of a risk control method provided in an embodiment of the present application;

[0058] FIG9 is a schematic structural diagram of a remote service node provided in an embodiment of the present application;

[0059] FIG10 is a schematic diagram of the structure of a root node provided in an embodiment of the present application;

[0060] FIG11 is a schematic diagram of the structure of a sub-node provided in an embodiment of the present application;

[0061] FIG12 is a schematic structural diagram of a first device 40 according to an embodiment of the present application;

[0062] FIG13 is a schematic structural diagram of a second device 50 according to an embodiment of the present application;

[0063] FIG14 is a schematic structural diagram of a third device 60 according to an embodiment of the present application;

[0064] FIG15 is a schematic structural diagram of a device 70 provided in an embodiment of the present application;

[0065] FIG16 is a schematic structural diagram of another wind control system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0066] In order to enable people in this technical field to better understand the solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in combination with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0067] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0068] In the description and claims of the embodiments of this application, the terms "first" and "second" are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first target object" and "second target object" are used to distinguish different objects, rather than to describe a specific order of objects.

[0069] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0070] In the description of the embodiments of this application, unless otherwise specified, "multiple" means two or more. For example, "multiple processing units" means two or more processing units; "multiple systems" means two or more systems.

[0071] For ease of understanding, the following first explains the relevant nouns or terms used in the embodiments of this application:

[0072] 1. Terminal Node

[0073] Also known as terminal or terminal device, it refers to the peripheral device in a computer network, mainly used for input and output of user information. It is an important device for interacting with users, including computers, mobile phones, etc.

[0074] 2. Edge device nodes

[0075] Refers to a device on the local network boundary that communicates with a remote service node (i.e., server).

[0076] 3. Node

[0077] Refers to various types of devices in the network, including terminal devices, servers, edge devices, etc. In the embodiment of the present application, a node refers to a device in the network other than a remote service node.

[0078] 4. Trusted Nodes

[0079] Refers to various types of nodes that have been authenticated or licensed and can be trusted, including terminal trusted nodes (or terminal trusted devices, trusted terminal devices) and edge trusted nodes (or trusted edge devices, pure trusted nodes), etc.

[0080] 5. Local Network

[0081] The local network can be divided according to geographical scope, Internet Protocol (IP) network segment, etc., and is not limited to the examples in the embodiment.

[0082] 6. Intelligent risk control

[0083] It is an important means to intelligently manage and control financial risks during the operation of financial business by comprehensively using big data, information systems, artificial intelligence (AI) and other technologies, in order to ensure the business security of financial institutions (such as banks, operators, Internet financial companies, etc.). Among them, financial risks include first-risk behavior, defaulted credit, group first-risk behavior, etc.

[0084] 7. Group-First Risk Behavior

[0085] First risk behavior refers to the behavior of obtaining user assets through improper means such as fabricating facts and concealing the truth. Group first risk behavior exists in various forms. The embodiment of the present application mainly identifies the group (referred to as the first risk behavior group) that initiates the first risk behavior within the same network range (i.e., a local network).

[0086] 8. Risk Groups

[0087] This application refers to a group of nodes within a local network or node group that may cause financial risk as a risk group. A common risk group includes a first-risk behavior group that engages in group-first risk behavior. A risk group can also include multiple nodes within a local network that trigger different types of financial risk events, such as some nodes engaging in first-risk behavior operations and others engaging in bank card deposit theft operations. This application uses the first-risk behavior group as an example for illustration, but this is not intended to be limiting.

[0088] The risk control method provided in the embodiment of the present application can identify risk groups and can be applied in a system that provides intelligent risk control services (such as financial risk control, etc.). The system can be as shown in Figure 1, including multiple local networks, each local network including multiple nodes, and the nodes can be terminal nodes or edge device nodes. In the embodiment of the present application, the example of a node group is used as an example to illustrate the multiple nodes included in each local network, but it is not limited to this. The node group can also be divided into nodes according to the actual deployment situation. Figure 1 is an architectural diagram of a risk control system provided in the embodiment of the present application. The system 100 includes a remote service node 10 and other nodes. The remote service node 10 is a device corresponding to the remote risk control service center. With reference to Figure 1, the service node in any local network is the remote service node. Other nodes include a root node 20 and a child node 30. In each node group, the one that directly accesses the remote service node is the root node 20, and the one that accesses the remote service node 10 through the root node 20 or other nodes is the child node 30. Both the root node 20 and the child node 30 can be trusted nodes, ordinary nodes, and untrusted nodes. A trusted node is a node that has been authenticated by a remote service node or other trusted node. A normal node is a new terminal node that has just joined the system and has not yet been authenticated. An untrusted node is a node that has become untrustworthy due to a risk event. System 100 includes multiple local networks, each of which includes several interconnected nodes. Each dotted box in Figure 1 represents a local network.

[0089] FIG2 is a flow chart of a risk control method provided in an embodiment of the present application. This embodiment of the present application uses the method applied to the system provided in FIG1 as an example for illustration, but is not limited thereto. The method is applied to a remote service node 10, including but not limited to steps S101 and S102.

[0090] S101. A remote service node obtains the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on the trusted status information stored therein.

[0091] A node group includes multiple nodes, such as terminal nodes or edge device nodes. Nodes directly connected to a remote service node are defined as root nodes. Nodes indirectly connected to a remote service node are defined as child nodes. Indirect access refers to accessing a remote service node through a root node or through another child node. At least one node group connected to a remote service node is defined as a node group with direct access to the remote service node from a root node.

[0092] The remote service node obtains the number of trusted nodes in at least one node group connected to the remote service node, which includes two parts: first, the remote service node obtains the situation of the node group connected to it, including the number of nodes included in the node group, and second, the remote service node obtains the number of trusted nodes in each node group. In the case of the remote service node obtaining the node group connected to it, the remote service node can divide these nodes into several groups based on the network relationships of the nodes connected to it, as node groups. With reference to Figure 1, the remote service node can divide each node in the local network into a node group and determine the total number of nodes in each node group based on the number of root nodes and child nodes in each node group.

[0093] For the remote service node to obtain the number of trusted nodes in each node group, the remote service node can obtain the trusted status information set in each node group through the root node to determine the number of trusted nodes in each node group, or it can obtain the number of trusted nodes in its corresponding node group based on the instruction information received from the root node, such as the trusted message.

[0094] For example, each node (including the root node and child nodes) stores the trusted status information corresponding to its own trusted status. In one possible implementation method, the trusted status information of each node is continuously updated based on whether the node is currently authenticated by a remote service node or other authenticated trusted nodes. If a node A (node ​​A can be a root node or a child node) has passed authentication, its trusted status information can be trusted; if node A has just come online and has not yet been authenticated, its trusted status information can be ordinary; if node A is confirmed to have a risk event in the risk control service, the trusted status information can be untrustworthy, and the same applies to other nodes. Assuming that in system 100, the remote service node is called an upstream device, each node can report its own trusted status information step by step, so that the root node collects the trusted status information of each child node in the node group to which it belongs. The root node can determine whether to judge whether the node group is a risk group or report it to the remote service node for judgment based on its processing capacity. If the root node is capable of processing, it will process the collected trusted status information to obtain the number of trusted nodes, and send a trusted message to inform the remote service node whether the node group is a risk group, or inform the number of trusted nodes. If the root node is not capable of processing, the collected trusted status information will be sent to the remote service node as a trusted status information set, and the remote service node will process it to obtain the number of trusted nodes.

[0095] Optionally, the trusted state information may be represented by a pre-defined identifier or character to indicate trusted, ordinary, or untrusted. The trusted state information may also include trusted and untrusted, where untrusted includes ordinary and untrusted.

[0096] S102: The remote service node determines whether each node group is a risk group or a trustworthy group according to the number of trustworthy nodes in each node group and a pre-stored first preset threshold.

[0097] Optionally, the remote service node determines whether the node group is a risk group or a trusted group based on the number of trusted nodes in each node group, the total number of nodes in the node group and a pre-stored first preset threshold, continues to provide risk control services to the trusted group, and refuses to provide risk control services to the risk group.

[0098] For example, the remote service node may pre-set and store a first preset threshold. This first preset threshold may be set based on experience in determining the number of risk groups, or based on the actual conditions of each local network during actual risk control. The remote service node may set the first preset threshold to be the same or different for each node group.

[0099] Optionally, the remote service node sets a first preset threshold based on the number of nodes in the node group. For example, if there are 10 nodes in node group A, the first preset threshold can be set to 5; if there are 4 nodes in node group B, the first preset threshold can be set to 2, and so on. The remote service node determines whether the node group is trustworthy based on the number of nodes in the node group and the number of trusted nodes. For example, if the number of trusted nodes in node group A is less than or equal to 5, the node group is determined to be a risky group. If the number of trusted nodes is greater than 5, the node group is determined to be a trusted group (also known as a normal group, a non-risk group, etc.).

[0100] Optionally, the remote service node can also set a first preset threshold value based on the number of trusted nodes in the node group and the proportion of the total number of nodes. This setting method is not affected by the number of nodes in the node group and is more flexible and convenient to apply. The embodiment of the present application takes the first preset threshold value as the proportion of trusted nodes and the first preset threshold value being equal as an example for explanation. Assuming that the first preset threshold value is set to 50%, that is, if the proportion of the number of trusted nodes in the total number of nodes is less than or equal to 50%, the node group is determined to be a risk group. If the proportion of the number of trusted nodes in the total number of nodes is greater than 50%, the node group is determined to be a trusted group. Referring to Figure 1, there are a total of 10 nodes in node group A, of which 4 are trusted nodes, accounting for 40%, so node group A is a risk group; there are a total of 4 nodes in node group B, of which 4 are trusted nodes, accounting for 100%, so node group B is a trusted group; there are a total of 4 nodes in node group C, of ​​which 1 is a trusted node, accounting for 25%, so node group C is a risk group; there are a total of 4 nodes in node group D, of which 0 is a trusted node, accounting for 0%, so node group D is a risk group; there are a total of 5 nodes in node group E, of which 3 are trusted nodes, accounting for 60%, so node group E is a trusted group.

[0101] In some instances, each node in a node group can obtain risk control services by accessing a remote service node or other trusted nodes. For example, referring to Figure 3, a terminal node (usually capable of providing ordinary business services) initiates a business request to a node in the local network (this node is used to process business requests, which can usually be an edge node that does not provide ordinary business services. To distinguish, this node is referred to as a node of the business system). The business request includes login, transaction, loan, or consumption, etc. The node of the business system sends a verification request to the remote service node or the local trusted node (including itself). Since the remote service node and the trusted node both store risk control service content, the risk control service content may include risk control models and risk prevention strategies. The risk control service content can identify risks for different business requests and determine whether the business request is risky. Therefore, the node that receives the verification request can return a verification result (such as risky or risk-free) to the node of the business system based on the risk control service content. The node of the business system confirms or rejects the business request based on the returned result.

[0102] Optionally, the risk control service content is intelligent risk control service content, including risk control models and risk prevention strategies obtained through big data calculations, machine learning or training, which can obtain more intelligent risk control results.

[0103] Based on this example and the risk control method provided by the embodiments of this application, if node groups A and C are identified as risky groups, it is considered that the nodes in node groups A and C are likely to engage in the first risk behavior, and therefore all service requests initiated by node groups A and C are rejected. Node groups B, D, and E are trusted groups, and when they receive service requests, they can refer to the method shown in Figure 3 to perform additional risk control on their service applications.

[0104] Optionally, after each service request, the trusted status of each node may change, and the trusted status information may be updated. The remote service node can initiate risk group identification at irregular or scheduled intervals to further enhance the real-time protection capabilities of security. For example, the initiation of risk group identification can be triggered by the occurrence of a risk control event (i.e., the return result of risk in the above example) or at a preset time interval, such as every hour.

[0105] The risk control method provided in the embodiment of the present application can identify risk groups through the number of trusted nodes in different node groups. Remote service nodes and other nodes that can provide services will no longer provide services to risk groups, thereby ensuring the security of financial services. In the embodiment of the present application, the identification of the first risk behavior of a group can be completed by the remote service node, or by the root node in each node group and then reported to the remote service node, which effectively alleviates the network overhead and computing overhead of the remote service node and can reduce service latency. The embodiment of the present application uses authenticated trusted nodes to judge risk groups. There is no need to collect user information of each node, avoiding problems such as user data leakage, which not only enhances privacy, but also reduces the network transmission pressure and storage pressure of remote service nodes caused by the transmission of large amounts of user information. The number or proportion of trusted nodes is calculated based on the trusted status information of each node, and there is no need to rely on complex algorithms for risk groups, such as the mining of the first risk behavior group and the judgment of the first risk behavior attribute. This greatly reduces the difficulty and overhead of the calculation, improves the overall response speed, and makes it possible to judge the first risk behavior of the group in real time.

[0106] Figure 4 is a third flow chart of a risk control method provided in an embodiment of the present application. As shown in Figure 4 , the method is executed by a remote service node, a root node and a child node respectively. Taking the risk group being the first risk behavior group as an example, the method includes: S201 to S209.

[0107] S201: The remote service node starts a process of identifying a first risk behavior group.

[0108] Initiating the identification process for the first risky behavior group is equivalent to the remote service node beginning to obtain the number of trusted nodes in at least one node group in its system, such as node groups A, B, C, D, and E in Figure 1. The initiation can be triggered by the occurrence of a risk control event or by a preset time interval, or both.

[0109] For example, a risk control event may be triggered by a terminal node in node group A, node group B, node group C, node group D, and node group E, which sends a business request. This business request, such as a request for a first risk behavior, is determined to be a risk event by other trusted nodes or remote service nodes, which triggers the remote service node to start the identification process of the first risk behavior group. For example, each node is informed of the need to obtain its current trusted status information to identify the first risk behavior group, and each node reports its current trusted status information. Generally speaking, edge device nodes do not provide ordinary business services. Therefore, under normal circumstances, it is the terminal node that sends the risk control event to trigger the start of the first risk behavior group identification.

[0110] Triggering at preset intervals can involve simultaneously starting timers at the remote service node and at the nodes within each node group. Each timer is set at a preset interval. When the timer expires, the nodes within each node group progressively report their trust status information. The preset interval is determined based on actual deployment requirements, such as the need to identify the first risk behavior group. Optionally, the time at which the timer is started can be the time of the last trust status information report.

[0111] Taking the case where the remote service node initiates the identification process of the first risk behavior group and each node updates and obtains the current trust status information as an example, after S201 , S202 and S203 are executed.

[0112] S202: The root node updates the trusted status information.

[0113] The root node in each node group updates its trusted status information. The root node in Figure 4 can refer to any root node in Figure 1. The root node of each node group in the system shown in Figure 1 can perform operations with reference to the root node in Figure 4, without being limited to the number of root nodes in the example in Figure 4.

[0114] S203: The child node updates the trust status information and reports it step by step.

[0115] The child nodes in each node group update their trusted status information. The child nodes in Figure 4 can refer to any child node in Figure 1. The child nodes of each node group in the system shown in Figure 1 can perform operations with reference to the child nodes in Figure 4, without being limited to the number of child nodes in the example in Figure 4.

[0116] For example, Figure 5 is an example diagram of the trusted status of each node in the node group A provided in an embodiment of the present application. In the node group A, the root node can access the remote service node through 4G or 5G, and the child nodes in the node group A can access other local nodes (including the root node and other child nodes) through Bluetooth, Wireless Fidelity (WIFI), 4G or 5G, etc. If the child node 2 in the current node group A is an authenticated trusted node, taking child node 1, child node 2, child node 3 and child node 4 as examples, child node 2 has not experienced a risk event, so it is still a trusted node after the update, and its trusted status information is still characterized as trusted. Since child node 1 is connected to child node 2, child node 1 initiates an authentication request to child node 2. As a trusted node, child node 2 stores risk control service content and can perform risk identification. If child node 2 determines there is no risk based on the authentication request sent by child node 1 and the stored risk control service content, then child node 1's authentication is confirmed as successful. If child node 2 determines there is risk based on the authentication request sent by child node 1 and the stored risk control service content, then child node 1's authentication is confirmed as failed. If child node 2 cannot determine whether there is risk based on the authentication request sent by child node 1 and the stored risk control service content, then child node 1's authentication is confirmed as invalid. Child node 2 then feeds back the authentication result to child node 1. If authentication succeeds, child node 1 becomes a trusted node. If authentication fails, child node 1 becomes an untrusted node. If authentication is invalid, child node 1 remains in its current state. Refer to the above example for child node 3 connecting to child node 4. Suppose, after authentication, the trusted states of each node in the current node group A are shown in Figure 5: child node 1 fails authentication and becomes an untrusted node. Child node 3, despite the invalid authentication, remains a normal node. Child nodes 2 and 4 remain trusted nodes, and so on. After updating the trusted status, child node 1 can report its own trusted status information to child node 2, that is, untrusted; child node 2 reports its own trusted status information and the trusted status information of child node 1 to the root node; child node 3 can report its own trusted status information to child node 4, that is, normal; child node 4 reports its own trusted status information and the trusted status information of child node 3 to the root node, etc.; the root node obtains the current trusted status information of each child node in node group A.

[0117] Optionally, after a node (including the root node and child nodes) updates its trusted status information to untrusted, it is necessary to determine whether the node includes downstream child nodes. If so, all downstream child nodes of the node are set as untrusted nodes. For example, if the root node of node group A is an untrusted node, the remote service node or root node can set all child nodes in node group A as untrusted nodes. If child node 2 is an untrusted node, the remote service node or root node can set its downstream child node 1 as an untrusted node. If child node 1 is an untrusted node, but it has no downstream nodes, there is no need to set other nodes as untrusted nodes. For example, referring to Figure 6, if the root node in node group D is an untrusted node, all its downstream nodes are set as untrusted nodes. The root node in node group D receives the node status information of each child node that is gradually reported. Since this root node is an untrusted node, all downstream nodes are reported as untrusted nodes. Alternatively, if the remote service node receives information that the root node in the node group D is an untrusted node, all nodes in the node group D are deemed to be untrusted nodes regardless of the actual trusted node information reported by each child node.

[0118] After S202 and S203 , S204 is executed.

[0119] S204: If the root node collects the trust status information of N child nodes, it determines the number of trustworthy nodes and the value of N.

[0120] Determine whether N is greater than the second preset threshold, where N is the total number of nodes in the node group to which the root node belongs, and N is a positive integer greater than 2. Each root node can set a second preset threshold based on its processing capacity. If N> the second preset threshold, execute S205; if N≤ the second preset threshold, execute S208. For example, if a root node can process the trusted status of 6 child nodes (including calculating its trusted status information to obtain the number of trusted nodes, updating the downstream nodes of untrusted nodes to untrusted nodes, etc.), the second preset threshold can be set to 6. Referring to the root node of node group A in Figure 1, it receives the trusted status information reported layer by layer by 10 child nodes. That is, N=10, which is greater than the second preset threshold, then execute S205. Referring to the root node of node group D in Figure 1, it receives the trusted status information reported layer by layer by 4 child nodes. That is, N=4, which is less than the second preset threshold, then execute S208.

[0121] S205: The root node reports a trusted state information set to the remote service node. Each trusted state information set includes trusted state information of each node in the node group to which the corresponding root node belongs.

[0122] S206: The remote service node obtains the number of trusted nodes in each node group according to the trusted status information set.

[0123] S207: The remote service node determines whether the node group is a first risk behavior group or a trustworthy group based on the number of trustworthy nodes in each node group and a pre-stored first preset threshold.

[0124] The method of determining whether the node group is the first risk behavior group or the trusted group may refer to S102 and will not be described in detail.

[0125] S208. The root node obtains the number of trusted nodes in the node group to which it belongs based on the trusted status information set.

[0126] S209: The root node determines whether the node group is a first risk behavior group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the first preset threshold. Optionally, if the proportion of trusted nodes in the node group to which the root node belongs is greater than the first preset threshold, the node group is determined to be a trusted group; if the proportion of trusted nodes in the node group to which the root node belongs is not greater than the first preset threshold, the node group is determined to be a trusted group.

[0127] Referring to Figure 1, in node groups B, C, D, and E, after the root node determines that N is less than the second preset threshold, the root node in each node group obtains the number of trusted nodes in the node group to which it belongs. The root node determines whether the node group is a first risk behavior group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the first preset threshold. The first preset threshold is 50, which is an example for explanation. The first preset threshold is the number. Please refer to the example of S102 and will not be expanded. There are 4 nodes in node group B, including 1 root node and 3 child nodes, all of which are trusted nodes, so the proportion is 100%, which is greater than the first preset threshold, and node group B is a trusted group; there are 4 nodes in node group C, including 1 root node and 3 child nodes, and there is 1 trusted node, so the proportion is 25%, which is less than the first preset threshold, and node group C is the first risk behavior group; there are 4 nodes in node group D, including 1 root node and 3 child nodes, and there are 4 untrustworthy nodes, so the proportion is 0%, which is less than the first preset threshold, and node group D is the first risk behavior group; there are 4 nodes in node group E, including 1 root node and 3 child nodes, and there are 3 trusted nodes, so the proportion is 60%, which is greater than the first preset threshold, and node group E is a trusted group.

[0128] Optionally, after the root node determines that the node group to which it belongs is the first risk behavior group or the trusted group, it can also report a trusted message to the remote service node to inform the node group to which it belongs that it is the first risk behavior group or the trusted group. For example, the root node of node group B reports a trusted message to the remote service node to inform node group B that it is a trusted group. The root node of node group C reports a trusted message to the remote service node to inform node group C that it is the first risk behavior group. The root node of node group D reports a trusted message to the remote service node to inform node group D that it is the first risk behavior group. The root node of node group E reports a trusted message to the remote service node to inform node group E that it is a trusted group.

[0129] Optionally, the root node may also report a trusted message to inform the number of trusted nodes included in the node group to which it belongs, or the root node may report a trusted message, which in addition to informing the node group to which the root node belongs that it is a trusted group, also informs the number of trusted nodes in the node group to which it belongs.

[0130] S209 is executed after S207 and S208.

[0131] S209: The remote service node obtains the first risk behavior identification result of the group.

[0132] For example, the remote service node can determine through its own node and the root node whether each node group is a group that is at risk, as determined through S207 and S208. It can then determine, based on the trusted information reported by each root node after S208 and S209, that node group B is a trusted group, node group C is a group that is at risk, node group D is a group that is at risk, and node group E is a trusted group. After obtaining the identification results, the first risk group identification process ends.

[0133] Optionally, the remote service node and the root node may perform further processing based on whether each node group is the first risk behavior group, such as not sending data to the first risk behavior group, or rejecting the service request of the first risk behavior group.

[0134] In the embodiments of the present application, risk control is performed by initiating the identification of first-risk behavior groups. This identification can be based on the identities already obtained by different nodes in each local network, such as trusted nodes, ordinary nodes, and untrusted nodes, rather than using graph computing, knowledge graphs, community mining, and other technologies commonly used in the industry to identify first-risk behavior groups. Therefore, the complexity of the calculation is greatly simplified, the possibility of real-time identification is increased, and there is no need to rely on rich user data. The first-risk behavior group can be identified simply and efficiently, providing a safer, real-time, and efficient risk control service.

[0135] In addition, in addition to the remote service node being able to identify the group's first risk behavior, the root node in each node group also has the ability to identify the group's first risk behavior. Once the remote service node fails, the group's first risk behavior can also be identified through the root node, which greatly enhances the fault tolerance of the risk control service.

[0136] FIG7 is a fourth flow chart of a risk control method provided in an embodiment of the present application. As shown in FIG7 , the method is applied to a root node, and the method includes:

[0137] S301. The root node collects the trust status information of each node in the node group to which it belongs.

[0138] S302. The root node reports the trusted status information to the remote service node, so that the remote service node determines whether the corresponding node group is a risk group or a trusted group based on the number of trusted nodes and a first preset threshold. The trusted status information is stored by each node and reported step by step by each child node.

[0139] The trust status information of the root node is stored by the root node, and the trust status information of other child nodes in the node group where the root node is located is reported by each child node step by step.

[0140] Optionally, after the root node collects the trusted status information of each node in the node group to which it belongs, it also includes: determining the number of trusted nodes based on the collected trusted status information of each node in the node group to which it belongs; reporting the trusted status information to the remote service node includes; if the total number of each node in the node group to which it belongs is greater than a pre-stored second preset threshold, then the collected trusted status information of each node is reported to the remote service node as a trusted status information set.

[0141] Optionally, the root node determines the number of trusted nodes based on the collected trusted status information of each node in the node group to which it belongs; if the total number of nodes in the node group to which it belongs is not greater than the pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the pre-stored first preset threshold; and reports a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0142] The root node may report the collected trust status information to the remote service node, may report the determined number of trusted nodes to the remote service node, and may also report to the remote service node whether the determined node group is a risk group.

[0143] Optionally, determining whether the node group to which a node belongs is a risk group or a trusted group based on the number of trusted nodes in the node group to which the node belongs and a pre-stored first preset threshold value includes: if the proportion of trusted nodes in the node group to which the node belongs is greater than the first preset threshold value, determining that the node group is a trusted group; if the proportion of trusted nodes in the node group to which the node belongs is not greater than the first preset threshold value, determining that the node group is a risk group.

[0144] Optionally, the triggering conditions for reporting the trustworthy status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0145] Optionally, the method further includes: if the root node determines that a node is an untrusted node, then determining all downstream nodes of the untrusted node as untrusted nodes.

[0146] In the embodiment of the present application, the root node execution risk control method can be implemented with reference to the example of Figure 4 and the above embodiment, and will not be elaborated on again.

[0147] FIG8 is a fifth flow chart of a risk control method provided in an embodiment of the present application. As shown in FIG8 , the method is applied to a child node, and the method includes:

[0148] S401. The child node reports the saved trusted status information step by step. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to each node group connected to the remote service node that is directly connected to the remote service node.

[0149] In the embodiment of the present application, the method for executing risk control by the sub-node can be implemented with reference to the example of Figure 4 and the above embodiment, and will not be elaborated on again.

[0150] FIG9 is a schematic structural diagram of a remote service node provided in an embodiment of the present application. As shown in FIG9 , the remote service node 10 includes a transceiver module 101 and a risk group identification module 102 .

[0151] The transceiver module 101 is configured to obtain the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on the trust status information stored by the node;

[0152] The risk group identification module 102 is configured to determine whether each node group is a risk group or a trustworthy group according to the number of trustworthy nodes in each node group and a pre-stored first preset threshold.

[0153] In one possible implementation, the transceiver module 101 is specifically used to receive the trusted status information set reported by each root node, and the trusted status information set reported by each root node includes the trusted status information of each node in the node group to which it belongs. The root node refers to the node in each node group that is directly connected to the remote service node; the risk group identification module 102 is specifically used to determine the number of trusted nodes in the node group according to each trusted status information set.

[0154] In one possible implementation, the transceiver module 101 is also used to receive a trusted message reported by the root node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group; the risk group identification module 102 is also used to determine whether the node group to which the root node belongs is a risk group or a trusted group based on the trusted message reported by the root node.

[0155] In one possible implementation, the risk group identification module 102 is specifically configured to determine that a node group is a trusted group if the proportion of trusted nodes in a node group is greater than a first preset threshold; and to determine that the node group is a risk group if the proportion of trusted nodes in a node group is not greater than the first preset threshold.

[0156] In one possible implementation, the triggering conditions for the transceiver module 101 to obtain the number of trusted nodes in at least one node group connected to the remote service node include one or both of the following: triggered by a risk control event, or triggered at a preset time interval.

[0157] In a possible implementation, the risk group identification module 102 is further configured to, if a node is determined to be an untrusted node, determine all downstream nodes of the untrusted node as untrusted nodes.

[0158] It should be understood that the modules shown in FIG. 9 are merely examples. The transceiver module 101 and the risk group identification module 102 may perform their operations, or variations thereof, with reference to the method sections described in the embodiments of this application. The remote service node 10 may also include other modules, such as a risk control module for storing risk control service content and a networking module for supporting network connections, and the present embodiment is not limiting.

[0159] FIG10 is a schematic structural diagram of a root node provided in an embodiment of the present application. As shown in FIG10 , the root node 20 includes: a transceiver module 201 and a risk group identification module 202 .

[0160] The root node 20 refers to a node in each node group connected to the remote service node that is directly connected to the remote service node, such as the node directly connected to the remote service node 10 in FIG. 1 , FIG. 5 or FIG. 6 .

[0161] The risk group identification module 202 is used to collect the trust status information of each node in the node group to which it belongs, wherein the trust status information is stored by each node and reported by each child node step by step.

[0162] The transceiver module 101 is used to report the trusted status information to the remote service node, so that the remote service node can determine the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determine whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0163] In one possible implementation, the risk group identification module 202 is specifically used to determine the number of trusted nodes based on the trusted status information of each node in the node group to which it belongs. If the total number of nodes in the node group to which it belongs is greater than a pre-stored second preset threshold, the collected trusted status information of each node is used as a trusted status information set; the transceiver module 201 is also used to report the trusted status information set to the remote service node.

[0164] In one possible implementation, the risk group identification module 202 is specifically used to determine the number of trusted nodes based on the collected trusted status information of each node in the node group to which it belongs. If the total number of nodes in the node group to which it belongs is not greater than the pre-stored second preset threshold, then the node group to which it belongs is determined to be a risk group or a trusted group based on the number of trusted nodes in the node group to which it belongs and the pre-stored first preset threshold; the transceiver module 201 is also used to report a trusted message to the remote service node, the trusted message including the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

[0165] In one possible implementation, the risk group identification module 202 is specifically used to determine that a node group is a trusted group if the proportion of trusted nodes in the node group to which it belongs is greater than a first preset threshold; if the proportion of trusted nodes in the node group to which it belongs is not greater than the first preset threshold, then determine that the node group is a risk group.

[0166] In a possible implementation, the triggering conditions for the transceiver module 201 to report the trust status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0167] In a possible implementation, the risk group identification module 202 is further configured to, if a node is determined to be an untrusted node, determine all downstream nodes of the untrusted node as untrusted nodes.

[0168] It should be understood that the modules shown in FIG10 are merely examples, and that the transceiver module 201 and the risk group identification module 202 may perform their operations, or variations thereof, with reference to the method sections described in the embodiments of this application. The root node 20 may also include other modules, such as a risk control management module for storing risk control service content, a networking module for supporting network connections, a trusted state management module, a risk control module update module, and the like. Alternatively, the risk control management module of the root node 20 may include a risk group identification module, etc., without limitation to the examples of this embodiment.

[0169] FIG11 is a schematic structural diagram of a sub-node provided in an embodiment of the present application. As shown in FIG11 , the sub-node 30 includes: a transceiver module 301 and a processing module 302 .

[0170] The transceiver module 301 is used to report the saved trusted status information step by step. The trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node can determine whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to each node in the node group connected to the remote service node that is directly connected to the remote service node.

[0171] The storage module 302 is used to perform other operations besides sending and receiving, such as saving trusted state information.

[0172] In a possible implementation, the triggering conditions for the transceiver module 301 to report the trust status information include one or both of the following: triggered by the occurrence of a risk control event, or triggered at a preset time interval.

[0173] It should be understood that the modules shown in FIG11 are merely examples, and that the transceiver module 301 may refer to the method sections of the embodiments of this application to perform their operations, or variations thereof. Subnode 30 may also include other modules to implement other functions. For example, in the example of FIG11 , subnode 30 may also include a risk control management module for storing risk control service content, a networking module for supporting network connections, a trusted state management module, a risk control module update module, and so on. This example is not intended to limit the scope of this embodiment.

[0174] In addition, an embodiment of the present application further provides a first device 40, as shown in Figure 12, which is a structural diagram of the first device 40 of an embodiment of the present application. The first device 40 includes a communication interface 401 and a processor 402 connected to the communication interface 401. The communication interface 401 can be a device such as a transceiver. The communication interface 401 can be used to perform the operations of the transceiver part in the above embodiment, and the processor 402 can be used for operations other than transceiver. For example, the communication interface 401 can be used to obtain the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes multiple nodes, and whether each node is a trusted node is determined based on the trusted status information saved by the node; the processor 402 can be used to determine whether the node group is a risk group or a trusted group based on the number of trusted nodes in each node group and a pre-stored first preset threshold.

[0175] The embodiment of the present application also provides a second device 50, as shown in Figure 13, which is a structural diagram of the second device 50 of the embodiment of the present application. The second device 50 includes a communication interface 501 and a processor 502 connected to the communication interface 501. The communication interface 501 can be a device such as a transceiver. The communication interface 501 can be used to perform the sending and receiving operations in the method in the above embodiment, and the processor 502 can be used for operations other than sending and receiving. For example, the processor 502 can be used to collect the trusted status information of each node in the node group to which it belongs, wherein the trusted status information is stored by each node and reported by each child node step by step. The communication interface 501 reports the trusted status information to the remote service node, so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

[0176] The embodiment of the present application also provides a third device 60, as shown in Figure 14, which is a structural diagram of the third device 60 of the embodiment of the present application. The third device 60 includes a communication interface 601 and a processor 602 connected to the communication interface 601. The communication interface 601 can be a device such as a transceiver. The communication interface 601 can be used to perform the sending and receiving operations in the method in the above embodiment, and the processor 602 can be used for operations other than sending and receiving. For example, the communication interface 601 can be used to report the saved trusted status information step by step. The trusted status information is used to determine whether the node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of trusted nodes and its pre-stored first preset threshold. The root node refers to each node group connected to the remote service node that is directly connected to the remote service node.

[0177] In addition, an embodiment of the present application further provides a device 70, as shown in FIG15 , which is a schematic diagram of the structure of a device 70 provided in an embodiment of the present application. As shown in FIG12 , the device 70 may include a processor 701, a memory 702 coupled to the processor 701, and a transceiver 703. The transceiver 703 may be a communication interface, an optical module, etc., for transmitting and receiving data. The processor 701 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and a NP, and is configured to execute the forwarding processing steps in the device exemplified in the above embodiment. The processor may also be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 701 may be a single processor or may include multiple processors. The memory 702 may include a volatile memory, such as a random-access memory (RAM); the memory may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); the memory 702 may also include a combination of the above types of memory. The memory 702 may refer to a single memory or may include multiple memories for storing program instructions. In one embodiment, the memory 702 stores computer-readable instructions, which include multiple software modules, such as a sending module, a processing module, and a receiving module. After executing each software module, the processor 701 may perform corresponding operations according to the instructions of each software module. In this embodiment, the operation performed by a software module actually refers to the operation performed by the processor 701 according to the instructions of the software module. Optionally, the processor 701 may also store program codes or instructions for executing the embodiments of the present application. In this case, the processor 701 does not need to read the program codes or instructions from the memory 702.

[0178] The device 70 can be used to execute the method in the above embodiment. Specifically, the device 70 can be used as

[0179] The terminal node executes the operations performed by the remote service node in methods S101 to S102, S201 to S209, or as a root node executes the operations performed by the root node in methods S201 to S209, S301 to S302, or the remote service node executes the operations performed by the child node in methods S201 to S209, S401.

[0180] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is executed on a processor, it implements part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0181] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed on a processor, implements part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0182] The embodiment of the present application also provides a risk control system, as shown in Figure 16, which is a schematic structural diagram of another risk control system provided by the embodiment of the present application. The risk control system 200 may include a remote service node, at least one root node and at least one child node. In Figure 16, system 3 including a remote service node 10, a root node 20 and a child node 30 is taken as an example. The structure of the remote service node 10 is shown in Figures 9, 12 and 15, the structure of the root node 20 is shown in Figures 10, 13 and 15, and the structure of the child node 30 is shown in Figures 11, 14 and 15. The system 200 can refer to the method part in the embodiment of the present application to perform its operation, or perform a variation of its operation, such as being applicable to the methods provided in Figures 2, 3, 4, 7-8, to perform its operation, or perform a variation of its operation.

[0183] In some instances, a risk control system is an information system that can be composed of any combination of hardware and software.

[0184] An embodiment of the present application also provides another risk control system, including at least one memory and at least one processor, wherein the at least one memory stores instructions, and the at least one processor executes instructions so that the communication system implements part or all of the operations of any of the methods in any of the embodiments described above.

[0185] The present application also provides a chip including an interface circuit and a processor connected to each other, wherein the processor is configured to cause the chip to execute part or all of the operations in any of the methods in any of the aforementioned embodiments.

[0186] An embodiment of the present application also provides a chip system, including: a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, when the program or instructions are executed by the processor, the chip system implements part or all of the operations of any one of the methods of any one of the embodiments described above.

[0187] Optionally, there may be one or more processors in the chip system. The processor may be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.

[0188] Optionally, the memory in the chip system may be one or more. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in the embodiments of the present application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on different chips. The embodiments of the present application do not specifically limit the type of memory or the configuration of the memory and the processor.

[0189] Exemplarily, the chip system can be an FPGA, an ASIC, a system on chip (SoC), a CPU, an NP, a digital signal processing circuit (DSP), a microcontroller (MCU), a programmable logic device (PLD), or other integrated chips.

[0190] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0191] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0192] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical business division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0193] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0194] In addition, each business unit in each embodiment of the present application can be integrated into a processing unit, each unit can exist physically separately, or two or more units can be integrated into a single unit. The above-mentioned integrated units can be implemented in the form of hardware or software business units.

[0195] If the integrated unit is implemented in the form of a software business unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of the present application can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, ROM, RAM, Random Access Memory, disk or optical disk, etc. Various media that can store program code.

[0196] Those skilled in the art will appreciate that, in one or more of the examples above, the services described herein may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these services may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one location to another. Storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0197] The above specific implementation methods further describe in detail the purpose, technical solutions and beneficial effects of this application. It should be understood that the above are only specific implementation methods of this application.

[0198] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A risk control method, characterized in that: Applied to a remote service node, the method comprises: Acquire the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes a plurality of nodes, and whether each of the nodes is a trusted node is determined according to trusted status information stored by the node; According to the number of the trusted nodes in each of the node groups and a pre-stored first preset threshold, each of the node groups is correspondingly determined to be a risk group or a trusted group.

2. The method according to claim 1, characterized in that The obtaining the number of trusted nodes in at least one node group connected to the remote service node comprises: Receiving a trusted state information set reported by each root node, wherein the trusted state information set reported by each root node includes trusted state information of each node in the node group to which it belongs, and the root node refers to a node in each node group that is directly connected to the remote service node; The number of the trusted nodes in the node group is determined according to each of the trusted status information sets.

3. The method according to claim 1 or 2, characterized in that: Also includes: Receiving a trusted message reported by a root node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group; According to the trusted message reported by the root node, it is determined that the node group to which the root node belongs is a risk group or a trusted group.

4. The method according to any one of claims 1 to 3, characterized in that: The determining, based on the number of trusted nodes in each node group and a first preset threshold, that the node group is a risk group or a trusted group includes: If the proportion of the trusted nodes in a node group is greater than the first preset threshold, the node group is determined to be a trusted group; If the proportion of the trusted nodes in a node group is not greater than the first preset threshold, the node group is determined to be a risk group.

5. The method according to any one of claims 1 to 4, characterized in that: The triggering condition for obtaining the number of trusted nodes in at least one node group connected to the remote service node includes one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

6. The method according to any one of claims 1 to 5, characterized in that: Also includes: If one of the nodes is determined to be an untrusted node, all downstream nodes of the untrusted node are determined to be untrusted nodes.

7. A risk control method, characterized in that: Applied to a root node, the root node refers to a node in each node group connected to the remote service node that is directly connected to the remote service node, the method comprising: Collecting the trusted status information of each node in the node group, wherein the trusted status information is stored by each node and reported by each child node step by step; Report the trusted status information to the remote service node so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

8. The method according to claim 7, characterized in that After collecting the trusted status information of each node in the node group, the method further includes: Determining the number of trusted nodes according to the trusted status information of each node in the node group to which the collection belongs; The reporting of the trusted status information to the remote service node includes: If the total number of the nodes in the node group is greater than a pre-stored second preset threshold, the collected trusted state information of the nodes is reported to the remote service node as a trusted state information set.

9. The method according to claim 7, characterized in that: Also includes: Determining the number of trusted nodes according to the trusted status information of each node in the node group to which the collection belongs; If the total number of nodes in the node group is not greater than the second pre-stored threshold, determining whether the node group is a risk group or a trustworthy group based on the number of trusted nodes in the node group and the first pre-stored threshold; Reporting a trusted message to the remote service node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

10. The method according to claim 9, characterized in that The determining, based on the number of the trusted nodes in the node group and the first pre-stored threshold, that the node group is a risk group or a trusted group includes: If the proportion of the trusted nodes in the node group is greater than the first preset threshold, the node group is determined to be a trusted group; If the proportion of the trusted nodes in the node group is not greater than the first preset threshold, the node group is determined to be a risky group.

11. The method according to any one of claims 7 to 10, characterized in that: The triggering conditions for reporting the trusted status information include one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

12. The method according to any one of claims 7 to 11, characterized in that Also includes: If one of the nodes is determined to be an untrusted node, all downstream nodes of the untrusted node are determined to be untrusted nodes.

13. A risk control method, characterized in that: Applied to a child node, the child node refers to a node in each node group connected to the remote service node that indirectly accesses the remote service node, the method comprising: The saved trusted status information is reported step by step, and the trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of the trusted nodes and its pre-stored first preset threshold. The root node refers to each node in the node group connected to the remote service node that is directly connected to the remote service node.

14. The method according to claim 13, characterized in that The triggering conditions for reporting the trusted status information include one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

15. A remote service node, characterized in that: include: A transceiver module, used to obtain the number of trusted nodes in at least one node group connected to the remote service node, wherein the node group includes a plurality of nodes, and whether each of the nodes is a trusted node is determined according to the trusted status information stored by the node; The risk group identification module is used to determine whether each of the node groups is a risk group or a trusted group according to the number of the trusted nodes in each of the node groups and a pre-stored first preset threshold.

16. The node according to claim 15, characterized in that The transceiver module is specifically used to receive a trusted state information set reported by each root node, wherein the trusted state information set reported by each root node includes trusted state information of each node in the node group to which it belongs, and the root node refers to a node in each node group that is directly connected to the remote service node; The risk group identification module is specifically configured to determine the number of the trusted nodes in the node group according to each of the trusted status information sets.

17. The node according to claim 15 or 16, characterized in that: The transceiver module is further used to receive a trusted message reported by a root node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group; The risk group identification module is further used to determine whether the node group to which the root node belongs is a risk group or a trusted group according to the trusted message reported by the root node.

18. The node according to any one of claims 15 to 17, characterized in that: The risk group identification module is specifically used to determine that a node group is a trusted group if the proportion of trusted nodes in a node group is greater than the first preset threshold; if the proportion of trusted nodes in a node group is not greater than the first preset threshold, determine that the node group is a risk group.

19. The node according to any one of claims 15 to 18, characterized in that: The triggering conditions for the transceiver module to obtain the number of trusted nodes in at least one node group connected to the remote service node include one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

20. The node according to any one of claims 15 to 19, characterized in that: The risk group identification module is further configured to determine all downstream nodes of the untrusted node as untrusted nodes if one of the nodes is determined to be an untrusted node.

21. A root node, characterized in that: The root node refers to a node in each node group connected to the remote service node that is directly connected to the remote service node. The root node includes: A risk group identification module, used to collect the trust status information of each node in the node group to which it belongs, wherein the trust status information is stored by each node and reported by each sub-node step by step; A transceiver module is used to report the trusted status information to the remote service node, so that the remote service node determines the number of trusted nodes in the node group to which the root node belongs based on the trusted status information, and determines whether the node group to which the root node belongs is a risk group or a trusted group based on the number of trusted nodes and a pre-stored first preset threshold.

22. The node according to claim 21, characterized in that The risk group identification module is specifically used to determine the number of trusted nodes according to the trusted status information of each node in the node group to which the collection belongs, and if the total number of each node in the node group to which the collection belongs is greater than a pre-stored second preset threshold, the collected trusted status information of each node is used as a trusted status information set; The transceiver module is further used to report the trusted status information set to the remote service node.

23. The node according to claim 21, characterized in that The risk group identification module is specifically used to determine the number of trusted nodes based on the collected trusted status information of each node in the node group, and if the total number of each node in the node group is not greater than the second pre-stored preset threshold, determine whether the node group is a risk group or a trusted group based on the number of trusted nodes in the node group and the first pre-stored preset threshold; The transceiver module is further used to report a trusted message to the remote service node, wherein the trusted message includes the number of trusted nodes in the node group, or the trusted message is used to indicate that the node group to which the root node belongs is a risk group or a trusted group.

24. The node according to claim 23, characterized in that The risk group identification module is specifically used to determine that the node group is a trusted group if the proportion of trusted nodes in the node group to which it belongs is greater than the first preset threshold; if the proportion of trusted nodes in the node group to which it belongs is not greater than the first preset threshold, then determine that the node group is a risk group.

25. The node according to any one of claims 21 to 24, characterized in that: The triggering conditions for the transceiver module to report the trusted status information include one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

26. The node according to any one of claims 21 to 25, characterized in that: The risk group identification module is further configured to determine all downstream nodes of the untrusted node as untrusted nodes if one of the nodes is determined to be an untrusted node.

27. A child node, characterized in that: The sub-node refers to a node in each node group connected to the remote service node that is indirectly connected to the remote service node, and the sub-node includes: A transceiver module is used to report the saved trusted status information level by level, wherein the trusted status information is used to determine whether the current node is a trusted node, so that the remote service node or the root node determines whether the node group to which the child node belongs is a risk group or a trusted group based on the number of the trusted nodes and its pre-stored first preset threshold value, wherein the root node refers to a node in each node group connected to the remote service node that is directly connected to the remote service node.

28. The node according to claim 27, characterized in that The triggering conditions for the transceiver module to report the trusted status information include one or both of the following: It is triggered by the occurrence of a risk control event, or at a preset time interval.

29. A wind control system, characterized in that: include: A remote service node, configured to implement the method described in any one of claims 1 to 6 above; At least one root node, used to implement the method described in any one of claims 7 to 12; At least one sub-node, used to implement the method described in claim 13 or 14.

Images