Abnormal transaction behavior identification method, device, equipment, medium and program product

Abstract

The application provides an abnormal transaction behavior identification method, device, equipment, medium and program product, which can be applied to the field of big data technology. The method comprises the following steps: extracting target fields from customer information and transaction information, the target fields comprising literal type fields and numerical type fields, the literal type fields being fields selected according to business characteristics of a target transaction scene and carrying specific industry categories and transaction behavior description information under the target transaction scene, and the numerical type fields being fields carrying quantitative information related to transactions; inputting the target fields into a preset rule set for detection to obtain target hit results of each rule; each rule in the rule set comprising at least one keyword matching condition and / or at least one quantitative threshold condition, the keyword matching condition being used for keyword matching on the literal type fields, and the quantitative threshold condition being used for threshold judgment on the numerical type fields; and determining an abnormal transaction behavior based on the target hit results of each rule.

Description

Technical Field

[0001] This application relates to the field of financial technology, specifically to the field of big data technology, and more specifically to a method, apparatus, device, medium, and program product for identifying abnormal transaction behavior. Background Technology

[0002] Anomaly detection is a crucial technical tool in financial risk control. Existing rule models are typically built upon general anomaly scenarios, primarily abstracting and quantifying abnormal transaction patterns such as unusual transaction amounts and numbers. However, for specific transaction scenarios like the circulation of high-value goods, existing rule models can only adopt the monitoring logic of other scenarios and cannot specifically identify the unique customer identity characteristics, transaction behavior features, and business models of these scenarios. This results in low accuracy and reliability of anomaly detection results for such scenarios. Summary of the Invention

[0003] In view of the above problems, embodiments of this application provide a method, apparatus, device, medium, and program product for identifying abnormal transaction behavior.

[0004] According to a first aspect of this application, a method for identifying abnormal transaction behavior is provided, comprising: extracting target fields from customer information and transaction information, wherein the target fields include textual fields and numerical fields, the textual fields being selected based on the business characteristics of the target transaction scenario and carrying specific industry category and transaction behavior description information under the target transaction scenario, and the numerical fields being fields carrying transaction-related quantitative information; inputting the target fields into a preset set of rules for detection, and obtaining the target hit results of each rule; each rule in the rule set includes at least one keyword matching condition and / or at least one quantification threshold condition, the keyword matching condition being used for keyword matching of the textual fields, and the quantification threshold condition being used for threshold judgment of the numerical fields; and determining abnormal transaction behavior based on the target hit results of each rule.

[0005] According to embodiments of this application, the target field is input into a preset set of rules for detection, and the hit results of each rule include at least one of the following rule detections: keyword matching of the customer name in the text field to obtain a first hit result; keyword matching of the counterparty name or business scope in the target field of the text field, combined with threshold judgment of the transaction amount in the numerical field, to obtain a second hit result; keyword matching of the transaction remarks in the text field, combined with threshold judgment of the relevant number of transactions and cumulative amount in the numerical field, to obtain a third hit result; threshold judgment of the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals in the numerical field, to obtain a fourth hit result; threshold judgment of the total number of electronic payments and the total amount of electronic payments in the numerical field, to obtain a fifth hit result; threshold judgment of the proportion of cross-border transaction lending and borrowing in the numerical field, to obtain a sixth hit result; and threshold judgment of the daily cumulative transaction amount, borrowing amount ratio, and end-of-day balance of the numerical field, to obtain a seventh hit result.

[0006] According to an embodiment of this application, keyword matching of customer names includes: determining the unit customer based on the customer type in the customer information, matching the customer name of the unit customer with a preset industry keyword database, and determining the first hit result as a hit if a match is found.

[0007] According to an embodiment of this application, keyword matching of the counterparty's name or business scope and threshold determination in combination with the transaction amount in the numerical field include: matching the counterparty's name or business scope with a preset industry keyword library; if the match is successful, obtaining the transaction amount of the corresponding transaction and determining whether it exceeds a first preset amount threshold; if it exceeds the threshold, determining the second hit result as a hit.

[0008] According to an embodiment of this application, keyword matching of transaction remarks and threshold determination based on the relevant number of transactions and cumulative amount in the numerical field includes: matching the transaction remarks with a preset transaction behavior keyword library; if the match is successful, obtaining the relevant number of transactions and cumulative amount of the customer within a preset period; determining whether the number of transactions exceeds a preset number threshold and whether the cumulative amount exceeds a second preset amount threshold; if both exceed, then determining the third hit result as a hit.

[0009] According to the embodiments of this application, threshold determination of the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals includes: obtaining the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals of customers within a preset backtracking period, determining whether the total number of cash deposits and withdrawals exceeds a third preset number threshold and whether the total amount of cash deposits and withdrawals exceeds a third preset amount threshold, and if both exceed the threshold, then determining the fourth hit result as a hit.

[0010] According to the embodiments of this application, threshold determination of the total number of electronic payments and the total amount of electronic payments includes: obtaining the total number of electronic payments and the total amount of electronic payments made by the customer within a preset backtracking period, determining whether the total number of electronic payments exceeds a fourth preset number threshold and whether the total amount of electronic payments exceeds a fourth preset amount threshold, and if both exceed the threshold, then determining the fifth hit result as a hit.

[0011] According to the embodiments of this application, the threshold judgment of the ratio of the number of cross-border transactions and the ratio of the loan amount includes: obtaining the number of debit transactions, the number of credit transactions, the cumulative amount of debits and the cumulative amount of credits in the customer's cross-border transactions within a preset backtracking period, calculating the ratio of the number of transactions and the ratio of the loan amount, determining whether the ratio of the number of transactions exceeds a preset ratio threshold and whether the ratio of the loan amount falls within a preset amount ratio range, and if both are satisfied, then the sixth hit result is determined to be a hit.

[0012] According to the embodiments of this application, the threshold judgment of the account's daily cumulative transaction amount, loan amount ratio and end-of-day balance includes: obtaining the cumulative transaction amount, total debit amount, total credit amount and end-of-day balance of any target account of the customer in a single day, calculating the loan amount ratio, and determining whether the cumulative transaction amount exceeds the fifth preset amount threshold, whether the loan amount ratio falls within the preset loan ratio range and whether the end-of-day balance is lower than the sixth preset amount threshold. If all conditions are met, the seventh hit result is determined to be a hit.

[0013] According to an embodiment of this application, determining abnormal transaction behavior based on the hit results of each rule includes: assigning a preset weight value to each hit rule, calculating the weighted sum of all hit rules; and generating a prompt message indicating the existence of abnormal transaction behavior when the weighted sum exceeds a preset abnormal reporting threshold.

[0014] According to a second aspect of this application, an abnormal transaction behavior identification device is provided, comprising: an extraction module for extracting target fields from customer information and transaction information, the target fields including text fields and numerical fields, wherein the text fields are selected according to the business characteristics of the target transaction scenario and carry specific industry category and transaction behavior description information under the target transaction scenario, and the numerical fields are fields carrying transaction-related quantitative information; a detection module for inputting the target fields into a preset rule set for detection to obtain the target hit result of each rule; each rule in the rule set includes at least one keyword matching condition and / or at least one quantification threshold condition, wherein the keyword matching condition is used for keyword matching of the text fields, and the quantification threshold condition is used for threshold judgment of the numerical fields; and a determination module for determining abnormal transaction behavior based on the target hit result of each rule.

[0015] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0016] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0017] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustration shows an application scenario of the abnormal transaction behavior identification method, apparatus, device, medium, and program product according to embodiments of this application;

[0020] Figure 2 A flowchart illustrating an abnormal transaction behavior identification method according to an embodiment of this application is shown in the schematic diagram.

[0021] Figure 3 A flowchart illustrating the determination of each rule hit result according to an embodiment of this application is shown schematically.

[0022] Figure 4 This schematic diagram illustrates the structural block diagram of an abnormal transaction behavior identification device according to an embodiment of this application;

[0023] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing an abnormal transaction behavior identification method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0029] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0030] Figure 1 The illustration shows an application scenario of the abnormal transaction behavior identification method according to an embodiment of this application.

[0031] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0032] The first terminal device 101 and the second terminal device 102 can be client terminals for initiating transactions or querying transaction records, or they can be business processing systems of banks, third-party payment institutions, or securities companies. For example, a user can initiate a transaction request through the first terminal device 101, and the transaction information is transmitted to the server 105 through the network 104; risk control personnel can view abnormal transaction reports generated by the server 105 through the second terminal device 102.

[0033] Database 103 can be used to store customer information and transaction information. Database 103 can be a relational database, a distributed database, or a cloud storage service, supporting structured data storage and efficient data retrieval.

[0034] Server 105 can be a server providing abnormal transaction behavior identification services. Server 105 retrieves customer information and transaction information from database 103, extracts target fields (including text fields and numerical fields), and inputs the target fields into a preset rule set for detection. The rule set includes keyword matching conditions and / or quantification threshold conditions. The server performs weighted integral calculation on the hit results of each rule. When the total weighted integral exceeds a preset reporting threshold, an abnormal transaction report is generated. Server 105 can store the abnormal transaction report in database 103 or push it to a second terminal device 102 via network 104 for processing by risk control review personnel.

[0035] Server 105 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0036] It should be noted that the abnormal transaction behavior identification method provided in this application embodiment can generally be executed by the server 105. Accordingly, the abnormal transaction behavior identification device provided in this application embodiment can generally be set in the server 105.

[0037] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0038] It should be noted that the abnormal transaction behavior identification method and apparatus of this application embodiment can be used in the field of financial technology, or in any field other than financial technology. This application does not limit the application field of the abnormal transaction behavior identification method and apparatus.

[0039] The following will be based on Figure 1 The described scene, through Figure 2 and Figure 3The method for identifying abnormal transaction behavior according to the embodiments of this application will be described in detail.

[0040] Figure 2 A flowchart illustrating an abnormal transaction behavior identification method according to an embodiment of this application is shown schematically. Figure 2 As shown, the abnormal transaction behavior identification method 200 according to the embodiments of this application may include steps S210 to S230.

[0041] In step S210, target fields are extracted from customer information and transaction information. Target fields include text fields and numeric fields. Text fields are selected based on the business characteristics of the target transaction scenario and carry descriptions of specific industry categories and transaction behaviors within the target transaction scenario. Numeric fields are fields that carry quantitative information related to the transaction.

[0042] Text-based fields are selected based on the business characteristics of the target transaction scenario and carry descriptive information about specific industry categories or transaction behaviors within that scenario. Examples include customer name, counterparty name, counterparty's business scope, and transaction remarks. This information reflects the background, industry, and transaction intent of the transaction participants. Numerical fields carry quantitative information related to the transaction, such as transaction amount, number of transactions, account balance, cumulative amount, percentage of transactions, and percentage of amount. This information reflects the scale, frequency, fund flow patterns, and account status of the transactions.

[0043] Parse and extract target fields from transaction and customer information. For text-based fields, a field parser can be used to directly read the raw content of the text field, including customer name, counterparty name, counterparty's business scope, transaction remarks, etc., preserving the complete string. For numeric fields, a numeric extractor can be used to read basic numeric fields, such as transaction amount, number of transactions, account balance, and transaction date; furthermore, derived numeric fields can be generated through a statistical aggregation engine. For example, the number of transactions can be counted within a preset time window to obtain the cumulative number of transactions, and the transaction amounts can be summed to obtain the cumulative amount; the number of transactions and amounts can be counted separately according to the transaction direction (debit / credit), and the ratio of the number of debit transactions and the ratio of the debit amount can be calculated; the closing balance at the end of each day can be extracted through the account balance tracking module.

[0044] In step S220, the target field is input into a preset rule set for detection to obtain the target hit result of each rule; each rule in the rule set contains at least one keyword matching condition and / or at least one quantization threshold condition. The keyword matching condition is used to perform keyword matching on text fields, and the quantization threshold condition is used to perform threshold judgment on numerical fields.

[0045] The rule set is pre-built based on the experience of business experts and analysis of real-world cases, and consists of multiple rules. Each rule can be stored in a structured form, such as condition-action pairs, decision tables, or expression trees. The rule set can be deployed in an in-memory database, a distributed cache, or a rule repository for fast loading and access during detection.

[0046] The detection process can be executed by a rule engine. The rule engine is responsible for matching the input target field with each rule in the rule set, and determining the hit status of each rule based on the matching results. In this embodiment, the rule engine preloads the rule set and binds text fields and numeric fields to the keyword matching conditions and quantization threshold conditions in the rules, respectively, and then executes the rule judgment one by one.

[0047] Keyword matching conditions are used to perform keyword matching on text fields. In implementation, a keyword library can be pre-built, and an efficient string matching algorithm can be used to perform matching checks on the text fields. Matching methods support exact matching, prefix matching, suffix matching, inclusion matching, and wildcard matching. For each rule, the keyword matching condition can output a boolean value to indicate whether the match was successful or not.

[0048] Quantization threshold conditions are used to determine thresholds for numeric fields. In implementation, numerical comparison operators can be used to compare the numeric field with a preset threshold. The threshold can be a fixed value or a quantile or standard deviation multiple dynamically calculated based on the statistical distribution. For quantization rules involving multiple conditions, the rule engine can combine multiple comparison expressions using logical AND, OR, NOT, and other operators to obtain the final Boolean result.

[0049] In this embodiment, each rule in the rule set contains at least one keyword matching condition and / or at least one quantization threshold condition. In other words, the rule set can contain the following three types of rules simultaneously.

[0050] Rules that only include keyword matching conditions can be called the first type of rule. These rules only perform keyword matching on text-based fields and do not involve threshold judgment for numeric fields.

[0051] Rules that only include quantified threshold conditions can be called the second type of rules. These rules only perform threshold judgments on numerical fields and do not involve keyword matching for textual fields.

[0052] Rules that include both keyword matching conditions and quantification threshold conditions can be called the third type of rule. This type of rule requires both keyword matching for text-based fields and threshold judgment for numeric fields to be met simultaneously for a match to be considered successful.

[0053] The rules are categorized into these three types because there are three typical detection needs in actual abnormal transaction behavior: First, anomalies can be identified solely based on business semantic information, such as when the transaction entity belongs to a highly sensitive industry; second, anomalies can be identified solely based on quantitative indicators, such as cash deposits and withdrawals far exceeding normal levels; and third, anomalies require mutual corroboration of semantic information and quantitative indicators to accurately pinpoint the anomaly, such as when entities in a specific industry simultaneously engage in large-scale transactions. By encapsulating keyword matching conditions and quantitative threshold conditions into independent or combined rules, and allowing mixed deployment within the same rule set, this application can flexibly adapt to different modes of anomaly detection needs while avoiding false positives or false negatives caused by a single type of rule.

[0054] In step S230, abnormal transaction behavior is determined based on the target hit results of each rule.

[0055] Based on the hit results of each rule, various comprehensive judgment logics can be used to determine whether abnormal trading behavior exists. For example, weighted integral comprehensive judgment, logical combination judgment, and other methods can be used to determine abnormal trading behavior based on the target hit results. The specific determination process will be further explained later.

[0056] Understandably, by extracting textual and numerical fields selected based on the target transaction scenario from customer and transaction information, and utilizing a rule set including keyword matching conditions and quantitative threshold conditions for detection, the joint utilization of business semantic information and quantitative transaction information under a specific transaction scenario is achieved. Specifically, the keyword matching condition performs string matching based on a pre-configured keyword library according to the target transaction scenario, accurately capturing the industry category and transaction behavior description unique to that scenario; the quantitative threshold condition performs threshold judgment on numerical fields, effectively identifying quantitative anomalies in fund flows. By dividing the rules into three categories—pure semantic, pure quantitative, and a hybrid of semantic and quantitative—this embodiment can flexibly adapt to the anomaly detection needs of different modes, significantly improving the accuracy, coverage, and interpretability of abnormal transaction behavior identification, and is particularly suitable for specialized identification of specific transaction scenarios such as the circulation of high-value goods.

[0057] Based on the above embodiments, this application designs 7 different rules. Figure 3 A flowchart illustrating the determination of the hit results for each rule according to an embodiment of this application is shown. Figure 3 As shown, the process of inputting the target field into a preset rule set for detection and obtaining the hit results of each rule may include at least one step from steps S301 to S307. That is, these rules can be arbitrarily combined to form a rule set. It is important to emphasize that these steps do not need to be executed in a specific order.

[0058] In step S301, keyword matching is performed on the customer name in the text field to obtain the first hit result.

[0059] To identify trading entities with specific industry backgrounds, keyword matching can be performed on the names of corporate clients. In specific business scenarios (such as the circulation of high-value goods), abnormal trading behavior is usually closely related to trading entities engaged in that industry. These industries typically have characteristics such as large transaction amounts, irregular transaction frequency, and complex fund flows, making them prone to becoming high-incidence areas for abnormal transactions.

[0060] Specifically, the customer type and customer name fields are first extracted from the customer information. If the customer type is an individual, this rule does not apply, and the process is skipped and a no-match result is returned. If the customer type is an organization (such as a company or institution), the customer name is entered as a text field in the keyword matching criteria. The keyword matching criteria are based on a pre-defined industry keyword library, which contains several business terms representing specific industry categories. The matching process supports exact matching, inclusion matching, and fuzzy matching.

[0061] The automated rule execution process may include: extracting the customer type field and customer name field from the customer information database; determining the customer type, and terminating the rule detection if the customer is an individual; if the customer is a corporate customer, matching the customer name with the industry keyword database; if the customer name contains any keyword, the rule is considered to have been hit, and the first hit result is marked as "hit"; otherwise, it is marked as "missed".

[0062] For example, if the industry keyword database contains "auction," and a client's name is "XX International Auction Co., Ltd.", then the keyword will be matched. However, if the name is "YY Technology Development Co., Ltd.", then the keyword will not be matched.

[0063] This rule enables the automatic and efficient identification of corporate clients with specific industry attributes from massive amounts of customer information. It directly utilizes industry keywords in the client's name for keyword matching, and the matching results are directly incorporated into the comprehensive judgment. This allows the rule to work in parallel and complement other quantitative rules, integrating the crucial clue of "transaction entity industry attributes" into the final identification result. This significantly improves the accuracy and interpretability of identifying abnormal transactions in specific scenarios.

[0064] In step S302, keyword matching is performed on the counterparty name or business scope in the target field of the text field, and threshold judgment is performed in combination with the transaction amount in the numerical field to obtain the second hit result.

[0065] To identify large transactions with entities in specific industries, keyword matching can be performed on the counterparty's name or business scope, while simultaneously applying numerical thresholds to the transaction amount. This is because even if the trading entity itself does not belong to a high-risk industry, a significantly large transaction amount with a counterparty belonging to a high-risk industry may still indicate abnormal capital flows.

[0066] Specifically, the counterparty's name and business scope are extracted from the transaction information as text fields, while the debit amount of the transaction is extracted as a numeric field. Keyword matching conditions are implemented based on an industry keyword library and can be shared with or configured independently of step S301. Quantitative threshold conditions are used to determine whether the transaction amount exceeds a first preset amount threshold.

[0067] The automated rule execution process may include: extracting the counterparty's name, business scope, and transaction amount from the transaction information; detecting whether the counterparty's name or business scope contains any keyword in the industry keyword library, where several exclusion words can be set; if a match is successful, further determining whether the debit amount of the transaction exceeds a first preset amount threshold; if both are satisfied, the rule is determined to be hit, and the second hit result is marked as "hit"; otherwise, it is marked as "missed".

[0068] For example, if the counterparty in a transaction is named "XX Art Auction House," matching the keyword "auction," and the transaction amount is 500,000 yuan, exceeding the preset threshold of 200,000 yuan, then the transaction is successful. If the counterparty's name is "YY Daily Necessities Store," the keyword is not matched, or if it is matched but the amount is only 50,000 yuan, which does not exceed the threshold, then the transaction is unsuccessful.

[0069] This rule automatically detects large-scale fund flows involving high-risk industry entities. By combining keyword matching with amount thresholds, it accurately identifies complex anomaly patterns in large-scale transactions with specific industry counterparties. Compared to monitoring large-scale transactions or industry keywords alone, this rule significantly improves the accuracy of anomaly detection, avoiding false positives for normal large-scale transactions or small, high-risk transactions, effectively reducing the false positive rate and enhancing the quality of evidence in comprehensive judgments.

[0070] In step S303, keyword matching is performed on the transaction remarks in the text field, and threshold judgment is performed in combination with the relevant transaction count and cumulative amount in the numeric field to obtain the third hit result.

[0071] To identify specific transaction intentions implied in transaction comments and determine whether the transaction scale is abnormal, keyword matching can be performed on the transaction comments, while quantitative threshold judgments can be made by combining relevant transaction counts and cumulative amounts from numerical fields. Transaction comments contain information such as transaction purpose and subject matter, and are an important semantic source for identifying abnormal behavior. However, matching a single comment may be too broad, and verification needs to be combined with transaction frequency and cumulative amount.

[0072] Specifically, the transaction remarks field is extracted from the transaction information as a text field; simultaneously, the number of transactions and cumulative amount of all transactions related to the current transaction for this customer within a preset monitoring period are counted as numerical fields. Keyword matching conditions are implemented based on a preset transaction behavior keyword library. The quantification threshold condition includes two sub-conditions: whether the number of related transactions is greater than a preset number threshold, and whether the cumulative amount exceeds a second preset amount threshold.

[0073] The automated rule execution process may include: extracting transaction remarks from transaction information and extracting the number of relevant transactions and cumulative amount for the customer within the monitoring period; detecting whether the transaction remarks contain any keyword in the transaction behavior keyword library; if a match is successful, further determining whether the number of relevant transactions exceeds a preset number threshold and whether the cumulative amount exceeds a second preset amount threshold; if all three conditions are met, the rule is determined to have been hit, and the third hit result is marked as "hit"; otherwise, it is marked as "missed".

[0074] For example, if a transaction's remarks contain the keyword "digital collectibles," and the customer has made three transactions containing similar keywords in the past day, totaling 50,000 yuan, exceeding the threshold, then the transaction is considered a match. If the remarks do not contain the keyword, or if the total amount is insufficient despite matching the keyword, then the transaction is not considered a match.

[0075] This rule automatically identifies behaviors that imply specific trading intentions through transaction comments, and where the frequency and scale of transactions under such intentions have reached abnormal levels. This rule overcomes the limitation of simple keyword matching in distinguishing between occasional and frequent transactions. By introducing thresholds for the number of transactions and cumulative amount, it effectively filters out irrelevant comments that appear occasionally, accurately capturing persistent and large-scale abnormal trading intentions.

[0076] In step S304, threshold judgment is performed on the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals in the numerical fields to obtain the fourth hit result.

[0077] To detect large, frequent cash deposits and withdrawals within a short period, quantitative monitoring of customer cash deposit and withdrawal transactions can be implemented. Cash transactions are anonymous, and unusually active cash deposits and withdrawals within a short period may be used to evade fund tracking, serving as an important indicator of abnormal behavior.

[0078] Specifically, all cash deposit and withdrawal records of the customer within a preset backtracking period are extracted from the transaction information, and the total number of transactions and total amount are counted as numerical fields. The quantitative threshold condition includes two sub-conditions: whether the total number of cash deposits and withdrawals exceeds the first preset number of transactions threshold, and whether the total amount of cash deposits and withdrawals exceeds the third preset amount threshold.

[0079] The automated execution process of the rule may include: obtaining the current date and backtracking all cash deposit and withdrawal transaction records within a preset backtracking period; calculating the total number of cash deposits and withdrawals and the total amount within this period; if the total number of transactions exceeds the first preset number threshold and the total amount exceeds the third preset amount threshold, the rule is determined to be hit, and the fourth hit result is marked as "hit"; otherwise, it is marked as "not hit".

[0080] For example, if a customer makes 6 cash deposits and withdrawals totaling 80,000 yuan in the past 3 days, exceeding the threshold for both the number of transactions (5 transactions) and the amount (50,000 yuan), then the transaction is considered a match. If the amount is large but the number of transactions is insufficient, or if the number of transactions is large but the amount is small, then the transaction is not considered a match.

[0081] This rule can automatically identify sudden surges in cash transactions within a short period. It can detect abnormal spikes in cash flow using only numerical thresholds, making it uniquely valuable for identifying fund transfers intended to evade electronic payment regulations. Furthermore, it is computationally efficient and suitable for real-time screening of massive amounts of transaction data.

[0082] In step S305, threshold judgments are performed on the total number of electronic payments and the total amount of electronic payments in the numerical fields to obtain the fifth hit result.

[0083] To detect high-frequency, large-amount electronic payment activities conducted within a short period through online banking transfers or third-party payment platforms, quantitative monitoring of customers' electronic payment transactions can be implemented. While electronic payment is currently the mainstream transaction method, unusually high-frequency or extremely large-amount electronic payments within a short period may indicate dispersed, laundered, or concentrated transfer of funds.

[0084] Specifically, all online banking transfers and third-party payment transactions for the customer within a preset backtracking period are extracted from the transaction information, and the total number of transactions and total amount are calculated as numerical fields. The quantitative threshold condition includes two sub-conditions: whether the total number of electronic payments exceeds the second preset number threshold, and whether the total amount of electronic payments exceeds the fourth preset amount threshold.

[0085] The automated execution process of the rule may include: obtaining the current date and backtracking all online banking transfers and third-party payment transaction records within a preset backtracking period; calculating the total number of electronic payments and the total amount within this period; if the total number of payments exceeds the second preset number threshold and the total amount exceeds the fourth preset amount threshold, the rule is determined to be hit, and the fifth hit result is marked as "hit"; otherwise, it is marked as "not hit".

[0086] For example, if a customer has made 8 transactions totaling 120,000 yuan through online banking and third-party payment in the past 3 days, exceeding the threshold, then the transaction is successful.

[0087] This rule can automatically detect abnormally high electronic payment activity within a short period. Complementing the cash deposit and withdrawal rules, this rule covers abnormal fund flows through electronic channels, quickly identifying accounts with transaction volumes far exceeding normal levels. It provides quantitative evidence of abnormal electronic payment activity for comprehensive assessment, effectively reducing the risk of missed detections relying on manual spot checks.

[0088] In step S306, threshold judgments are performed on the proportion of cross-border transaction loans and the proportion of loan amounts in the numerical fields to obtain the sixth hit result.

[0089] To identify unusual fund transfers through cross-border capital flows, a loan-to-deposit ratio analysis can be performed on a client's cross-border transactions. In cross-border capital flows, a significant imbalance in the number of outflows and inflows, while the amounts remain nearly equal, may indicate fund transfers using fictitious trade or wash trading tactics.

[0090] Specifically, all cross-border transaction records of the customer within a preset backtracking period are extracted from the transaction information. The number of debit (outbound) transactions, the number of credit (inbound) transactions, the cumulative debit amount, and the cumulative credit amount are then counted as numerical fields. Based on these statistics, the ratio of the number of loans and the ratio of the loan amount are calculated. The quantitative threshold conditions include whether the ratio of the number of loans exceeds a preset threshold and whether the ratio of the loan amount falls within a preset range.

[0091] The automated execution process of the rule may include: obtaining the current date and backtracking all cross-border transaction records within a preset backtracking period; counting the number of debits, the number of credits, the amount of debits, and the amount of credits respectively; calculating the ratio of the number of debits to the number of credits, and if it meets the condition of ≥1: preset ratio threshold or ≥ preset ratio threshold: 1, then further calculating the ratio of the amount of credits; if the ratio of the amount of credits is between the lower limit and the upper limit of the preset ratio of the amount of credits, then the rule is determined to be hit, and the sixth hit result is marked as "hit"; otherwise, it is marked as "missed".

[0092] For example, if a customer has made 30 cross-border remittances and 10 cross-border remittances in the past 10 days, with a loan-to-transaction ratio of 3:1, exceeding the 3:1 threshold; and simultaneously, the total outflow amount is 950,000 yuan, while the total inflow amount is 1,000,000 yuan, resulting in a loan-to-transaction ratio of 0.95, falling within the range [0.95, 1.05], then this scenario indicates a balance between the amount of funds flowing in and out, but a significant imbalance in the number of transactions, which may suggest an anomaly.

[0093] This rule can automatically detect hidden anomalies in cross-border capital flows where the number of transactions is unbalanced but the amounts are balanced. Utilizing proportional thresholds, this rule effectively identifies wash trading through splitting or merging transactions, providing unique evidence of abnormal cross-border capital structures for comprehensive assessment.

[0094] In step S307, threshold judgments are performed on the account's daily cumulative transaction amount, loan amount ratio, and end-of-day balance in the numerical fields to obtain the seventh hit result.

[0095] To identify accounts exhibiting characteristics of rapid fund transfers (i.e., funds move in and out quickly, leaving almost no balance at the end of the day), multi-dimensional quantitative monitoring of the account's daily trading behavior can be conducted. These transitional accounts are typically used for short-term fund transfers, characterized by high daily trading volumes, near-balanced borrowing and lending amounts, and extremely low balances.

[0096] Specifically, the system extracts all transaction records (excluding non-current account transactions such as fixed-term wealth management products) for any account of the customer within a single day from the transaction information, and calculates the cumulative transaction amount, total debit amount, total credit amount, and end-of-day balance as numerical fields. It then calculates the loan-to-debit ratio. The quantified threshold conditions include three sub-conditions: whether the cumulative transaction amount for the day exceeds the fifth preset threshold; whether the loan-to-debit ratio falls within the preset loan-to-debit ratio range; and whether the end-of-day balance is lower than the sixth preset threshold.

[0097] The automated execution process of the rule may include: extracting all transaction records of the customer's account for the day and excluding fixed-term wealth management transactions; calculating the cumulative transaction amount, total debit amount, total credit amount and end-of-day balance for the day; if the cumulative transaction amount exceeds the fifth preset amount threshold, and the ratio of the total loan amount is between the preset lower and upper limits of the loan ratio, and the end-of-day balance is lower than the sixth preset amount threshold, then the rule is determined to be hit, and the seventh hit result is marked as "hit"; otherwise, it is marked as "not hit".

[0098] For example, if an account has a total transaction amount of 2 million yuan on a given day, with a total debit amount of 1 million yuan and a total credit amount of 980,000 yuan, resulting in a debit-to-credit ratio of 1.02 (falling within the range [0.9, 1.1]), and the account has a closing balance of only 500 yuan (less than 1,000 yuan), then this account meets the criteria. This indicates that funds are flowing in and out in large quantities, but the account has almost no balance, which matches the characteristics of a transitional account.

[0099] This rule automatically identifies typical characteristics of transitional accounts. It combines three dimensions—cumulative transaction volume, loan-to-deposit balance, and end-of-day balance—to effectively differentiate them from normal operating accounts (which typically maintain reserve funds and whose loan-to-deposit ratio is not necessarily balanced) and savings accounts (with low transaction volumes). This rule provides strong evidence of "abnormal account usage patterns" for comprehensive judgment and has a very high accuracy rate in identifying shell accounts specifically used for fund transfers, significantly improving the targeting and effectiveness of abnormal transaction identification.

[0100] The seven rules above each correspond to different abnormal behavior characteristics. In practical applications, some or all of the rules can be deployed according to business needs, and a comprehensive judgment can be made through weighted integration or logical combination. It is understandable that using all seven rules allows for comprehensive detection from seven complementary dimensions: customer identity semantics, counterparty semantics, message semantics, cash deposits and withdrawals, electronic payments, cross-border fund ratios, and transitional account behavior. This enables semantic information and quantitative indicators to corroborate each other, effectively eliminating monitoring blind spots, significantly reducing false positive and false negative rates, accurately locating complex abnormal transaction patterns, and ultimately improving the accuracy, coverage, and interpretability of abnormal transaction behavior identification.

[0101] As mentioned earlier, in some embodiments, weighted integrals can be used to comprehensively determine the hit results. Specifically, a weight score can be pre-configured for each rule in the rule set, and the magnitude of the weight value reflects the importance of the rule in anomaly detection. The weight value can be set based on the experience of business experts or dynamically adjusted through training with historical data. For a detection process, the weight values ​​of all hit rules are collected, and the weighted integral sum is calculated. An anomaly reporting threshold is preset. When the weighted integral sum reaches or exceeds the threshold, it is determined that there is abnormal transaction behavior; otherwise, it is determined that there is no anomaly. This method is suitable for scenarios with a large number of rules and different importance of each rule, and can flexibly adjust the contribution of different rules to the final decision. For example, the calculation of the weighted integral sum can use a linear weighting formula: S = Σ(w_i × h_i), where w_i is the weight of the i-th rule, and h_i is a Boolean variable (1 when hit, 0 when not hit). An anomaly report is triggered when S ≥ T, where T is the preset anomaly reporting threshold.

[0102] Once abnormal transaction behavior is identified, the system can generate an abnormal transaction report. As an example, the report content may include: customer identifier, a list of triggering rules (which may include rule name, hit time, hit condition details, etc.), the hit result of each rule and its corresponding weight, the overall judgment score, and the abnormal judgment conclusion. The report can be stored in a structured format in a database, or pushed to a manual review system or regulatory reporting system via a message queue or human-computer interaction interface for subsequent processing. In addition, the system can also record logs of the judgment process, including the execution time of each rule, feature value snapshots, etc., for subsequent auditing and rule optimization.

[0103] Based on the above-mentioned abnormal transaction behavior identification method, this application also provides an abnormal transaction behavior identification device. The following will be combined with... Figure 4 The device is described in detail.

[0104] Figure 4The diagram illustrates the structure of an abnormal transaction behavior identification device according to an embodiment of this application.

[0105] like Figure 4 As shown, the abnormal transaction behavior identification device 400 of this embodiment includes an extraction module 410, a detection module 420, and a determination module 430.

[0106] The extraction module 410 is used to extract target fields from customer information and transaction information. Target fields include text fields and numeric fields. Text fields are selected based on the business characteristics of the target transaction scenario and carry descriptions of specific industry categories and transaction behaviors within that scenario. Numeric fields carry quantitative information related to the transaction. In one embodiment, the extraction module 410 can be used to execute step S210 as described above, which will not be repeated here.

[0107] The detection module 420 is used to input the target field into a preset rule set for detection, and obtain the target hit result of each rule; each rule in the rule set contains at least one keyword matching condition and / or at least one quantization threshold condition. The keyword matching condition is used to perform keyword matching on text-type fields, and the quantization threshold condition is used to perform threshold judgment on numerical fields. In one embodiment, the detection module 420 can be used to execute step S220 described above, which will not be repeated here.

[0108] The determination module 430 is used to determine abnormal transaction behavior based on the target hit results of each rule. In one embodiment, the determination module 430 can be used to execute step S230 described above, which will not be repeated here.

[0109] According to an embodiment of this application, the detection module 420 is further configured to: perform keyword matching on the customer name in the text field to obtain a first hit result; perform keyword matching on the counterparty name or business scope in the target field of the text field, and combine it with the transaction amount in the numerical field to perform threshold judgment to obtain a second hit result; perform keyword matching on the transaction remarks in the text field, and combine it with the relevant number of transactions and cumulative amount in the numerical field to perform threshold judgment to obtain a third hit result; perform threshold judgment on the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals in the numerical field to obtain a fourth hit result; perform threshold judgment on the total number of electronic payments and the total amount of electronic payments in the numerical field to obtain a fifth hit result; perform threshold judgment on the proportion of cross-border transaction lending and borrowing and the proportion of lending and borrowing in the numerical field to obtain a sixth hit result; and perform threshold judgment on the daily cumulative transaction amount, lending and borrowing ratio, and end-of-day balance of the account in the numerical field to obtain a seventh hit result.

[0110] According to an embodiment of this application, the detection module 420 is further configured to determine the unit customer based on the customer type in the customer information, match the customer name of the unit customer with a preset industry keyword database, and if a match is found, determine the first hit result as a hit.

[0111] According to an embodiment of this application, the detection module 420 is further configured to match the name or business scope of the counterparty with a preset industry keyword database. If the match is successful, the transaction amount of the corresponding transaction is obtained and it is determined whether it exceeds a first preset amount threshold. If it exceeds the threshold, the second hit result is determined to be a hit.

[0112] According to an embodiment of this application, the detection module 420 is further configured to match the transaction remarks with a preset transaction behavior keyword library. If the match is successful, the module obtains the number of relevant transactions and the cumulative amount of the customer within a preset period, determines whether the number of transactions exceeds a preset number threshold and whether the cumulative amount exceeds a second preset amount threshold, and if both exceed the threshold, then the third hit result is determined to be a hit.

[0113] According to an embodiment of this application, the detection module 420 is further configured to obtain the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals within a preset backtracking period, determine whether the total number of cash deposits and withdrawals exceeds a third preset number threshold and whether the total amount of cash deposits and withdrawals exceeds a third preset amount threshold, and if both exceed the threshold, then the fourth hit result is determined to be a hit.

[0114] According to an embodiment of this application, the detection module 420 is further configured to obtain the total number of electronic payments and the total amount of electronic payments made by the customer within a preset backtracking period, determine whether the total number of electronic payments exceeds a fourth preset number threshold and whether the total amount of electronic payments exceeds a fourth preset amount threshold, and if both exceed the threshold, then the fifth hit result is determined to be a hit.

[0115] According to an embodiment of this application, the detection module 420 is further used to obtain the number of debit transactions, the number of credit transactions, the cumulative amount of debits and the cumulative amount of credits in the customer's cross-border transactions within a preset backtracking period, calculate the ratio of the number of debit transactions and the ratio of the amount of debits, determine whether the ratio of the number of debit transactions exceeds a preset ratio threshold and whether the ratio of the amount of debits falls within a preset amount ratio range, and if both are satisfied, then the sixth hit result is determined to be a hit.

[0116] According to an embodiment of this application, the detection module 420 is further used to obtain the cumulative transaction amount, total debit amount, total credit amount and end-of-day balance of any target account of the customer in a single day, calculate the loan amount ratio, determine whether the cumulative transaction amount exceeds the fifth preset amount threshold, whether the loan amount ratio falls within the preset loan ratio range and whether the end-of-day balance is lower than the sixth preset amount threshold, and if all conditions are met, then the seventh hit result is determined to be a hit.

[0117] According to an embodiment of this application, the determining module 430 is further configured to assign a preset weight value to each hit rule, calculate the weighted sum of all hit rules, and generate a prompt message indicating abnormal transaction behavior when the weighted sum exceeds a preset abnormal reporting threshold.

[0118] According to embodiments of this application, any multiple modules among the extraction module 410, detection module 420, and determination module 430 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the extraction module 410, detection module 420, and determination module 430 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the extraction module 410, detection module 420, and determination module 430 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0119] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing an abnormal transaction behavior identification method according to an embodiment of this application.

[0120] like Figure 5 As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory 502 or a program loaded from a storage portion 508 into a random access memory 503. The processor 501 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0121] Random access memory 503 stores various programs and data required for the operation of electronic device 500. Processor 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Processor 501 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 502 and / or random access memory 503. It should be noted that programs may also be stored in one or more memories other than read-only memory 502 and random access memory 503. Processor 501 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0122] According to embodiments of this application, the electronic device 500 may further include an input / output interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card, such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0123] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0124] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 502, and / or random access memory 503, and / or one or more memories other than read-only memory 502 and random access memory 503 described above.

[0125] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0126] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0127] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0128] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0129] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0130] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for identifying abnormal transaction behavior, characterized in that, The method includes: Target fields are extracted from customer information and transaction information. These target fields include text fields and numeric fields. The text fields are selected based on the business characteristics of the target transaction scenario and carry a description of a specific industry category or transaction behavior under the target transaction scenario. The numeric fields are fields that carry quantitative information related to the transaction. The target field is input into a preset rule set for detection to obtain the target hit result of each rule; each rule in the rule set contains at least one keyword matching condition and / or at least one quantization threshold condition, the keyword matching condition is used to perform keyword matching on the text field, and the quantization threshold condition is used to perform threshold judgment on the numerical field; Based on the target hit results of each of the aforementioned rules, abnormal transaction behavior is identified.

2. The method according to claim 1, characterized in that, The target field is input into a preset set of rules for detection, and the hit results of each rule include at least one of the following rule detections: Keyword matching is performed on the customer name in the text field to obtain the first hit result; Keyword matching is performed on the counterparty name or business scope in the text field, and a threshold judgment is made in combination with the transaction amount in the numeric field to obtain the second hit result; Keyword matching is performed on the transaction remarks in the text field, and a threshold judgment is made by combining the relevant number of transactions and cumulative amount in the numeric field to obtain the third hit result; A threshold judgment is performed on the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals in the numerical fields to obtain the fourth hit result; The total number of electronic payments and the total amount of electronic payments in the numerical fields are judged by thresholds to obtain the fifth hit result; The sixth hit result is obtained by applying threshold judgments to the proportion of cross-border loan transactions and the proportion of loan amounts in the numerical fields. Threshold judgments were performed on the account's daily cumulative transaction amount, loan amount ratio, and end-of-day balance in the numerical fields to obtain the seventh hit result.

3. The method according to claim 2, characterized in that, Keyword matching for customer names includes: Based on the customer type in the customer information, the corporate customer is determined, and the customer name of the corporate customer is matched with a preset industry keyword database. If a match is found, the first hit result is determined to be a hit.

4. The method according to claim 2, characterized in that, The process of performing keyword matching on the counterparty's name or business scope, combined with threshold determination based on the transaction amount in a numerical field, includes: The name or business scope of the counterparty is matched with a preset industry keyword database. If the match is successful, the transaction amount of the corresponding transaction is obtained and it is determined whether it exceeds the first preset amount threshold. If it does, the second hit result is determined to be a hit.

5. The method according to claim 2, characterized in that, The transaction remarks are subjected to keyword matching, and threshold determination is performed by combining relevant transaction counts and cumulative amounts from numeric fields, including: The transaction notes are matched with a preset database of transaction behavior keywords. If the match is successful, the number of relevant transactions and the cumulative amount of the customer within a preset period are obtained. It is then determined whether the number of transactions exceeds a preset threshold and whether the cumulative amount exceeds a second preset amount threshold. If both exceed the threshold, the third hit result is determined to be a hit.

6. The method according to claim 2, characterized in that, Threshold determination for the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals includes: Obtain the total number of cash deposits and withdrawals and the total amount of cash deposits and withdrawals within a preset backtracking period. Determine whether the total number of cash deposits and withdrawals exceeds a third preset number threshold and whether the total amount of cash deposits and withdrawals exceeds a third preset amount threshold. If both exceed the threshold, then the fourth hit result is determined to be a hit.

7. The method according to claim 2, characterized in that, Threshold determination for the total number of electronic payment transactions and the total amount of electronic payments includes: Obtain the total number of electronic payments and the total amount of electronic payments made by the customer within a preset backtracking period. Determine whether the total number of electronic payments exceeds a fourth preset number threshold and whether the total amount of electronic payments exceeds a fourth preset amount threshold. If both exceed the threshold, then the fifth hit result is determined to be a hit.

8. The method according to claim 2, characterized in that, Threshold determination for the proportion of cross-border loan transactions and the proportion of loan amount includes: Obtain the number of debit transactions, the number of credit transactions, the cumulative amount of debits, and the cumulative amount of credits in the customer's cross-border transactions within a preset backtracking period. Calculate the ratio of the number of debit transactions and the ratio of the amount of debits. Determine whether the ratio of the number of debit transactions exceeds a preset ratio threshold and whether the ratio of the amount of debits falls within a preset amount ratio range. If both conditions are met, the sixth hit result is determined to be a hit.

9. The method according to claim 2, characterized in that, Threshold determinations for the account's daily cumulative transaction amount, loan-to-value ratio, and end-of-day balance include: Obtain the cumulative transaction amount, total debit amount, total credit amount, and end-of-day balance of any target account of the customer within a single day, calculate the loan-to-debit ratio, and determine whether the cumulative transaction amount exceeds the fifth preset amount threshold, whether the loan-to-debit ratio falls within the preset loan-to-debit ratio range, and whether the end-of-day balance is lower than the sixth preset amount threshold. If all conditions are met, the seventh hit result is determined to be a hit.

10. The method according to any one of claims 1 to 9, characterized in that, Based on the hit results of the aforementioned rules, the abnormal transaction behaviors are identified as including: Assign a preset weight value to each hit rule and calculate the weighted sum of all hit rules; When the weighted sum of the integrals exceeds a preset anomaly reporting threshold, a notification message indicating the existence of the abnormal transaction behavior is generated.

11. An abnormal transaction behavior identification device, characterized in that, The device includes: The extraction module is used to extract target fields from customer information and transaction information. The target fields include text fields and numeric fields. The text fields are selected according to the business characteristics of the target transaction scenario and carry specific industry category and transaction behavior description information under the target transaction scenario. The numeric fields are fields that carry quantitative information related to the transaction. The detection module is used to input the target field into a preset rule set for detection and obtain the target hit result of each rule; each rule in the rule set contains at least one keyword matching condition and / or at least one quantization threshold condition, the keyword matching condition is used to perform keyword matching on the text field, and the quantization threshold condition is used to perform threshold judgment on the numerical field; The determination module is used to determine abnormal transaction behavior based on the target hit results of each rule.

12. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

Images