Suspicious account identification method, system, device, storage medium and program product

Abstract

The present application relates to a suspicious account identification method, system, device, storage medium and program product. The method comprises: obtaining transaction data and determining risk data in the transaction data; extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship and a transaction time, and the transaction entity identifier at least includes an account identifier; when identifying a suspicious account, first determine the target account identifier to be identified, determine a transaction clue graph with the target account identifier as an index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph. The method can utilize the entity and relationship characteristics unique to the knowledge graph to mine suspicious clues and their invisible associations in the transaction event data, improve the accuracy and reliability of suspicious account identification, and also improve the work efficiency of the staff.

Description

Technical Field

[0001] The present application relates to the field of big data technology, and in particular to a suspicious account identification method, system, device, storage medium and program product. Background Art

[0002] Money laundering is the act of converting funds from illegal sources into legal funds or hiding the source of funds through financial institutions such as banks and insurance companies. Anti-money laundering is an important means to prevent financial risks, maintain financial stability, and build a harmonious and good financial environment. In anti-money laundering work, accurate identification of suspicious accounts is particularly important.

[0003] Traditional anti-money laundering work mainly targets single transaction data and uses a rule engine to trigger fixed indicators to identify suspicious accounts. This method has a single calculation logic and a long data processing process, making it difficult to uncover the invisible relationship between accounts. As a result, the existing technology has low efficiency in identifying suspicious accounts and low recognition reliability. Summary of the invention

[0004] Based on this, it is necessary to provide a suspicious account identification method, system, device, storage medium and program product that can improve identification efficiency and reliability in response to the above technical problems.

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

[0006] Obtain transaction data and identify risk data in the transaction data;

[0007] Extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0008] Determine the target account identifier to be identified, determine the transaction clue graph with the target account identifier as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0009] In one embodiment, building a knowledge graph based on transaction event data includes:

[0010] A directed graph is constructed with transaction entity identifiers as nodes and entity relationships as edges, and the transaction time is associated to obtain a knowledge graph.

[0011] In one embodiment, determining a transaction clue graph with a target account identifier as an index in a knowledge graph includes:

[0012] The target account identifier is located in the knowledge graph, the target entity relationship and the target transaction entity identifier associated with the target account identifier are determined, and the transaction clue graph is determined based on the target account identifier, the target entity relationship and the target transaction entity identifier.

[0013] In one embodiment, determining a target entity relationship and a target transaction entity identifier associated with a target account identifier includes:

[0014] Based on the target account identifier, the expansion is performed, the entity relationship directly or indirectly connected to the target account identifier is used as the target entity relationship, and the transaction entity identifier indirectly connected to the target account identifier is used as the target transaction entity identifier.

[0015] In one embodiment, obtaining transaction data and determining risk data in the transaction data includes:

[0016] Obtaining original transaction data from multiple systems, and summarizing the original transaction data to obtain transaction data;

[0017] The transaction data is extracted and converted to obtain original risk data, and the original risk data is normalized to obtain risk data.

[0018] In one embodiment, the method further comprises:

[0019] Store risk data, transaction event data and knowledge graphs in different databases.

[0020] In a second aspect, the present application provides a suspicious account identification system, the system comprising:

[0021] A risk data acquisition module, used to acquire transaction data and determine risk data in the transaction data;

[0022] A risk data processing module, used to extract transaction event data from the risk data and construct a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0023] The suspicious account identification module is used to determine the target account identifier to be identified, determine the transaction clue graph with the target account identifier as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0024] In a third aspect, the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0025] Obtain transaction data and identify risk data in the transaction data;

[0026] Extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0027] Determine the target account identifier to be identified, determine the transaction clue graph with the target account identifier as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0028] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0029] Obtain transaction data and identify risk data in the transaction data;

[0030] Extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0031] Determine the target account identifier to be identified, determine the transaction clue graph with the target account identifier as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0032] In a fifth aspect, the present application provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0033] Obtain transaction data and identify risk data in the transaction data;

[0034] Extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0035] Determine the target account identifier to be identified, determine the transaction clue graph with the target account identifier as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0036] The above-mentioned suspicious account identification method, system, device, storage medium and program product obtain transaction data and determine risk data in the transaction data; then extract transaction event data from the risk data, and construct a knowledge graph based on the transaction event data, wherein the transaction event data at least includes transaction entity identification, entity relationship and transaction time, and the transaction entity identification at least includes account identification; when identifying a suspicious account, first determine the target account identification to be identified, determine a transaction clue graph with the target account identification as the index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph. This application is characterized by business rules, and utilizes the entity and relationship characteristics unique to the knowledge graph to mine suspicious clues and their invisible associations in transaction event data, and proposes a new data analysis method in the field of financial-related business. By constructing a knowledge graph, transaction data with money laundering risks are displayed in the form of a clue graph, and suspicious transaction behaviors are scientifically analyzed, thereby improving the accuracy and reliability of suspicious account identification and also improving the work efficiency of staff. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0038] Figure 1 A diagram of an application environment of a suspicious account identification method in one embodiment;

[0039] Figure 2 A schematic diagram of a process for identifying a suspicious account in one embodiment;

[0040] Figure 3 A schematic diagram of an interface for performing a query based on an entity identifier in an embodiment;

[0041] Figure 4 A schematic diagram of entity relationship expansion in one embodiment;

[0042] Figure 5 It is a schematic diagram of entity relationship expansion in another embodiment;

[0043] Figure 6 Construct a data flow diagram for a knowledge graph in one embodiment;

[0044] Figure 7 A flowchart of a suspicious account identification method according to another embodiment;

[0045] Figure 8 A structural block diagram of a suspicious account identification system in one embodiment;

[0046] Fig. 9 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] The suspicious account identification method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. The server 104 obtains transaction data and determines risk data in the transaction data; the server 104 extracts transaction event data from the risk data, and constructs a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier; the server 104 determines the target account identifier to be identified, determines a transaction clue graph with the target account identifier as an index in the knowledge graph, and identifies whether the target account is a suspicious account based on the transaction clue graph.

[0049] The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The IoT devices may be smart speakers, smart TVs, smart air conditioners, smart car-mounted devices, etc. The portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. The server 104 may be implemented as an independent server or a server cluster consisting of multiple servers.

[0050] In an exemplary embodiment, Figure 2 As shown, a suspicious account identification method is provided, which is applied to Figure 1 The server 104 in the example is used as an example to illustrate the method, which includes the following steps 202 to 206. Among them:

[0051] Step 202, obtaining transaction data, and determining risk data in the transaction data.

[0052] Among them, transaction data is data used to describe transaction behavior, including transaction time, transaction object, transaction content, transaction type, etc. By analyzing transaction data, finding risk data in transaction data is very important for identifying suspicious accounts. Risk data refers to data with risks in transaction data, such as frequent transaction behavior, large transaction data, etc.

[0053] Exemplarily, risk data can be determined in transaction data by data extraction, data conversion, data loading, etc. In the face of a huge amount of data, risk data can be determined by using data extraction tools.

[0054] In an exemplary embodiment, the determined risk data may be represented as CSV (Comma-Separated Values) data. CSV data stores table data in plain text form. CSV data can realize data conversion between incompatible systems and improve data processing efficiency.

[0055] Step 204, extracting transaction event data from the risk data, and constructing a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier.

[0056] Among them, transaction event data is used to describe transaction events. Taking the insurance field as an example, transaction events can be policy insurance events, policy cancellation events, policy loan events, policy claims events, etc. In transaction event data, transaction entity identifiers are used to uniquely identify transaction entities in transaction events, such as account identifiers, policy identifiers, and salesperson identifiers. Among them, account identifiers can be account numbers, ID numbers, etc., insurance identifiers can be policy numbers, and salesperson identifiers can be salesperson work numbers, serial numbers, etc.; entity relationships represent the relationships between transaction entities in transaction events, such as the relationship between accounts and policies, the relationship between accounts and salespersons, and the relationship between accounts and salespersons; transaction time represents the time when a transaction event occurs. A knowledge graph is constructed based on transaction event data to associate transaction event data, which is more intuitive.

[0057] For example, the JSON (JavaScript Object Notation, JS object notation) script generated by the Aviator Script computing engine can be used to process transaction event data and build a knowledge graph. Using the AviatorScript computing engine to aggregate data processing into Excel can record data lineage, that is, the source of each table and each field, and divide the data hierarchy more clearly. When there is an iterative development requirement, the historical data processing process can be found in the Excel table to design a development model for new requirements. When developers change, the handover time of developers can be effectively shortened. The Aviator Script computing engine also avoids the direct development of redundant and complex spark code. Developers can share an Excel table to generate JSON automation programs, effectively reducing development costs and improving data processing efficiency.

[0058] Step 206, determine the target account identifier to be identified, determine a transaction clue graph with the target account identifier as an index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0059] Among them, the target account identifier can be used to uniquely represent the identifier of the target account. The transaction clue graph can be considered as a part of the knowledge graph. When identifying suspicious accounts, the target account identifier to be identified is first determined, and the transaction clue graph with the target account identifier as the index is determined in the knowledge graph, that is, the transaction clue graph is formed by extracting the data related to the target account identifier in the knowledge graph separately. By analyzing and processing the transaction clue graph, it is determined whether the target account is a suspicious account. The identification of suspicious accounts through graphical methods and visual account identification can improve the efficiency and accuracy of suspicious account identification.

[0060] In the above suspicious account identification method, transaction data is obtained and risk data is determined in the transaction data; then transaction event data is extracted from the risk data, and a knowledge graph is constructed based on the transaction event data, wherein the transaction event data at least includes transaction entity identification, entity relationship and transaction time, and the transaction entity identification at least includes account identification; when identifying a suspicious account, the target account identification to be identified is first determined, and a transaction clue graph with the target account identification as the index is determined in the knowledge graph, and the target account is identified as a suspicious account based on the transaction clue graph. This application is characterized by business rules, and utilizes the entity and relationship characteristics unique to the knowledge graph to mine suspicious clues and their invisible associations in transaction event data, and proposes a new data analysis method in the field of financial-related business. By constructing a knowledge graph, transaction data with money laundering risks are displayed in the form of a clue graph, and suspicious transaction behaviors are scientifically analyzed, thereby improving the accuracy and reliability of suspicious account identification and also improving the work efficiency of staff.

[0061] In an exemplary embodiment, a knowledge graph is constructed based on transaction event data, including: constructing a directed graph with transaction entity identifiers as nodes and entity relationships as edges, and associating transaction time to obtain a knowledge graph.

[0062] Among them, the knowledge graph is a knowledge base that represents entities and relationships, and presents the relationships between different entities in a graphical way. To build a knowledge graph, the transaction entities and entity relationships are first extracted from the transaction event data, and then the extracted transaction entities and entity relationships are structured and stored to obtain the knowledge graph. For the generated knowledge graph, data reasoning, data expansion or data query can be further performed.

[0063] Exemplarily, taking the insurance event as an example, before constructing the knowledge graph, the policyholder ID, insured person ID, policy ID, salesperson ID, insurance time, policy time, etc. are first extracted from the insurance data, among which the policyholder ID, insured person ID, policy ID, and salesperson ID are all transaction entity IDs. There is an insurance relationship between the policyholder and the insured, a purchase relationship between the policyholder and the policy, a guarantee relationship between the insured and the policy, and a management relationship between the policy and the salesperson. The above-mentioned insurance relationship, purchase relationship, guarantee relationship, and management relationship are entity relationships. A directed graph is constructed based on the transaction entity IDs and entity relationships, and the insurance event and policy event of the insurance event are associated with the constructed structure graph to obtain a knowledge graph.

[0064] like Figure 3 As shown, it is a schematic diagram of an interface for querying based on entity identification in one embodiment. In this embodiment, a knowledge graph is constructed based on transaction event data. In the foreground application, entity information can be queried based on entity identification. For example, Figure 3 Taking the entity identifier as the account identifier as an example, the information of account 001 is queried, and the entity category corresponding to the account identifier includes a customer entity. The customer entity has a cancellation event of 2,688 yuan on April 23, 2019, and the cancelled policy number is 999. This embodiment associates the transaction entity identifier, entity relationship and transaction event data to improve the query efficiency of the entity, and can more conveniently mine the relationship between entities and more accurately identify suspicious accounts.

[0065] In a further embodiment, a transaction clue graph indexed by a target account identifier is determined in a knowledge graph, including: locating the target account identifier in the knowledge graph, determining a target entity relationship and a target transaction entity identifier associated with the target account identifier, and determining the transaction clue graph based on the target account identifier, the target entity relationship and the target transaction entity identifier.

[0066] Among them, the target account identifier is an identifier used to uniquely identify the target account. The target account identifier can be the ID, ID number, etc. of the target account. In the knowledge graph, the entity relationship associated with the target account identifier is used as the target entity relationship, and the transaction clue graph is obtained based on the target account identifier and the target entity relationship. In addition, the transaction entity identifier associated with the target entity relationship is also used as the target transaction entity identifier. The target transaction entity identifier can be a policy identifier, a salesperson identifier, or an insured person identifier. The transaction clue graph is determined based on the target account identifier, the target entity relationship, and the target transaction entity identifier to achieve data expansion of the target account identifier.

[0067] For example, the account with account ID 001 is determined as the target account, and the relationship related to the account is obtained in the knowledge graph according to the target account ID 001, including the insurance policies purchased by the target account, the insurance policies settled, and the insurance policies revoked. For the insurance policies purchased by the target account, the information of the insured and salesperson of the insurance policies purchased by the target account can be further expanded, or the information of the insured and salesperson of the insurance policies settled by the target account can be further expanded; the relationship between the target account and the insurance policy, between the insurance policy and the insured, and between the insurance policy and the salesperson is the target entity relationship. The transaction clue graph can be determined according to the target account ID, the target entity relationship, and the target transaction entity ID. The transaction clue graph can intuitively show the transaction data related to the target account, which is convenient for tracing the source of funds and checking suspicious accounts.

[0068] like Figure 4 As shown, in one embodiment, Figure 3 The following is a schematic diagram of the partial relationship expansion of the account shown in Figure 4 The transaction clue graph after expansion includes a customer entity and four policy entities. The customer entity name is Zhang San, and the policy entities are Policy No. 1 to Policy No. 4. The relationship categories of the four policies and the customer entity are all insured-customer relationship, that is, Zhang San is insured by the four policies. Figure 4 As shown, when the account relationship of this embodiment is expanded, the transaction time is also associated. The transaction time data can be used to determine the transaction entities and entity relationships within a period of time. For example, if a certain account has a large amount of insurance information, but the insurance information of the account is not concentrated, but regularly distributed in various time periods, then the suspicion of the account is not high.

[0069] This embodiment distinguishes entity relationships in the time dimension and obtains special event categories based on transaction time. Compared with the traditional knowledge graph, the entity relationships described in the knowledge graph of this embodiment are relationships within a period of time, and do not represent occurrences at a certain moment, such as parent-child relationships, grandparent-grandchild relationships, and friend relationships. Special events describe events that occur at a single moment, such as insurance policy purchase events, insurance policy cancellation events, and insurance policy loan events. This embodiment can improve the accuracy of identifying suspicious accounts by adding transaction time parameters to the knowledge graph.

[0070] In one embodiment, determining a target entity relationship and a target transaction entity identifier associated with a target account identifier includes: expanding based on the target account identifier, taking an entity relationship directly or indirectly connected to the target account identifier as a target entity relationship, and taking a transaction entity identifier indirectly connected to the target account identifier as a target transaction entity identifier.

[0071] Among them, the entity relationship or transaction entity identifier indirectly connected to the target account identifier indicates that it is not directly connected to the target account identifier, but can be associated with the target account through other entity identifiers or entity relationships, and has an indirect connection relationship with the target account. When conducting in-depth analysis of the target account, each entity node and the corresponding entity relationship can be deeply expanded through the target account identifier.

[0072] Exemplarily, taking the aforementioned example, after obtaining the target entity identifier and target entity relationship associated with the target account identifier based on the target account identifier, the entity relationship of the target entity identifier can be further expanded. For example, based on the A identifier, the B identifier having an entity relationship with A is obtained, and then the B identifier is extended and analyzed to obtain the C identifier having an entity relationship with the B identifier, and so on. The entity identifiers and entity relationships are continuously expanded, the entity relationships between transaction entities are explored, and the efficiency of suspicious account identification is improved.

[0073] Figure 5 In another embodiment, Figure 3 A schematic diagram of in-depth relationship expansion of the account shown. Figure 5 After the relationship expansion of the account entity, the transaction clue graph obtained includes five customer entities and nine policy entities. The customer entities are Zhang San, Li Si, Wang Wu, Zhao Liu, and Sun Qi, and the policy entities are Policy 001 to Policy 009. The relationship categories of the nine policies include nine insured customer insured relationships and six customer-insured insured relationships. That is, the insured objects of the nine policies are among the five customer entities, but the five customer entities only correspond to the insured of six of the policies. Figure 5Take Sun Qi in the example of target account for analysis. The dotted line between policy 07 and customer Sun Qi represents the policy that has an entity relationship with customer Sun Qi. This transaction clue graph includes a customer entity Sun Qi, and policy 07 provides protection for customer Sun Qi. Figure 4 similar, Figure 5 The illustrated embodiment also associates transaction time when expanding account relationships, thereby improving the accuracy of identifying suspicious accounts through transaction time.

[0074] In one embodiment, transaction data is obtained, and risk data is determined in the transaction data, including: obtaining original transaction data from multiple systems, and aggregating the original transaction data to obtain transaction data; extracting and converting the transaction data to obtain original risk data, and normalizing the original risk data to obtain risk data.

[0075] Among them, the original transaction data is the transaction data collected directly in the transaction system. Taking the financial-related business field as an example, the same product may be launched on multiple business platforms or transaction systems at the same time. When identifying suspicious accounts, the original transaction data of each transaction system is first aggregated to obtain transaction data. The transaction data is converted, extracted and cleaned to obtain the original risk data. Since the data between different systems or platforms may be inconsistent, the original risk data is normalized to obtain standardized risk data, which provides a high-quality data foundation for the identification of suspicious accounts.

[0076] In one embodiment, the method further includes: storing the risk data, transaction event data, and knowledge graph in different databases respectively.

[0077] Exemplarily, after the risk data is determined from the original transaction data, the risk data can be uploaded and stored in the anti-money laundering history database of the original data layer of the Hive processing library. After the transaction event data is determined from the risk data, and the transaction entity, entity relationship and other data are obtained based on the transaction event data analysis, the transaction event data and the data obtained by the analysis and processing can be uploaded and stored in the anti-money laundering middleware database. When the knowledge graph data is obtained by processing the transaction event data, the knowledge graph data can be uploaded and stored in the anti-money laundering knowledge graph database. By distributing and storing different types of data and isolating the data, the security of the data can be improved, and the scalability of the system can be improved, making it easier to manage and maintain.

[0078] Combination Figure 6 The knowledge graph construction flowchart shown in Figure 7 As shown, in one embodiment, taking the insurance system as an example, the suspicious account identification method includes the following steps 702 to 708. Among them:

[0079] Step 702, obtaining transaction data from the insurance system, and determining risk data in the transaction data.

[0080] Transaction data refers to data synchronized from the business system. The acquired transaction data is cleaned and integrated to obtain risk data. The risk data can be stored in the DWD (Data WareHouse Detail) risk data cluster.

[0081] Step 704, using the scheduling system and data processing tools, extracting transaction event data from the risk data.

[0082] Among them, the scheduling system can be the Dolphin Cloud Scheduling System, which is a distributed and easily scalable visual DAG workflow task scheduling open source system. The scheduling system can be applied to enterprise-level scenarios and provide solutions for visual operation tasks, workflows and full life cycle data processing processes.

[0083] Data processing tools can be ETL (Extract-Transform-Load) tools, which are used to extract, transform, and load data from risk data to the destination. ETL tools can be GDS, DataX, etc.

[0084] like Figure 6 As shown in the figure, the risk data obtained from the DWD risk data cluster is pushed to the CDH (Cloudera's Distribution, including Apache Hadoop) big data cluster after cleaning and other processing, and landed as CSV data. Among them, CDH is a big data platform. The core of the platform is a distributed computing framework built on Apache Hadoop. CDH supports multiple data processing engines, such as Hadoop, Spark, Impala, HBase, etc.

[0085] The risk data is transmitted to the gateway node of the CDH big data cluster, which can be used to increase computing tasks from the node to the computing cluster, but the node does not store data or participate in the overall cluster calculation. The transaction event data transmitted to the gateway is landed as CSV data, which stores table data in plain text.

[0086] Step 706: Process the transaction event data to obtain a knowledge graph.

[0087] The oozie scheduling of the CDH big data cluster executes the shell script to upload the risk data in the gateway node to the amls-his (Anti-Money Laundering Historical Data) database, the original data layer of the Hive processing library, and executes the Hive SQL processing script to perform the middle-layer processing and store the data in the amls-mid (Anti-Money Laundering Middleware) data. Then, the avoier computing engine is used to execute the generated JSON script to process the transaction entities, entity relationships, and transaction events and store the results in the amls-knowledgegraph (Anti-Money Laundering Knowledge Graph) database, and the push script is started to push the transaction entity index to the ES (Elasticsearch) cluster, and import the transaction entity, entity relationship, and transaction event data into Hbase. Spark is used to perform multi-degree relationship expansion on the generated transaction entities, entity relationships, and transaction events, that is, graph mining, and the mined transaction clue graph is pushed and stored in the OceanBase database.

[0088] Among them, Oozie is a scheduling system for managing Hadoop jobs on CDH big data clusters. Shell is a command language and also a programming language, such as shell script. As a command-based language, Shell interactively interprets and executes commands entered by users; as a programming language, Shell can define variables, pass parameters, and provide many process control structures that all high-level languages ​​have. Hive is a data warehouse tool based on Hadoop, which is used for data extraction, transformation, and loading. It is a mechanism that can store, query, and analyze large-scale data stored in Hadoop. HiveSQL is a data warehouse tool based on hdfs. It is a MapReduce encapsulation, and the underlying layer is the MapReduce program.

[0089] Aviator, or Aviator Script, is a high-performance, lightweight scripting language hosted on the JVM. In this embodiment, the traditional multi-table association method is modified to a vertical aggregation method in the aviator lightweight engine code. JSON is a lightweight data exchange format that uses a text format that is completely independent of the programming language to store and represent data. Elasticsearch is a distributed, RESTful-style search and data analysis engine that is used to store transaction entity index data of knowledge graphs, which can speed up the retrieval efficiency of tens of billions of data. Spark is a fast, general, and scalable big data analysis engine developed in the Scala language. Scala is a multi-paradigm programming language, similar to the Java programming language. The language is scalable and integrates various features of object-oriented programming and functional programming. OceanBase is a distributed database.

[0090] This embodiment uses the method of combining the aviator lightweight rule engine with spark. Compared with the traditional direct writing of spark programs, this embodiment aggregates the overall governance ideas into Excel to record the lineage of transaction data, that is, the source of each table and each field, and divides the data hierarchy more clearly. If there is an iterative development demand in the future, the old data governance process can be found from Excel to design the development mode of new requirements. If a developer resigns or changes, the developer handover work cycle can be effectively shortened. At the same time, this embodiment avoids the direct development of redundant and complex spark code. Developers can share the automation program of Excel to generate JSON and the aviator rule engine combined with spark calculation code to effectively reduce development costs. For the governance of millions of incremental data, this embodiment uses the vertical aggregation method to replace the traditional multi-table link matching when using the aviator engine combined with spark execution, reducing the shuffle process in the overall governance process, thereby improving the calculation efficiency. Among them, Shuffle refers to sorting the intermediate results generated in the Map stage according to the Key value in big data calculation, and merging the Value values ​​with the same Key value together to form a list, and then redistributing these lists to the Reduce node according to the Hash algorithm for further processing. In the verification test, the data processing time of this embodiment has been reduced from 6.5 hours to 5.5 hours on average per day compared to the original direct use of spark computing management.

[0091] Step 708, select the target account identifier to be identified, obtain a transaction clue graph with the target account identifier as an index, and identify suspicious accounts based on the transaction clue graph.

[0092] This embodiment builds a knowledge graph of the open source big data ecosystem, using the CDH big data cluster as the main data platform, storing intermediate tables in the Hive database, and storing the knowledge graph using a large-scale graph database integrated with HBase and ES, supporting the Gremlin graph query language. Through the graph mining algorithm, complex and hidden customer relationships, customer behavior associations, account relationships and other information are deeply mined, and displayed in the form of a transaction clue graph, intuitively and conveniently discovering abnormalities in customer behavior, customer relationships, key transactions and other aspects.

[0093] For high-performance computing and retrieval queries of massive data, this embodiment uses the Spark on Hive method to process and calculate massive business data, achieving the goal of T+1 daily incremental data, greatly improving the timeliness and timeliness value of data. The distributed and efficient data analysis search engine Elastic Search is connected to the big data service interface, and uses indexing, word segmentation and other technologies to effectively shorten the query time of the gallery. At the same time, it provides fuzzy query functions, connects implicit clues in series, effectively improves computing performance, and reduces processing time costs. Graph database technology enables the reuse of expert experience. Combined with the characteristics of anti-money laundering investigation, based on Graph X, a graphical method is built to mine hidden fund transfer behaviors with one click, and display the flow of funds, forming an intelligent expert verification mode.

[0094] This application integrates insurance business knowledge from multiple angles and in all aspects, and realizes a highly accurate, high-performance and effective artificial intelligence system through technologies such as big data, knowledge graphs, and graph mining. At the same time, it achieves a comprehensive leap in technical framework, performance, and deployment.

[0095] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0096] Based on the same inventive concept, the embodiment of the present application also provides a suspicious account identification system for implementing the suspicious account identification method involved above. The implementation scheme for solving the problem provided by the system is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more suspicious account identification system embodiments provided below can refer to the limitations of the suspicious account identification method above, and will not be repeated here.

[0097] In an exemplary embodiment, Figure 8 As shown, a suspicious account identification system is provided, including: a risk data acquisition module 802, a risk data processing module 804 and a suspicious account identification module 806, wherein:

[0098] The risk data acquisition module 802 is used to acquire transaction data and determine risk data in the transaction data;

[0099] The risk data processing module 804 is used to extract transaction event data from the risk data and construct a knowledge graph based on the transaction event data, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier;

[0100] The suspicious account identification module 806 is used to determine the target account identifier to be identified, determine a transaction clue graph with the target account identifier as an index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph.

[0101] In one embodiment, the risk data processing module 804 is further used to construct a directed graph with transaction entity identifiers as nodes and entity relationships as edges, and associate transaction times to obtain a knowledge graph.

[0102] In one embodiment, the suspicious account identification module 806 is also used to: locate the target account identifier in the knowledge graph, determine the target entity relationship and target transaction entity identifier associated with the target account identifier, and determine the transaction clue graph based on the target account identifier, the target entity relationship and the target transaction entity identifier.

[0103] In one embodiment, the suspicious account identification module 806 is further used to: expand based on the target account identifier, use the entity relationship directly or indirectly connected to the target account identifier as the target entity relationship, and use the transaction entity identifier indirectly connected to the target account identifier as the target transaction entity identifier.

[0104] In one embodiment, the risk data acquisition module 802 is also used to: acquire original transaction data from multiple systems, and aggregate the original transaction data to obtain transaction data; extract and convert the transaction data to obtain original risk data, and normalize the original risk data to obtain risk data.

[0105] In one embodiment, the device is also used to store risk data, transaction event data and knowledge graphs in different databases respectively.

[0106] Each module in the above suspicious account identification system can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module.

[0107] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Fig. 9 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store business transaction data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a suspicious account identification method is implemented.

[0108] Those skilled in the art will understand that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0109] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0110] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0111] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

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

[0113] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0114] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0115] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A suspicious account identification method, characterized in that: The method comprises: obtaining transaction data and determining risk data in the transaction data; Transaction event data is extracted from the risk data, and an Excel table is compiled based on the transaction event data, so that the Excel table is read by the Aviator Script calculation engine to construct a knowledge graph, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier; the Excel table is used to record the lineage of the transaction data; Determine a target account identifier to be identified, determine a transaction clue graph with the target account identifier as an index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph; The constructing of the knowledge graph based on the transaction event data includes: constructing a directed graph with the transaction entity identifiers as nodes and the entity relationships as edges, and associating the transaction time, determining the transaction entities and entity relationships within a period of time through the transaction time data, and obtaining the knowledge graph.

2. The method according to claim 1, characterized in that: The step of determining a transaction clue graph with the target account identifier as an index in the knowledge graph includes: The target account identifier is located in the knowledge graph, a target entity relationship and a target transaction entity identifier associated with the target account identifier are determined, and the transaction clue graph is determined according to the target account identifier, the target entity relationship and the target transaction entity identifier.

3. The method according to claim 2, characterized in that The determining of the target entity relationship and the target transaction entity identifier associated with the target account identifier includes: Based on the target account identifier, an entity relationship directly or indirectly connected to the target account identifier is expanded as the target entity relationship, and a transaction entity identifier indirectly connected to the target account identifier is used as the target transaction entity identifier.

4. The method according to claim 1, characterized in that: The obtaining of transaction data and determining risk data in the transaction data includes: Acquire original transaction data of multiple systems, and aggregate the original transaction data to obtain the transaction data; The transaction data is extracted and converted to obtain original risk data, and the original risk data is normalized to obtain the risk data.

5. The method according to claim 1, characterized in that: The method further comprises: The risk data, the transaction event data and the knowledge graph are stored in different databases respectively.

6. A suspicious account identification system, characterized in that: The system comprises: a risk data acquisition module, used to acquire transaction data and determine risk data in the transaction data; A risk data processing module, used to extract transaction event data from the risk data, compile the transaction event data into an Excel table, and read the Excel table through the Aviator Script calculation engine to build a knowledge graph, wherein the transaction event data at least includes a transaction entity identifier, an entity relationship, and a transaction time, and the transaction entity identifier at least includes an account identifier; the Excel table is used to record the lineage of the transaction data; A suspicious account identification module, used to determine a target account identifier to be identified, determine a transaction clue graph with the target account identifier as an index in the knowledge graph, and identify whether the target account is a suspicious account based on the transaction clue graph; The risk data processing module is also used to construct a directed graph with the transaction entity identifier as a node and the entity relationship as an edge, and associate the transaction time, determine the transaction entities and entity relationships within a period of time through the transaction time data, and obtain the knowledge graph.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images