Risk behavior identification method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a risk behavior recognition method and device, equipment, a storage medium and a program product, and relates to the field of big data. The method comprises the following steps: receiving encrypted entity relationship data uploaded by a plurality of mechanisms; using a federated learning algorithm to generate fusion features of a plurality of pairs of transaction entities according to the encrypted data uploaded by the plurality of mechanisms; constructing a dynamic graph according to the fusion features of the plurality of pairs of transaction entities; dividing the dynamic graph into a plurality of sub-graphs; and identifying risk behaviors existing in each sub-graph. According to the method provided by the invention, by using the federated learning algorithm, the encrypted entity relationship data of the multiple mechanisms are fused, so that cross-mechanism risk behavior identification is effectively realized on the basis of guaranteeing the privacy of the user.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of big data, and in particular to a risk behavior identification method and device, equipment, a storage medium and a program product. BACKGROUND

[0002] With the rapid development of digital finance and e-commerce, the means of implementing risk behaviors on financial systems are also evolving, and risk behaviors are increasingly showing characteristics such as cross-institutional, organized, and concealed. Accurate identification of risk behaviors is of great significance to maintaining the stability of financial systems and protecting asset security, and has become a key problem that needs to be solved urgently.

[0003] Currently, risk identification mainly relies on internal data of each institution for identification. However, due to the fact that the original data in each institution cannot be interchanged with the original data in other institutions, it is difficult to effectively identify cross-institutional and organized risk behaviors, thereby allowing such risk behaviors to spread. SUMMARY

[0004] The present application provides a risk behavior identification method, device, equipment, storage medium and program product, which uploads encrypted entity relationship data by multiple institutions, fuses the data without decrypting the original data, and identifies risk behaviors based on the fused features, thereby significantly improving the identification ability of cross-institutional and organized risk behaviors while ensuring compliance.

[0005] In a first aspect, the present application provides a risk behavior identification method, comprising:

[0006] receiving encrypted entity relationship data uploaded by multiple institutions; the encrypted entity relationship data uploaded by each institution includes at least one piece of encrypted data, and each piece of encrypted data includes two transaction entities that are not encrypted and transaction data between the two transaction entities that is encrypted;

[0007] using a federated learning algorithm to generate fused features of multiple pairs of transaction entities according to each piece of encrypted data uploaded by the multiple institutions; a pair of transaction entities are the two transaction entities in one piece of encrypted data;

[0008] constructing a dynamic graph based on the fused features of the multiple pairs of transaction entities; the dynamic graph takes transaction entities as nodes, and the nodes corresponding to a pair of transaction entities have a connected edge, and the attribute of the edge is determined by the fused features of the pair of transaction entities;

[0009] dividing the dynamic graph into multiple sub-graphs; any node in a sub-graph is connected to at least one other node of the sub-graph through an edge, and is not connected to a node in another sub-graph through an edge;

[0010] identifying risk behaviors existing in each sub-graph.

[0011] In a second aspect, the present application provides a risk behavior identification device, comprising:

[0012] a data receiving module configured to receive encrypted entity relationship data uploaded by a plurality of institutions; each piece of encrypted entity relationship data uploaded by an institution comprises at least one piece of encrypted data, and each piece of encrypted data comprises two transaction entities that are not encrypted and transaction data between the two transaction entities that is encrypted;

[0013] a feature fusion module configured to generate fusion features of a plurality of pairs of transaction entities according to each piece of encrypted data uploaded by the plurality of institutions using a federated learning algorithm; a pair of transaction entities are the two transaction entities in one piece of encrypted data;

[0014] a graph construction module configured to construct a dynamic graph according to the fusion features of the plurality of pairs of transaction entities; the dynamic graph takes transaction entities as nodes, and a pair of transaction entities correspond to nodes that are connected by an edge, and the attribute of the edge is determined by the fusion features of the pair of transaction entities;

[0015] a graph division module configured to divide the dynamic graph into a plurality of sub-graphs; any node in a sub-graph is connected to at least one other node of the sub-graph through an edge, and is not connected to nodes in other sub-graphs through an edge;

[0016] a risk identification module configured to identify risk behaviors existing in each sub-graph.

[0017] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory connected to the processor in communication;

[0018] the memory stores computer execution instructions;

[0019] the processor executes the computer execution instructions stored in the memory to implement the method provided in the first aspect above.

[0020] In a fourth aspect, the present application provides a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are used to implement the method provided in the first aspect above when executed by a processor.

[0021] In a fifth aspect, the present application provides a computer program product, comprising a computer program, and the computer program is used to implement the method provided in the first aspect above when executed by a processor.

[0022] The risk behavior identification method, apparatus, device, storage medium, and program products provided in this application enable the identification of cross-institutional risk behaviors. Specifically, they receive encrypted data between multiple pairs of transaction entities uploaded by multiple institutions. By ensuring that the original data remains within the domain and only encrypted data is transmitted, the privacy and security of the data from multiple institutions are protected, meeting compliance requirements. Through a federated learning algorithm, the data from multiple institutions are integrated, and a cross-institutional, multi-perspective dynamic graph is constructed. This enables the construction of a dynamic graph based on encrypted data, providing a high-quality data foundation for subsequent risk behavior identification. Then, the dynamic graph is divided into multiple sub-graphs, reducing the amount of data to be processed during risk behavior identification and improving processing efficiency. Finally, deep identification of risk behaviors present in each sub-graph enables the effective identification of hidden cross-institutional risk behaviors, improving the detection rate and accuracy of risk behavior identification. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0025] Figure 2 A flowchart illustrating a risk behavior identification method provided in an embodiment of this application;

[0026] Figure 3 This application provides a schematic diagram of the structure of an application system according to an embodiment of the present application.

[0027] Figure 4 A flowchart illustrating another risk behavior identification method provided in this application embodiment;

[0028] Figure 5 A flowchart illustrating another risk behavior identification method provided in this application embodiment;

[0029] Figure 6 This is a schematic diagram of the structure of a risk behavior recognition device provided in an embodiment of this application;

[0030] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0031] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0034] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0035] It should be noted that the risk behavior identification method, device, equipment, storage medium and program products provided in this application can be used in the field of big data, or in any field other than big data. The application field of the risk behavior identification method, device, equipment, storage medium and program products in this application is not limited.

[0036] Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. This application is applied to a scenario involving risk identification and control of user transaction behavior within an institution. The institution can be a banking financial institution, or other institutions such as e-commerce platforms. Figure 1 As shown, Figure 1 Take banking and financial institutions as an example. Figure 1The example illustrates three transactions: User 1 transferring funds from bank A to User 2, User 2 transferring funds from bank B to User 3, and User 3 transferring funds from bank C to User 1. To ensure the stability and security of funds within banking institutions and to prevent fraud, each banking institution must conduct risk identification for each transaction (such as User 1 transferring funds to User 2, User 2 transferring funds to User 3, and User 3 transferring funds to User 1). Upon identifying risky transactions, they must manage both the identified risky transactions and the users who committed them.

[0037] Currently, the main method of risk identification is for each institution to identify the risks of transactions that occur within the institution based on its internal data and risk lists shared by multiple institutions. For example, bank financial institution A identifies the risk of a transaction in which user 1 transfers money to user 2, bank financial institution B identifies the risk of a transaction in which user 2 transfers money to user 3, and bank financial institution C identifies the risk of a transaction in which user 3 transfers money to user 1.

[0038] However, there is a growing number of cross-institutional, organized, and covert risk behaviors, which are fraudulent activities carried out collaboratively by multiple members, often involving the transfer of funds or fictitious transactions through multiple accounts, devices, and institutions. For cross-institutional, organized, and covert risk behaviors, a single institution cannot effectively identify such behaviors based solely on its internal data.

[0039] The risk behavior identification method provided in this application aims to solve the above-mentioned technical problems. Specifically, it receives encrypted data uploaded by multiple institutions, and by aggregating the encrypted data from multiple institutions, it overcomes the problem of being able to identify risks based solely on the internal data of each institution while protecting the privacy of the original data. A federated learning algorithm is used to identify the encrypted data, thereby generating fusion features for each pair of transaction entities in an encrypted state. The fusion features of each pair of transaction entities integrate data from multiple institutions, realizing data association among multiple institutions. Based on the fusion features, a dynamic graph can be constructed, which can represent the transaction behavior of transaction entities within multiple institutions. Finally, by identifying the risk behaviors present in the sub-graphs formed by connected transaction entities in the dynamic graph, cross-institutional risk behavior identification can be achieved, improving the detection rate of risk behavior identification.

[0040] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0041] Figure 2This is a flowchart illustrating a risk behavior identification method provided in an embodiment of this application. The risk behavior identification method provided in this embodiment can be executed by an electronic device with corresponding processing capabilities, including a server. Figure 2 As shown, the method provided in this embodiment includes the following steps:

[0042] Step S201: Receive encrypted entity relationship data uploaded by multiple institutions.

[0043] In this application, "institution" refers to an organization or system that can provide financial services, such as... Figure 1 Banking institutions A through C are listed in the table. Entity relationship data refers to the records kept by each institution when a transaction occurs within that institution. Each record includes at least one entry for each transaction involving two entities and the transaction details between those entities. Transaction entities are the parties involved in the transaction, including users (such as...). Figure 1 (Users 1 to 3 in the data). Transaction data is the core information of transaction behavior, including but not limited to transaction time, transaction frequency, and transaction amount.

[0044] In some embodiments, the transaction entity also includes a device that performs the transaction. If a transaction entity in a data entry includes a device, then the transaction data in that data entry includes, but is not limited to, device usage time and device usage frequency.

[0045] For example, if user 1 uses device 1 to transfer money to user 2, the entity relationship data includes at least two data entries. The two transaction entities in these two data entries can be user 1 and user 2, and user 1 and device 1, respectively. The transaction data between user 1 and user 2 includes the time of transfer, the frequency of transfer, and the amount of transfer. The transaction data between user 1 and device 1 includes the time of device use and the frequency of device use.

[0046] Encrypted entity relationship data refers to data obtained by various organizations using predefined encryption algorithms to encrypt entity relationship data in order to ensure its privacy and security. These encryption algorithms include homomorphic encryption algorithms and secure multi-party computation algorithms. Encrypted entity relationship data obtained through these algorithms can be directly processed without decryption, and the decrypted result is completely identical to the result of performing the same operation directly on the original data.

[0047] In this application, the encrypted entity relationship data uploaded by each institution includes at least one encrypted data entry. Each encrypted data entry includes two unencrypted transaction entities and the encrypted transaction data between the two transaction entities. In other words, each institution encrypts at least one data entry from its internal entity relationship data to obtain at least one encrypted data entry. Specifically, the encryption method involves encrypting only the transaction data within the data to prevent transaction data leakage.

[0048] Figure 3 This is a schematic diagram of the structure of an application system provided in an embodiment of this application. For example... Figure 3 As shown, the application system includes a server and multiple institutions (Institution 1 to Institution 3). The server is used to implement the risk behavior identification method provided in this application. The server communicates with the multiple institutions. Specifically, the server has multiple ports, each port being connected to the ports of the multiple institutions to receive encrypted entity relationship data uploaded by each institution through the connected ports.

[0049] In practice, each institution encrypts the transaction relationship data generated within a preset period to obtain encrypted entity relationship data, and then uploads the encrypted entity relationship data to the server through the connected port.

[0050] Step S202: Using a federated learning algorithm, generate fusion features of multiple pairs of transaction entities based on the encrypted data uploaded by multiple institutions.

[0051] In this context, a pair of transaction entities refers to two transaction entities within a single encrypted data entry.

[0052] Federated Learning (FL) is a distributed machine learning paradigm. Through federated learning, multiple organizations can collaborate to achieve global optimization without leaving their original data (entity relationship data) locally. This fundamentally resolves the conflict between data silos and privacy protection within a single organization, thus meeting data privacy and compliance requirements. In this application, Figure 3 The servers in the database are federated learning-based servers.

[0053] Federated learning algorithms are technical means that support federated learning and are used to solve core problems such as privacy and security protection, heterogeneous client adaptation, and model accuracy balance.

[0054] Multiple encrypted data entries from various institutions may exist between the same pair of trading entities. These encrypted data entries need to be merged to represent the global trading relationship between the pair of entities. The merged feature, also known as the Federated Relation Fusion Feature, refers to the feature obtained by fusing encrypted entity relationship data from multiple institutions using a federated learning algorithm without sharing the original data.

[0055] Specifically, without decrypting the encrypted entity relationship data, the server uses federated learning algorithms (such as weighted average in encrypted state, fusion algorithm based on attention mechanism) on the encrypted data uploaded by multiple institutions to generate fusion features for each pair of transaction entities.

[0056] Step S203: Construct a dynamic graph based on the fusion characteristics of multiple pairs of transaction entities.

[0057] A dynamic graph is a knowledge graph (KG), specifically a structured semantic network. It abstracts transaction entities as nodes in the dynamic graph and the relationships between transaction entities as edges, ultimately forming a semantic data model that supports reasoning about complex transaction relationships.

[0058] Specifically, the dynamic graph uses transaction entities as nodes, and the attributes of a node can be the identifier of the corresponding transaction entity, such as user ID and device ID. There are connecting edges between nodes corresponding to a pair of transaction entities, and the attributes of the edges are determined by the fusion features of the pair of transaction entities.

[0059] For example, a dynamic graph is constructed based on the transaction entities and fusion features corresponding to the fusion features of multiple pairs of transaction entities. In the dynamic graph, each node corresponds to each transaction entity, and the attributes of the edges can be the fusion features of the connected transaction entities.

[0060] One way to construct a dynamic graph is to identify the trading entities corresponding to the fusion characteristics and add nodes corresponding to these entities to the dynamic graph. If there are fusion characteristics between two trading entities, a directed edge is added between them, with the direction of the edge indicating the flow of funds in the trading activity.

[0061] In some embodiments, if a pair of related transaction entities includes a device and a user, an undirected edge can be added between the transaction entities, or a directed edge can be added according to preset rules. For example, if a user uses a device to perform a transaction, the direction of the edge can be set to point from the user node to the device node.

[0062] Optionally, the method provided in this embodiment further includes: receiving newly added encrypted entity relationship data uploaded by various institutions within a preset period; using a federated learning algorithm to generate new fusion features of multiple pairs of transaction entities based on each encrypted data in the newly added encrypted entity relationship data; and updating the dynamic graph based on the new fusion features.

[0063] The preset period is a pre-set configurable parameter, such as 1 day, 2 days, etc.

[0064] The newly added encrypted entity relationship data is generated by each organization encrypting newly generated entity relationship data within a preset period. The newly added encrypted entity relationship data includes at least one newly added encrypted data entry.

[0065] The server periodically receives newly added encrypted entity relationship data uploaded by various institutions within a preset period, and generates new fusion features for multiple pairs of transaction entities according to step S202. Based on the dynamic graph of the previous preset period, the dynamic graph of the previous preset period is updated according to the new fusion features.

[0066] If the newly added fusion feature includes a newly added trading entity, then the node corresponding to that trading entity is added to the dynamic graph of the previous preset period, and the edges between multiple pairs of trading entities are updated. The attributes of the edges are determined based on the newly added fusion feature and the fusion feature of the previous preset period. If the newly added fusion feature does not include a newly added trading entity, then only the edges between multiple pairs of trading entities in the dynamic graph of the previous preset period are updated. The attributes of the edges are determined based on the newly added fusion feature and the fusion feature of the previous preset period.

[0067] In this embodiment, the structure of the dynamic graph, such as nodes and edges, can be incrementally updated and evolved based on the newly added entity relationship data uploaded by each institution. The resulting dynamic graph can respond to dynamically changing transaction relationships, and the dynamic graph has higher timeliness.

[0068] Step S204: Divide the dynamic map into multiple sub-maps.

[0069] Any node in a subgraph is connected to at least one other node in the subgraph via an edge, but is not connected to any other node in the subgraph via an edge.

[0070] Ignoring the direction of edges in the dynamic graph, traverse the dynamic graph, identify weakly connected components in the dynamic graph, and divide the dynamic graph into multiple independent subgraphs.

[0071] Within a weakly connected component, any two nodes are directly connected or indirectly connected (e.g., connected through other nodes), while no two weakly connected components are connected by any other node. Weakly Connected Components (WCC) algorithms are used to identify weakly connected components in dynamic graphs, including algorithms based on depth-first search and breadth-first search.

[0072] For example, if user 1 is associated with user 2, user 2 is associated with user 3, and user 1, user 2, and user 3 are not associated with other transaction entities, then user 1-user 2-user 3 is an independent link, and user 1, user 2, user 3 and their connected edges can be divided into a subgraph.

[0073] By dividing a dynamic graph containing a massive number of nodes into multiple independent subgraphs, the associated transaction entities are initially screened. Subsequent processing of each subgraph can then avoid the enormous computational burden caused by directly processing the dynamic graph. Furthermore, by traversing the dynamic graph, the resulting subgraphs avoid overlooking scattered but related transaction entities, ensuring the accuracy of risk identification through subgraphs.

[0074] Step S205: Identify the risky behaviors present in each sub-map.

[0075] Risky behavior refers to trading activities that may threaten an institution's stability or financial security.

[0076] In some embodiments, features can be extracted in advance for known risk behaviors, such as extracting link features and edge attribute features from historical subgraphs of the risk behavior. If the attributes of links and edges within the subgraph match the features of known risk behaviors, then it is determined that the subgraph contains the risk behavior.

[0077] Known risky behaviors may include circular transfers, linking multiple users to the same device, high-frequency small-amount transactions, and rapid dispersion and aggregation of funds.

[0078] For example, the similarity between the attributes of links and edges within a subgraph and the features of known risky behaviors is calculated; if the similarity is greater than or equal to a preset similarity threshold, it is determined that the subgraph contains the risky behavior.

[0079] In other embodiments, a subgraph isomorphism algorithm can be used to match each subgraph with predefined risk behavior features; if a predefined risk behavior feature is matched, it is determined that there is a predefined risk behavior among the trading entities within that subgraph.

[0080] If a risky behavior is identified in a subgraph, the server can send the transaction entity within the subgraph and the corresponding risky behavior to the institution that has the transaction entity, so that the institution can process and control the transaction entity.

[0081] The risk behavior identification method provided in this embodiment enables the identification of cross-institutional risk behaviors. Specifically, it receives encrypted data between multiple pairs of transaction entities uploaded by multiple institutions. By ensuring that the original data does not leave the domain and only the encrypted data is transmitted, the privacy and security of the data of multiple institutions are protected, meeting compliance requirements. Through a federated learning algorithm, the data from multiple institutions are merged to construct a cross-institutional, global dynamic graph. This enables the construction of a dynamic graph based on encrypted data, providing a high-quality data foundation for subsequent risk behavior identification. Then, the dynamic graph is divided into multiple sub-graphs to reduce the amount of data to be processed during risk behavior identification and improve processing efficiency. Finally, deep identification of risk behaviors existing in each sub-graph enables the effective identification of hidden cross-institutional risk behaviors, improving the detection rate and accuracy of risk behavior identification.

[0082] In one possible implementation, step S205, identifying risky behaviors in each subgraph, includes: for each subgraph, identifying whether a target link exists in the subgraph; if so, determining whether the transaction entity corresponding to the target link has risky behaviors based on the attributes of the edges between nodes in the target link.

[0083] In real-world scenarios, different risk behaviors often manifest as typical links in the graph. Target links are pre-defined typical links exhibiting risk behaviors, including but not limited to loop links and distributed-aggregated links.

[0084] For each subgraph, identify the links existing in each subgraph. If an existing link includes a target link, further determine whether the attributes of the edges between nodes in the target link of the subgraph meet preset conditions. If they do, determine that the transaction entity corresponding to the target link exhibits the risk behavior corresponding to the target link. The preset conditions are the typical characteristics of the edge attributes manifested by each risk behavior in the target link.

[0085] For example, connectivity and path tracing algorithms can be used to effectively identify whether a target link exists in each sub-graph.

[0086] By first identifying whether a target link exists in the subgraph, and then determining whether there is risky behavior based on the attributes of the edges, this method is logically clear, easy to implement, and highly interpretable compared to identifying the entire subgraph.

[0087] Optionally, the target link includes a ring link, which includes multiple nodes connected in sequence, with the starting node and the ending node being the same node; the risk behavior corresponding to the ring link is the cyclical transaction risk behavior.

[0088] In financial transaction scenarios, circular transaction risk refers to the risky behavior of multiple members using closed-loop transaction flows to fabricate business backgrounds, inflate transaction scale, or obtain financial resources. The core characteristic of this risky behavior is the circulation of funds within a fixed trading entity without any actual demand support, which is often represented as a strongly connected loop in the transaction graph.

[0089] In this embodiment, the nodes and edges in the ring link form a closed ring. For example, User 1-User 2-User 3-User 1 form a ring link, with User 1 and User 3 connected sequentially, and the starting node and ending node are both nodes corresponding to User 1.

[0090] Optionally, the target link includes a decentralized-aggregated link, which includes a first node, a second node, and multiple third nodes. Each third node is connected to the first node and the second node through an edge, while there is no edge connecting the first node and the second node. The risk behavior corresponding to the decentralized-aggregated link is the risk behavior of fund aggregation.

[0091] In financial transactions, fund aggregation risk refers to the rapid dispersion of funds among multiple participants across multiple trading entities within a short period, followed by the aggregation of funds into a single trading entity. This fragmentation and rapid flow of funds conceals the true source and destination of the funds, circumventing regulatory or risk control measures. This risk behavior is often represented in a dispersion-aggregation chain in a financial transaction graph.

[0092] The path characteristics in the distributed-aggregated link are from the first node to the third node to the second node. The number of the first and second nodes is generally one or less, while the number of the third node is multiple.

[0093] By analyzing the typical characteristics of different risk behaviors in the graph, i.e. target links, we first conduct preliminary screening of risk behaviors based on the target links to quickly identify the range of links with potential risks. Then, based on the attributes of the edges between nodes in the target links, we conduct refined identification of risk behaviors and finally accurately locate the risk behaviors.

[0094] Figure 4 This is a flowchart illustrating another risk behavior identification method provided in this application embodiment. The method provided in this embodiment is... Figure 2 Based on the illustrated embodiment, step S205 is implemented using a machine learning model, and step S202 is refined. Furthermore, a step for processing the sub-map is added. For example... Figure 4As shown, the method provided in this embodiment includes the following steps:

[0095] Step S401: Receive encrypted entity relationship data uploaded by multiple institutions.

[0096] Step S402: Extract multiple encrypted data corresponding to the same pair of transaction entities from the encrypted data uploaded by multiple institutions.

[0097] In this step, encrypted data corresponding to multiple transactions of the same pair of trading entities is filtered from multiple encrypted data uploaded by multiple institutions.

[0098] In practice, the two transaction entities included in each encrypted data entry are extracted, and a search is performed among multiple encrypted data entries. Encrypted data entries containing the same two transaction entities are identified as belonging to the same pair of transaction entities.

[0099] Step S403: For each encrypted data in the multiple encrypted data, determine the weight of each encrypted data according to the institution corresponding to each encrypted data and the data type of the original data corresponding to each encrypted data.

[0100] The original data corresponding to the encrypted data is the unencrypted initial data within the organization. The data type of the original data is classified according to the information attributes it carries, the generation scenario, or the business purpose, such as transaction data (e.g., transfer amount) and behavioral data (e.g., device usage records).

[0101] In scenarios involving collaborative processing of encrypted data uploaded by multiple institutions, the contribution of different types of encrypted data to the fused features varies. Applying equal weights to all encrypted data directly might reduce the representativeness of the fused features and dilute effective information. This embodiment addresses this issue by providing a dynamic weight adjustment strategy to achieve rational weighting.

[0102] For each encrypted data entry from multiple encrypted data entries of the same pair of transaction entities that need to be merged, determine the institution corresponding to each encrypted data entry and obtain the data type of the original data corresponding to that encrypted data uploaded by the institution. Based on the institution and data type, determine the weight of each encrypted data entry.

[0103] In one example, the weights can be determined by pre-setting a correspondence between each organization and data type and its weight. The weight corresponding to that organization and data type is then determined from this pre-set correspondence.

[0104] Step S404: Based on the weights, use a federated learning algorithm to obtain the fusion features of the pair of transaction entities.

[0105] In this embodiment, the federated learning algorithm is a weighted average under encrypted conditions. That is, based on weights, multiple encrypted data of the same pair of transaction entities are weighted and averaged to obtain the fused features of each pair of transaction entities.

[0106] Step S405: Construct a dynamic graph based on the fusion characteristics of multiple pairs of transaction entities.

[0107] Step S406: Divide the dynamic map into multiple sub-maps.

[0108] Step S407: For each subgraph, determine the association strength of the edges in the subgraph based on the attributes of the edges between nodes in the subgraph.

[0109] Association strength is a numerical indicator quantified based on the attributes of the edges.

[0110] In this step, for each subgraph, the correlation strength of each edge is quantified based on the various indicators in the attributes of all edges in the subgraph.

[0111] For example, each attribute of all edges in the subgraph is quantified into a single value, and then these values ​​are weighted to obtain the association strength. For instance, transaction frequency, transaction time, and transaction amount are quantified as a1, a2, and a3, respectively. Ultimately, the association strength = a1. w1+a2 w2+a3 w3. Where w1, w2, and w3 are pre-set weight values.

[0112] Step S408: Delete edges with association strength lower than the preset strength to obtain the intermediate subgraph.

[0113] The edge strength is a preset configurable parameter. If the association strength is lower than the preset strength, it indicates a weak relationship between the two transaction entities connected by the edge, and can be ignored. Therefore, edges with association strengths lower than the preset strength are deleted from the subgraph to obtain an intermediate subgraph.

[0114] In this embodiment, the link strength filtering algorithm can be used to delete edges whose association strength is lower than a preset strength.

[0115] Step S409: Delete isolated nodes or links in the intermediate subgraph to obtain the processed subgraph, so as to identify the risky behaviors present in the processed subgraph.

[0116] After deleting edges with low association strength, there may be isolated nodes or links in the subgraph, that is, the node or link has no edge connection to other nodes in the subgraph. Deleting the isolated nodes or links from the subgraph yields the processed subgraph.

[0117] Step S410: For each subgraph, input the subgraph into the pre-trained risk identification model, and the risk identification model outputs the risk behaviors in the subgraph and their corresponding transaction entities.

[0118] A pre-trained risk identification model is a type of machine learning model. By training the risk identification model, the machine learning model can learn the topology, link and node characteristics within a subgraph, and finally combine rules to comprehensively determine whether there is risky behavior within the subgraph.

[0119] The training samples used during the training of the risk identification model include positive samples and negative samples. Negative samples include the first type of samples, where the sub-graph corresponding to the first type of samples contains a target link and the risk behavior label is consistent with the risk behavior corresponding to the target link. The sub-graph corresponding to the positive samples does not contain a target link, or it contains a target link and the risk behavior label indicates that the target link does not contain a risk behavior.

[0120] By training the risk identification model using negative samples, the model can learn the characteristics of risky behaviors within the subgraph. Then, after inputting the subgraph into the pre-trained risk identification model, the model can analyze the subgraph. If it identifies a characteristic of a risky behavior within the subgraph, the model outputs that risky behavior and the corresponding transaction entity.

[0121] Optionally, the target links existing in the sub-map corresponding to the first type of sample include the loop links and / or scatter-aggregate links in the above embodiments.

[0122] Optionally, negative samples also include a second type of sample, in which the subgraph corresponding to the second type of sample contains target nodes with a transaction frequency greater than the preset frequency and a transaction amount less than the preset amount within a preset time period, and the risk behavior label corresponding to the first type of sample is high-frequency small-amount risk behavior.

[0123] In addition to the risk behaviors provided in the above embodiments, risk behaviors also include high-frequency, low-amount risk behaviors.

[0124] High-frequency, low-amount risky behavior refers to a trading entity initiating multiple small transactions within a preset time period (such as minutes or hours). This behavior deviates from normal business logic, implies risks to fund security, or is suspected of being illegal.

[0125] The preset time, preset frequency, and preset amount are configurable parameters that can be set in advance. For example, the preset time can be 1 hour, the preset frequency can be 5 times / hour, and the preset amount can be 5000 yuan.

[0126] If a trading entity (i.e., the target node) has a trading frequency greater than a preset frequency and a trading amount less than a preset amount within a preset time period, then this trading entity may be engaging in high-frequency, low-amount risky behavior. By using the subgraph containing the target node as negative samples, the risk identification model can learn the characteristics of high-frequency, low-amount risky behavior, enabling the model to identify this type of risky behavior.

[0127] By adding negative samples corresponding to high-frequency, low-value risk behaviors, the risk identification model's sample is made more comprehensive. By learning from the more comprehensive sample, the risk identification model's identification ability is improved.

[0128] In this embodiment, by leveraging the powerful learning and recognition capabilities of machine learning models to identify risky behaviors, the detection rate and accuracy of risky behavior identification can be improved. Furthermore, by deleting weakly connected edges and nodes in the subgraph, strong connections are established between nodes within the processed subgraph, simplifying the subgraph and eliminating a large number of irrelevant nodes, thus making the organized multi-member structure clearer. Simultaneously, by performing a weighted average based on dynamic weights on encrypted data from different institutions and of different data types, differentiated processing of encrypted data is achieved, improving the accuracy of cross-institutional collaborative processing.

[0129] In one possible implementation, to avoid consuming significant computational resources due to frequent risk behavior identification, this application also proposes a rule-based risk behavior identification method. Specifically, subsequent operations are performed only when the sub-graph or the processed sub-graph meets preset conditions.

[0130] Figure 5 This is a flowchart illustrating another risk behavior identification method provided in this application. The method provided in this embodiment only performs subsequent operations when the sub-map or the processed sub-map meets preset conditions. For example... Figure 5 As shown, the method provided in this embodiment, after constructing a dynamic graph, includes the following risk behavior identification method:

[0131] Step S501: Divide the dynamic map into multiple sub-maps.

[0132] In this step, weakly connected components are identified using a weakly connected component algorithm; and the dynamic graph is divided into multiple sub-graphs based on the weakly connected components.

[0133] Step S502: Determine whether the sub-map meets the first condition; if it does, proceed to step S503; if it does not, terminate the risk behavior identification method.

[0134] In this step, if the sub-graph contains complex connections, i.e., a large scale (e.g., more than n1 transaction entities), then this method is used to identify risky behaviors, i.e., step S503 is executed. If the connections are simple, i.e., fewer than or equal to n1 transaction entities, then the probability of risky behaviors is low, and risky behavior identification is not continued.

[0135] In some embodiments, a risk list shared by multiple institutions may also be introduced. If there are more than n1 transaction entities and the proportion of transaction entities on the risk list is greater than a first preset proportion, then step S503 is executed.

[0136] Step S503: For each subgraph, determine the association strength of the edges in the subgraph based on the attributes of the edges between nodes in the subgraph.

[0137] Step S504: Delete edges with association strength lower than the preset strength to obtain the intermediate subgraph.

[0138] In this step, based on the Link Strength Filtering algorithm, edges with association strength lower than a preset strength are deleted to obtain an intermediate subgraph.

[0139] Step S505: Delete isolated nodes or links in the intermediate subgraph to obtain the processed subgraph, and identify the risky behaviors present in the processed subgraph.

[0140] Step S506: Determine whether the processed sub-map meets the second condition; if it does, proceed to step S507; if it does not, terminate the risk behavior identification method.

[0141] This step is similar to step S502. If the processed subgraph contains complex connections, i.e., a large scale (e.g., more than n² transaction entities), then this method is used to identify risky behaviors, i.e., step S507 is executed. If the connections are simple, i.e., fewer than or equal to n² transaction entities, then the probability of risky behaviors is low, and risky behavior identification is not continued.

[0142] In some embodiments, a risk list shared by multiple institutions may also be introduced. If there are more than n² transaction entities and the proportion of transaction entities on the risk list is greater than a second preset proportion, then step S507 is executed.

[0143] Step S507: Identify the risky behaviors present in each sub-map.

[0144] In this step, the connectivity and path tracing algorithm is used to effectively identify whether there is a target link in each subgraph. Then, based on the attributes of the edges between nodes in the target link, it is determined whether the transaction entity corresponding to the target link has the risk behavior corresponding to the target link.

[0145] The risk behavior identification method provided in this application has similar technical effects to the method provided in any of the above embodiments of this application, and will not be described again here.

[0146] Figure 6 This is a schematic diagram of a risk behavior recognition device provided in an embodiment of this application. Figure 6 As shown, the risk behavior identification device provided in this embodiment includes a data receiving module 601, a feature fusion module 602, a map construction module 603, a map segmentation module 604, and a risk identification module 605.

[0147] The data receiving module 601 is used to receive encrypted entity relationship data uploaded by multiple institutions; the encrypted entity relationship data uploaded by each institution includes at least one piece of encrypted data, and each piece of encrypted data includes two unencrypted transaction entities and encrypted transaction data between the two transaction entities;

[0148] The feature fusion module 602 is used to generate fusion features of multiple pairs of transaction entities based on encrypted data uploaded by multiple institutions using a federated learning algorithm; a pair of transaction entities refers to two transaction entities in a single encrypted data set. The graph construction module 603 is used to construct a dynamic graph based on the fusion features of multiple pairs of transaction entities; the dynamic graph uses transaction entities as nodes, and nodes corresponding to a pair of transaction entities are connected by edges, the attributes of which are determined by the fusion features of the pair of transaction entities. The graph partitioning module 604 is used to divide the dynamic graph into multiple subgraphs; any node in a subgraph is connected to at least one other node in the subgraph by an edge, but not connected to any other node in the subgraph by an edge. The risk identification module 605 is used to identify risky behaviors present in each subgraph.

[0149] Optional, the risk identification module 605 is specifically used for:

[0150] For each subgraph, identify whether a target link exists in the subgraph; if so, determine whether the transaction entity corresponding to the target link has the risk behavior corresponding to the target link based on the attributes of the edges between nodes in the target link.

[0151] Optional, the risk identification module 605 is specifically used for:

[0152] For each subgraph, the subgraph is input into a pre-trained risk identification model, which outputs the risk behaviors in the subgraph and their corresponding transaction entities. The training samples used during the training of the risk identification model include positive samples and negative samples. Negative samples include the first type of samples, where the subgraph corresponding to the first type of samples contains a target link and the risk behavior label is consistent with the risk behavior corresponding to the target link. The subgraph corresponding to the positive samples either does not contain a target link or contains a target link and the risk behavior label indicates that the target link does not contain any risk behavior.

[0153] Optionally, the target link includes a ring link, which includes multiple nodes connected in sequence, with the starting node and the ending node being the same node; the risk behavior corresponding to the ring link is the cyclical transaction risk behavior.

[0154] Optionally, the target link includes a decentralized-aggregated link, which includes a first node, a second node, and multiple third nodes. Each third node is connected to the first node and the second node through an edge, while there is no edge connecting the first node and the second node. The risk behavior corresponding to the decentralized-aggregated link is the risk behavior of fund aggregation.

[0155] Optionally, negative samples also include a second type of sample, in which the subgraph corresponding to the second type of sample contains target nodes with a transaction frequency greater than the preset frequency and a transaction amount less than the preset amount within a preset time period, and the risk behavior label and high-frequency small-amount risk behavior corresponding to the first type of sample.

[0156] Optionally, the feature fusion module 602 is specifically used for:

[0157] Multiple encrypted data entries corresponding to the same pair of transaction entities are extracted from various encrypted data entries uploaded by multiple institutions. For each encrypted data entry, the weight of each encrypted data entry is determined according to the institution corresponding to each encrypted data entry and the data type of the original data corresponding to each encrypted data entry. Based on the weights, a federated learning algorithm is used to obtain the fusion features of the pair of transaction entities.

[0158] Optionally, the risk behavior identification device further includes a sub-map processing module for:

[0159] For each subgraph, the association strength of the edges in the subgraph is determined based on the attributes of the edges between nodes in the subgraph; edges with association strength lower than the preset strength are deleted to obtain an intermediate subgraph; isolated nodes or links in the intermediate subgraph are deleted to obtain the processed subgraph, so as to identify the risky behaviors in the processed subgraph.

[0160] Optionally, the risk behavior identification device also includes a dynamic map update module, used for:

[0161] According to a preset cycle, the system receives newly added encrypted entity relationship data uploaded by various institutions within the preset cycle; using a federated learning algorithm, it generates new fusion features for multiple pairs of transaction entities based on each encrypted data entry in the newly added encrypted entity relationship data; and updates the dynamic graph based on the new fusion features.

[0162] The risk behavior recognition device provided in this application can be used to execute the risk behavior recognition method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0163] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device of this embodiment may include: at least one processor 701; and a memory 702 communicatively connected to at least one processor; wherein the memory 702 stores instructions that can be executed by at least one processor 701, and the instructions are executed by at least one processor 701 to cause the electronic device to perform the method as described in any of the above embodiments.

[0164] Optionally, the memory 702 can be either standalone or integrated with the processor 701. When the memory 702 is set up independently, the device also includes a bus for connecting the memory 702 and the processor 701.

[0165] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0166] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

[0167] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0168] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0169] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0170] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0171] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0172] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0173] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0174] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0175] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0176] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for identifying risky behaviors, characterized in that, include: Receive encrypted entity relationship data uploaded by multiple institutions; each institution uploads at least one piece of encrypted data, and each piece of encrypted data includes two unencrypted transaction entities and encrypted transaction data between the two transaction entities; Using a federated learning algorithm, multiple pairs of transaction entity fusion features are generated based on the encrypted data uploaded by the multiple institutions. A pair of transaction entities refers to two transaction entities within a single encrypted data entry. A dynamic graph is constructed based on the fusion characteristics of the multiple pairs of transaction entities; the dynamic graph uses the transaction entities as nodes, and there are connecting edges between the nodes corresponding to a pair of transaction entities, the attributes of which are determined by the fusion characteristics of the pair of transaction entities. The dynamic graph is divided into multiple subgraphs; any node in a subgraph is connected to at least one other node in the subgraph via an edge, but is not connected to any other node in the subgraph via an edge. Identify the risky behaviors present in each of the sub-maps.

2. The method according to claim 1, characterized in that, The identification of risky behaviors in each of the sub-maps includes: For each of the sub-maps, identify whether a target link exists in the sub-map; If so, then based on the attributes of the edges between nodes in the target link, determine whether the transaction entity corresponding to the target link has any risky behavior corresponding to the target link.

3. The method according to claim 1, characterized in that, The identification of risky behaviors in each of the sub-maps includes: For each of the subgraphs, the subgraphs are input into a pre-trained risk identification model, and the risk identification model outputs the risk behaviors in the subgraphs and their corresponding transaction entities. The training samples used during the training of the risk identification model include positive samples and negative samples. The negative samples include a first type of sample, in which the sub-graph corresponding to the first type of sample contains a target link and the risk behavior label is consistent with the risk behavior corresponding to the target link. The sub-graph corresponding to the positive sample does not contain a target link, or contains a target link and the risk behavior label indicates that the target link does not contain a risk behavior.

4. The method according to claim 2 or 3, characterized in that, The target link includes a ring link, which includes multiple nodes connected in sequence, with the starting node and the ending node being the same node; the risk behavior corresponding to the ring link is the cyclical transaction risk behavior.

5. The method according to claim 2 or 3, characterized in that, The target link includes a distributed-aggregated link, which includes a first node, a second node, and multiple third nodes. Each third node is connected to the first node and the second node through an edge, and there is no edge connecting the first node and the second node. The risk behavior corresponding to the decentralized-aggregated link is the risk behavior of fund aggregation.

6. The method according to claim 3, characterized in that, The negative samples also include a second type of samples. In the subgraph corresponding to the second type of samples, there are target nodes with a transaction frequency greater than a preset frequency and a transaction amount less than a preset amount within a preset time period. The risk behavior label corresponding to the second type of samples is high-frequency low-amount risk behavior.

7. The method according to any one of claims 1-3, characterized in that, The method uses a federated learning algorithm to generate fusion features for multiple pairs of transaction entities based on the encrypted data uploaded by the multiple institutions, including: Extract multiple encrypted data entries corresponding to the same pair of transaction entities from the encrypted data entries uploaded by the aforementioned multiple institutions; For each encrypted data item among the multiple encrypted data items, the weight of each encrypted data item is determined based on the organization corresponding to each encrypted data item and the data type of the original data corresponding to each encrypted data item. Based on the weights, a federated learning algorithm is used to obtain the fusion features of the pair of transaction entities.

8. The method according to any one of claims 1-3, characterized in that, Prior to identifying the risky behaviors present in each of the sub-maps, the method further includes: For each of the subgraphs, the association strength of the edges in the subgraph is determined based on the attributes of the edges between nodes in the subgraph. Delete the edges whose association strength is lower than the preset strength to obtain the intermediate subgraph; Isolated nodes or links in the intermediate subgraph are deleted to obtain a processed subgraph, which is then used to identify risky behaviors present in the processed subgraph.

9. The method according to any one of claims 1-3, characterized in that, The method further includes: According to a preset period, receive newly added encrypted entity relationship data uploaded by each of the aforementioned institutions within the preset period; Using a federated learning algorithm, new fusion features for multiple pairs of transaction entities are generated based on each encrypted data entry of the newly added encrypted entity relationship data. The dynamic map is updated based on the newly added fusion features.

10. A risk behavior identification device, characterized in that, include: A data receiving module is used to receive encrypted entity relationship data uploaded by multiple institutions; each encrypted entity relationship data uploaded by the institution includes at least one piece of encrypted data, and each piece of encrypted data includes two unencrypted transaction entities and encrypted transaction data between the two transaction entities; The feature fusion module is used to generate fused features of multiple pairs of transaction entities based on the encrypted data uploaded by the multiple institutions using a federated learning algorithm. A pair of transaction entities refers to two transaction entities within a single encrypted data entry. The graph construction module is used to construct a dynamic graph based on the fusion characteristics of the multiple pairs of transaction entities. The dynamic graph uses the transaction entities as nodes, and there are connecting edges between the nodes corresponding to a pair of transaction entities. The attributes of the edges are determined by the fusion characteristics of the pair of transaction entities. The graph partitioning module is used to divide the dynamic graph into multiple subgraphs; any node in a subgraph is connected to at least one other node in the subgraph through an edge, but is not connected to any other node in the subgraph through an edge. The risk identification module is used to identify risky behaviors present in each of the sub-graphies.

11. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

Images