Method, device and computer storage medium for detecting abnormal transaction behavior

Abstract

The application discloses a kind of detection methods, device and computer storage medium of abnormal transaction behavior, it is related to blockchain technology field.Therein, the method comprises: obtaining original transaction information from data lake, and the original transaction information is desensitized, and obtain desensitized transaction dataset;According to subject account number, obtain the customer identification and branch identification corresponding to subject account number from the preset mapping table, and based on subject account number, transaction associated account number, customer identification and branch identification, construct triad dataset;Based on triad dataset, construct graph structure;According to graph structure, call target model to classify inference on graph structure, obtain the classification result of abnormal transaction behavior;Based on the classification result of abnormal transaction behavior, generate detection report.The application solves the technical problem that the detection result is not reliable due to the dependence of centralized system in the prior art to process target financial data.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method, apparatus, and computer storage medium for detecting abnormal transaction behavior. Background Technology

[0002] With the large-scale development of bank acquiring business, the accurate identification and detection of abnormal bank account transaction behavior has become a core aspect of risk control for financial institutions. Existing technologies typically rely on a centralized data architecture, where business systems directly extract massive amounts of transaction data from the bank's data lake, combine this data with classification algorithms for feature extraction and anomaly detection, and finally output detection conclusions.

[0003] However, the aforementioned technical solutions heavily rely on centralized systems to process financial data, lacking a fully trusted execution environment and an immutable operation log mechanism. Because the access control boundaries of centralized servers are relatively static, the data processing logic is opaque, and operation logs are easily overwritten or modified, unauthorized access, internal violations, or external malicious attacks will undermine the underlying technical guarantees for data integrity, operational traceability, and the authenticity of results throughout the detection process. This "black box" centralized processing mechanism makes it difficult for detection conclusions to withstand independent verification and cross-checking, leading to technical deficiencies in the unreliability of the detection process due to reliance on centralized systems to process target financial data. This hinders the compliant deployment and large-scale application of intelligent risk control systems in acquiring scenarios.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and computer storage medium for detecting abnormal transaction behavior, so as to at least solve the technical problem in the prior art that the detection results are unreliable due to reliance on centralized systems to process target financial data.

[0006] According to one aspect of the embodiments of this application, a method for detecting abnormal transaction behavior is provided, comprising: responding to a target request authenticated via a blockchain network, obtaining original transaction information from a data lake, and performing desensitization processing on the original transaction information to obtain a desensitized transaction dataset, wherein the desensitized transaction dataset is obtained by encrypting the original transaction information, and the desensitized transaction dataset includes a principal account number, a transaction-related account number, a transaction amount, and a transaction time; obtaining a customer identifier and a branch identifier corresponding to the principal account number from a preset mapping table based on the principal account number, the transaction-related account number, the customer identifier, and the branch identifier, and constructing a triplet dataset based on the principal account number, the transaction-related account number, the customer identifier, and the branch identifier, wherein the triplet dataset is used to represent the ownership and transaction flow relationship of funds in financial accounts; constructing a graph structure based on the triplet dataset, wherein the graph structure is used to represent the flow and ownership relationship of funds between accounts; based on the graph structure, calling a target model through a secure off-chain call mechanism to perform classification reasoning on the graph structure to obtain a classification result of abnormal transaction behavior; and generating a detection report based on the classification result of abnormal transaction behavior.

[0007] Optionally, in response to a target request authenticated via the blockchain network, the original transaction information is retrieved from the data lake, including: receiving a target request initiated by a business person authenticated via the blockchain network through a client, wherein the target request includes a principal account number and a detection time range; and extracting the original transaction information of the principal account number within the detection time range from the data lake based on the principal account number and the detection time range.

[0008] Optionally, a triplet dataset is constructed based on the principal account number, transaction associated account number, customer identifier, and branch identifier, including: establishing a first relation set based on the attribution relationship between the principal account number and the customer identifier; establishing a second relation set based on the attribution relationship between the principal account number and the branch identifier; establishing a third relation set based on the transaction relationship between the principal account number and the transaction associated account number; and constructing a triplet dataset based on the first relation set, the second relation set, and the third relation set.

[0009] Optionally, based on the triplet dataset, a graph structure is constructed, including: using the main account number as the root node, constructing customer identifier nodes and branch identifier nodes associated with the main account number based on customer identifier and branch identifier, forming a first-level node set; using the transaction-related account number as the second-level node, establishing directed edges between the root node and the second-level nodes, wherein the directed edges use transaction amount and transaction time as edge attributes; and constructing a directed graph structure between the first-level node set and the second-level nodes based on the attribution and transaction relationships in the triplet dataset, and using the directed graph structure as the graph structure.

[0010] Optionally, based on the graph structure, the target model is invoked through an external security chain call mechanism to perform classification reasoning on the graph structure to obtain the classification result of abnormal trading behavior. This includes: converting the graph structure into a structured feature vector; matching the structured feature vector with a preset semantic template to generate prompt information, wherein the semantic template includes a set of rules for abnormal behavior semantic labels and feature thresholds, and the prompt information is used to trigger the classification reasoning of the target model; based on the prompt information, the target model is invoked through an external security chain call mechanism to perform classification reasoning to obtain the classification result of abnormal trading behavior. The target model is used to receive the prompt information and, through a multi-layer feature encoding and semantic mapping mechanism, convert the prompt information into a financial behavior semantic representation. Subsequently, through a preset classification decision boundary, the financial behavior semantic representation is matched and discriminated, and the classification result corresponding to the preset abnormal trading behavior category is output.

[0011] Optionally, based on the classification results of abnormal transaction behavior, a detection report is generated, including: associating the classification results with the corresponding subject account number, time range, graph structure, and semantic template that triggered the classification to form inspection data; performing signature verification and integrity verification on the inspection data, and generating an inspection certificate after the verification is passed; writing the inspection certificate into the blockchain ledger to complete the state update of the blockchain ledger, and generating a detection report based on the inspection certificate.

[0012] Optionally, after generating a detection report based on the classification results of abnormal transaction behavior, the method further includes: obtaining the subject account number, transaction-related account number, time range, graph structure, and semantic template that triggered the classification corresponding to the classification results, and constructing a feedback dataset; and updating the semantic template stored in the blockchain ledger based on the feedback dataset.

[0013] Optionally, based on the feedback dataset, the semantic template stored in the blockchain ledger is updated, including: obtaining newly emerging transaction patterns in the feedback dataset; and performing a first update operation and / or a second update operation on the semantic template stored in the blockchain ledger according to the newly emerging transaction patterns in the feedback dataset, wherein the first update operation is used to expand the abnormal behavior semantic labels in the semantic template, and the second update operation is used to adjust the feature thresholds in the semantic template.

[0014] According to another aspect of the embodiments of this application, an abnormal transaction behavior detection device is also provided, comprising: an acquisition unit, configured to, in response to a target request authenticated via a blockchain network, acquire original transaction information from a data lake and perform desensitization processing on the original transaction information to obtain a desensitized transaction dataset, wherein the desensitized transaction dataset is obtained by encrypting the original transaction information, and the desensitized transaction dataset includes a main account number, a transaction-related account number, a transaction amount, and a transaction time; a first construction unit, configured to, based on the main account number, acquire a customer identifier and a branch identifier corresponding to the main account number from a preset mapping table, and construct a triplet dataset based on the main account number, the transaction-related account number, the customer identifier, and the branch identifier, wherein the triplet dataset is used to represent the ownership and transaction flow relationship of funds in financial accounts; a second construction unit, configured to, based on the triplet dataset, construct a graph structure, wherein the graph structure is used to represent the flow and ownership relationship of funds between accounts; an inference unit, configured to, based on the graph structure, call a target model through a secure off-chain call mechanism to perform classification inference on the graph structure to obtain a classification result of abnormal transaction behavior; and a generation unit, configured to, based on the classification result of abnormal transaction behavior, generate a detection report.

[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located performs the above-described method for detecting abnormal transaction behavior.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors are caused to perform the above-described method for detecting abnormal transaction behavior.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for detecting abnormal transaction behavior.

[0018] In this embodiment, a unified scheduling and execution method using smart contracts deployed in a blockchain network is adopted. Through blockchain network identity authentication triggering, encryption and desensitization of raw transaction data, multi-dimensional identifier mapping and triple construction based on a preset mapping table, graph-based fund flow representation, and feature classification reasoning by calling the target model outside the secure chain, the massive and scattered raw transactions are transformed into a structured account relationship graph, and the abnormal behavior detection is completed. This achieves the closed-loop operation of the entire detection process in a trusted execution environment, which helps to achieve the technical effects of full encryption and desensitization of sensitive data, transparent and verifiable graph construction logic, and traceable processing results. This solves the technical problem of unreliable detection results caused by the reliance on centralized systems to process target financial data in the prior art. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a flowchart of an optional method for detecting abnormal transaction behavior according to an embodiment of this application;

[0021] Figure 2 This is an optional transaction execution flowchart according to an embodiment of this application;

[0022] Figure 3 This is an optional member service structure diagram according to an embodiment of this application;

[0023] Figure 4 This is a software structure diagram of an optional abnormal transaction behavior detection method according to an embodiment of this application;

[0024] Figure 5 This is an execution flowchart of an optional abnormal transaction behavior detection system according to an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of an optional abnormal transaction behavior detection device according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] According to an embodiment of this application, a method embodiment for detecting abnormal transaction behavior is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] According to the embodiments of this application, smart contracts can be used as the execution subject of the abnormal transaction behavior detection method of this application embodiment. Of course, the execution subject of the method in the embodiments of this application can also be other forms of execution subject, such as systems, devices, equipment, etc. It should be known by those skilled in the art that this application does not particularly limit the specific form of the execution subject.

[0030] Figure 1 This is a flowchart of an optional abnormal transaction behavior detection method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0031] Step S101: In response to the target request authenticated by the blockchain network, the original transaction information is obtained from the data lake, and the original transaction information is anonymized to obtain an anonymized transaction dataset. The anonymized transaction dataset is obtained by encrypting the original transaction information. The anonymized transaction dataset includes the main account number, the transaction associated account number, the transaction amount, and the transaction time.

[0032] Optionally, blockchain network identity authentication refers to a node permission verification mechanism based on consortium blockchain member service components and digital certificate system, used to confirm whether the request initiator has legitimate access rights.

[0033] Optionally, a data lake refers to a distributed data storage layer that centrally stores all bank acquiring transaction records, basic account information, and historical transaction logs.

[0034] Optionally, after receiving the target request submitted by the client, the smart contract first verifies the request's digital signature and the identity certificate issued by the blockchain network. Once the authorization is verified, the smart contract sends a data retrieval command to the data lake to extract the original transaction records within the specified time range. Subsequently, the smart contract performs data encryption and field filtering operations in the on-chain computing environment, replacing sensitive information such as customer name, ID number, and contact information with ciphertext or hash values, retaining only four core fields: the main account number, the transaction-related account number, the transaction amount, and the transaction time. This forms a de-identified transaction dataset, which is then temporarily stored in the working area.

[0035] Step S102: Based on the main account number, obtain the customer identifier and branch identifier corresponding to the main account number from the preset mapping table, and construct a triplet dataset based on the main account number, transaction-related account number, customer identifier and branch identifier. The triplet dataset is used to represent the ownership and transaction flow relationship of funds in the financial account.

[0036] Optionally, the preset mapping table refers to a static key-value mapping library that stores account hierarchy relationships and institutional affiliation relationships, usually hosted in encrypted form in the blockchain world state.

[0037] Optionally, the customer identifier refers to a globally unique business code that identifies a single legal person or natural person; the branch identifier refers to the management unit code that identifies the branch to which the funds clearing belongs.

[0038] Optionally, a triplet dataset refers to a structured data set consisting of a primary entity, relational attributes, and secondary entities, used to express the logical relationships between objects.

[0039] Optionally, the smart contract iterates through the anonymized transaction dataset, extracting the main account number from each record as a query key. Using this key, it retrieves the corresponding customer identifier and branch identifier from a pre-defined mapping table, and binds the search results to the transaction-related account number. Subsequently, the smart contract combines the main account number, transaction-related account number, customer identifier, and branch identifier into standardized triples according to a fixed format, and writes them sequentially into temporary storage space to form a complete triple dataset.

[0040] Step S103: Based on the triplet dataset, construct a graph structure, which is used to represent the flow and ownership relationships of funds between accounts.

[0041] Optionally, a graph structure refers to a relational data structure where nodes represent entities and directed edges represent fund flows. Fund flow refers to the one-way or two-way fund transfer paths between accounts due to transactions. Attribution relationship refers to the subordinate mapping relationship between an account and its customer identifier and its branch identifier.

[0042] Optionally, the smart contract reads the triplet dataset and instantiates the main account number, customer identifier, and branch identifier as independent nodes. For each transaction record, a directed edge is constructed, starting from the node corresponding to the main account number and ending at the node corresponding to the transaction-related account number, with transaction amount and transaction time attributes appended to the edge. Finally, all nodes and edges are connected according to topological rules, outputting a graph structure including multi-level entities and weighted paths.

[0043] Optionally, the establishment of the graph structure makes the complex patterns of hidden fund collection, decentralized transfer or circular transfer explicit, providing high-dimensional feature input for subsequent model recognition and improving the dimensional coverage of abnormal behavior capture.

[0044] Step S104: Based on the graph structure, the target model is invoked through the security chain external call mechanism to perform classification reasoning on the graph structure and obtain the classification results of abnormal transaction behavior.

[0045] Optionally, the secure off-chain call mechanism refers to a controlled interaction channel through which smart contracts send inference requests to off-chain high-performance computing environments and receive return results via pre-defined interface specifications and communication protocols.

[0046] Optionally, the target model refers to a classification algorithm or large language model trained in a financial scenario, capable of semantic parsing and category discrimination of fund flow patterns. The classification result refers to the abnormal transaction behavior type labels and their confidence indices output by the model.

[0047] Optionally, the smart contract serializes the graph structure into a structured feature vector and sends an inference request to the target model via a secure off-chain call mechanism. After receiving the feature vector, the target model performs multi-layer feature encoding and pattern matching operations in an off-chain environment, comparing it against preset abnormal behavior rule boundaries. Upon completion of the operations, the target model sends the classification result back to the smart contract, which then performs integrity verification on the returned data and writes it to disk.

[0048] Step S105: Generate a detection report based on the classification results of abnormal transaction behavior.

[0049] Optionally, the detection report refers to a structured document that summarizes the anomaly classification results, related account information, and a summary of map features, serving as a carrier of the detection conclusions.

[0050] Optionally, after receiving the classification results, the smart contract binds the classification results with the entity account number, time range, and graph structure characteristics that triggered the detection, and compiles the above content into a standardized report file according to a preset template, and completes digital signature and version fixing. After the report is generated, the smart contract synchronously updates the report and signature certificate to the blockchain ledger for authorized nodes to access and verify.

[0051] In one optional embodiment, in response to a target request authenticated via the blockchain network, obtaining raw transaction information from the data lake includes: receiving a target request initiated by a business person authenticated via the blockchain network through a client, wherein the target request includes a principal account number and a detection time range; and extracting raw transaction information of the principal account number within the detection time range from the data lake based on the principal account number and the detection time range.

[0052] Optionally, the target request refers to a standardized instruction package encapsulated by the client and sent to the blockchain network, where the main account number refers to the unique identifier of the core account of the fund flow to be detected, and the detection time range refers to the start and end time points of the transactions that need to be verified as specified by the business personnel.

[0053] Optionally, after business personnel enter the target entity account number and detection time range through the client, the client calls the software development kit provided by the blockchain network to generate a transaction proposal. The proposal, carrying the business personnel's digital signature and identity credentials, is submitted to the endorsing node. The endorsing node verifies the validity of the certificate and the channel access policy, and forwards the request to the smart contract after successful verification. The smart contract parses the request payload, extracts the entity account number and detection time range parameters, and completes the request receiving process.

[0054] Optionally, this step establishes a strict identity access control and permission isolation mechanism at the entry point of the detection process. Double security through cryptographic signatures and certificate verification helps ensure that only authorized business personnel can trigger data retrieval operations. Simultaneously, limiting the detection scope to designated accounts and time periods avoids the indiscriminate retrieval of all data, controlling the exposure of sensitive information from the source, and providing compliant data input boundaries for subsequent de-identification and graph construction.

[0055] Optionally, after receiving the verified target request parameters, the smart contract uses these parameters as a query index to initiate a data retrieval command to the data lake. The data lake storage engine locates the data using the principal account number as the primary key and constructs time interval filtering conditions based on the detection time range. The storage layer executes a joint query operation to filter out all transaction records that meet the conditions. The query results are returned to the smart contract's workspace in the form of structured data packets, completing the extraction of the original transaction information.

[0056] Figure 2 This is an optional transaction execution flowchart according to an embodiment of this application. For example... Figure 2As shown, the application client registers and obtains identity certificates for the login interface by calling member services. Next, the application client initiates a transaction proposal to the blockchain network. This proposal includes the smart contract identifier to be called, the contract method (the specific implementation logic of the smart contract method), parameter information (mandatory inputs required to call the corresponding smart contract and unique identifiers), and the client signature (an identifier of the client's transaction channel and a tag for identity verification). Upon receiving the transaction signature, the endorsement node verifies the signature and confirms the submitter's right to execute the operation. Simultaneously, it simulates the execution of the smart contract according to the endorsement strategy and returns the result and its respective signature to the application client. After receiving the information from the endorsement node, the application client determines whether the proposal result is consistent and whether it follows the specified endorsement strategy. Depending on the different scenarios involved in the executed smart contract (which may include data preprocessing, calling graph structure models and knowledge application, calling target models to classify visualization results, and outputting bank anomaly detection reports), the application client packages the data together, forms a transaction, signs it, and sends it to the sorting node. The sorting nodes perform consensus sorting on the received transactions, and finally package a batch of transactions together according to the block generation strategy to generate a new block, which is then sent to the committing nodes. After receiving the block, the committing nodes verify each transaction in the block, checking whether the inputs and outputs that the transaction depends on conform to the current state of the blockchain. After completion, they append the block to their local blockchain, modify the world state, and store the graph structure training results, relevant parameters of the target model, and information related to the detection report of abnormal bank behavior on the chain.

[0057] Figure 3 This is an optional member service structure diagram according to an embodiment of this application. For example... Figure 3 As shown, member services include root certification authorities, intermediate certification authorities, organizational units, administrators, certificate revocation, signing certificates, private keys, transport layer security root certification authorities, and transport layer security intermediate certification authorities.

[0058] In one optional embodiment, a triplet dataset is constructed based on the principal account number, the transaction associated account number, the customer identifier, and the branch identifier, including: establishing a first relation set based on the attribution relationship between the principal account number and the customer identifier; establishing a second relation set based on the attribution relationship between the principal account number and the branch identifier; establishing a third relation set based on the transaction relationship between the principal account number and the transaction associated account number; and constructing a triplet dataset based on the first relation set, the second relation set, and the third relation set.

[0059] Optionally, the smart contract reads the entity account number extracted from the anonymized transaction dataset and inputs it as a query key into a preset mapping table. After the mapping table returns the corresponding customer identifier, the smart contract combines the two into ownership record pairs in a fixed format. Then, it iterates through all account numbers and writes the generated ownership record pairs into the memory buffer sequentially to form a complete first relation set, thereby binding discrete transaction records with the ultimate responsible entity.

[0060] Optionally, while obtaining the customer identifier, the smart contract simultaneously retrieves the branch identifier field associated with the main account number from a pre-defined mapping table, pairs the main account number with the branch identifier, and sorts and deduplicates them according to institutional hierarchy. The pairing results are loaded in batches into an independent storage area to form a second relation set, thereby determining the institutional jurisdiction boundaries of fund transfers.

[0061] Optionally, the smart contract parses each transaction record in the anonymized transaction dataset, extracts the main account number and the transaction-related account number as interaction node pairs, and counts the number of times the same node pair appears within a specified period, as well as the corresponding transaction amount attributes. The statistical results are serialized and stored in key-value pair format, forming a third relation set including interaction strength and fund size characteristics, used to characterize the actual business context of fund transactions.

[0062] Optionally, the smart contract loads the first, second, and third relation sets and aligns them according to preset data fusion rules. Using the main account number as the primary key, customer identifiers, branch identifiers, and transaction-related account numbers are horizontally concatenated. The concatenated multi-source data is converted into a standardized triplet format and sequentially written to temporary storage space, completing the final assembly of the triplet dataset. This achieves structured integration of multi-source heterogeneous data, helps eliminate data silos, and allows subsequent graph calculations to simultaneously consider both ownership and behavioral dimensions.

[0063] In one optional embodiment, a graph structure is constructed based on the triplet dataset, including: using the main account number as the root node, constructing customer identifier nodes and branch identifier nodes associated with the main account number based on customer identifier and branch identifier, forming a first-level node set; using the transaction-related account number as the second-level node, establishing directed edges between the root node and the second-level nodes, wherein the directed edges use transaction amount and transaction time as edge attributes; and constructing a directed graph structure by combining the first-level node set and the second-level nodes based on the attribution and transaction relationships in the triplet dataset, and using the directed graph structure as the graph structure.

[0064] Optionally, the root node refers to the core anchoring entity in the graph structure, specifically the entity account number to be detected in this embodiment; the customer identifier node refers to the business identity coding mapping unit representing the actual ownership of funds; and the branch identifier node refers to the management unit coding mapping unit representing the fund clearing jurisdiction. The first-level node set refers to the static ownership dimension node group surrounding the root node.

[0065] Optionally, after reading the triplet dataset, the smart contract first extracts the main account number as the starting coordinate for topology construction. Then, according to preset mapping rules, it instantiates the corresponding customer identifier and branch identifier as independent node objects. Subsequently, the smart contract maintains node reference relationships in the in-memory computing environment, pointing the customer identifier node and branch identifier node to the main account number root node through the ownership relationship pointer. All generated ownership nodes are serialized and stored according to data structure specifications, and finally packaged to form the first-level node set.

[0066] Optionally, a second-level node refers to a mapping unit of a counterparty account that directly interacts with the main account. A directed edge refers to a topological connection with a direction indicator, used to represent a one-way or two-way transfer path of funds. Edge attributes refer to quantitative characteristic parameters attached to the connection, specifically transaction amount and transaction time in this embodiment.

[0067] Optionally, the smart contract iterates through the transaction flow records in the triplet dataset, instantiating the transaction-related account number in each record as a second-level node. Then, a directed edge is constructed, starting from the root node of the main account number and ending at the second-level node of the transaction-related account number. During construction, the smart contract synchronously reads the transaction amount and transaction time fields of the corresponding transaction record, encapsulates them as edge attribute objects, and binds them to the directed edge. All directed edges with attributes are attached to the root node and the second-level nodes according to topology rules, completing the digital mapping of dynamic interaction relationships.

[0068] Optionally, the smart contract loads the generated first-level node set and second-level node group, performs topological stitching based on predefined ownership and transaction relationship rules in the triplet dataset, and verifies the legality of connections between nodes, eliminating isolated nodes and invalid connections. This helps ensure that ownership mapping and fund interaction paths meet the connectivity requirements of graph theory. After successful verification, the smart contract encapsulates the complete node set, edge set, and attribute set into a standardized graph database format, outputs the final graph structure, and writes it to the on-chain working area.

[0069] Optionally, after generating the directed graph structure, the smart contract pushes the graph structure to the visualization rendering engine. The rendering engine reads the node type labels and edge attribute weights, and calls the layout algorithm to calculate the initial coordinates of each node in the two-dimensional canvas. Based on preset style rules, customer identifier nodes, branch identifier nodes, and second-level nodes are mapped to differentiated geometric shapes, and the edge thickness and transparency are gradient-colored according to the transaction amount and time decay rules. After rendering, the view data is synchronized to the client display layer, and business users can input filter conditions or drag and drop node positions through the control panel. Interactive operations only affect the front-end rendering layer, and real-time recording of view state change logs helps visual adjustments without reverse-modifying the on-chain graph structure itself.

[0070] In one optional embodiment, based on the graph structure, the target model is invoked through an external security chain call mechanism to perform classification reasoning on the graph structure to obtain the classification result of abnormal trading behavior. This includes: converting the graph structure into a structured feature vector; matching the structured feature vector with a preset semantic template to generate a prompt message, wherein the semantic template includes a set of rules for abnormal behavior semantic labels and feature thresholds, and the prompt message is used to trigger the classification reasoning of the target model; based on the prompt message, the target model is invoked through the external security chain call mechanism to perform classification reasoning to obtain the classification result of abnormal trading behavior, wherein the target model is used to receive the prompt message and, through a multi-layer feature encoding and semantic mapping mechanism, convert the prompt message into a financial behavior semantic representation, and then, through a preset classification decision boundary, matches and discriminates the financial behavior semantic representation, outputting a classification result corresponding to a preset abnormal trading behavior category.

[0071] Optionally, a structured feature vector refers to a fixed-length numerical sequence generated by mathematically mapping non-numerical topological relationships and attribute data, used to characterize node distribution density, cumulative edge weights, and connectivity features.

[0072] Optionally, the smart contract reads the metadata of the directed graph structure that has been written to disk, extracting the degree centrality, clustering coefficient, and cumulative transaction amount and time interval sequence of each node. Then, it calls a graph embedding algorithm to reduce the dimensionality of the multi-dimensional weights, minimizing redundant topological information. After calculation, the smart contract arranges the compressed numerical array according to a preset dimensional order, generates a structured feature vector, and temporarily stores it in the working area for subsequent template matching.

[0073] Optionally, the preset semantic template refers to the rule base stored in the blockchain, which includes a set of rules for abnormal behavior semantic tags and feature thresholds, used to define the judgment criteria for various abnormal transaction patterns.

[0074] Optionally, the prompt message refers to the structured trigger command generated after template matching, which carries the semantic label of successful matching, the subset of features that exceed the limit, and the associated threshold parameters.

[0075] Optionally, the smart contract loads a preset semantic template and compares the values ​​of each dimension in the structured feature vector with the feature thresholds embedded in the template. When a vector component reaches or exceeds a specified threshold range, the smart contract extracts the corresponding abnormal behavior semantic label and binds the subset of features that exceed the limit to the label. The smart contract encapsulates the above content according to a standard protocol and generates a prompt message. The prompt message only contains the necessary parameters to trigger inference, does not carry the original transaction data, and is the only entry signal for the execution of the target model.

[0076] Optionally, the smart contract packages the notification information and sends it to the target model's runtime environment via a secure off-chain call mechanism. Upon receiving the instruction, the target model initiates a multi-layer feature encoding module to perform deep analysis of the notification information, stripping away surface statistical features and extracting the non-linear correlation patterns of fund flows. Subsequently, a semantic mapping mechanism transforms the analysis results into a semantic representation of financial behavior and compares its similarity with a preset classification decision boundary. The smart contract receives the data returned by the model, verifies it with a digital signature, completes a state update, and outputs a classification result corresponding to a preset abnormal transaction behavior category. Here, the multi-layer feature encoding and semantic mapping mechanism refer to the computational layers within the model used to extract deep interaction patterns and construct semantic representations of financial behavior; the classification decision boundary refers to the probability threshold for category division pre-trained by the model, used to distinguish between normal and abnormal transactions.

[0077] Optionally, smart contracts achieve a complete closed loop from relationship quantification to rule filtering and then to deep semantic discrimination through the linkage of structured feature vector transformation, semantic template matching, prompt information generation and secure off-chain call mechanism.

[0078] In one optional embodiment, a detection report is generated based on the classification results of abnormal transaction behavior, including: associating the classification results with the corresponding subject account number, time range, graph structure, and semantic template that triggered the classification to form inspection data; performing signature verification and integrity verification on the inspection data, and generating an inspection certificate after the verification is passed; writing the inspection certificate into the blockchain ledger to complete the state update of the blockchain ledger, and generating a detection report based on the inspection certificate.

[0079] Optionally, after receiving the classification result, the smart contract retrieves the principal account number and time range parameters carried in the current target request from the working area. The smart contract reads the graph structure and extracts the semantic template identifier that triggered this inference. According to the preset data binding protocol, the smart contract aligns the classification result with the four basic elements and performs logical concatenation to generate a structured record containing complete contextual information, which is finally encapsulated as verification data and temporarily stored in a memory buffer.

[0080] Optionally, signature verification refers to the cryptographic operation of verifying the legitimacy of the data issuer's identity using an asymmetric encryption algorithm.

[0081] Optionally, integrity verification refers to comparing the degree of matching between the current state and the initial state of data using a hash algorithm to detect traces of tampering.

[0082] Optionally, the inspection certificate refers to an electronic certificate document that has been digitally signed and has tamper-proof properties, used to confirm the compliance and validity of the testing process.

[0083] Optionally, after loading the verification data, the smart contract calls the built-in cryptography library to perform a hash operation on the verification data to generate a digest value. The smart contract digitally signs the digest value using the institution's private key and binds the signature value to the verification data. Subsequently, the smart contract recalculates the hash value and cross-compares it with the digest contained in the signature. After verification, the smart contract packages the verification data bound to the signature, generates a verification credential with a unique serial number, and completes internal state marking.

[0084] Alternatively, a blockchain ledger refers to an immutable database that stores transaction records in block order in a distributed network.

[0085] Optionally, the smart contract calls the underlying ledger interface to submit the verification certificate as the transaction payload to the blockchain network. The smart contract listens for the block receipt returned by the network consensus to confirm that the verification certificate has been successfully appended to the latest block. The smart contract synchronously modifies its own state, recording the certificate hash value and effective time. Subsequently, the smart contract parses the core fields in the verification certificate, assembles text and chart elements according to preset formatting specifications, and generates a standardized inspection report. After the inspection report is bound to access permissions, it is pushed to the client interface for authorized access.

[0086] Optionally, the above steps, through multi-dimensional element association, cryptographic signature verification, ledger storage, and report generation, achieve a complete transformation from model inference results to compliance verification credentials. This mechanism not only facilitates end-to-end traceability and tamper-proof characteristics of verification data but also endows detection conclusions with cross-domain mutual recognition validity through the ownership confirmation capabilities of distributed ledgers. The overall solution completes the standardized encapsulation of detection business within the on-chain environment, enhancing the legal validity and business usability of risk control conclusions, and providing a reliable and transparent technical foundation for the governance of abnormal transactions in acquiring scenarios.

[0087] In an optional embodiment, after generating a detection report based on the classification results of abnormal transaction behavior, the method further includes: obtaining the subject account number, transaction-related account number, time range, graph structure, and semantic template that triggered the classification corresponding to the classification results, and constructing a feedback dataset; and updating the semantic template stored in the blockchain ledger based on the feedback dataset.

[0088] Optionally, after the smart contract completes the execution of the test report generation instruction, it retrieves all the context data retained from the workspace for this test process. The smart contract aligns the classification results, main account number, transaction-related account number, time range, graph structure, and semantic template identifier that triggered the classification. The smart contract removes redundant runtime logs according to a preset data binding protocol, packages the core elements into standardized records, and finally encapsulates them into a feedback dataset, temporarily storing it in a memory buffer.

[0089] Optionally, the smart contract loads the feedback dataset, extracts the classification result labels and graph feature distributions for cross-analysis, identifies rule coverage blind spots and misjudgment tendencies within the current threshold range, recalculates the feature thresholds based on a preset weight adjustment algorithm, and replaces the corresponding parameters in the original semantic template. The smart contract calls the underlying ledger interface to submit a state change transaction. After verification by the consensus node, the version overwrite and activation mark of the on-chain rule base are completed.

[0090] Optionally, the above steps combine to form a continuous optimization process for the intelligent detection workflow. By collecting all elements to build a feedback dataset, the smart contract establishes a data link between single detection decisions and long-term rule evolution. Based on the feedback dataset, on-chain template updates are driven, enabling dynamic optimization of detection thresholds and anomaly labels. This overcomes the rigidity and lag of traditional static rule bases, giving the risk control system self-learning and adaptive capabilities.

[0091] In one optional embodiment, updating the semantic template stored in the blockchain ledger based on the feedback dataset includes: obtaining newly emerging transaction patterns in the feedback dataset; and performing a first update operation and / or a second update operation on the semantic template stored in the blockchain ledger according to the newly emerging transaction patterns in the feedback dataset, wherein the first update operation is used to expand the abnormal behavior semantic labels in the semantic template, and the second update operation is used to adjust the feature thresholds in the semantic template.

[0092] Optionally, emerging transaction patterns refer to combinations and topological forms of fund flow characteristics that appear for the first time in the feedback dataset and have not yet been mapped to the on-chain historical rule base.

[0093] Optionally, the smart contract parses the graph structure and classification result fields in the feedback dataset to extract node degree distribution, edge weight sequence, and fund flow topological features. The smart contract then performs a similarity comparison operation between the extracted feature sequence and the on-chain registered historical pattern library. When the matching degree of the feature sequence is lower than a preset benchmark and does not match an existing rule index, the smart contract marks it as a newly emerging transaction pattern and writes it to a temporary cache, completing the pattern capture process.

[0094] Optionally, the smart contract reads newly emerging transaction patterns from the cache and generates corresponding candidate semantic tags for abnormal behavior based on their fund flow dimensions and associated account characteristics. The smart contract calls the on-chain template management interface to perform the first update operation, appending the candidate tags to the tag set of the semantic template according to the classification hierarchy. Simultaneously, the smart contract analyzes the feature value distribution of the newly emerging transaction patterns and calculates the deviation between historical false positive and false negative rates. Based on the deviation analysis results, the smart contract performs a second update operation, dynamically recalculating and overwriting the corresponding feature threshold parameters in the semantic template. All change operations are packaged into a state update transaction and submitted to the blockchain network. After verification by consensus nodes, the on-chain version iteration is completed.

[0095] Figure 4 This is a software structure diagram of an optional abnormal transaction behavior detection method according to an embodiment of this application. For example... Figure 4 As shown, the software structure of the abnormal transaction behavior detection method includes a smart contract design module, a target model prompt word design module, and a graph structure design module.

[0096] Figure 5 This is an execution flowchart of an optional abnormal transaction behavior detection system according to an embodiment of this application. Figure 5 As shown, the system incorporates a blockchain framework to ensure information immutability. The design includes on-chain data preprocessing, account data model construction, triple extraction and storage, graph visualization and knowledge application, classification of visualization results using the target model, and outputting anomaly detection reports based on the anomaly classification results, thus completing the system's execution flow. Subsequently, by designing a front-end interactive interface, identity authentication mechanism, endorsement nodes, and sorting nodes within the blockchain framework, a secure and controllable blockchain environment is achieved, enhancing the system's security. Furthermore, the graph visualization model, employing a graph structure design, initially identifies suspicious and abnormal transactions based on bank transaction data, visually representing key counterparty accounts and fund flows. Finally, prompts are designed to identify suspicious points through verification of key detection areas, highlighting relevant suspicious transactions and account behaviors in the report. A comprehensive analysis is also conducted based on customer transaction behavior information, transaction frequency, and the customer's identity as tagged by the system, ultimately outputting a specialized analysis report.

[0097] Figure 6 This is a schematic diagram of an optional abnormal transaction behavior detection device according to an embodiment of this application. According to another aspect of an embodiment of this application, an abnormal transaction behavior detection device is also provided, including: an acquisition unit 601, a first construction unit 602, a second construction unit 603, an inference unit 604, and a generation unit 605.

[0098] The system comprises the following components: Acquisition unit 601, which responds to a target request authenticated via the blockchain network, retrieves original transaction information from the data lake, and performs desensitization processing on the original transaction information to obtain a desensitized transaction dataset. This desensitized transaction dataset is obtained by encrypting the original transaction information and includes the main account number, transaction-related account number, transaction amount, and transaction time. First construction unit 602, based on the main account number, retrieves the corresponding customer identifier and branch identifier from a preset mapping table, and constructs a triplet dataset based on the main account number, transaction-related account number, customer identifier, and branch identifier. This triplet dataset represents the ownership and transaction flow relationship of funds in financial accounts. Second construction unit 603, based on the triplet dataset, constructs a graph structure, which represents the flow and ownership relationship of funds between accounts. Inference unit 604, based on the graph structure, calls the target model through a secure off-chain call mechanism to perform classification inference on the graph structure, obtaining classification results for abnormal transaction behaviors. Generation unit 605, based on the classification results of abnormal transaction behaviors, generates a detection report.

[0099] Optionally, the acquisition unit 601 includes: a receiving subunit, used to receive a target request initiated by a business person whose identity has been authenticated through the blockchain network via a client, wherein the target request includes a principal account number and a detection time range; and an extraction subunit, used to extract the original transaction information of the principal account number within the detection time range from the data lake based on the principal account number and the detection time range.

[0100] Optionally, the first construction unit 602 includes: a first construction subunit for establishing a first relation set based on the attribution relationship between the principal account number and the customer identifier; a second construction subunit for establishing a second relation set based on the attribution relationship between the principal account number and the branch identifier; a third construction subunit for establishing a third relation set based on the transaction relationship between the principal account number and the transaction-related account number; and a fourth construction subunit for constructing a triplet dataset based on the first relation set, the second relation set, and the third relation set.

[0101] Optionally, the second construction unit 603 includes: a first processing subunit, used to construct customer identifier nodes and branch identifier nodes associated with the main account number, based on the customer identifier and branch identifier, with the main account number as the root node, forming a first-level node set; a second processing subunit, used to establish directed edges between the root node and the second-level nodes, with the transaction-related account number as the second-level node, wherein the directed edges use transaction amount and transaction time as edge attributes; and a third processing subunit, used to construct a directed graph structure by combining the first-level node set and the second-level nodes, based on the attribution and transaction relationships in the triplet dataset, and using the directed graph structure as the graph structure.

[0102] Optionally, the inference unit 604 includes: a transformation subunit for converting the graph structure into a structured feature vector; a matching subunit for matching the structured feature vector with a preset semantic template to generate a prompt message, wherein the semantic template includes a set of rules for abnormal behavior semantic labels and feature thresholds, and the prompt message is used to trigger the classification inference of the target model; and an inference subunit for calling the target model to perform classification inference based on the prompt message through an external security chain call mechanism to obtain the classification result of abnormal transaction behavior, wherein the target model receives the prompt message and converts the prompt message into a financial behavior semantic representation through a multi-layer feature encoding and semantic mapping mechanism, and then matches and discriminates the financial behavior semantic representation through a preset classification decision boundary, and outputs a classification result corresponding to the preset abnormal transaction behavior category.

[0103] Optionally, the generation unit 605 includes: a first generation subunit, used to associate the classification result with the corresponding subject account number, time range, graph structure, and semantic template that triggers the classification to form verification data; a second generation subunit, used to perform signature verification and integrity verification on the verification data, and generate verification credentials after the verification is passed; and a third generation subunit, used to write the verification credentials into the blockchain ledger, complete the state update of the blockchain ledger, and generate a test report based on the verification credentials.

[0104] Optionally, the device for detecting abnormal transaction behavior further includes: a third construction unit, used to obtain the subject account number, transaction-related account number, time range, graph structure, and semantic template that triggers the classification corresponding to the classification result, and construct a feedback dataset; and an update unit, used to update the semantic template stored in the blockchain ledger based on the feedback dataset.

[0105] Optionally, the update unit includes: an acquisition subunit for acquiring newly emerging transaction patterns in the feedback dataset; and an update subunit for performing a first update operation and / or a second update operation on the semantic template stored in the blockchain ledger based on the newly emerging transaction patterns in the feedback dataset, wherein the first update operation is used to expand the abnormal behavior semantic labels in the semantic template, and the second update operation is used to adjust the feature thresholds in the semantic template.

[0106] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located performs the above-described method for detecting abnormal transaction behavior.

[0107] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors are caused to perform the above-described method for detecting abnormal transaction behavior.

[0108] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described method for detecting abnormal transaction behavior.

[0109] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0110] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0112] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0114] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0115] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for detecting abnormal transaction behavior, characterized in that, include: In response to a target request that has been authenticated via a blockchain network, the original transaction information is retrieved from the data lake and the original transaction information is anonymized to obtain an anonymized transaction dataset. The anonymized transaction dataset is obtained by encrypting the original transaction information and includes the main account number, the transaction associated account number, the transaction amount, and the transaction time. Based on the main account number, the customer identifier and branch identifier corresponding to the main account number are obtained from the preset mapping table. Based on the main account number, the transaction associated account number, the customer identifier, and the branch identifier, a triplet dataset is constructed, wherein the triplet dataset is used to represent the ownership and transaction flow relationship of funds in the financial account. Based on the triplet dataset, a graph structure is constructed, wherein the graph structure is used to represent the flow and ownership relationships of funds between accounts; Based on the graph structure, the target model is invoked through the external security chain call mechanism to perform classification reasoning on the graph structure and obtain the classification results of abnormal transaction behavior; A detection report is generated based on the classification results of the abnormal transaction behavior.

2. The method according to claim 1, characterized in that, In response to a target request authenticated via the blockchain network, raw transaction information is retrieved from the data lake, including: The system receives the target request initiated by a business person whose identity has been authenticated through the blockchain network via a client, wherein the target request includes the main account number and the detection time range; Based on the principal account number and the detection time range, the original transaction information of the principal account number within the detection time range is extracted from the data lake.

3. The method according to claim 1, characterized in that, Based on the principal account number, the transaction-related account number, the customer identifier, and the branch identifier, a triplet dataset is constructed, including: Based on the attribution relationship between the main account number and the customer identifier, a first relationship set is established; A second relationship set is established based on the attribution relationship between the main account number and the branch identifier; A third relationship set is established based on the transaction relationship between the main account number and the transaction-related account number; The triplet dataset is constructed based on the first relation set, the second relation set, and the third relation set.

4. The method according to claim 1, characterized in that, Based on the triplet dataset, a graph structure is constructed, including: Using the main account number as the root node, and based on the customer identifier and the branch identifier, construct customer identifier nodes and branch identifier nodes associated with the main account number to form a first-level node set; Using the transaction-related account number as the second-level node, a directed edge is established between the root node and the second-level node, wherein the directed edge uses the transaction amount and the transaction time as edge attributes; The first-level node set and the second-level node set are combined to construct a directed graph structure based on the ownership and transaction relationships in the triplet dataset, and the directed graph structure is used as the graph structure.

5. The method according to claim 1, characterized in that, Based on the aforementioned graph structure, the target model is invoked through an external security chain call mechanism to perform classification reasoning on the graph structure, resulting in a classification of abnormal transaction behaviors, including: The graph structure is converted into a structured feature vector; The structured feature vector is matched with a preset semantic template to generate a prompt message. The semantic template includes a set of rules for abnormal behavior semantic labels and feature thresholds. The prompt message is used to trigger the classification reasoning of the target model. Based on the aforementioned prompt information, the target model is invoked through an external security chain call mechanism to perform classification reasoning and obtain the classification result of abnormal transaction behavior. The target model is used to receive the prompt information and transform it into a financial behavior semantic representation through a multi-layer feature encoding and semantic mapping mechanism. Subsequently, the financial behavior semantic representation is matched and discriminated through a preset classification decision boundary, and the classification result corresponding to the preset abnormal transaction behavior category is output.

6. The method according to claim 1, characterized in that, Based on the classification results of the abnormal transaction behavior, a detection report is generated, including: The classification results are associated with the corresponding subject account number, time range, graph structure, and semantic template that triggered the classification to form verification data; The inspection data is subjected to signature verification and integrity verification, and an inspection certificate is generated after the verification is passed. The inspection certificate is written into the blockchain ledger, the state of the blockchain ledger is updated, and the inspection report is generated based on the inspection certificate.

7. The method according to claim 1, characterized in that, After generating a detection report based on the classification results of the abnormal transaction behavior, the method further includes: Obtain the subject account number, transaction-related account number, time range, graph structure, and semantic template that triggered the classification corresponding to the classification result, and construct a feedback dataset; Based on the feedback dataset, the semantic template stored in the blockchain ledger is updated.

8. The method according to claim 7, characterized in that, Based on the feedback dataset, update the semantic template stored in the blockchain ledger, including: Obtain newly emerging transaction patterns from the feedback dataset; Based on the newly emerging transaction patterns in the feedback dataset, a first update operation and / or a second update operation are performed on the semantic template stored in the blockchain ledger. The first update operation is used to expand the abnormal behavior semantic labels in the semantic template, and the second update operation is used to adjust the feature thresholds in the semantic template.

9. A device for detecting abnormal transaction behavior, characterized in that, include: The acquisition unit is used to respond to a target request that has been authenticated by the blockchain network, acquire the original transaction information from the data lake, and perform de-identification processing on the original transaction information to obtain a de-identified transaction dataset. The de-identified transaction dataset is obtained by encrypting the original transaction information. The de-identified transaction dataset includes the main account number, the transaction associated account number, the transaction amount, and the transaction time. The first construction unit is used to obtain the customer identifier and branch identifier corresponding to the main account number from a preset mapping table according to the main account number, and construct a triplet dataset based on the main account number, the transaction associated account number, the customer identifier and the branch identifier, wherein the triplet dataset is used to represent the ownership and transaction flow relationship of funds in the financial account; The second construction unit is used to construct a graph structure based on the triplet dataset, wherein the graph structure is used to represent the fund flow and ownership relationship between accounts; The reasoning unit is used to perform classification reasoning on the graph structure by calling the target model through the security chain external call mechanism based on the graph structure, and obtain the classification result of abnormal transaction behavior; The generation unit is used to generate a detection report based on the classification results of the abnormal transaction behavior.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the abnormal transaction behavior detection method according to any one of claims 1 to 8.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the abnormal transaction behavior detection method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the method for detecting abnormal transaction behavior as described in any one of claims 1 to 8.

Images