Event risk assessment method, apparatus, device, and medium

Abstract

Embodiments of the application disclose an event risk evaluation method, device, equipment and medium, wherein the method comprises: acquiring historical application data and relational data to construct a double-layer heterogeneous graph, the double-layer heterogeneous graph comprising a main graph layer and a thin event layer; performing an edge layering operation on edges in the main graph layer to obtain a plurality of edge gears, and calculating edge weights for edges belonging to a preset edge gear; performing a recursive splitting operation based on component character node numbers on connected components in the main graph layer based on the edge weights to obtain a plurality of sub-components; performing a community discovery operation on sub-components that meet a preset size condition to obtain core community identifiers, and performing a homing and merging operation on nodes that do not participate in the community discovery to obtain an attached affiliation identifier, a bridging marker and a fragment marker; calculating a plurality of features required for an application-level risk score based on application nodes in the thin event layer and the core community identifiers, and generating the application-level risk score based on the plurality of features.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of data security technology, and in particular to an event risk assessment method, apparatus, equipment, and medium. Background Technology

[0002] In fraud prevention scenarios such as retail lending, credit card applications, personal business loans, and consumer installment payments, accurately identifying and preventing fraudulent activities is a core aspect of risk control for financial institutions. With the continuous upgrading of fraud methods, especially the increasing prevalence of organized and gang-related fraud, traditional risk identification technologies face severe challenges.

[0003] Existing technologies typically employ rule-based application fraud prevention solutions. The core of these solutions revolves around static fields of a single application event or customer, with risk control experts manually defining a series of rules. Risks are identified by matching these rules. While this approach is simple to implement and fast-responding, it can only detect single points of anomaly and cannot effectively identify complex, organized fraud groups operating through shared devices, shared IP addresses, shared addresses, escrow chains, contact networks, and unusual fund flows. Summary of the Invention

[0004] In view of this, embodiments of this application provide at least one event risk assessment method, apparatus, device, and medium.

[0005] The technical solution of this application embodiment is implemented as follows: On the one hand, embodiments of this application provide an event risk assessment method, the method comprising: A two-layer heterogeneous graph is constructed by acquiring historical application data and relational data, the two-layer heterogeneous graph including a main layer and a thin event layer; Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels; Based on the edge weights, a recursive segmentation operation based on the number of character nodes in each component is performed on the connected components in the main layer to obtain multiple sub-components. For the sub-components that meet the preset size conditions, a community discovery operation is performed to obtain the core community identifier. For nodes that do not participate in community discovery, a homecoming and merging operation is performed to obtain the attached affiliation identifier, bridging marker, and fragment marker. Based on the application nodes in the thin event layer and the core community identifier, various features required for the application-level risk score are calculated, and the application-level risk score is generated based on these features.

[0006] On the other hand, embodiments of this application provide an event risk assessment device, the method of which includes: The processing module is used to acquire historical application data and relational data to construct a two-layer heterogeneous graph, which includes a main layer and a thin event layer. Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels; Based on the edge weights, a recursive segmentation operation based on the number of character nodes in each component is performed on the connected components in the main layer to obtain multiple sub-components. For the sub-components that meet the preset size conditions, a community discovery operation is performed to obtain the core community identifier. For nodes that do not participate in community discovery, a homecoming and merging operation is performed to obtain the attached affiliation identifier, bridging marker, and fragment marker. The evaluation module is used to calculate multiple features required for the application-level risk score based on the application nodes in the thin event layer and the core community identifier, and to generate the application-level risk score based on the multiple features.

[0007] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described event risk assessment method.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described event risk assessment method.

[0009] In another aspect, embodiments of this application provide a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the above-described event risk assessment method.

[0010] In another aspect, embodiments of this application provide a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-mentioned event risk assessment method.

[0011] This application embodiment constructs a two-layer heterogeneous graph and performs data-driven edge layering, recursive segmentation, community detection, and relocation and merging operations. Combined with thin event layer features, it achieves accurate identification and structured interpretation of organized fraud gangs, improves the accuracy of anti-fraud detection, enhances the interpretability of results, and supports automated batch processing.

[0012] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 A schematic diagram illustrating the implementation process of an event risk assessment method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of another event risk assessment method provided in this application embodiment. Figure 3 This is a schematic diagram of a two-layer heterogeneous spectral structure provided in an embodiment of this application; Figure 4 This application provides a schematic diagram of an edge layering and edge weight generation process. Figure 5 A schematic diagram of a CC recursive segmentation and community merging process is provided for an embodiment of this application; Figure 6 A schematic diagram of a three-line feature development architecture provided in this application embodiment; Figure 7 This application provides a schematic diagram of a T+1 batch processing and result output process. Figure 8 This is a schematic diagram of the composition structure of an event risk assessment device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In the following description, some embodiments are referred to, which describe a subset of all possible embodiments. However, it is understood that some embodiments may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0017] The terms first / second / third are used only to distinguish similar objects and do not represent a specific ordering of objects. It is understood that first / second / third may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0019] This application provides an event risk assessment method, which can be executed by the processor of a computer device. The computer device can refer to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (such as a mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other similar computer equipment. Figure 1 This is a schematic diagram illustrating the implementation process of an event risk assessment method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: Step 101: Obtain historical application data and relational data to construct a two-layer heterogeneous graph, which includes a main layer and a thin event layer.

[0020] In this embodiment, historical application data refers to the information of past application records, such as application time, application results, and declaration information; relational data refers to the information describing the relationships between different entities, such as equipment usage records, guarantee relationships, and social relationships; the two-layer heterogeneous graph is a network structure data model that includes two hierarchical structures and diverse node types, used to express complex relationships; the main layer is one layer in the two-layer heterogeneous graph, used to store and represent the aggregation relationships between customers and their long-term associated entities; the thin event layer is another layer in the two-layer heterogeneous graph, used to store and represent the instantaneous relationships centered on a single application event and its declaration time information.

[0021] Historical application data and relational data are retrieved from the database. Based on this data, a two-layer heterogeneous graph is constructed. Entities such as customers, devices, IPs, and addresses, along with their historical aggregation relationships (e.g., devices frequently used by customers or IP addresses long-term), form the main layer. Simultaneously, each application event is treated as a node, and the application information entered at the time of application, such as the submitted phone number and address, is associated with that node, forming a thin event layer. Finally, the main layer and the thin event layer are integrated into a complete two-layer heterogeneous graph, where the main layer and the thin event layer share some entity nodes, such as device nodes and IP nodes.

[0022] Step 102: Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels.

[0023] In this embodiment, the edge layering operation is a process of classifying edges in the main layer according to their risk differentiation capabilities and the degree of graph structure adhesion that they may cause. The edge level is the edge level classification result obtained through the edge layering operation, such as high-risk level, medium-risk level, or low-risk level. The preset edge level is a specific edge level that is pre-set and used for subsequent edge weight calculation. The edge weight is a value calculated for an edge belonging to the preset edge level, used to quantify the strength of the association or risk signal intensity between the two nodes connected by the edge.

[0024] After constructing the two-layer heterogeneous graph, edge layering is performed on the edges in the main layer. This involves analyzing the attributes of each edge type, such as the number of customers sharing the same device, and combining this with historical risk tag data to calculate the risk enhancement value and graph cohesion for each edge subtype. Based on these calculations, edges are divided into multiple edge tiers, such as high-risk, medium-risk, and low-risk tiers. Then, edges belonging to the preset edge tiers are identified, and for these edges, an edge weight is calculated using a preset weighting formula based on their risk enhancement value and the degree of the connected nodes. This edge weight represents the strength of the risk correlation between the two nodes connected by the edge.

[0025] Step 103: Based on the edge weights, perform a recursive segmentation operation on the connected components in the main layer based on the number of character nodes in each component to obtain multiple sub-components.

[0026] In this embodiment, a connected component is the largest set of nodes in the main layer that are connected by edges, where any two nodes can be connected by a path; the number of character nodes in a component is the number of nodes of the character type in the connected component; the recursive splitting operation is a process of repeatedly decomposing a connected component with an excessively large size until the size of all subcomponents meets the preset controllable range; a subcomponent is a set of smaller nodes decomposed from the original connected component by the recursive splitting operation.

[0027] Identify all connected components in the main layer and count the number of person nodes in each connected component. For extremely large connected components where the number of person nodes exceeds a preset threshold, initiate a recursive splitting operation. This involves identifying bridging nodes in the extremely large component—those whose removal would cause the connected component to split—and temporarily removing these nodes first. After removing bridging nodes, recalculate the connected components for the remaining subgraph. If the newly generated subcomponents are still too large, repeat the process of identifying and removing bridging nodes, performing recursive splitting, until the number of person nodes in all generated subcomponents is less than or equal to the preset threshold, thus obtaining multiple subcomponents with controllable sizes.

[0028] Step 104: Perform community discovery operation on the sub-components that meet the preset size conditions to obtain the core community identifier, and perform home and merge operations on the nodes that did not participate in community discovery to obtain the attached affiliation identifier, bridging mark and fragment mark.

[0029] In this embodiment, the preset size condition is a pre-defined size range used to determine whether a subcomponent can directly execute the community discovery algorithm, such as the number of character nodes being within a certain range; the community discovery operation is an algorithmic process that groups nodes in a graph structure, making nodes within a group tightly connected and nodes between groups sparsely connected; the core community identifier is a unique identifier assigned to each tightly connected node group identified through the community discovery operation; the relocation and merging operation is a process of assigning nodes that did not participate in the community discovery operation to the identified core communities or marking them specially; the attached affiliation identifier is an identifier assigned to nodes merged into a core community but not its core member, indicating their affiliation; the bridging identifier is a identifier assigned to nodes connecting multiple core communities, indicating their bridging role; and the fragment identifier is a identifier assigned to a set of nodes that cannot be merged into any core community and are too small in size.

[0030] Determine if each subcomponent meets the preset size conditions. For subcomponents that meet the conditions, perform a community discovery operation to identify tightly connected groups and assign a core community identifier to each group. For nodes that did not participate in the community discovery operation, such as bridging nodes temporarily removed during recursive partitioning and small fragment node sets generated after recursive partitioning, perform a repositioning and merging operation. Based on the connection relationships between these nodes and the identified core communities, such as calculating their cumulative edge weights with each core community, merge them into the most relevant core community and assign them an affiliation identifier, or assign them a bridging tag or fragment tag to clarify their structural role.

[0031] Step 105: Based on the application nodes in the thin event layer and the core community identifier, calculate the various features required for the application-level risk score, and generate the application-level risk score based on the various features.

[0032] In this embodiment, the application node is a node representing a single application event in the thin event layer; the application-level risk score is a numerical value calculated for each application event to assess the likelihood of fraud risk in the application; and the multiple features are quantitative indicators extracted from the graph data to describe the risk attributes of the application event and its associated environment.

[0033] Starting with application nodes in the thin event layer and combining them with their associated core community identifiers, various features are calculated for application-level risk scoring. These features include: application outbreak features and packaging contradiction features extracted from the thin event layer; graph query features and graph pattern features extracted from the main layer; and community profile features calculated based on core community identifiers. These various features, and possibly other external features, are uniformly input into a pre-defined risk scoring model. Based on the values ​​of these features, the model calculates and generates an application-level risk score for each application node, which directly reflects the risk level of the application event.

[0034] This application embodiment constructs a two-layer heterogeneous graph and performs data-driven edge layering, recursive segmentation, community detection, and relocation and merging operations. Combined with thin event layer features, it achieves accurate identification and structured interpretation of organized fraud gangs, improves the accuracy of anti-fraud detection, enhances the interpretability of results, and supports automated batch processing.

[0035] Optionally, step 101 includes: Step 1011: Based on the application record table, customer basic information table, and external risk data, construct the main layer and the thin event layer. The main layer includes person nodes, device nodes, network protocol nodes, address nodes, and unit nodes, and includes person and device edges, person and network protocol edges, person and address edges, person and unit edges, guarantee edges, and social relationship edges. The thin event layer includes application nodes, application phone number nodes, and application email number nodes, and includes person and application edges, application and device edges, application and network protocol edges, application and application phone number edges, application and application unit edges, application and application address edges, and application and application email number edges.

[0036] In this embodiment, the application record table is a database table storing detailed information about each customer's application, such as application time, product type, and application status; the customer basic information table is a database table storing customer identity and background information, such as customer name, ID number, and contact information; external risk data refers to risk-related data from third-party institutions or public channels, such as blacklists and fraud databases; the main layer is a core level in the relationship graph, used to model long-term, stable relationships between customers and various entities; the thin event layer is another level in the relationship graph, used to model individual application events and their immediate information; person nodes are abstract data points in the graph representing a customer or applicant; devices... A node is an abstract data point in a graph representing a hardware device, such as a mobile phone or computer; a network protocol node is an abstract data point representing a network protocol address; an address node is an abstract data point representing a geographical location; a unit node is an abstract data point representing a company or organization; a person-device edge is a relationship line connecting a person node and a device node, indicating that the person has used the device; a person-network protocol edge is a relationship line connecting a person node and a network protocol node, indicating that the person has used the network protocol address; a person-address edge is a relationship line connecting a person node and an address node, indicating that the person is associated with the address; a person-unit edge is a relationship line connecting a person node and a unit node. A relationship line indicates that the person is associated with the organization; a guarantee edge is a relationship line connecting two people in the graph, indicating that one person has provided a guarantee for the other; a social relationship edge is a relationship line connecting two people in the graph, indicating that there is some kind of social connection between the two people, such as a kinship or friendship; an application node is an abstract data point in the graph representing a specific application event; a registration phone number node is an abstract data point in the graph representing a phone number filled in during the application; a registration email address node is an abstract data point in the graph representing an email address filled in during the application; a person-application edge is a relationship line connecting a person node and an application node in the graph, indicating that the person initiated the application; an application-equipment edge is a relationship line connecting an application node and an equipment node in the graph. The first line represents the device used when the application event occurred; the second line represents the network protocol address used when the application event occurred; the third line represents the telephone number entered in the application event; the fourth line represents the organization information entered in the application event; the fifth line represents the address information entered in the application event; and the sixth line represents the email address entered in the application event.

[0037] Data is extracted from application record forms, customer basic information forms, and external risk data. Based on this data, a two-layer heterogeneous relationship graph is constructed, consisting of a main layer and a thin event layer. In the main layer, person nodes, device nodes, network protocol nodes, address nodes, and entity nodes are created, along with edges between person and device, person and network protocol, person and address, person and entity, guarantee, and social relationship edges. These nodes and edges are used to model the long-term aggregation relationships between customers and entities. Simultaneously, in the thin event layer, application nodes, application phone number nodes, and application email number nodes are created, along with edges between person and application, application and device, application and network protocol, application and application phone number, application and application entity, application and application address, and application and application email. These nodes and edges are used to model individual application events and their immediate information.

[0038] Step 1012: Configure the device node, network protocol node, address node, and unit node in the thin event layer to share the same physical node as the corresponding type of node in the main layer.

[0039] In the embodiments of this application, a physical node is a data point actually stored in the relational graph database, representing a unique entity, such as a specific device or a specific network protocol address.

[0040] Device nodes, network protocol nodes, address nodes, and unit nodes in the thin event layer are configured to share the same physical nodes as their corresponding types in the main layer. This means, for example, that the node representing device MAC-001 in the main layer and the node representing the same device in the thin event layer point to the same physical storage location in the database. This design achieves physical unification between the main layer and the thin event layer at the node level, but different relationship semantics are distinguished between the two layers through different types of edges, thus maintaining data relevance while achieving separation of business logic.

[0041] This application embodiment constructs a two-layer heterogeneous relationship graph containing a main layer and a thin event layer, and configures shared physical nodes in both layers. This enables independent modeling and effective association of long-term customer aggregation relationships and application-time declaration information. Thus, without interfering with the community discovery algorithm of the main layer, it can effectively capture changes and inconsistencies in declaration information during intermediary packaging behavior.

[0042] Optionally, step 102 includes: Step 1021: For the edges formed by intermediate entities in the main layer, bin them according to the type and degree of the intermediate entities to obtain multiple edge subtypes.

[0043] In this embodiment, the main layer is the core part of the relationship graph, containing person nodes and entity nodes such as devices, IPs, addresses, and units, as well as historical aggregation relationship edges between them, used to reflect stable customer relationships. Intermediate entities are entity nodes connecting two person nodes, such as devices, IPs, and addresses. Edges are relationships connecting two nodes in the graph, used to represent the association between nodes. Degree refers to the number of edges a node is connected to; for example, if a device node is connected to 3 person nodes, then the degree of that device node is 3. Bucketing divides data into different intervals or groups according to certain rules; for example, edges with a degree of 2 are grouped together. Edge subtypes are more detailed classifications of edges of the same type based on the type and degree of the intermediate entities they connect to.

[0044] Retrieve all edges in the main layer, then identify those edges that connect two character nodes and whose paths pass through an intermediate entity. For these edges, group them into different groups based on the type and degree of the intermediate entity they pass through; each group is defined as an edge subtype. For example, all edges connecting two character nodes where the intermediate entity is a device node with a degree of 2 will be categorized as the edge subtype "device_2person".

[0045] Step 1022: Under the condition of known risk labels, calculate the pairwise purity enhancement value for each of the edge subtypes.

[0046] In this embodiment, the risk label is known historical data used to mark whether a customer or an application is a fraudulent sample. The pairwise purity enhancement value measures the probability that both connected person nodes in an edge subtype are bad customers, relative to the probability that both customers are bad customers in a random case.

[0047] Based on historical risk label data, the pairwise purity enhancement value is calculated for each identified edge subtype. Specifically, first, the number of pairs of person-node pairs under that edge subtype where both nodes are bad customers is calculated, and this number is divided by the total number of person-node pairs under that edge subtype to obtain the pairwise purity of that edge subtype. Then, the square of the global bad sample rate is calculated as a random baseline. The pairwise purity is divided by the random baseline to obtain the pairwise purity enhancement value for that edge subtype. The larger this value, the more effectively the edge of that type can be associated with bad customers.

[0048] Step 1023: Compare the pairwise purity enhancement value with a preset first threshold to filter out edge types that meet the conditions.

[0049] In this embodiment, the system compares the calculated pairwise purity enhancement value for each edge subtype with a preset first threshold. The system filters out all edge subtypes whose pairwise purity enhancement value is greater than or equal to the preset first threshold. These filtered edge subtypes are considered to have strong risk signal correlation capabilities and are worth further analysis in subsequent steps to determine whether they will lead to excessive adhesion of the graph structure.

[0050] Step 1024: For the selected edge types, construct subgraphs and calculate the proportion of giant components under different entity degree thresholds.

[0051] In this embodiment, the entity degree threshold is an upper limit used to filter intermediate entities; for example, only device nodes with a degree not exceeding 5 are considered. A subgraph is a smaller graph formed by selecting a subset of nodes and edges from the original graph. The giant component percentage is the number of nodes contained in the largest connected component of the graph, divided by the total number of nodes in the graph, used to measure the degree of graph cohesion.

[0052] For each selected edge subtype, different entity degree thresholds are used to construct subgraphs. For example, for the edge subtype "device_3-5 people," subgraphs are constructed under different conditions, such as entity degree thresholds not exceeding 3, 5, and 10. For each subgraph under each entity degree threshold, the proportion of its giant component is calculated, which is the number of nodes contained in the largest connected component in the subgraph divided by the total number of nodes in the subgraph. The purpose of this step is to evaluate how much adhesion the edge subtype causes in the graph structure under different constraints.

[0053] Step 1025: Determine the entity degree threshold corresponding to when the proportion of the giant component is less than or equal to the preset second threshold as the optimal degree threshold, and mark the edge subtype that satisfies the optimal degree threshold as a preset high priority edge level.

[0054] In this embodiment, the preset second threshold is a pre-set value used to control the degree of graph cohesion and avoid generating excessively large giant connected components. The optimal degree threshold is the entity degree threshold that ensures the proportion of giant components does not exceed the preset second threshold; this threshold balances the risk signal of edges with the cohesion of the graph. The preset high-priority edge level is a marker used to identify high-quality edges that have strong risk signals but do not cause excessive cohesion in the graph structure.

[0055] Among the calculated entity degree thresholds and their corresponding giant component proportions, an entity degree threshold is found that makes the giant component proportion less than or equal to a preset second threshold. This threshold is determined as the optimal degree threshold for this edge subtype. Then, edge subtypes that satisfy their optimal degree threshold are marked as a preset high-priority edge level. This means that only edges under the optimal degree constraint will be used in subsequent graph calculations, thus effectively suppressing the generation of giant connected components while preserving strong risk correlation signals.

[0056] This application embodiment uses a dual screening method of pairwise purity enhancement value and giant component proportion. The system can automatically identify and retain high-quality edges with strong risk signals and low adhesion from massive edges, improve the input graph quality of the community detection algorithm, avoid the giant connected component problem, and improve the purity and stability of subsequent gang identification results.

[0057] Optionally, step 102 further includes: Step 1026: For a target edge formed by an intermediate entity and belonging to the preset edge level, obtain the risk enhancement value of the target edge and the degree of the intermediate entity.

[0058] In this embodiment, the intermediate entity is a non-person node in the graph that connects two person nodes, such as a device node, IP node, address node, or unit node. The preset edge tier is a classification of edges that meet specific risk enhancement and connectivity conditions based on a data-driven edge layering method; for example, tier S indicates that this type of edge has a high fraud risk correlation. The target edge is the part of the edge determined to belong to the preset edge tier and whose connection path contains an intermediate entity. For example, an edge connecting person A and person B using a device passes through device nodes that are intermediate entities, and this edge is marked as tier S. The risk enhancement value measures the increase in probability that two persons are both bad customers when associated through a specific type of edge compared to random cases; for example, the pair_purity_lift value. The degree is the number of person nodes directly connected to the intermediate entity in the graph; for example, a device node connecting 10 persons has a degree of 10.

[0059] For a target edge formed through an intermediate entity and belonging to a preset edge tier, obtain the risk enhancement value of the target edge and the degree of the intermediate entity. First, traverse all edges formed through intermediate entities and filter out those target edges that have been marked as preset edge tiers. For each target edge, read the pre-calculated risk enhancement value from its corresponding edge subtype. At the same time, query the intermediate entity nodes traversed by the target edge from the graph database and obtain the degree attribute of the nodes.

[0060] Step 1027: Calculate the logarithm of the risk enhancement value to obtain the first intermediate weight.

[0061] In this embodiment, the logarithmic result is a value obtained by performing a logarithmic operation on the risk enhancement value, such as the logarithm with the natural constant e as the base. The first intermediate weight is a preliminarily calculated value used to measure the edge association strength. It is based solely on the risk enhancement value and does not yet consider the attenuation effect brought by the degree of intermediate entities.

[0062] The logarithm of the risk enhancement value is calculated to obtain the first intermediate weight. Applying a logarithmic function, such as the natural logarithm log(lift), to the risk enhancement value obtained in step 1026 yields the first intermediate weight. For example, if the risk enhancement value is 20, the first intermediate weight is log(20), approximately equal to 2.9957. The purpose of using logarithmic operations is to compress the high dynamic range of the risk enhancement value, preventing a few extremely high risk enhancement values ​​from dominating the subsequent weight calculation, thus making the weight distribution smoother and more reasonable.

[0063] Step 1028: Calculate the difference between the degree and the preset first attenuation parameter raised to the power of the preset second attenuation parameter to obtain the attenuation factor.

[0064] In this embodiment, the preset first attenuation parameter is a system-preset constant used to adjust the starting point of degree attenuation, for example, a value of 1. The preset second attenuation parameter is a system-preset exponential parameter used to control the rate of degree attenuation, for example, a value of 0.5. The attenuation factor is a value calculated by the system to quantify the degree of intermediate entities and its influence on edge weight attenuation.

[0065] The system calculates the difference between the degree and the preset first attenuation parameter raised to the power of the preset second attenuation parameter to obtain the attenuation factor. The system subtracts the preset first attenuation parameter from the degree of the intermediate entity to obtain an intermediate result. Then, the system uses this intermediate result as the base and the preset second attenuation parameter as the exponent to perform a power operation, i.e., calculates (deg - 1)^δ, and the result is the attenuation factor. For example, if the degree is 2, the preset first attenuation parameter is 1, and the preset second attenuation parameter is 0.5, then the attenuation factor is (2-1)^0.5 = 1; if the degree is 20, then the attenuation factor is (20-1)^0.5 ≈ 4.3589. The purpose of this step is that the more people an intermediate entity connects to, the larger its attenuation factor becomes, thus strengthening the suppression of edge weights in subsequent steps, thereby suppressing noise from common equipment or entities.

[0066] Step 1029: Divide the first intermediate weight by the attenuation factor, compare the result with zero, and take the maximum value of the two as the final edge weight of the target edge.

[0067] In this embodiment of the application, the final edge weight is the value that the system finally assigns to the target edge, which is used to represent the connection strength or importance of the edge in the subsequent community detection algorithm.

[0068] The first intermediate weight is divided by the decay factor, and the result is compared with zero. The larger of the two values ​​is taken as the final edge weight of the target edge. The first intermediate weight is then divided by the decay factor to obtain a quotient. This quotient is then compared with zero, and the larger of the two values ​​is selected as the final edge weight of the target edge. This maximum-value operation ensures that the edge weight is not negative, avoiding negative weight problems caused by a small logarithmic result or a large decay factor. For example, if the first intermediate weight is 2.9957 and the decay factor is 4.3589, the quotient is 0.687, and the final edge weight is 0.687; if the first intermediate weight is 0.5 and the decay factor is 0.9, the quotient is 0.556, and the final edge weight is 0.556; if the first intermediate weight is 0.2 and the decay factor is 0.9, the quotient is 0.222, and the final edge weight is 0.222.

[0069] This application embodiment combines the logarithm of the risk enhancement value with a power-law decay based on the degree of intermediate entities, and takes a non-negative value, to suppress noisy edges generated by highly connected public entities and strengthen high-fraud-risk association edges, providing high-quality input for subsequent more accurate and stable community detection algorithms.

[0070] Optionally, step 103 includes: Step 1031: Perform connected component segmentation on the input graph to obtain multiple connected components, and count the number of character nodes in each connected component.

[0071] In this embodiment, the input graph is the received basic graph structure used for the community discovery algorithm. This graph consists of multiple nodes and edges connecting the nodes. Nodes represent entities, and edges represent relationships between entities. A connected component is a concept in graph theory, referring to a maximally connected subgraph of a graph, where there is at least one path connecting any two nodes, and this connectivity cannot be maintained by adding more nodes. A person node is a type of node in the graph representing an applicant customer or individual, carrying attributes such as customer identification.

[0072] The graph structure used as input to the community detection algorithm is subjected to a connected component segmentation operation. This operation identifies all interconnected sets of nodes by traversing all nodes in the graph and defines each set as an independent connected component. After segmentation, each connected component is traversed, and the number of all character nodes within that component is counted and recorded.

[0073] Step 1032: Identify connected components with more than the preset threshold for ultra-large components as ultra-large components to be segmented.

[0074] In this embodiment, the preset oversized component threshold is a pre-defined numerical limit used to determine whether a connected component is too large due to containing too many person nodes, thus requiring special processing. The oversized components to be segmented refer to connected components whose number of identified person nodes exceeds the preset threshold.

[0075] The number of person nodes in each connected component is compared with a preset threshold for extremely large components. If the number of person nodes in a connected component exceeds this threshold, it is marked as an extremely large component to be segmented. This determination process is to identify giant connected components that are too large and directly running the community discovery algorithm may lead to unstable results or performance issues.

[0076] Step 1033: Perform cut point detection on the undirected projected subgraph of the large component to be segmented.

[0077] In the embodiments of this application, an undirected projective subgraph refers to the graph structure formed by treating the edges in the super-large component to be segmented as undirected edges. A cut vertex is a concept in graph theory; it refers to a node in an undirected graph whose deletion, along with all its connected edges, would destroy the connectivity of the original connected components, resulting in more connected components.

[0078] For each connected component identified as a large component to be segmented, its corresponding undirected projective subgraph is first constructed. Then, a cut vertex detection algorithm is performed on this undirected projective subgraph to find all cut vertices in the graph. The purpose of cut vertex detection is to find those bridge nodes connecting different sub-communities; removing them can effectively split a large connected component into multiple smaller, more independent sub-components.

[0079] Step 1034: When a cut point is detected, select a preset number of nodes with the highest degree from all detected cut points as bridge candidate nodes.

[0080] In this embodiment, degree refers to the number of other nodes connected to a node in a graph. The preset number is a pre-defined value used to limit the maximum number of nodes selected from cut vertices as bridge candidate nodes. Bridge candidate nodes are selected nodes considered key nodes connecting different subgroups and are prepared for temporary removal from the graph for component partitioning.

[0081] If at least one cut vertex is found after cut vertex detection, all detected cut vertices are further sorted according to their degree from highest to lowest. Then, from these sorted cut vertices, a predetermined number of nodes with the highest degree are selected and defined as bridge candidate nodes. A higher degree indicates that the node connects to more other nodes, making it more likely to effectively cut large connected components.

[0082] Step 1035: When no cut point is detected, select a preset number of nodes with the highest degree from the undirected projection subgraph as alternative cut points.

[0083] In this embodiment, the alternative cut points are nodes used by the system to replace the function of cut points when no cut points exist in the undirected projected subgraph. These nodes also have high degrees, and removing them can also split connected components to some extent.

[0084] If no cut vertices are found after performing cut vertex detection, it means that the current undirected projective subgraph is a biconnected or approximately biconnected component with a very compact structure and no single critical connection point. In this case, as a fallback, all nodes in the undirected projective subgraph are sorted in descending order of their degree. Then, a predetermined number of nodes with the highest degree are selected from these nodes and defined as alternative cut vertices for subsequent partitioning operations.

[0085] Step 1036: Temporarily remove the bridging candidate node or the alternative cut point from the subgraph, and re-perform connected component splitting on the remaining subgraph to obtain new subcomponents.

[0086] In this embodiment, the remaining subgraph refers to the graph structure remaining after temporarily removing bridging candidate nodes or alternative cut points and all their connected edges from the original undirected projective subgraph. The new subcomponents refer to several smaller connected components obtained after re-performing connected component partitioning on the remaining subgraph.

[0087] The selected bridge candidate nodes or alternative cut points, along with all the edges they connect, are temporarily removed from the original undirected projective subgraph. This removal is temporary and aims to observe changes in the graph structure. Subsequently, the connected component splitting algorithm is performed again on the remaining subgraph resulting from the removal operation. This splitting produces several new, smaller sub-components. Compared to the original massive sub-components, the size of these new sub-components is effectively controlled, providing more stable and manageable input for subsequent, more refined community detection algorithms.

[0088] This application embodiment uses recursive segmentation and cut vertex detection to gradually decompose giant connected components into sub-components of controllable size. This avoids the problems of unstable results and poor community purity caused by directly applying community detection algorithms to ultra-large graphs, thereby improving the computability and stability of community detection in ultra-large graph scenarios.

[0089] Optionally, step 104 includes: Step 1041: After obtaining the core community identifier, obtain the bridging character node and calculate the cumulative edge weight of the core community to which all neighbor nodes of the bridging character node belong.

[0090] In this embodiment, bridging character nodes are identified during the recursive partitioning of extremely large connected components. Deleting these nodes would increase the number of connected components; these nodes typically connect to multiple different core communities. The core community identifier is a unique number assigned to each identified core community after the community discovery algorithm is completed, used to distinguish different communities. The cumulative edge weight is calculated as the sum of the weights of all edges originating from a node and connected to the communities of its neighboring nodes.

[0091] After completing the community discovery algorithm and assigning identifiers to core communities, the previously identified and recorded bridging nodes are retrieved. For each bridging node, all its neighboring nodes are traversed, and the core community to which each neighboring node belongs is determined. Then, based on the edge weights calculated in the edge layering stage, the weights of all edges connecting the bridging node to its neighboring nodes within the same core community are accumulated to obtain the cumulative edge weights between the bridging node and each core community.

[0092] Step 1042: When the bridging character node is associated with only one core community, attach the bridging character node to the core community and generate an attachment affixation identifier.

[0093] In this embodiment of the application, the attached affiliation identifier is a marker generated for the bridging character node that is merged into the core community, used to indicate that the node is not an original member of the core community, but was attached through a subsequent attribution process.

[0094] After completing the statistics on the core communities to which the neighboring nodes of the bridging character node belong, it is determined whether all the neighboring nodes of the bridging character node belong to the same core community. If it is determined that the bridging character node is associated with only one core community, that is, all its neighboring nodes have the same core community identifier, then the bridging character node will be attached to this unique core community, and an attachment affixation identifier will be generated for it. This identifier is used to distinguish the node from the original members of the core community in subsequent data output and verification.

[0095] Step 1043: When the bridging character node is associated with multiple core communities, calculate the cumulative edge weight ratio between the first candidate core community and the second candidate core community.

[0096] In this embodiment, the first candidate core community is the core community ranked first after sorting by the cumulative edge weights of the edges connecting to the bridging character node in descending order when multiple core communities are associated with that node. The second candidate core community is the core community ranked second in the same sorting. The cumulative edge weight ratio is calculated as the quotient of the cumulative edge weights of the first candidate core community and the second candidate core community.

[0097] If a bridging node is determined to be associated with multiple different core communities (i.e., its neighboring nodes are distributed across two or more different core communities), a more refined placement process will be initiated. Based on the accumulated edge weights from the previous steps, all associated core communities are sorted in descending order. The core community with the largest accumulated edge weight is defined as the first candidate core community, and the core community with the second largest accumulated edge weight is defined as the second candidate core community. Subsequently, the ratio of the accumulated edge weight of the first candidate core community to that of the second candidate core community is calculated to obtain the accumulated edge weight ratio.

[0098] Step 1044: When the cumulative edge weight ratio is greater than or equal to a preset third threshold, attach the bridging character node to the first candidate core community and generate an attachment affiliation identifier.

[0099] In this embodiment, the preset third threshold is a pre-set value used to determine whether the connection strength between the bridging character node and a certain core community is significantly higher than that of other communities, thereby deciding whether to attach it to that community.

[0100] After calculating the cumulative edge weight ratio, this ratio is compared with a preset third threshold. If the ratio is greater than or equal to the preset third threshold, it means that the connection strength between the bridging character node and the first candidate core community is much higher than the connection strength with the second candidate core community, and its affiliation is relatively clear. In this case, the bridging character node is attached to the first candidate core community, and an attachment affiliation identifier is generated for it, indicating that the node is assigned to this community as a subordinate structure.

[0101] Step 1045: When the cumulative edge weight ratio is less than the preset third threshold, generate a bridging marker for the bridging character node.

[0102] In this embodiment of the application, the bridging marker is a marker generated for bridging character nodes that cannot be clearly classified into any core community. It indicates that the node plays a bridging role between multiple communities, but does not belong to any core community itself.

[0103] If the cumulative edge weight ratio is less than a preset third threshold, it means that the connection strength between the bridging node and the first candidate core community is not significantly stronger than the connection strength with the second candidate core community. It's impossible to clearly determine which core community the node should belong to. In this case, the node will not be forcibly attached to any community; instead, a bridging marker will be generated for it. This marker is used in subsequent verification and visualization to identify that the node is a bridge connecting multiple core communities, its affiliation is unclear, and it requires manual attention or special handling.

[0104] This application embodiment achieves refined processing of boundary nodes in complex graph structures by distinguishing the core communities, attached structures, and bridging nodes through a merging mechanism, thereby improving the interpretability and verification friendliness of community partitioning results.

[0105] Optionally, step 105 includes: Step 1051: Based on the application nodes in the thin event layer, and taking the application time as the time anchor point, calculate the application outbreak characteristics, packaging contradiction characteristics, and application result aggregation characteristics to obtain the event layer features.

[0106] In this embodiment, the application node is a node representing a single credit application event in the thin event layer, and its primary key is the application identifier. The application time is the specific moment the application occurred, recorded in the application node attributes. Application burst features are used to measure whether there is an abnormal concentration of application behavior within a specific time window near the application time. Packaging contradiction features are used to detect inconsistencies or frequent changes in the application information filled in by the applicant between different applications or between the applicant and the master file information. Application result aggregation features are features that summarize the historical application results of neighboring nodes related to the current application. Event layer features are the collective term for all features calculated by the system based on the thin event layer.

[0107] Based on the constructed thin event layer, the application nodes within it are used as the starting point for calculation. Using the application time attribute of each node as the time anchor, three types of features are calculated within the thin event layer. The first type is application burst features, which count the number of applications within a specific number of days prior to the application time, the number of different applicants associated with the same device, and the number of different applicants associated with the same IP address. The second type is packaging contradiction features, which detects the number of changes in the reporting unit or address filled in by the same person in different applications, and the number of inconsistencies in the reporting information appearing in different applications associated with the same device. The third type is application result aggregation features, which finds related individuals through the main layer relationship and counts the number of times these related individuals have been rejected in recent applications. The results calculated from these three types are then unified as event layer features.

[0108] Step 1052: Based on the main layer, starting from the application node, calculate the number of risky customers within two hops, the shortest path distance to the nearest risky customer, and the number of risk association dimensions to obtain graph query features.

[0109] In this embodiment, the main layer is a layer in the constructed two-layer graph structure that contains core entities such as people, devices, IPs, addresses, and organizations, along with their historical aggregation relationships, and is used to execute the community discovery algorithm. The number of risky customers within two hops is the number of blacklisted individuals reachable from the person corresponding to the current application node through no more than two edges in the graph structure. The shortest path distance is the minimum number of edges traversed in the graph from the person corresponding to the current application node to the nearest blacklisted individual. The number of risk association dimensions is an indicator that measures how many different dimensions (device, IP, address, organization, etc.) the person corresponding to the current application node can be associated with in the blacklist. Graph query features are features calculated by performing graph traversal queries on the main layer.

[0110] Based on the constructed main layer, the application nodes of the thin event layer are used as the starting point for the query. A graph traversal query method is employed. First, the number of risky customers within two hops is calculated. This involves starting from the person corresponding to the application node, traversing all neighboring nodes within their two-hop range, counting the number of blacklisted customers, and ensuring that the traversed edges satisfy time constraints. Second, the shortest path distance to the nearest risky customer is calculated. This involves finding the shortest path length from the current person to any blacklisted customer using a shortest path algorithm. Finally, the number of risk association dimensions is calculated. This involves counting which entity dimensions (device, IP, address, and organization) the current person uses to reach blacklisted customers. The results of these calculations are used as graph query features.

[0111] Step 1053: Based on the main layer, calculate the guarantee loop marker, guarantee chain length, and number of associated high-risk communities to obtain graph pattern features.

[0112] In this embodiment, the guarantee loop marker is a Boolean feature used to identify whether the person corresponding to the current application node is in a closed loop structure formed by guarantee relationships. The guarantee chain length refers to the number of hops in the longest guarantee relationship chain to which the person corresponding to the current application node belongs. The number of associated high-risk communities is the number of communities to which the person corresponding to the current application node is associated within two hops, where the percentage of blacklisted members exceeds a preset threshold. The graph pattern feature is a feature calculated by matching a specific graph structure pattern on the main layer.

[0113] Based on the constructed main layer, a structural pattern matching algorithm is used for calculation. First, the guarantee loop marker is calculated: the current character node in the main layer is checked to see if it participates in forming a loop formed by guarantee edges; if so, it is marked as true. Second, the guarantee chain length is calculated: starting from the current character node, the longest continuous path along the guarantee edge direction is found and the number of hops is calculated. Finally, the number of associated high-risk communities is calculated: all neighboring nodes within two hops of the current character are traversed, and the number of communities to which these nodes belong is counted, identifying those communities where the proportion of blacklisted customers exceeds a preset threshold. The results of these calculations are used as graph pattern features.

[0114] Step 1054: Based on the core community identifier, calculate the proportion of high-risk customers within the community, the recent surge in applications within the community, the community density, and the penetration rate of guarantee relationships within the community to obtain community profile features.

[0115] In this embodiment, the core community identifier is a unique number assigned to each identified core community after community discovery and merging. The proportion of high-risk customers within a community is the ratio of blacklisted customers in the core community to the total number of customers in that community. The recent application surge rate of a community is an indicator measuring the concentration of application behavior among all members within a core community within a recent specific time window. Community density is the ratio of the actual number of edges existing within a core community to the maximum possible number of edges in that community. The penetration rate of guarantee relationships within a community is the ratio of the number of member pairs with guarantee relationships within a core community to the total number of possible member pairs in that community. Community profile features are statistical features used to describe and summarize the overall risk status and behavioral patterns of core communities.

[0116] Based on the generated core community identifiers, profile metrics are calculated for each core community. First, the percentage of high-risk customers within the community is calculated, which is the number of all blacklisted customers in the community divided by the total number of customers in the community. Second, the recent application surge rate of the community is calculated, which is the total number or average number of applications from all members of the community within a specific number of days. Next, the community density is calculated, which is the actual number of edges within the community divided by the maximum number of edges the community could have in a fully connected state. Finally, the penetration rate of guarantee relationships within the community is calculated, which is the number of all customer pairs with guarantee relationships within the community divided by the total number of all possible customer pairs in the community. The results of these calculations are used as community profile features.

[0117] This application embodiment constructs a two-layer graph structure consisting of a main layer and a thin event layer. It performs community discovery and merging on the main layer, calculates event layer features on the thin event layer, and calculates graph query features, graph pattern features, and community profile features on the main layer. This achieves the goal of unifying the application-level risk scoring framework with changes in declaration criteria, graph structure patterns, community risk status, and time series outbreak features. This comprehensively and multidimensionally improves the ability to identify organized fraud groups and enhances the friendliness of verification.

[0118] Optionally, refer to Figure 2 This application provides an event risk assessment method, including: Step S1: Obtain application records, customer information, device logs, network logs, guarantee relationships, social relationships, and external risk data; Step S2: Construct a two-layer graph. Main layer: Person + Entity nodes; thin event layer: Application node; both layers share entity nodes.

[0119] Step S3, layer the edges: pair_purity_lift + giant_ratio - S-level / M-level / W-level.

[0120] Step S4, calculate the edge weight of edge S: weight_final = max(0, log(lift)) × 1 / (deg-1)^δ; Where `lift` is the risk enhancement value for this edge type, `deg` is the degree of the intermediate entity, and `δ` is the attenuation parameter (suggested initial value of 0.5). The formula means: the base signal strength is logarithmic (log(lift)), and attenuation is applied according to the number of connected people in the intermediate entity. Attenuation is minimal when a device connects only 2 people, but significant when it connects 20 people, thus suppressing the sticky noise from shared devices. For edges where people are directly connected, `weight_final=max(0, log(lift))` is used, and degree attenuation is not required.

[0121] Step S5, CC recursive segmentation + Leiden community discovery Phase 1; CC recursive segmentation (cut point detection) Phase 2: Leiden (CPM objective function) - core community; Step S6: Merge and reposition the Person-community_id_attach bridge to the Entity-bridge mapping; fragmentation - independent / merge / mark; Step S7, Feature calculation route A: Graph query features; route B: Event layer features; route C: Graph pattern features + community profile indicators; Step S8: Output application-level risk score, community-level risk score, and investigation checklist.

[0122] Optionally, refer to Figure 3 The process of constructing the two-layer heterogeneous map is as follows: In this embodiment, a two-layer heterogeneous relationship graph is constructed based on the application record table (apply_log), the customer basic information table, the mobile banking log table, the guarantee relationship table, the social relationship table, and external risk data.

[0123] The main layer contains the following nodes and edges: The Person node uses customer_id as the primary key, carries first_apply_time (first application time), retrieves MIN(apply_time) from apply_log, and has the is_blacklist attribute.

[0124] Entity nodes include: Device node, IP node, Address node, and Company node.

[0125] The main layer edges include: Person-Device Edge, Person-IP Edge, Person-Address Edge, Person-Company Edge, Guarantee Edge, and Social Relationship Edge.

[0126] The thin event layer contains the following nodes and edges: The Application node uses `apply_id` as its primary key and carries attributes such as `apply_time`, `product_type`, `apply_status`, `apply_amount`, and `channel`. All this data originates from the unified application record table `apply_log`. This table simultaneously carries application event information and application caliber information at the time of application, including the device identifier at the time of application, the IP address at the time of application, the applicant's mobile phone number, work phone number, emergency contact number, applying organization, applying address, and applying email address.

[0127] The DeclaredPhone node is generated by deduplicating the three phone numbers in apply_log.

[0128] The declared email address node, DeclaredEmail, is generated by standardizing the email field in apply_log.

[0129] The event layer edges are divided into 7 categories: Person-Applicant, Application-Equipment, Application-IP, Application-Applying Phone Number, Application-Applying Organization, Application-Applying Address, and Application-Applying Email. All 7 types of edges originate from the apply_log table.

[0130] The main layer and the thin event layer share device nodes, IP nodes, address nodes, and unit nodes. For example, in the main layer, customer A using device MAC-001 and in the thin event layer, application 001 using device MAC-001 both point to the same physical node. However, the meanings of the two layers differ. The device used in the main layer represents the customer's historical aggregation relationship, while the application device in the event layer is a snapshot at the time of the current application. The most common modification made by intermediaries during packaging is the declaration criteria information; inconsistencies between the declared values ​​and the master file values ​​are a risk signal.

[0131] In this embodiment, the two-layer heterogeneous graph contains a total of 8 types of nodes. The core nodes of the main layer are Person, Device, IP, Address, and Company. The thin event layer adds Application, DeclaredPhone, and DeclaredEmail, and shares entity nodes such as Device, IP, Address, and Company with the main layer. The entire graph has a total of 13 types of edges, including 6 types of main layer edges and 7 types of event layer edges. The community detection algorithm is only executed on the S-level edges of the main layer; edges of the thin event layer do not participate in edge layering and community calculation.

[0132] Optionally, refer to Figure 4 The process of edge layering and edge weight calculation is as follows: For edges formed by intermediate entities in the main layer, first, they are bucketed according to entity type and entity degree to form edge subtypes. For example, using the device edge type, a device connected to 2 people is recorded as device_2 people, and connected to 3-5 people is recorded as device_3-5 people. The bucket boundaries are based on the inflection points of the actual data distribution.

[0133] Then, person pairs are constructed, and the pair_purity_lift for each edge_subtype is calculated under the condition that the risk labels are known. Specifically, pair_purity = number of bad pairs / total number of person pairs, and pair_purity_lift = pair_purity / p², where p is the global bad sample rate and p² is the random baseline.

[0134] For example, if the global bad sample rate p = 5%, then p² = 0.0025. If the pair_purity of the device_2 subtype is 0.05, then pair_purity_lift = 0.05 / 0.0025 = 20, which is much higher than the threshold of 10. This indicates that when two people share the same device that is only used by two people, the risk is significantly higher than the random level.

[0135] For edge subtypes that satisfy pair_purity_lift ≥ 10, graph construction is further performed under different entity degree thresholds, and giant_ratio (number of nodes in the largest connected component / total number of nodes) is calculated. For example, for the device_3-5 person subtype, try thresholds such as deg ≤ 3, deg ≤ 5, deg ≤ 10: if giant_ratio = 1.5% when deg ≤ 5, and giant_ratio = 5% when deg ≤ 10, then best_deg_threshold = 5, and this subtype is marked as S grade.

[0136] For guarantee edges and social relationship edges, since they represent direct person-to-person relationships, no bucketing by entity degree is performed, but their risk lift values are still calculated, and person-side hub filtering is performed for professional guarantors or relationship hubs.

[0137] Weights are further calculated for S-grade edges. For edges formed via intermediate entities, the formula weight_final = max(0, log(lift)) × 1 / (deg-1)^δ is adopted, where lift is the risk lift value of the edge type, deg is the intermediate entity degree, and δ is the attenuation parameter. The meaning of this formula is: the base signal strength is taken as the logarithm (log(lift)), and attenuation is applied according to the number of connections of the intermediate entity. When a device is connected to only 2 people, the attenuation is very small, and when it is connected to 20 people, the attenuation is significant, so as to suppress adhesion noise caused by public devices. For direct person-to-person edges, weight_final = max(0, log(lift)) is adopted, and no degree attenuation is required.

[0138] With reference to Figure 5 , the process of CC recursive segmentation, Leiden community detection and merging is as follows: First, connected component segmentation is performed on the input graph of the community algorithm to obtain the cc_id of each component, and the number of person nodes cc_person_size and the total number of nodes cc_total_size in each component are counted. Using cc_person_size as the main business standard, the components are divided into: isolated point or single-person component (cc_person_size = 0 or 1), original small component (2 ≤ cc_person_size ≤ leiden_lower), medium component (leiden_lower < cc_person_size ≤ K) and super-large component (cc_person_size > K).

[0139] The overall process is divided into three phases: Phase 1 (CC Recursive Segmentation): This phase only handles the segmentation of extremely large components to a manageable size, without defining the final community. For undirected projected subgraphs of extremely large components, cut vertex detection is performed first. Cut vertex detection itself does not use edge weights; edge weights are only used for candidate node ranking and subsequent placement. A cut vertex is a node whose deletion would increase the number of connected components. If a cut vertex exists, the Top-N nodes are selected as bridging candidate nodes in descending degree order. If no cut vertex exists, the process degenerates into selecting alternative cut points based on the Top-N nodes by degree. Node types are distinguished during identification: entity nodes are identified by a type threshold (best_deg_threshold) or the component's intra-quantile; person / person nodes are only identified by degree anomalies for specific Hub relationships such as guarantors / contact persons. Bridging candidate nodes are divided into bridging person / person and bridging entity nodes, recorded separately. After temporary removal at the subgraph projection layer, connected component segmentation is re-performed on the remaining subgraph. If the new component is still greater than K, recursion continues; if the largest component shrinks by less than 10% compared to the previous round, or has reached max_iter, the process terminates early. The residual oversized component flag (oversized_flag) is output as a checklist.

[0140] Phase 2: The Leiden algorithm is executed on the medium-sized components, using the CPM objective function and weight_final as the edge weight, to produce community_id_core. The original small components are directly assigned to community_id_core with cc_id, without running Leiden. Fragments generated by recursive partitioning are not directly treated as communities here, but are processed uniformly in Phase 3.

[0141] Phase 3 (Relocation and Merging): Bridge nodes and fragments will be processed after the core community is determined.

[0142] Bridge Personnel Placement: Calculate the cumulative edge weights of the core communities to which their neighbors belong. If only a single community is associated, directly assign `community_id_attach`. If multiple communities are associated, calculate the weight ratio between the first and second candidate communities. If the ratio is ≥ α, attach to the first candidate community; otherwise, mark `bridge_flag=1`. Bridge personnel are not included in the core community profile and risk score by default.

[0143] Bridging entity processing: It is not forcibly assigned to a single community, but only its bridging mapping relationship with multiple communities is retained. It is used as a bridging resource node for visualization and verification, and is not included in the number of members or risk score of any community.

[0144] Fragmentation Handling: For small fragments generated by recursive segmentation, first determine whether they are genuine small groups that were segmented. Only when the following conditions are met simultaneously: number of character nodes ≥ 3, internal edge density ≥ β × average density of connected core communities, and internal cumulative edge weight / external cumulative edge weight ≥ γ, are they confirmed as independent small communities and assigned a community_id_core. Otherwise, they are merged into the corresponding core community through adjacent bridging nodes according to their cumulative edge weights. If all adjacent bridging nodes of a fragment are bridge_flag=1 or cannot be explicitly merged, mark fragment_flag=1 and output a checklist. Merged fragments are treated as peripheral auxiliary structures and do not increase the risk score of the core community by default.

[0145] The thin event layer feature calculation process is as follows: Based on a thin event layer architecture, starting from the application node and using apply_time as the time anchor, the characteristics of three types of application time points are calculated: Application outbreak characteristics: Statistical analysis of abnormal concentration within the application time window. Specifically, this includes: the number of applications in the past 30 days (apply_cnt_30d), i.e., the number of applications submitted by the same person in the 30 days prior to apply_time; the number of applicants from the same device in the past 7 days (device_apply_persons_7d), i.e., the number of different applicants associated with the same device in the 7 days prior to apply_time, found through the event layer edge "application-device"; and the number of applicants from the same IP address in the past 7 days (ip_apply_persons_7d).

[0146] Packaging contradiction features detect changes and inconsistencies in declared information. Specifically, this includes: the number of declared company changes (declared_company_change_cnt), i.e., the number of different companies listed in different applications by the same person; and the number of inconsistencies in declared companies for the same device (device_company_mismatch_cnt), i.e., the number of different declared companies appearing in different applications linked to the same device. If multiple people apply through the same device but list different companies, it indicates possible that intermediaries have filled out the information on their behalf.

[0147] Application result aggregation features: summarizing the historical application results of neighboring nodes. Specifically, this includes: the number of recent rejections by neighbors (neighbor_reject_cnt), which is the number of recent application rejections among the related individuals found through the main layer relationship; this feature is obtained by aggregating application status information from the event layer.

[0148] All event layer features are calculated at the apply_id granularity, set to the Application node, and exported together with the graph query features and graph pattern features of the main layer for training and inference.

[0149] Reference Figure 6 , the process of graph query features and graph pattern features is as follows: Based on the main layer, taking the application node as the starting point and using app.apply_time as the time anchor, two types of main layer features are calculated: Line A - Graph query features are calculated through graph traversal query, including: the number of risk customers within two hops blacklist_within_2hop, that is, the number of blacklisted persons reachable within 2 hops starting from the current person, which needs to meet the time constraint of edges and the constraint that the first_apply_time of the blacklist is less than app.apply_time; the shortest path distance to the nearest risk customer min_dist_to_blacklist; the number of customers associated with shared devices shared_device_count; the number of customers associated with shared IPs shared_ip_count; the number of customers associated with shared addresses shared_address_count; the number of customers associated with shared companies shared_company_count; the number of risk association dimensions blacklist_link_dimensions, that is, how many dimensions among device, IP, address and company can reach the blacklist.

[0150] Line C - Graph pattern features are calculated through structural pattern matching, including: guarantee loop flag is_in_guarantee_loop, that is, whether the current person is in a loop formed by guarantee relationships; guarantee chain length guarantee_chain_length, that is, the number of hops of the longest guarantee chain where the current person is located; multi-dimensional cross-sharing flag is_in_cross_sharing, that is, whether there are two persons that share entities in multiple dimensions such as device, IP and address at the same time; the number of associated high-risk communities high_risk_community_count, that is, the number of communities where the proportion of blacklists associated within 2 hops of the current person exceeds a threshold.

[0151] All main layer features are also calculated at the apply_id granularity, and SET to the Application node.

[0152] Refer to Figure 7 , after the community results are generated, profile indicators are calculated for the core communities, which at least include: the proportion of high-risk customers in the community community_blacklist_ratio, the recent application burst degree of the community community_apply_burst_7d, the community density community_density, the proportion of recent rejections in the community community_rejected_ratio, and the penetration rate of guarantee relationships in the community community_guarantee_ratio.

[0153] The aforementioned community profile indicators, along with graph query features (Route A), graph pattern features (Route C), event layer features (Route B), basic features, and external features, collectively constitute the input for application-level risk scoring. When exporting features, apply_id is used as the primary key to export all set feature values ​​from the Application node, ensuring consistency in granularity between training and inference.

[0154] Based on the foregoing embodiments, this application provides an event risk assessment device, which includes various units and modules included in each unit. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0155] Figure 8 This is a schematic diagram of the composition structure of an event risk assessment device provided in an embodiment of this application, as shown below. Figure 8 As shown, the event risk assessment device 20 includes: Processing module 201 is used to acquire historical application data and relational data to construct a two-layer heterogeneous graph, wherein the two-layer heterogeneous graph includes a main layer and a thin event layer; Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels; Based on the edge weights, a recursive segmentation operation based on the number of character nodes in each component is performed on the connected components in the main layer to obtain multiple sub-components. For the sub-components that meet the preset size conditions, a community discovery operation is performed to obtain the core community identifier. For nodes that do not participate in community discovery, a homecoming and merging operation is performed to obtain the attached affiliation identifier, bridging marker, and fragment marker. Evaluation module 202 is used to calculate multiple features required for application-level risk scoring based on the application nodes in the thin event layer and the core community identifier, and to generate an application-level risk score based on the multiple features.

[0156] Optionally, the processing module 201 is further configured to: Based on the application record table, the customer basic information table, and external risk data, the main layer and the thin event layer are constructed. The main layer includes person nodes, device nodes, network protocol nodes, address nodes, and organization nodes, and includes person and device edges, person and network protocol edges, person and address edges, person and organization edges, guarantee edges, and social relationship edges. The thin event layer includes application nodes, application phone number nodes, and application email number nodes, and includes person and application edges, application and device edges, application and network protocol edges, application and application phone number edges, application and application organization edges, application and application address edges, and application and application email number edges. Configure the device nodes, network protocol nodes, address nodes, and unit nodes in the thin event layer to share the same physical nodes as the corresponding type of nodes in the main layer.

[0157] Optionally, the processing module 201 is further configured to: For the edges formed by intermediate entities in the main layer, they are bucketed according to the type and degree of the intermediate entities to obtain multiple edge subtypes; Given the risk labels, calculate the pairwise purity enhancement value for each of the edge subtypes; The pairwise purity enhancement value is compared with a preset first threshold to filter out edge types that meet the conditions; For the selected edge types, construct subgraphs and calculate the proportion of giant components under different entity degree thresholds; The entity degree threshold corresponding to the giant component ratio being less than or equal to a preset second threshold is determined as the optimal degree threshold, and the edge subtypes that satisfy the optimal degree threshold are marked as preset high-priority edge positions.

[0158] Optionally, the processing module 201 is further configured to: For a target edge formed by an intermediate entity and belonging to the preset edge level, obtain the risk enhancement value of the target edge and the degree of the intermediate entity; Calculate the logarithm of the risk enhancement value to obtain the first intermediate weight; The attenuation factor is obtained by raising the difference between the degree and the preset first attenuation parameter to the power of the preset second attenuation parameter. Divide the first intermediate weight by the decay factor, compare the result with zero, and take the maximum value of the two as the final edge weight of the target edge.

[0159] Optionally, the processing module 201 is further configured to: Perform connected component partitioning on the input graph to obtain multiple connected components, and count the number of human nodes in each connected component; Connected components whose number of character nodes exceeds a preset threshold for ultra-large components are identified as ultra-large components to be segmented. Cut point detection is performed on the undirected projected subgraph of the large component to be segmented; When a cut point is detected, a preset number of nodes with the highest degree are selected from all detected cut points as bridge candidate nodes. When no cut point is detected, a preset number of nodes with the highest degree are selected from the undirected projection subgraph as alternative cut points. The bridging candidate node or the alternative cut point is temporarily removed from the subgraph, and the connected component splitting is re-performed on the remaining subgraph to obtain new subcomponents.

[0160] Optionally, the processing module 201 is further configured to: After obtaining the core community identifier, the bridging character node is obtained, and the cumulative edge weight of the core community to which all neighbor nodes of the bridging character node belong is calculated. When the bridging character node is associated with only one core community, the bridging character node is attached to the core community, and an attachment affixation identifier is generated; When the bridging character node is associated with multiple core communities, the cumulative edge weight ratio between the first candidate core community and the second candidate core community is calculated; When the cumulative edge weight ratio is greater than or equal to a preset third threshold, the bridging character node is attached to the first candidate core community, and an attachment affixation identifier is generated. When the cumulative edge weight ratio is less than the preset third threshold, a bridging marker is generated for the bridging character node.

[0161] Optionally, the evaluation module 202 is further configured to: Based on the application nodes in the thin event layer, and with the application time as the time anchor, the event layer features are calculated as application outbreak features, packaging contradiction features, and application result aggregation features. Based on the main layer, starting from the application node, the number of risky customers within two hops, the shortest path distance to the nearest risky customer, and the number of risk association dimensions are calculated to obtain graph query features; Based on the main layer, the guarantee loop markers, guarantee chain lengths, and the number of associated high-risk communities are calculated to obtain graph pattern features; Based on the core community identifier, the proportion of high-risk customers within the community, the recent surge in applications within the community, the community density, and the penetration rate of guarantee relationships within the community are calculated to obtain community profile features.

[0162] This application embodiment constructs a two-layer heterogeneous graph and performs data-driven edge layering, recursive segmentation, community detection, and relocation and merging operations. Combined with thin event layer features, it achieves accurate identification and structured interpretation of organized fraud gangs, improves the accuracy of anti-fraud detection, enhances the interpretability of results, and supports automated batch processing.

[0163] The descriptions of the apparatus embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. In some embodiments, the functions or modules included in the apparatus provided in this application can be used to perform the methods described in the method embodiments above. For technical details not disclosed in the apparatus embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0164] It should be noted that, in the embodiments of this application, if the above-mentioned event risk assessment method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0165] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0166] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0167] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0168] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0169] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0170] It should be noted that, Figure 9 This is a schematic diagram of a hardware entity of a computer device in an embodiment of this application, such as... Figure 9 As shown, the hardware entity of the computer device 700 includes: one or more processors 701, a communication interface 702, and a memory 703, wherein: Processor 701 typically controls the overall operation of computer device 700.

[0171] Communication interface 702 enables computer devices to communicate with other terminals or servers over a network.

[0172] The memory 703 is configured to store instructions and applications executable by the processor 701, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data, and video communication data) in the processor 701 and various modules in the computer device 700. It can be implemented using flash memory or random access memory (RAM). Data transfer between the processor 701, the communication interface 702, and the memory 703 can be performed via bus 704. Only one processor is shown in the figure; each processor 701 includes one or more cores.

[0173] It should be noted that the computer device may include multiple processors 701, and each processor 701 can interact with each other through aggregated communication methods such as all-to-all, all-gather, or all-reduce. The processors 701 may be central processing units (CPUs), graphics processing units (GPUs), embedded neural network processing units (NPUs), tensor processing units (TPUs), data processing units (DPUs), accelerated processing units (APUs), floating-point processing units (FPUs), or application-specific integrated circuits (ASICs). The processors may also be single-core or multi-core processors. The processor may consist of a CPU and hardware chips. The hardware chips may be ASICs, PLDs, or combinations thereof. The PLDs may be complex programmable logic devices (CPLDs), FPGAs, generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0174] The communication interface 702 can be a wired interface or a wireless interface, used to communicate with other modules or devices. The wired interface can be an Ethernet interface, a local interconnect network (LIN), etc., and the wireless interface can be a cellular network interface or a wireless LAN interface, etc.

[0175] Memory 703 can be non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 703 can also be volatile memory, which can be random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM), direct rambus DRAM (DRDRAM), and rambus DRAM.

[0176] The 704 bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0177] It should be understood that an embodiment or a particular feature mentioned throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, an embodiment appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0178] It should be noted that, in this document, the terms include, encompass, or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "including a…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0179] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and 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. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0180] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0181] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0182] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0183] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0184] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for event risk assessment, characterized in that, The method includes: A two-layer heterogeneous graph is constructed by acquiring historical application data and relational data, the two-layer heterogeneous graph including a main layer and a thin event layer; Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels; Based on the edge weights, a recursive segmentation operation based on the number of character nodes in each component is performed on the connected components in the main layer to obtain multiple sub-components. For the sub-components that meet the preset size conditions, a community discovery operation is performed to obtain the core community identifier. For nodes that do not participate in community discovery, a homecoming and merging operation is performed to obtain the attached affiliation identifier, bridging marker, and fragment marker. Based on the application nodes in the thin event layer and the core community identifier, various features required for the application-level risk score are calculated, and the application-level risk score is generated based on these features.

2. The method according to claim 1, characterized in that, The process of acquiring historical application data and relational data to construct a two-layer heterogeneous graph includes: Based on the application record table, the customer basic information table, and external risk data, the main layer and the thin event layer are constructed. The main layer includes person nodes, device nodes, network protocol nodes, address nodes, and organization nodes, and includes person and device edges, person and network protocol edges, person and address edges, person and organization edges, guarantee edges, and social relationship edges. The thin event layer includes application nodes, application phone number nodes, and application email number nodes, and includes person and application edges, application and device edges, application and network protocol edges, application and application phone number edges, application and application organization edges, application and application address edges, and application and application email number edges. Configure the device nodes, network protocol nodes, address nodes, and unit nodes in the thin event layer to share the same physical nodes as the corresponding type of nodes in the main layer.

3. The method according to claim 1, characterized in that, The process of performing edge layering on the edges of the main layer results in multiple edge positions, including: For the edges formed by intermediate entities in the main layer, they are bucketed according to the type and degree of the intermediate entities to obtain multiple edge subtypes; Given the risk labels, calculate the pairwise purity enhancement value for each of the edge subtypes; The pairwise purity enhancement value is compared with a preset first threshold to filter out edge types that meet the conditions; For the selected edge types, construct subgraphs and calculate the proportion of giant components under different entity degree thresholds; The entity degree threshold corresponding to the giant component ratio being less than or equal to a preset second threshold is determined as the optimal degree threshold, and the edge subtypes that satisfy the optimal degree threshold are marked as preset high-priority edge positions.

4. The method according to claim 1, characterized in that, The calculation of edge weights for edges belonging to preset edge levels includes: For a target edge formed by an intermediate entity and belonging to the preset edge level, obtain the risk enhancement value of the target edge and the degree of the intermediate entity; Calculate the logarithm of the risk enhancement value to obtain the first intermediate weight; The attenuation factor is obtained by raising the difference between the degree and the preset first attenuation parameter to the power of the preset second attenuation parameter. Divide the first intermediate weight by the decay factor, compare the result with zero, and take the maximum value of the two as the final edge weight of the target edge.

5. The method according to claim 1, characterized in that, The recursive segmentation operation based on the number of character nodes in the connected components of the main layer, based on the edge weights, is performed to obtain multiple sub-components, including: Perform connected component partitioning on the input graph to obtain multiple connected components, and count the number of human nodes in each connected component; Connected components whose number of character nodes exceeds a preset threshold for ultra-large components are identified as ultra-large components to be segmented. Cut point detection is performed on the undirected projected subgraph of the large component to be segmented; When a cut point is detected, a preset number of nodes with the highest degree are selected from all detected cut points as bridge candidate nodes. When no cut point is detected, a preset number of nodes with the highest degree are selected from the undirected projection subgraph as alternative cut points. The bridging candidate node or the alternative cut point is temporarily removed from the subgraph, and the connected component splitting is re-performed on the remaining subgraph to obtain new subcomponents.

6. The method according to claim 5, characterized in that, The process of returning and merging nodes that did not participate in community discovery includes: After obtaining the core community identifier, the bridging character node is obtained, and the cumulative edge weight of the core community to which all neighbor nodes of the bridging character node belong is calculated. When the bridging character node is associated with only one core community, the bridging character node is attached to the core community, and an attachment affixation identifier is generated; When the bridging character node is associated with multiple core communities, the cumulative edge weight ratio between the first candidate core community and the second candidate core community is calculated; When the cumulative edge weight ratio is greater than or equal to a preset third threshold, the bridging character node is attached to the first candidate core community, and an attachment affixation identifier is generated. When the cumulative edge weight ratio is less than the preset third threshold, a bridging marker is generated for the bridging character node.

7. The method according to claim 1, characterized in that, The calculation of application-level risk scores based on application nodes in the thin event layer and the core community identifier includes multiple features, such as: Based on the application nodes in the thin event layer, and with the application time as the time anchor, the event layer features are calculated as application outbreak features, packaging contradiction features, and application result aggregation features. Based on the main layer, starting from the application node, the number of risky customers within two hops, the shortest path distance to the nearest risky customer, and the number of risk association dimensions are calculated to obtain graph query features; Based on the main layer, the guarantee loop markers, guarantee chain lengths, and the number of associated high-risk communities are calculated to obtain graph pattern features; Based on the core community identifier, the proportion of high-risk customers within the community, the recent surge in applications within the community, the community density, and the penetration rate of guarantee relationships within the community are calculated to obtain community profile features.

8. An event risk assessment device, characterized in that, The device includes: The processing module is used to acquire historical application data and relational data to construct a two-layer heterogeneous graph, which includes a main layer and a thin event layer. Perform edge layering operation on the edges in the main layer to obtain multiple edge levels, and calculate the edge weight for the edges belonging to the preset edge levels; Based on the edge weights, a recursive segmentation operation based on the number of character nodes in each component is performed on the connected components in the main layer to obtain multiple sub-components. For the sub-components that meet the preset size conditions, a community discovery operation is performed to obtain the core community identifier. For nodes that do not participate in community discovery, a homecoming and merging operation is performed to obtain the attached affiliation identifier, bridging marker, and fragment marker. The evaluation module is used to calculate multiple features required for the application-level risk score based on the application nodes in the thin event layer and the core community identifier, and to generate the application-level risk score based on the multiple features.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the event risk assessment method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps in the event risk assessment method according to any one of claims 1 to 7.

Images