Account anomaly detection method and device, electronic equipment and storage medium

Abstract

The application relates to an account anomaly detection method and device, electronic equipment and a storage medium. The method comprises the following steps: collecting target account multi-source heterogeneous financial data through a real-time message queue, a data interface and batch extraction loading, and obtaining a standardized data set after preprocessing; taking the data set as input, constructing a transaction behavior graph taking an account and an associated account as nodes and a transaction and an associated relationship as edges based on entity relationships; performing multi-stage neighbor sampling and hierarchical feature aggregation on the graph to obtain a low-dimensional embedding vector of each node; determining global and local anomaly scores of a target account node based on the vector, and obtaining a target anomaly score through weighted fusion; calling a preset rule engine, and determining a target account anomaly risk detection result according to a matching result of the target anomaly score and the preset rule. Through the construction of the transaction behavior graph, information is integrated, features are mined through graph learning, an anomaly score is fused, a rule engine is judged, and high-precision traceable anomaly detection is realized.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a method, apparatus, electronic device and storage medium for detecting account anomalies. Background Technology

[0002] With the rapid development of online and networked financial services, various account transaction behaviors are becoming increasingly complex, and cross-entity and multi-level fund transfer patterns are constantly emerging. Risk behaviors such as abnormal account transactions and illegal fund transfers are showing increasingly concealed and chain-like characteristics. Currently, the financial risk control field generally uses rule engines or single machine learning models to detect account anomalies. These models rely on multi-source financial data collection, basic feature analysis, and simple rule matching to identify risks in account transaction behavior. Meanwhile, conventional risk control methods can identify risks in individual transactions and, by combining basic transaction information with preset risk control rules, complete preliminary risk assessments, initially meeting the business needs of daily financial transaction compliance screening and basic risk prevention and control.

[0003] However, existing technologies still have significant shortcomings in practical applications. On the one hand, traditional detection methods often focus on single or direct transactions of target accounts, lacking the ability to penetrate and trace multi-level fund flows and multi-level transaction objects. They cannot construct a complete chain of transaction topologies and are unable to identify hidden suspicious transactions in multi-level circulation links. On the other hand, conventional risk detection only outputs simple risk level results and cannot combine anomaly quantitative scores, hit risk control rules, transaction timing and amount characteristics to conduct linked analysis. It cannot accurately mark suspicious nodes and abnormal transaction behaviors within the link and is difficult to form a complete, traceable, and verifiable risk tracing link. Ultimately, this results in a single dimension of risk assessment, one-sided identification of suspicious transactions, and the inability to generate standardized suspicious transaction reports with rule-based basis and a complete picture of the link, making it difficult to meet the actual needs of high-precision, full-link, and traceable financial risk control supervision and risk screening.

[0004] Therefore, there is an urgent need to develop an account anomaly detection method, device, electronic equipment, and storage medium to solve one or more of the aforementioned problems. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, the present invention provides an account anomaly detection method, device, electronic device and storage medium. The method collects multi-source heterogeneous financial data and preprocesses it to obtain a standardized dataset. On this basis, it constructs a transaction behavior graph based on entity relationships, fully restores the transaction relationship topology between accounts and related accounts, and then obtains the low-dimensional embedding vector of each node through multi-level neighbor sampling and hierarchical feature aggregation. It integrates global and local anomaly scores to obtain a comprehensive target anomaly score, and finally combines a preset rule engine to obtain the final anomaly detection result. It can effectively uncover hidden anomalies in multi-level transaction links, realize traceable and verifiable full-link anomaly risk detection, and meet the needs of high-precision risk control and supervision.

[0006] Firstly, this application provides a method for detecting account anomalies, the method comprising:

[0007] Multi-source heterogeneous financial data of target accounts are collected through real-time message queues, data interfaces, and batch extraction and loading methods, and the multi-source heterogeneous financial data is preprocessed to obtain a standardized dataset.

[0008] Using the standardized dataset as input, a transaction behavior graph is constructed based on entity relationships, with accounts and associated accounts as nodes and transactions and associated relationships as edges;

[0009] Multi-level neighbor sampling and hierarchical feature aggregation are performed on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph;

[0010] Based on the node's low-dimensional embedding vector, the global anomaly score and local anomaly score of the target account node are determined. The global anomaly score and local anomaly score are then weighted and fused to obtain the target anomaly score.

[0011] The preset rule engine is invoked, and the abnormal risk detection result of the target account is determined based on the matching result between the target abnormal score and the preset rule.

[0012] In one possible implementation, the step of collecting multi-source heterogeneous financial data of the target account through real-time message queues, data interfaces, and batch extraction and loading methods, and preprocessing the multi-source heterogeneous financial data to obtain a standardized dataset, includes:

[0013] By connecting to the financial business system through a real-time message queue, transaction data of the target account can be collected in real time.

[0014] By calling the entity information disclosure system through open data interfaces, data of associated accounts corresponding to the target account can be collected.

[0015] Import industry benchmark information systems through batch extraction and loading to collect benchmark feature data for corresponding industry dimensions;

[0016] The transaction data, associated account data, and industry benchmark feature data are integrated to construct a multi-dimensional heterogeneous dataset that includes transaction dimension, subject dimension, and industry dimension;

[0017] The multi-dimensional heterogeneous dataset is subjected to noise removal and invalid transaction filtering to obtain the first processed data.

[0018] The account entities in the first processed data are subjected to entity alignment and normalization merging to obtain the second processed data;

[0019] The missing fields of the second processed data are adaptively filled, and the values ​​that deviate from the normal distribution in the filled second processed data are truncated to obtain a standardized dataset.

[0020] In one possible implementation, the step of constructing a transaction behavior graph based on entity relationships, using the standardized dataset as input and with accounts and related accounts as nodes and transactions and related relationships as edges, includes:

[0021] Entity recognition is performed on the standardized dataset to extract the associated accounts corresponding to the target account;

[0022] Based on the transaction data in the standardized dataset, obtain the transaction behavior between the target account and the associated account;

[0023] Based on the associated account data in the standardized dataset, the association relationship between the target account and associated accounts is obtained;

[0024] The target account and its associated accounts are used as graph nodes, and the transaction behavior and relationships between the target account and its associated accounts are used as graph edges. A directed topology is constructed based on the time dimension and transaction flow to form a transaction behavior graph.

[0025] In one possible implementation, the step of performing multi-order neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph includes:

[0026] Using the target account node and associated account node in the transaction behavior graph as the initial sampling node, random sampling based on node association weight is performed on the initial sampling node according to a preset order to filter effective neighbor nodes and form an effective neighbor structure;

[0027] The effective neighbor structure is used to determine the neighborhood range of the nodes and regularize the topological association relationship. Based on the node's own attribute features, transaction behavior features corresponding to the associated edges and association relationship features under the regularized topological association relationship, the attention mechanism is used to perform feature aggregation layer by layer to extract the local neighborhood features of the neighboring nodes.

[0028] By using an inductive learning mechanism, the node features of the target account are concatenated, normalized, and nonlinearly transformed with the local neighborhood features of neighboring nodes to obtain high-dimensional fusion features.

[0029] With the low-dimensional embedding vector as the optimization objective, the feature weights are optimized through multiple rounds of iterative training. Based on the optimized feature weights, the high-dimensional fusion features are subjected to dimensionality reduction and compression processing to obtain the low-dimensional embedding vectors of each node in the transaction behavior graph.

[0030] In one possible implementation, determining the global anomaly score and local anomaly score of the target account node based on the node's low-dimensional embedding vector, and then weighting and fusing the global anomaly score and local anomaly score to obtain the target anomaly score includes:

[0031] Construct training data, which is composed of low-dimensional embedding vectors of historical normal transaction nodes and account business features;

[0032] The isolation forest model and the autoencoder model were trained using the training data to obtain the parameters of the isolation forest model, the parameters of the autoencoder model, and the reconstruction error threshold.

[0033] Construct a sample to be detected, which is composed of a low-dimensional embedding vector of the node to be detected and the corresponding account business features;

[0034] The samples to be detected are input into the trained isolation forest model and autoencoder model respectively to obtain the global anomaly score and local reconstruction error of the target account node;

[0035] The local reconstruction error is compared with the reconstruction error threshold. If the local reconstruction error exceeds the preset reconstruction error threshold, the local reconstruction error is normalized to obtain a local anomaly score. Otherwise, the local anomaly score is assigned to zero.

[0036] The global anomaly score and the local anomaly score are weighted and fused according to preset weights to obtain the target anomaly score corresponding to the target account node.

[0037] In one possible implementation, the step of invoking a preset rule engine to determine the abnormal risk detection result of the target account based on the matching result of the target anomaly score and the preset rules includes:

[0038] Call the preset rule engine and load risk control rules from the regulatory rule base and the custom rule base;

[0039] The target abnormal score and corresponding transaction behavior data of the target account are input into the preset rule engine. The risk control rules are matched with the quantitative range of the target abnormal score and the characteristics of the transaction behavior to determine the initial risk level of the target account.

[0040] If the risk control rule matched by the target abnormal score is a preset regulatory rule, then the risk level of the target account is increased according to the risk level increase rule of the preset regulatory rule; otherwise, the risk level of the target account is maintained at the initial risk level.

[0041] Based on the risk level of the target account, a corresponding risk label is generated, and based on the matching risk control rules and the transaction behavior data of the target account, a suspicious transaction chain report of the target account is generated to obtain the abnormal risk detection result of the target account.

[0042] In one possible implementation, generating a suspicious transaction chain report for the target account based on matching risk control rules includes:

[0043] Starting with the target account node, associate the risk control rules for this match, the target account's target anomaly score, and the corresponding transaction behavior data;

[0044] Based on the transaction behavior data, a multi-level transaction chain is constructed, including transaction object, transaction time, transaction amount, and transaction flow direction;

[0045] Based on the matching risk control rules, transaction time, and transaction amount, identify and mark suspicious transaction nodes in the multi-level transaction chain;

[0046] Integrate all marked suspicious transaction nodes with complete transaction chain information to generate a suspicious transaction chain report containing a complete risk tracing chain.

[0047] Secondly, this application provides an account anomaly detection device, the device comprising:

[0048] The data acquisition module is used to collect multi-source heterogeneous financial data of the target account through real-time message queues, data interfaces, and batch extraction and loading methods, and to preprocess the multi-source heterogeneous financial data to obtain a standardized dataset.

[0049] The construction module is used to construct a transaction behavior graph based on entity relationships, with accounts and associated accounts as nodes and transactions and associated relationships as edges, using the standardized dataset as input.

[0050] The aggregation module is used to perform multi-level neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph.

[0051] The weighted fusion module is used to determine the global anomaly score and local anomaly score of the target account node based on the node's low-dimensional embedding vector, and to perform weighted fusion of the global anomaly score and local anomaly score to obtain the target anomaly score.

[0052] The determination module is used to call a preset rule engine and determine the abnormal risk detection result of the target account based on the matching result of the target abnormal score and the preset rule.

[0053] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the account anomaly detection method described in any embodiment of the first aspect.

[0054] Fourthly, this application also provides a computer storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the account anomaly detection method described in any embodiment of the first aspect.

[0055] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application obtains a standardized dataset through the collection and preprocessing of multi-source heterogeneous financial data, constructs a transaction behavior graph containing accounts, related accounts, transactions and related relationships based on entity relationships, obtains low-dimensional embedding vectors of each node by relying on multi-level neighbor sampling and hierarchical feature aggregation, obtains target anomaly scores by fusing global anomaly scores and local anomaly scores, and finally obtains accurate anomaly risk detection results by combining a preset rule engine. It can penetrate and trace multi-level capital links, completely restore transaction topology relationships, and accurately identify hidden suspicious transactions in the links. At the same time, it can rely on quantitative scores and rule matching to achieve linkage judgment, accurately mark suspicious nodes and abnormal transactions in the links, and generate a suspicious transaction chain report with a complete risk tracing link. It overcomes the defects of the prior art, such as single risk identification dimension, lack of multi-level transaction penetration tracing, one-sided suspicious transaction positioning, and inability to trace risk results, and improves the comprehensiveness, accuracy and risk tracing and control capabilities of financial account anomaly detection. Attached Figure Description

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

[0057] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0059] Figure 1 A flowchart illustrating an account anomaly detection method provided in this application embodiment;

[0060] Figure 2 A flowchart illustrating a standardized dataset acquisition method provided in this application embodiment;

[0061] Figure 3 A flowchart illustrating the steps of a standardized dataset acquisition method provided in this application embodiment;

[0062] Figure 4 A flowchart illustrating a method for constructing a transaction behavior graph provided in an embodiment of this application;

[0063] Figure 5 A flowchart illustrating the steps of a transaction behavior graph construction method provided in this application embodiment;

[0064] Figure 6 A flowchart illustrating a low-dimensional embedding vector acquisition method provided in an embodiment of this application;

[0065] Figure 7 A flowchart illustrating the steps of a low-dimensional embedding vector acquisition method provided in this application embodiment;

[0066] Figure 8 A flowchart illustrating a method for obtaining target anomaly scores provided in an embodiment of this application;

[0067] Figure 9 A flowchart illustrating the steps of a method for obtaining a target anomaly score, as provided in an embodiment of this application.

[0068] Figure 10 A flowchart illustrating a method for determining abnormal risk detection results provided in an embodiment of this application;

[0069] Figure 11 A flowchart illustrating the steps of a method for determining anomaly risk detection results provided in an embodiment of this application;

[0070] Figure 12 A flowchart illustrating a method for generating a suspicious transaction chain report, provided in an embodiment of this application;

[0071] Figure 13 A flowchart illustrating the steps of a method for generating a suspicious transaction chain report, provided in an embodiment of this application;

[0072] Figure 14 A flowchart illustrating the steps of an account anomaly detection method provided in this application embodiment;

[0073] Figure 15 This is a schematic diagram of the structure of an account anomaly detection device provided in an embodiment of this application;

[0074] Figure 16 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0075] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0076] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0077] To address the technical problems of existing financial account anomaly detection technologies that rely on single-dimensional features, cannot penetrate multiple transaction links to identify hidden anomalies, and lack traceability of risk results, this application provides an account anomaly detection method, device, electronic device, and storage medium. By constructing a transaction behavior graph to integrate multi-dimensional transaction association information, combining graph learning to mine multi-level link features, and integrating a global and local anomaly scoring linkage rule engine for judgment, high-precision and traceable anomaly detection is achieved.

[0078] Figure 1 This is a flowchart illustrating an account anomaly detection method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method specifically includes:

[0079] S101. Collect multi-source heterogeneous financial data of the target account through real-time message queue, data interface, and batch extraction and loading method, and perform data preprocessing on the multi-source heterogeneous financial data to obtain a standardized dataset.

[0080] Multi-source heterogeneous financial data refers to financial data that originates from different business systems, data interfaces, and storage media, and whose data structure covers structured transaction logs, semi-structured subject attribute information, and unstructured relational text, while integrating three different dimensions of financial data: transaction dimension, subject dimension, and industry dimension.

[0081] In this embodiment, the real-time message queue can achieve low-latency collection of high-frequency transaction data, ensuring the integrity of data collection in sudden transaction scenarios. The open data interface can dynamically obtain external related information such as business registration changes and equity associations of account entities. Batch extraction and loading can synchronize industry risk benchmark data on a monthly or quarterly basis, providing industry-dimensional comparison basis for anomaly judgment.

[0082] The preprocessing stage involves multiple steps, including multi-source data fusion, noise filtering, entity alignment and normalization, missing data filling, and numerical truncation, to eliminate format differences and data quality issues from different sources. This outputs standardized data that meets the requirements for subsequent map construction, laying the data foundation for subsequent feature extraction and anomaly detection.

[0083] S102. Using the standardized dataset as input, construct a transaction behavior graph based on entity relationships, with accounts and associated accounts as nodes and transactions and related relationships as edges.

[0084] In this embodiment, entities are first extracted from the standardized dataset, and the target account and all its corresponding related accounts are identified as the basic nodes of the graph. Then, transaction behavior data and subject association data between the target account and related accounts are extracted as graph edges connecting the nodes. Finally, a directed topology structure is constructed according to the time dimension and the direction of fund transaction, and a complete transaction behavior graph is generated, which fully restores the multi-level transaction association between accounts and provides structural support for the subsequent extraction of abnormal features of multi-level links.

[0085] S103. Perform multi-level neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph.

[0086] In this embodiment, firstly, account nodes within the graph are selected as sampling objects, and effective neighbor nodes are filtered according to a preset order to determine the node neighborhood topology. Then, multi-dimensional association information within the neighborhood is aggregated layer by layer by combining the node's own attributes, transaction edge features, and subject association features. Next, the node's own features and neighbor neighborhood features are fused, and high-dimensional fused features are obtained through normalization and nonlinear transformation. Finally, the feature weights are iteratively optimized to reduce the dimensionality of the high-dimensional features and output the low-dimensional embedding vectors corresponding to all nodes.

[0087] S104. Based on the node's low-dimensional embedding vector, determine the global anomaly score and local anomaly score of the target account node, and perform weighted fusion of the global anomaly score and local anomaly score to obtain the target anomaly score.

[0088] In this embodiment, training samples and samples to be detected are constructed based on the low-dimensional embedding vectors corresponding to the graph nodes and combined with the account business features. The global anomaly score is calculated using the isolated forest model, and the local anomaly situation is determined by the reconstruction error of the autoencoder model and converted into the local anomaly score. Finally, the two types of anomaly scores are weighted and fused according to the preset weights to obtain the final quantitative anomaly score of the target account.

[0089] S105. Call the preset rule engine and determine the abnormal risk detection result of the target account based on the matching result of the target abnormal score and the preset rule.

[0090] A preset rule engine refers to a rule processing engine that incorporates compliance rules required by regulatory agencies and customizes business risk control rules based on actual business needs. It can automatically match the corresponding risk control rules based on the input target anomaly score and corresponding transaction behavior data, and output risk detection results that meet regulatory and business requirements.

[0091] In this embodiment, the built-in rule engine is invoked to load regulatory rules and custom risk control rules; combined with the target anomaly score of the account quantification, various preset risk control clauses are matched to determine the risk situation, and the initial risk level of the account is determined accordingly; for accounts that hit the regulatory rules, the risk level is upgraded and adjusted, and finally, a risk label is generated based on the determined risk level, and a suspicious transaction chain report is generated based on the rule matching results, and a comprehensive anomaly risk detection conclusion for the target account is output.

[0092] The account anomaly detection method provided in this application constructs a transaction behavior graph covering all transaction relationships, fully mining the implicit correlation information in multi-level transaction links. This solves the problem that traditional detection relies only on single-point features of accounts and cannot identify anomalies in multi-level links across accounts. At the same time, it integrates global anomaly scores and local anomaly scores to achieve accurate quantification of the degree of anomaly. Combined with rule engine linkage analysis, it not only meets the hard requirements of regulatory compliance, but also adapts to custom risk control logic in actual business scenarios. Finally, it generates a suspicious transaction chain report with a complete risk tracing link, which can provide complete and traceable risk evidence for subsequent risk verification and regulatory reporting, effectively improving the accuracy and control efficiency of financial account anomaly detection.

[0093] Figure 2 This is a flowchart illustrating a standardized dataset acquisition method provided in an embodiment of this application, as shown below. Figure 2 As shown, the process of collecting multi-source heterogeneous financial data of target accounts through real-time message queues, data interfaces, and batch extraction and loading methods, and preprocessing the multi-source heterogeneous financial data to obtain a standardized dataset, includes:

[0094] S201. Connect to the financial business system through a real-time message queue to collect transaction data of the target account in real time.

[0095] In this embodiment, transaction log data from financial business systems (such as a bank's core system) is accessed in near real-time using a Kafka message queue. The collected data includes transaction time, amount, lending direction, counterparty account, and a summary of the transaction purpose.

[0096] S202. By calling the main information disclosure system through the open data interface, collect the associated account data corresponding to the target account.

[0097] In this embodiment, the associated account data (such as business registration information) of the main information disclosure system (such as the enterprise credit information disclosure system and platforms such as Qichacha) are accessed quarterly through API interfaces to obtain data such as shareholders, legal persons, senior executives, registered capital, establishment date, and business scope.

[0098] S203. Import industry benchmark information system through batch extraction and loading method to collect benchmark feature data of corresponding industry dimensions.

[0099] In this embodiment, benchmark characteristic data (such as industry characteristic data) published by industry benchmark information systems (such as the National Bureau of Statistics or industry associations) are imported periodically using a batch ETL method. The content includes industry average transaction frequency, amount distribution, seasonal fluctuation characteristics, etc.

[0100] S204. The transaction data, associated account data, and industry benchmark feature data are integrated to construct a multi-dimensional heterogeneous dataset that includes transaction dimension, subject dimension, and industry dimension.

[0101] In this embodiment, data from three different sources are first associated and aligned according to the account, and various types of data corresponding to the same account in different dimensions are integrated and archived to solve the problem of inconsistent entities in multi-source data and form a heterogeneous dataset that fully covers all dimensions of information of the target account.

[0102] S205. Perform noise removal and invalid transaction filtering on the multi-dimensional heterogeneous dataset to obtain the first processed data.

[0103] In this embodiment, invalid and noisy data such as test transactions, canceled transactions, and duplicate records are removed, and interference from invalid data caused by data entry errors and changes in transaction status is eliminated. Valid transaction and entity association data with normal status and complete information are retained to obtain the first processed data after cleaning.

[0104] S206. Perform entity alignment and normalization merging on the account entities in the first processed data to obtain the second processed data.

[0105] In this embodiment, different names and account codes under different system records for the same subject are aligned and matched. Multiple records belonging to the same account subject are merged and unified to eliminate data redundancy caused by multiple records of the same subject, ensuring that one account subject corresponds to a unique node in the transaction behavior graph, and obtaining the second processed data after entity alignment.

[0106] S207. Adaptive filling is performed on the missing fields of the second processed data, and truncation constraints are applied to the values ​​in the filled second processed data that deviate from the normal distribution to obtain a standardized dataset.

[0107] In this embodiment, a differentiated filling method is adopted for different types of missing fields: the global mode is used to fill categorical attribute fields, the industry median is used to fill numerical attribute fields, and non-essential related attribute fields are directly marked as unknown categories. After the filling is completed, extreme values ​​such as transaction amounts that exceed the reasonable range are truncated, and abnormal values ​​that deviate from the threshold are constrained to a reasonable distribution range. Finally, a standardized dataset that meets the requirements of graph construction is output.

[0108] Figure 3 A flowchart illustrating the steps of a standardized dataset acquisition method provided in this application embodiment is shown below. Figure 3As shown, taking the financial business system as the core banking system, the main information disclosure system as the industrial and commercial disclosure system, and the benchmark feature data as the industry database as an example, data is obtained through a multi-source heterogeneous data access method: the core banking system outputs account transaction flow data, which is accessed through a real-time message queue to realize real-time collection and transmission of transaction data; the industrial and commercial disclosure system outputs enterprise industrial and commercial information data, which is obtained through API interface calls to supplement the associated information of the account subject; the industry database outputs industry benchmark feature data, which is imported through batch ETL (extract-transform-load) to provide reference features at the industry level.

[0109] After the three types of data are input, they are uniformly entered into the preprocessing process to generate a standardized dataset. The specific steps are as follows:

[0110] Step 1: Data Cleaning: Delete internal transfer transactions that have no actual business significance and remove invalid and noisy data;

[0111] Step 2, Counterparty Normalization: Merge multiple related accounts under the same entity to achieve unified entity definitions and provide standardized entities for subsequent graph node construction;

[0112] Step 3: Missing value imputation: For missing fields in the cleaned and normalized data, adaptive imputation is performed using preset rules to ensure data integrity;

[0113] Step 4: Outlier truncation: Truncate extreme values ​​that deviate from the normal distribution to prevent them from interfering with subsequent model training and rule matching;

[0114] Step 5: Data storage after cleaning: Store all preprocessed standardized data to form a standardized dataset that can be directly used in subsequent steps.

[0115] The above process enables the multi-source fusion and standardized processing of transaction data, entity data, and industry data, providing a high-quality and highly consistent data foundation for subsequent transaction behavior graph construction, node embedding, and anomaly detection models.

[0116] Figure 4 This is a flowchart illustrating a method for constructing a transaction behavior graph according to an embodiment of this application, as shown below. Figure 4 As shown, using the standardized dataset as input, a transaction behavior graph is constructed based on entity relationships, with accounts and related accounts as nodes and transactions and related relationships as edges, including:

[0117] S401. Perform entity recognition on the standardized dataset and extract the associated accounts corresponding to the target account.

[0118] In this embodiment, the target account itself and all related accounts that have transaction or personnel associations with the target account are identified from the subject dimension information of the standardized dataset based on account identifier and subject attribute matching. The target account and all related accounts are then uniformly used as entity nodes of the graph to be constructed.

[0119] S402. Based on the transaction data in the standardized dataset, obtain the transaction behavior between the target account and the associated account.

[0120] In this embodiment, core information such as account identifiers, transaction amounts, transaction times, and transaction types of both parties in the transaction log are extracted to obtain all transaction behaviors between the target account and each associated account, which serve as the basic attributes of the transaction edges between nodes.

[0121] S403. Based on the associated account data in the standardized dataset, obtain the association relationship between the target account and the associated accounts.

[0122] In this embodiment, equity relationships, personnel relationships, and controlling relationships between target accounts and related accounts are identified from business registration information. These relationships are used as the basic attributes of attribute edges between nodes to supplement implicit entity relationship information beyond transaction relationships.

[0123] S404. The target account and its associated accounts are taken as graph nodes, and the transaction behavior and relationship between the target account and the associated accounts are taken as graph edges. A directed topology is constructed based on the time dimension and transaction flow to form a transaction behavior graph.

[0124] In this embodiment, each edge is timestamped according to the time of the transaction, and the direction of the edge is determined according to the flow of funds. At the same time, information such as transaction amount, transaction frequency, and association type are stored as attributes of the edge. Finally, a directed transaction behavior graph with both structural and attribute information is generated, which clearly presents the multi-level connection relationship between the target account and each associated account, and completely restores the transaction association network of the account.

[0125] The transaction behavior graph construction method provided in this application integrates scattered single-point transaction data into a structured relational network structure by identifying account entities and two types of association relationships. This not only preserves the attribute characteristics and transaction information of the account itself, but also fully presents the multi-level relational topology across accounts. It solves the problem of losing link association information in the traditional isolated feature processing method, and provides complete structural support for subsequent abnormal feature extraction.

[0126] Figure 5 A flowchart illustrating the steps of a transaction behavior graph construction method provided in this application embodiment is shown below. Figure 5As shown, a corporate transaction behavior graph is constructed using cleaned transaction records, business registration information, and industry characteristics as inputs.

[0127] The graph defines three types of nodes: corporate account nodes (attributes include account ID, bank, industry code, registered capital, and years of establishment), legal person nodes (attributes include legal person ID, name, and number of affiliated companies), and counterparty nodes (corporate or individual accounts); it also defines three types of edges: transaction edges (directed, attributes include transaction amount, transaction time, transaction frequency, and transaction purpose), control relationship edges (undirected, attributes include shareholding ratio and employment relationship), and industry-related edges (undirected, attributes include industry code and region code).

[0128] The construction process includes entity alignment (merging multiple accounts of the same enterprise into a single entity), time window division (generating dynamic graph slices by day), and graph feature extraction (calculating node centrality, transaction intensity, capital loop index, time series volatility, etc.). The completed graph is stored in a graph database (such as Neo4j), and the node feature vectors can be used by the graph embedding module.

[0129] Figure 6 This is a flowchart illustrating a low-dimensional embedding vector acquisition method provided in an embodiment of this application, as shown below. Figure 6 As shown, multi-order neighbor sampling and hierarchical feature aggregation are performed on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph, including:

[0130] S601. Using the target account node and associated account node in the transaction behavior graph as initial sampling nodes, random sampling based on node association weight is performed on the initial sampling nodes according to a preset order to filter effective neighbor nodes and form an effective neighbor structure.

[0131] In this embodiment, based on the graph embedding algorithm GraphSAGE, each initial node is first randomly sampled according to the transaction association weight. The higher the weight, the greater the probability of the neighbor node being sampled. Each sampling order does not exceed a preset fixed number of neighbor nodes to avoid the feature aggregation computation volume from being too large for a single node. Finally, an effective neighbor set of different orders corresponding to each initial node is obtained, forming a hierarchical neighbor structure.

[0132] S602. Determine the node neighborhood range and regularize the topological association relationship based on the effective neighbor structure. Based on the node's own attribute features, transaction behavior features corresponding to the associated edges, and association relationship features under the regularized topological association relationship, use the attention mechanism to perform feature aggregation layer by layer to extract the local neighborhood features of neighboring nodes.

[0133] In this embodiment, following a hierarchical order, the features of first-order neighbor nodes are first aggregated to generate the first-order fusion feature of the current node. Then, based on the first-order fusion feature, the features of second-order neighbor nodes are further aggregated, and so on, to complete the hierarchical aggregation of multi-order neighborhood features. An attention mechanism is introduced during the aggregation process to assign differentiated attention weights to neighbor nodes with different association strengths. Neighbor nodes with closer transaction associations and stronger subject associations will be assigned higher weights, making feature aggregation more in line with the actual degree of association. Finally, a fusion feature containing local neighborhood association information is extracted.

[0134] S603. Using an inductive learning mechanism, the node features of the target account are concatenated, normalized, and nonlinearly transformed with the local neighborhood features of neighboring nodes to obtain high-dimensional fusion features.

[0135] In this embodiment, based on the inductive learning framework, feature embedding of newly added nodes can be generated without a fixed graph structure. The original attribute features of the node itself are concatenated with the multi-level neighborhood fusion features obtained by aggregation, and then the feature distribution is unified through batch normalization. Finally, the feature is input into a fully connected layer to complete the nonlinear transformation and map to obtain a high-dimensional fusion feature containing the node's own information and multi-level neighborhood association information.

[0136] S604. Taking the representation of the low-dimensional embedding vector as the optimization objective, the feature weights are optimized through multiple rounds of iterative training. Based on the optimized feature weights, the high-dimensional fusion features are subjected to dimensionality reduction and compression processing to obtain the low-dimensional embedding vectors of each node in the transaction behavior graph.

[0137] In this embodiment, neighborhood contrast loss is set as the training optimization objective, constraining the embedding distance of similar structural nodes to be closer and the distance of dissimilar structural nodes to be farther. The feature weights of the fully connected layer are adjusted through multiple rounds of training. After training is completed, the high-dimensional fused features are reduced in dimensionality by the optimized fully connected layer, and a low-dimensional embedding vector with uniform dimension is output. This vector contains both the attribute information of the target node itself and the association structure information of the multi-layer neighborhood, which can provide a more comprehensive feature input for subsequent anomaly scoring.

[0138] This application provides a method for obtaining low-dimensional embedding vectors. Through multi-level weighted sampling, attention-level aggregation, and inductive dimensionality reduction, high-dimensional graph information is transformed into low-dimensional vectors that can be directly processed by computers while retaining key structural and attribute information. This method controls the feature dimension, reduces the subsequent computational load, and fully preserves the multi-layered association information between accounts, thus solving the problem that large-scale transaction graphs cannot be directly input into anomaly detection models.

[0139] Figure 7 A flowchart illustrating the steps of a low-dimensional embedding vector acquisition method provided in this application embodiment is shown below. Figure 7As shown, the graph embedding module uses the GraphSAGE algorithm to perform inductive learning on graph nodes and generate low-dimensional vector representations.

[0140] The input features include node features and edge features: node features are composed of transaction statistics features and business registration features, while edge features are the logarithm of transaction amount and transaction time difference. The algorithm consists of three steps: First, two-hop neighbor sampling is performed on each target node. Within its two-hop range, 10 neighboring nodes are sampled at each layer to form a sampled subgraph; second, feature aggregation is performed through two layers of Mean aggregators. The first layer aggregates first-order neighbor features, and the second layer aggregates second-order neighbor features (the aggregation function is to average the neighbor features); finally, a 128-dimensional node embedding vector is output.

[0141] This low-dimensional embedding vector acquisition method is trained using an unsupervised learning approach. It employs a negative sampling mechanism to increase the similarity of embedding vectors between adjacent nodes and decrease the similarity between non-adjacent nodes. Furthermore, it retrains weekly using data from the past six months. During the inference phase, for newly added nodes, embedding vectors can be directly generated using a pre-trained aggregation function, supporting real-time incremental updates.

[0142] Figure 8 This is a flowchart illustrating a method for obtaining target anomaly scores provided in an embodiment of this application, as shown below. Figure 8 As shown, the step of determining the global anomaly score and local anomaly score of the target account node based on the node's low-dimensional embedding vector, and then weighting and fusing the global anomaly score and local anomaly score to obtain the target anomaly score includes:

[0143] S801. Construct training data, which is composed of low-dimensional embedding vectors of historical normal transaction nodes and account business features.

[0144] In this embodiment, account nodes that have been manually verified and confirmed to have no abnormal transaction behavior in historical data are selected, their corresponding low-dimensional embedding vectors are extracted, and business statistical features such as the account's own transaction frequency, transaction amount volatility, and industry deviation are concatenated to form a training dataset containing only normal samples, which is used to train an unsupervised anomaly detection model.

[0145] S802. Using the training data, train the isolation forest model and the autoencoder model respectively to obtain the parameters of the isolation forest model, the parameters of the autoencoder model, and the reconstruction error threshold.

[0146] In this embodiment, the isolated forest model and the autoencoder model are trained on the training dataset respectively: the isolated forest model calculates the abnormal path length of each sample by randomly splitting the feature space and outputs the corresponding abnormal score; the autoencoder model learns the feature distribution of normal samples by compressing features through the encoder and reconstructing features through the decoder, and uses the reconstruction error as the basis for abnormal judgment; after training, the parameters of the two models are saved respectively, and the corresponding reconstruction error threshold and isolated forest abnormal score threshold are determined based on the abnormal scores and reconstruction error distribution of normal samples in the validation set, for subsequent abnormality determination.

[0147] S803. Construct a sample to be detected, wherein the sample to be detected is composed of a low-dimensional embedding vector of the node to be detected and the corresponding account business features.

[0148] In this embodiment, the generated low-dimensional embedding vector of the target account to be detected is extracted, and the transaction statistics business features of the account within a preset period are concatenated to form a sample to be detected that can be input into the model, ensuring that the dimension of the input features remains consistent with that of the training stage.

[0149] S804. Input the sample to be detected into the trained isolation forest model and autoencoder model respectively to obtain the global anomaly score and local reconstruction error of the target account node.

[0150] In this embodiment, the sample to be detected is processed by two models: the isolated forest model calculates the global anomaly score based on the segmentation path of the sample in the feature space, which reflects the degree of deviation of the sample to be detected from the overall normal sample distribution; the autoencoder model calculates the reconstruction error between the input sample and the reconstructed sample based on the result of encoding, compression and then decoding, which reflects the degree of local difference between the sample to be detected and the learned normal feature distribution.

[0151] S805. The local reconstruction error is compared with the reconstruction error threshold. If the local reconstruction error exceeds the preset reconstruction error threshold, the local reconstruction error is normalized to obtain a local anomaly score. Otherwise, the local anomaly score is assigned to zero.

[0152] In this embodiment, if the local reconstruction error does not exceed the preset reconstruction error threshold, it means that the difference between the feature distribution of the sample to be detected and the normal feature distribution learned by the model is within an acceptable range, and it is determined that there is no anomaly at the local feature level in the sample. Therefore, the local anomaly score is directly recorded as zero. If the local reconstruction error exceeds the preset threshold, it means that the feature distribution of the sample to be detected deviates from the normal distribution to a high degree. At this time, the reconstruction error exceeding the threshold is normalized according to the maximum error range and mapped to the [0,1] interval to obtain a standardized local anomaly score. The higher the score, the more significant the deviation of the local features from the normal distribution.

[0153] S806. Perform a weighted fusion calculation on the global anomaly score and the local anomaly score according to the preset weights to obtain the target anomaly score corresponding to the target account node.

[0154] In this embodiment, the preset weights are weight coefficients pre-set based on business risk control strategies and historical model performance, corresponding to global anomaly scores and local anomaly scores, respectively. The two types of anomaly quantification results from different dimensions are integrated into a unified target anomaly score through weighted fusion, so as to comprehensively reflect the overall deviation and local anomaly degree of the target account in the transaction behavior graph, and provide a unified quantitative basis for subsequent risk control rule matching and risk level determination.

[0155] The target anomaly score acquisition method provided in this application combines the global anomaly detection capability of isolated forest with the local feature deviation recognition capability of autoencoder, thereby achieving quantitative integration of multi-dimensional anomaly degree. It can identify global anomaly behaviors that deviate from the overall distribution, as well as capture subtle deviations at the local feature level, effectively improving the comprehensiveness and accuracy of anomaly detection and avoiding the problem of missed detections and misjudgments by a single model.

[0156] Figure 9 A flowchart illustrating the steps of a method for obtaining target anomaly scores provided in this application embodiment is shown below. Figure 9 As shown, a dual detection model of Isolation Forest and AutoEncoder is adopted to detect anomalies from two dimensions: global distribution anomalies and local reconstruction anomalies. The final anomaly score is output through weighted fusion.

[0157] In the training phase, Isolation Forest takes node embedding vectors (128-dimensional) and handcrafted features as input. These handcrafted features include prior statistics such as transaction frequency Z-score, amount Z-score, and counterparty diversity index, serving both guiding and complementary roles in training: directly encoding business experience into numerical signals, helping the model quickly focus on suspicious dimensions and reducing blind searches in the early stages of training; and compensating for the insensitivity of graph embedding to statistical outliers, enabling anomaly detection to consider both structural correlation and statistical bias. In short, handcrafted features accelerate model convergence and enhance its ability to identify explicit anomalous behavior. During training, 100 isolated trees are constructed, with 256 samples sampled from each subtree. The extended isolated forest algorithm is used to eliminate axis alignment bias, and model parameters are saved after training. The AutoEncoder takes node embedding vectors as input, with a network structure of 128-64-32-64-128, and is trained using the Adam optimizer and MSE loss function. The 95th quantile of the reconstruction error in the training set is set as the anomaly detection threshold.

[0158] Inference Phase: New samples are the direct targets of detection actions (without new samples, risk assessment of real-time transactions or new accounts is impossible, and the system will lose the practical significance of online monitoring), requiring input to two models simultaneously. At this point, the Isolation Forest and Autoencoder have learned the distribution threshold from historical normal data: Isolation Forest outputs anomaly scores SIF∈[0,1]; Autoencoder calculates the reconstruction error, and if it exceeds the threshold, it is normalized to SAE, otherwise SAE=0; combined with the rule hit rate Srule obtained by the rule verification module, the final anomaly score is calculated according to the formula Sfinal=0.4SIF+0.4SAE+0.2Srule; and risk levels are divided according to Sfinal: low risk [0,0.3), medium risk [0.3,0.7), and high risk [0.7,1].

[0159] It should be noted that the model is generally retrained weekly using data from the past 6 months, and feedback samples that are manually reviewed are used for continuous model optimization.

[0160] Figure 10 This is a flowchart illustrating a method for determining anomaly risk detection results provided in an embodiment of this application, as shown below. Figure 10 As shown, the step of calling the preset rule engine and determining the abnormal risk detection result of the target account based on the matching result of the target anomaly score and the preset rule includes:

[0161] S1001. Call the preset rule engine and load the risk control rules of the regulatory rule base and the custom rule base.

[0162] In this embodiment, the preset rule engine has built-in compliance risk control rules required by regulatory authorities and business rules customized by business parties according to their own risk control needs. When the detection is started, all effective rules in the two types of rule bases are loaded directly to prepare for subsequent rule matching.

[0163] S1002. Input the target abnormal score and corresponding transaction behavior data of the target account into the preset rule engine, combine the quantitative range of the target abnormal score with the transaction behavior characteristics, match the risk control rules, and determine the initial risk level of the target account.

[0164] In this embodiment, the rule engine will match the rule conditions one by one according to the specific transaction behavior of the target account, and make a comprehensive judgment based on the risk range corresponding to the target abnormal score. If multiple risk control rules are matched, the highest value will be taken as the initial risk level according to the risk level corresponding to the rule. If no rule is matched, the risk level corresponding to the target abnormal score will be used as the initial result.

[0165] S1003. If the risk control rule matched by the target abnormal score is a preset regulatory rule, then the risk level of the target account is increased according to the risk level increase rule of the preset regulatory rule; otherwise, the risk level of the target account is maintained at the initial risk level.

[0166] In this embodiment, when the target account matches a regulatory risk control rule, it indicates that the account's transaction behavior has triggered compliance regulatory requirements. At this time, the initial risk level of the target account needs to be increased according to the risk level upgrade standard preset by the regulatory rule to ensure that regulatory compliance requirements are rigidly implemented in the risk assessment process. If the target account only matches a custom business rule or does not match any risk control rule, its initial risk level remains unchanged and no additional adjustment is required.

[0167] S1004. Generate a corresponding risk rating label based on the risk level of the target account, and generate a suspicious transaction chain report for the target account based on the matching risk control rules and the transaction behavior data of the target account, thereby obtaining the abnormal risk detection result of the target account.

[0168] In this embodiment, corresponding risk labels are generated based on the final determined risk level. For example, high-risk labels are marked as "highly suspicious", medium-risk labels are marked as "pending verification", and low-risk labels are marked as "low-risk attention". At the same time, related transaction links in the transaction behavior graph of the target account are automatically extracted. The risk control rule descriptions and abnormal score results are integrated to generate a structured suspicious transaction chain report, which fully presents the basis for judging account abnormality and related transaction paths. Finally, the risk labels and suspicious transaction chain reports are integrated to output the final abnormal risk detection result of the target account, providing a clear and complete basis for judgment and data support for subsequent manual review and risk handling.

[0169] The method for determining abnormal risk detection results provided in this application combines model quantification results with a rule engine, which not only leverages the model's intelligent ability to identify abnormal behavior but also ensures the rigid implementation of regulatory compliance requirements. It balances the intelligence and compliance of abnormal detection, and the hierarchical labeling and suspicious transaction chain reporting provide clear and actionable output results for subsequent risk control and disposal, reducing the information sorting costs of manual review and improving the overall efficiency of risk control and disposal.

[0170] Figure 11 A flowchart illustrating the steps of an anomaly risk detection result determination method provided in this application embodiment is shown below. Figure 11 As shown, the rule verification module integrates the regulatory rule base and custom supplementary rules to perform dual verification on the candidate samples output by the anomaly detection module.

[0171] The regulatory rule base includes mandatory risk control rules that meet compliance requirements, such as rules based on anti-money laundering regulations and central bank regulatory requirements, such as "single transaction amount exceeding a preset threshold", "frequent large transactions in a short period of time", and "transactions with high-risk / sanctioned entities". The custom supplementary rule base is built based on transaction behavior graph characteristics and business risk control experience, such as "funds closed-loop index exceeding a preset threshold", "transaction frequency surging more than a preset multiple compared to historical average", and "funds from multiple accounts being consolidated and transferred to a single account".

[0172] The verification process specifically includes the following steps:

[0173] Step 1: The rule engine matches each rule to the candidate sample and records the rule identifier and the number of matches.

[0174] Step 2: If a candidate sample matches any regulatory rule, the initial risk level of the target account will be increased according to the preset risk level enhancement standard.

[0175] Step 3: Based on the target account's abnormal score and hit rules, generate a final risk label of high, medium, or low.

[0176] Step 4: Synchronously generate a suspicious transaction chain report. The report includes the abnormal transaction chain, the list of rules that were hit, the transaction details, and the final risk level information.

[0177] In addition, after business personnel complete manual review and provide feedback, false alarm samples and confirmed risk samples are recorded for subsequent rule weight adjustments and iterative optimization of the anomaly detection model, thereby achieving closed-loop optimization and continuous improvement of the account anomaly detection system.

[0178] Figure 12 This is a flowchart illustrating a method for generating a suspicious transaction chain report, as provided in an embodiment of this application. Figure 12 As shown, the generation of a suspicious transaction chain report for the target account based on matching risk control rules includes:

[0179] S1201. Starting from the target account node, associate the risk control rules for this match, the target account's target abnormal score, and the corresponding transaction behavior data.

[0180] In this embodiment, the target account is the core, and all transaction nodes directly or indirectly related to the account in the transaction behavior graph are traversed. The basic account information, transaction flow, related entity information and the target anomaly score and hit risk control rule information that are scattered in different dimensions are associated and integrated to provide complete data source support for subsequent link sorting and summary.

[0181] S1202. Based on the transaction behavior data, construct a multi-level transaction link that includes transaction object, transaction time, transaction amount, and transaction flow direction.

[0182] In this embodiment, the flow path of transaction funds is analyzed and extended layer by layer. Starting from the target account, the counterparty of the transfer is linked level by level, and the next level of the counterparty's transaction object is linked. The entire link flow of funds from transfer to final collection is completely restored. At the same time, core information such as the time, amount and account type of the corresponding transaction is marked at each level node, forming a clear and visualized transaction link structure, avoiding the clutter and omission of link information, and fully presenting the actual flow trajectory of funds.

[0183] S1203. Based on the matching risk control rules, transaction time and transaction amount, identify and mark suspicious transaction nodes in the multi-level transaction chain.

[0184] In this embodiment, by combining the triggering conditions of the risk control rules, the corresponding transaction nodes that meet the triggering conditions are marked as suspicious nodes. At the same time, the specific rule name and triggering conditions that the node is matched are marked, which makes it convenient for reviewers to quickly locate the core suspicious links and intuitively grasp the specific location where the anomaly occurred.

[0185] S1204. Integrate all marked suspicious transaction nodes with complete transaction chain information to generate a suspicious transaction chain report containing a complete risk tracing chain.

[0186] In this embodiment, all the integrated and sorted information is structured and packaged according to a preset report template to form a complete report containing three modules: core risk summary, full-chain transaction graph, and detailed description. This facilitates a quick overview of the overall risk situation and also supports penetrating to view detailed transaction information, meeting the risk viewing needs in different scenarios.

[0187] Figure 13 A flowchart illustrating the steps of a method for generating a suspicious transaction chain report, as provided in this application embodiment, is shown below. Figure 13 As shown, taking the case of Company A having funds flowing out to Company B, Company C, and Company D as an example, the visualization and early warning push module presents the detection results to the bank's account manager in an intuitive form.

[0188] For example, for high-risk samples, early warning information is automatically pushed through the bank's internal workflow platform, email, or SMS. The content includes basic information about the high-risk account, the anomaly score S_final, the risk level, and a suspicious transaction chain report in PDF format. After the account manager completes manual review, the confirmation result (confirming anomaly / false alarm) is fed back to the system. The feedback data is stored in the feedback database for subsequent model iteration and optimization, forming a complete closed loop.

[0189] The visualized fund flow chart adopts an interactive design: nodes represent accounts, directed edges represent fund flows, and transaction amounts and times are marked on the edges; high-risk accounts are highlighted with thick dashed borders, and suspicious transactions are marked with dashed lines; hovering the mouse allows you to view transaction details, and clicking on nodes allows you to view business information (such as shareholders, legal persons, related companies, etc.).

[0190] Figure 14 A flowchart illustrating the steps of an account anomaly detection method provided in this application is shown below. Figure 14 As shown, the enterprise account anomaly detection method based on transaction behavior graph consists of six core functional modules. The data and control flow between the modules work together to realize the entire process of anomaly detection from data collection to early warning push.

[0191] Data acquisition module: responsible for acquiring transaction records of corporate accounts, information on business-related entities, and industry benchmark characteristic data from the bank's core system, business registration data platform, and industry databases, respectively, to provide multi-source heterogeneous data support for subsequent processing;

[0192] Graph Construction Module: Based on the collected standardized data, construct a graph of enterprise transaction behavior with enterprise accounts, legal persons, and counterparties as nodes and transaction relationships, control relationships, and industry association relationships as edges, forming a structured data model containing topological relationships;

[0193] Graph embedding module: The GraphSAGE algorithm is used to perform inductive learning on the transaction behavior graph. Through multi-order neighbor sampling and hierarchical feature aggregation, a low-dimensional vector representation of each account node is generated to characterize the behavioral characteristics of the node in the transaction network.

[0194] Anomaly Detection Module: A dual detection model is constructed by combining Isolation Forest and AutoEncoder. The model takes low-dimensional node embedding vectors and account business features as inputs, calculates global anomaly scores and local anomaly scores respectively, and obtains the target anomaly score through weighted fusion to identify abnormal transaction behaviors that deviate from industry norms.

[0195] Rule verification module: Integrates regulatory rule base and custom supplementary rules, performs dual verification on target accounts output by anomaly detection module, generates high, medium and low risk labels based on anomaly score and rule matching results, and simultaneously generates suspicious transaction chain report containing transaction link, hit rule and transaction details;

[0196] Early warning push module: Automatically pushes risk warning information and visualized fund flow charts to the bank's customer manager terminal, supporting manual review and result feedback.

[0197] During operation, data flows sequentially from the data acquisition module through the graph construction module, graph embedding module, anomaly detection module, and rule verification module, and finally the early warning push module outputs the detection results to the business terminal. Among them, the low-dimensional vector of nodes generated by the graph embedding module serves as the key input feature of the anomaly detection module. The target anomaly score output by the anomaly detection module is combined with the rule matching results of the rule verification module to jointly support the final risk assessment. The review feedback results of the account manager can feed back into the model training and rule optimization stages, realizing the closed-loop iteration and continuous optimization of the account anomaly detection system.

[0198] Figure 15 This is a schematic diagram of the structure of an account anomaly detection device provided in an embodiment of this application, as shown below. Figure 15 As shown, the device specifically includes:

[0199] The acquisition module 1501 is used to acquire multi-source heterogeneous financial data of the target account through real-time message queue, data interface and batch extraction loading method, and to preprocess the multi-source heterogeneous financial data to obtain a standardized dataset.

[0200] The construction module 1502 is used to construct a transaction behavior graph based on entity relationships, with accounts and associated accounts as nodes and transactions and associated relationships as edges, using the standardized dataset as input.

[0201] The aggregation module 1503 is used to perform multi-level neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph.

[0202] The weighted fusion module 1504 is used to determine the global anomaly score and local anomaly score of the target account node based on the node's low-dimensional embedding vector, and to perform weighted fusion of the global anomaly score and local anomaly score to obtain the target anomaly score.

[0203] The determination module 1505 is used to call the preset rule engine and determine the abnormal risk detection result of the target account based on the matching result of the target abnormal score and the preset rule.

[0204] In one possible implementation, the acquisition module 1501 is further configured to connect to the financial business system via a real-time message queue to acquire transaction data of the target account in real time; call the entity information disclosure system through an open data interface to acquire related account data corresponding to the target account; import the industry benchmark information system through batch extraction and loading to acquire benchmark feature data corresponding to the industry dimension; merge the transaction data, related account data, and industry benchmark feature data to construct a multi-dimensional heterogeneous dataset containing transaction dimension, entity dimension, and industry dimension; perform noise removal and invalid transaction filtering on the multi-dimensional heterogeneous dataset to obtain first processed data; perform entity alignment and normalization merging on the account entities in the first processed data to obtain second processed data; perform adaptive filling on the missing fields of the second processed data, and perform truncation constraint processing on the values ​​that deviate from the normal distribution in the filled second processed data to obtain a standardized dataset.

[0205] In one possible implementation, the construction module 1502 is further configured to perform entity recognition on the standardized dataset, extract the associated accounts corresponding to the target account; obtain the transaction behavior between the target account and the associated accounts based on the transaction data in the standardized dataset; obtain the association relationship between the target account and the associated accounts based on the associated account data in the standardized dataset; and construct a directed topology structure to form a transaction behavior graph by using the target account and the associated accounts corresponding to the target account as graph nodes and the transaction behavior and association relationship between the target account and the associated accounts as graph edges, based on the time dimension and transaction flow direction.

[0206] In one possible implementation, the aggregation module 1503 is further configured to use the target account node and associated account node in the transaction behavior graph as initial sampling nodes, perform random sampling on the initial sampling nodes based on node association weights according to a preset order, filter effective neighbor nodes and form an effective neighbor structure; determine the node neighborhood range and regularize the topological association relationship according to the effective neighbor structure; based on the node's own attribute features, transaction behavior features corresponding to the associated edges and association relationship features under the regularized topological association relationship, perform feature aggregation layer by layer using an attention mechanism to extract the local neighborhood features of neighbor nodes; use an inductive learning mechanism to concatenate, normalize and nonlinearly transform the node features of the target account and the local neighborhood features of neighbor nodes to obtain high-dimensional fusion features; take the representation of low-dimensional embedding vectors as the optimization objective, optimize the feature weights through multiple rounds of iterative training, and perform dimensionality reduction and compression processing on the high-dimensional fusion features based on the optimized feature weights to obtain the low-dimensional embedding vectors of each node in the transaction behavior graph.

[0207] In one possible implementation, the weighted fusion module 1504 is further configured to construct training data, which is composed of low-dimensional embedding vectors of historical normal transaction nodes concatenated with account business features; train an isolated forest model and an autoencoder model using the training data to obtain the parameters of the isolated forest model, the parameters of the autoencoder model, and a reconstruction error threshold; construct a sample to be detected, which is composed of low-dimensional embedding vectors of the node to be detected concatenated with the corresponding account business features; input the sample to be detected into the trained isolated forest model and autoencoder model respectively to obtain the global anomaly score and local reconstruction error of the target account node; compare the local reconstruction error with the reconstruction error threshold; if the local reconstruction error exceeds the preset reconstruction error threshold, normalize the local reconstruction error to obtain the local anomaly score; otherwise, assign the local anomaly score to zero; and perform a weighted fusion calculation on the global anomaly score and the local anomaly score according to preset weights to obtain the target anomaly score corresponding to the target account node.

[0208] In one possible implementation, the determining module 1505 is further configured to invoke a preset rule engine, load risk control rules from a regulatory rule base and a custom rule base; input the target abnormal score of the target account and the corresponding transaction behavior data into the preset rule engine, combine the quantitative range of the target abnormal score with the transaction behavior characteristics, match the risk control rules, and determine the initial risk level of the target account; if the risk control rule matched by the target abnormal score is a preset regulatory rule, then the risk level of the target account is increased according to the risk level improvement rule of the preset regulatory rule; otherwise, the risk level of the target account is maintained at the initial risk level; generate a corresponding graded risk label based on the risk level of the target account, and generate a suspicious transaction chain report of the target account based on the matched risk control rules and the transaction behavior data of the target account, thereby obtaining the abnormal risk detection result of the target account.

[0209] In one possible implementation, the determining module 1505 is further configured to, starting from the target account node, associate the risk control rules matched this time, the target abnormal score of the target account, and the corresponding transaction behavior data; construct a multi-level transaction chain including transaction object, transaction time, transaction amount, and transaction flow based on the transaction behavior data; identify and mark suspicious transaction nodes in the multi-level transaction chain based on the matched risk control rules, transaction time, and transaction amount; integrate all marked suspicious transaction nodes with the complete transaction chain information to generate a suspicious transaction chain report containing a complete risk tracing chain.

[0210] The account anomaly detection device provided in this embodiment can be as follows: Figure 15 The account anomaly detection device shown can perform the following: Figures 1-14 All steps of abnormal account detection in China, thereby achieving Figures 1-14 For details on the technical effectiveness of the account anomaly detection, please refer to [link / reference]. Figures 1-14 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0211] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0212] Figure 16 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 16As shown, this application embodiment provides an electronic device, including a processor 1601, a communication interface 1602, a memory 1603, and a communication bus 1604. The processor 1601, the communication interface 1602, and the memory 1603 communicate with each other through the communication bus 1604. The memory 1603 is used to store computer programs. When the processor 1601 executes the program stored in the memory 1603, it implements the steps of the account anomaly detection method provided in any of the aforementioned method embodiments.

[0213] Multi-source heterogeneous financial data of the target account is collected through real-time message queues, data interfaces, and batch extraction loading methods. The multi-source heterogeneous financial data is preprocessed to obtain a standardized dataset. Using the standardized dataset as input, a transaction behavior graph is constructed based on entity relationships, with accounts and related accounts as nodes and transactions and related relationships as edges. Multi-level neighbor sampling and hierarchical feature aggregation are performed on the transaction behavior graph to obtain low-dimensional embedding vectors for each node. Based on the low-dimensional embedding vectors, the global anomaly score and local anomaly score of the target account node are determined. The global anomaly score and local anomaly score are weighted and fused to obtain the target anomaly score. A preset rule engine is invoked, and based on the target anomaly score and the matching result of the preset rules, the anomaly risk detection result of the target account is determined.

[0214] In one possible implementation, a real-time message queue is used to connect to the financial business system to collect transaction data of the target account in real time; an open data interface is used to call the entity information disclosure system to collect related account data corresponding to the target account; industry benchmark information system is imported through batch extraction and loading to collect benchmark feature data of the corresponding industry dimension; the transaction data, related account data, and industry benchmark feature data are fused to construct a multi-dimensional heterogeneous dataset containing transaction dimension, entity dimension, and industry dimension; noise removal and invalid transaction filtering are performed on the multi-dimensional heterogeneous dataset to obtain first processed data; entity alignment and normalization merging are performed on the account entities in the first processed data to obtain second processed data; missing fields in the second processed data are adaptively filled, and values ​​that deviate from the normal distribution in the filled second processed data are truncated and constrained to obtain a standardized dataset.

[0215] In one possible implementation, entity recognition is performed on the standardized dataset to extract associated accounts corresponding to the target account; based on transaction data in the standardized dataset, transaction behavior between the target account and associated accounts is obtained; based on associated account data in the standardized dataset, the association relationship between the target account and associated accounts is obtained; the target account and its corresponding associated accounts are used as graph nodes, and the transaction behavior and association relationship between the target account and associated accounts are used as graph edges. A directed topology structure is constructed according to the time dimension and transaction flow direction to form a transaction behavior graph.

[0216] In one possible implementation, the target account node and associated account node within the transaction behavior graph are used as initial sampling nodes. Random sampling based on node association weights is performed on the initial sampling nodes according to a preset order to filter effective neighbor nodes and form an effective neighbor structure. The node neighborhood range is determined based on the effective neighbor structure, and the topological association relationships are regularized. Based on the node's own attribute features, transaction behavior features corresponding to the associated edges, and association relationship features under the regularized topological association relationships, an attention mechanism is used to perform feature aggregation layer by layer to extract the local neighborhood features of neighbor nodes. Using an inductive learning mechanism, the node features of the target account and the local neighborhood features of neighbor nodes are concatenated, normalized, and nonlinearly transformed to obtain high-dimensional fusion features. With the representation of low-dimensional embedding vectors as the optimization objective, the feature weights are optimized through multiple rounds of iterative training. Based on the optimized feature weights, the high-dimensional fusion features are subjected to dimensionality reduction and compression processing to obtain the low-dimensional embedding vectors of each node in the transaction behavior graph.

[0217] In one possible implementation, training data is constructed, which consists of low-dimensional embedding vectors of historical normal transaction nodes concatenated with account business features. An isolated forest model and an autoencoder model are trained using this training data to obtain the parameters of the isolated forest model, the parameters of the autoencoder model, and a reconstruction error threshold. A sample to be detected is constructed, which consists of low-dimensional embedding vectors of the node to be detected concatenated with the corresponding account business features. The sample to be detected is input into the trained isolated forest model and autoencoder model to obtain the global anomaly score and local reconstruction error of the target account node. The local reconstruction error is compared with the reconstruction error threshold. If the local reconstruction error exceeds the preset reconstruction error threshold, the local reconstruction error is normalized to obtain a local anomaly score; otherwise, the local anomaly score is set to zero. The global anomaly score and the local anomaly score are weighted and fused according to preset weights to obtain the target anomaly score corresponding to the target account node.

[0218] In one possible implementation, a preset rule engine is invoked to load risk control rules from a regulatory rule base and a custom rule base. The target abnormal score of the target account and its corresponding transaction behavior data are input into the preset rule engine. Combining the quantitative range of the target abnormal score with the transaction behavior characteristics, the risk control rules are matched to determine the initial risk level of the target account. If the risk control rule matched by the target abnormal score is a preset regulatory rule, the risk level of the target account is increased according to the risk level enhancement rule of the preset regulatory rule; otherwise, the risk level of the target account is maintained at the initial risk level. A corresponding tiered risk label is generated based on the risk level of the target account, and a suspicious transaction chain report for the target account is generated based on the matched risk control rules and the transaction behavior data of the target account, thus obtaining the abnormal risk detection result of the target account.

[0219] In one possible implementation, starting from the target account node, the risk control rules matched this time, the target account's target anomaly score, and the corresponding transaction behavior data are associated; based on the transaction behavior data, a multi-level transaction chain including the transaction object, transaction time, transaction amount, and transaction flow is constructed; based on the matched risk control rules, transaction time, and transaction amount, suspicious transaction nodes in the multi-level transaction chain are identified and marked; all marked suspicious transaction nodes and complete transaction chain information are integrated to generate a suspicious transaction chain report containing a complete risk tracing chain.

[0220] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0221] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0222] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for detecting account anomalies, characterized in that, The method includes: Multi-source heterogeneous financial data of target accounts are collected through real-time message queues, data interfaces, and batch extraction and loading methods, and the multi-source heterogeneous financial data is preprocessed to obtain a standardized dataset. Using the standardized dataset as input, a transaction behavior graph is constructed based on entity relationships, with accounts and associated accounts as nodes and transactions and associated relationships as edges; Multi-level neighbor sampling and hierarchical feature aggregation are performed on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph; Based on the low-dimensional embedding vector, the global anomaly score and local anomaly score of the target account node are determined. The global anomaly score and local anomaly score are then weighted and fused to obtain the target anomaly score. This process includes: constructing training data, which is composed of low-dimensional embedding vectors of historical normal transaction nodes concatenated with account business features; training an isolated forest model and an autoencoder model using the training data to obtain the parameters of the isolated forest model, the parameters of the autoencoder model, and a reconstruction error threshold; constructing a sample to be detected, which is composed of low-dimensional embedding vectors of the node to be detected concatenated with the corresponding account business features; inputting the sample to be detected into the trained isolated forest model and autoencoder model to obtain the global anomaly score and local reconstruction error of the target account node; comparing the local reconstruction error with the reconstruction error threshold; if the local reconstruction error exceeds the preset reconstruction error threshold, normalizing the local reconstruction error to obtain the local anomaly score; otherwise, assigning the local anomaly score to zero; and weighting and fusing the global anomaly score and local anomaly score according to preset weights to obtain the target anomaly score corresponding to the target account node. The process involves invoking a preset rule engine and determining the abnormal risk detection result of the target account based on the matching result of the target anomaly score and the preset rule. This includes: invoking the preset rule engine and loading risk control rules from the regulatory rule library and the custom rule library; inputting the target anomaly score and corresponding transaction behavior data of the target account into the preset rule engine, and matching the risk control rules with the quantitative range of the target anomaly score and the transaction behavior characteristics to determine the initial risk level of the target account; if the risk control rule matched by the target anomaly score is a preset regulatory rule, then increasing the risk level of the target account according to the risk level improvement rule of the preset regulatory rule; otherwise, maintaining the initial risk level of the target account; generating a corresponding tiered risk label based on the risk level of the target account, and generating a suspicious transaction chain report for the target account based on the matched risk control rules and the transaction behavior data of the target account, thus obtaining the abnormal risk detection result of the target account. The process of generating a suspicious transaction chain report for the target account based on matching risk control rules includes: starting from the target account node, associating the matching risk control rules, the target account's target anomaly score, and the corresponding transaction behavior data; constructing a multi-level transaction chain including the transaction object, transaction time, transaction amount, and transaction flow based on the transaction behavior data; identifying and marking suspicious transaction nodes in the multi-level transaction chain based on the matching risk control rules, transaction time, and transaction amount; and integrating all marked suspicious transaction nodes with the complete transaction chain information to generate a suspicious transaction chain report containing a complete risk tracing chain.

2. The method according to claim 1, characterized in that, The process involves collecting multi-source heterogeneous financial data from target accounts through real-time message queues, data interfaces, and batch extraction and loading methods, and preprocessing the multi-source heterogeneous financial data to obtain a standardized dataset, including: By connecting to the financial business system through a real-time message queue, transaction data of the target account can be collected in real time. By calling the entity information disclosure system through open data interfaces, data of associated accounts corresponding to the target account can be collected. Import industry benchmark information systems through batch extraction and loading to collect benchmark feature data for corresponding industry dimensions; The transaction data, associated account data, and industry benchmark feature data are integrated to construct a multi-dimensional heterogeneous dataset that includes transaction dimension, subject dimension, and industry dimension; The multi-dimensional heterogeneous dataset is subjected to noise removal and invalid transaction filtering to obtain the first processed data. The account entities in the first processed data are subjected to entity alignment and normalization merging to obtain the second processed data; The missing fields of the second processed data are adaptively filled, and the values ​​that deviate from the normal distribution in the filled second processed data are truncated to obtain a standardized dataset.

3. The method according to claim 1, characterized in that, The process of constructing a transaction behavior graph based on entity relationships, using the standardized dataset as input, with accounts and related accounts as nodes and transactions and related relationships as edges, includes: Entity recognition is performed on the standardized dataset to extract the associated accounts corresponding to the target account; Based on the transaction data in the standardized dataset, obtain the transaction behavior between the target account and the associated account; Based on the associated account data in the standardized dataset, the association relationship between the target account and associated accounts is obtained; The target account and its associated accounts are used as graph nodes, and the transaction behavior and relationships between the target account and its associated accounts are used as graph edges. A directed topology is constructed based on the time dimension and transaction flow to form a transaction behavior graph.

4. The method according to claim 1, characterized in that, The process of performing multi-level neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph includes: Using the target account node and associated account node in the transaction behavior graph as the initial sampling node, random sampling based on node association weight is performed on the initial sampling node according to a preset order to filter effective neighbor nodes and form an effective neighbor structure; The effective neighbor structure is used to determine the neighborhood range of the nodes and regularize the topological association relationship. Based on the node's own attribute features, transaction behavior features corresponding to the associated edges and association relationship features under the regularized topological association relationship, the attention mechanism is used to perform feature aggregation layer by layer to extract the local neighborhood features of the neighboring nodes. By using an inductive learning mechanism, the node features of the target account are concatenated, normalized, and nonlinearly transformed with the local neighborhood features of neighboring nodes to obtain high-dimensional fusion features. With the low-dimensional embedding vector as the optimization objective, the feature weights are optimized through multiple rounds of iterative training. Based on the optimized feature weights, the high-dimensional fusion features are subjected to dimensionality reduction and compression processing to obtain the low-dimensional embedding vectors of each node in the transaction behavior graph.

5. An account anomaly detection device, characterized in that, The device includes: The data acquisition module is used to collect multi-source heterogeneous financial data of the target account through real-time message queues, data interfaces, and batch extraction and loading methods, and to preprocess the multi-source heterogeneous financial data to obtain a standardized dataset. The construction module is used to construct a transaction behavior graph based on entity relationships, with accounts and associated accounts as nodes and transactions and associated relationships as edges, using the standardized dataset as input. The aggregation module is used to perform multi-level neighbor sampling and hierarchical feature aggregation on the transaction behavior graph to obtain the low-dimensional embedding vector of each node in the transaction behavior graph. The weighted fusion module is used to determine the global anomaly score and local anomaly score of the target account node based on the low-dimensional embedding vector, and to perform weighted fusion of the global anomaly score and local anomaly score to obtain the target anomaly score. This includes: constructing training data, which is composed of low-dimensional embedding vectors of historical normal transaction nodes concatenated with account business features; training an isolated forest model and an autoencoder model using the training data to obtain the parameters of the isolated forest model, the parameters of the autoencoder model, and a reconstruction error threshold; constructing a sample to be detected, which is composed of low-dimensional embedding vectors of the node to be detected concatenated with the corresponding account business features; inputting the sample to be detected into the trained isolated forest model and autoencoder model to obtain the global anomaly score and local reconstruction error of the target account node; comparing the local reconstruction error with the reconstruction error threshold; if the local reconstruction error exceeds the preset reconstruction error threshold, normalizing the local reconstruction error to obtain the local anomaly score; otherwise, assigning the local anomaly score to zero; and performing weighted fusion calculation of the global anomaly score and local anomaly score according to preset weights to obtain the target anomaly score corresponding to the target account node. The determination module is used to invoke a preset rule engine and determine the abnormal risk detection result of the target account based on the target anomaly score and the matching result of the preset rule. This includes: invoking the preset rule engine and loading risk control rules from the regulatory rule library and the custom rule library; inputting the target anomaly score and corresponding transaction behavior data of the target account into the preset rule engine, combining the quantitative range of the target anomaly score with the transaction behavior characteristics, matching the risk control rules, and determining the initial risk level of the target account; if the risk control rule matched by the target anomaly score is a preset regulatory rule, then increasing the risk level of the target account according to the risk level improvement rule of the preset regulatory rule; otherwise, maintaining the risk level of the target account at the initial risk level; generating a corresponding graded risk label based on the risk level of the target account, and generating a suspicious transaction chain report of the target account based on the matched risk control rules and the transaction behavior data of the target account, thus obtaining the abnormal risk detection result of the target account. The process of generating a suspicious transaction chain report for the target account based on matching risk control rules includes: starting from the target account node, associating the matching risk control rules, the target account's target anomaly score, and the corresponding transaction behavior data; constructing a multi-level transaction chain including the transaction object, transaction time, transaction amount, and transaction flow based on the transaction behavior data; identifying and marking suspicious transaction nodes in the multi-level transaction chain based on the matching risk control rules, transaction time, and transaction amount; and integrating all marked suspicious transaction nodes with the complete transaction chain information to generate a suspicious transaction chain report containing a complete risk tracing chain.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the account anomaly detection method according to any one of claims 1 to 4.

7. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the account anomaly detection method according to any one of claims 1 to 4.

Images