Financial account abnormity identification method and device, equipment, medium and program product

Abstract

The invention relates to a financial account abnormity identification method and device, equipment, a medium and a program product. The method comprises the following steps: acquiring multi-source data of a newly added abnormal account; identifying a suspicious behavior pattern from the multi-source data, and generating a candidate identification rule based on the suspicious behavior pattern; performing similarity comparison on the candidate recognition rule and each recognition rule to obtain a similarity index; if each similarity index is smaller than a similarity threshold value, testing the candidate recognition rule based on the historical account behavior set to obtain a preset test index; if the preset test index meets the condition, adding the candidate identification rule into a current identification rule base; and in response to the received target financial account behavior data, performing anomaly identification on the target financial account behavior data based on the latest identification rule library of the rule engine. By adopting the method, the new recognition rule can be automatically and efficiently learned from the abnormal data, the problems that the recognition rule depends on manual summarization, updating lags and the like are avoided, and the anomaly recognition timeliness and the intelligence level are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of financial analysis, in particular to a financial account abnormality identification method, a financial account abnormality identification device, a computer device, a computer readable storage medium and a computer program product. BACKGROUND

[0002] In recent years, behaviors such as telecom fraud and network fraud occur more and more frequently. As an important node of fraud behaviors, banks are involved in increasingly large amounts, which not only causes serious harm to customer funds, but also seriously affects the normal transaction mechanism of the bank. In order to reduce customer fund losses and improve the bank's anti-fraud level, it is urgent to establish a perfect account abnormality identification mechanism.

[0003] At present, there are some technical solutions in the industry that combine data analysis and rule determination. Such solutions collect bank internal transaction data and external data such as judicial investigation and control, use machine learning models to extract features and score abnormalities from the data, and then combine pre-set business rules for comprehensive research and judgment in order to achieve risk early warning.

[0004] However, the rules relied on by such existing solutions are usually static rules based on historical cases, manually summarized and pre-encoded, and separate from the data analysis model in the front end. This mutual separation of model analysis and rule determination can make the update of the entire system seriously lag behind the evolution of fraud methods, making it difficult to discover new fraud patterns in a timely manner, and thus making it difficult to cope with constantly renewed fraud methods, seriously restricting the timeliness and intelligence level of bank anti-fraud identification. SUMMARY

[0005] Therefore, it is necessary to provide a financial account abnormality identification method, a financial account abnormality identification device, a computer device, a computer readable storage medium and a computer program product in view of the above technical problems.

[0006] In a first aspect, the present application provides a financial account abnormality identification method, which comprises: obtaining multi-source data of a newly added abnormal account; identifying a suspicious behavior pattern from the multi-source data and generating a candidate identification rule based on the suspicious behavior pattern; performing similarity comparison of the candidate identification rule with each identification rule in a current identification rule library of a rule engine, to obtain corresponding similarity indicators; the identification rules in the current identification rule library are all generated based on historical abnormal behavior patterns, and the historical abnormal behavior patterns are identified from multi-source data of historical abnormal accounts; if each similarity indicator is less than a similarity threshold, testing the candidate identification rule based on a historical account behavior set to obtain a preset test indicator; If the preset test index meets the preset conditions, the candidate recognition rule is added to the current recognition rule library; In response to receiving target financial account behavior data, the system performs anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

[0007] In one embodiment, the multi-source data includes financial transaction data and judicial investigation and control data; The step of identifying suspicious behavior patterns from the multi-source data of the newly added abnormal accounts includes: Based on the financial transaction data, the first data to be analyzed for the newly added abnormal account is obtained, and financial behavior characteristics are extracted from the first data to be analyzed; the first data to be analyzed includes account opening behavior information, activation behavior information, transaction behavior information, and credit limit increase behavior information; Based on the judicial investigation and control data, the second data to be analyzed for the newly added abnormal account is obtained, and abnormal behavior characteristics are extracted from the second data to be analyzed; the second data to be analyzed includes abnormal behavior information. Based on the financial behavior characteristics, the abnormal behavior characteristics, and the preset behavior pattern template, a suspicious behavior pattern is generated.

[0008] In one embodiment, the preset behavior pattern template includes multiple feature extraction dimensions; Based on the financial behavior characteristics, the abnormal behavior characteristics, and the preset behavior pattern template, a suspicious behavior pattern is generated, including: Starting from the account opening time, the financial behavior characteristics and abnormal behavior characteristics are arranged in chronological order of the occurrence of the behaviors to form time-series data of account behavior characteristics. Feature values ​​of each feature extraction dimension are extracted from the time-series data of account behavior characteristics, and the feature values ​​are combined according to the preset behavior pattern template to generate a target feature sequence. The target feature sequence is used as a suspicious behavior pattern.

[0009] In one embodiment, the plurality of feature extraction dimensions include at least two of the following: activation delay days, transaction frequency after activation, transaction amount after activation, credit limit increase delay days, transaction type after credit limit increase, and total time from account opening to anomaly.

[0010] In one embodiment, the rule engine is the Drools rule engine; The step of generating candidate identification rules based on the suspicious behavior pattern includes: Convert the target feature sequence corresponding to the suspicious behavior pattern into a conditional statement; Based on the syntax rules of the Drools rule engine, the conditional statement is encapsulated into candidate recognition rules.

[0011] In one embodiment, the candidate recognition rule is compared with each recognition rule in the current recognition rule base to obtain a corresponding similarity index, including: Based on the preset behavior pattern template, the candidate recognition rules and each recognition rule in the current recognition rule base are respectively parsed into corresponding condition feature sets; the condition feature set consists of multiple condition clauses, and the multiple condition clauses correspond to the multiple feature extraction dimensions respectively; Calculate the Jaccard similarity between the condition feature set of the candidate recognition rule and the feature set of each recognition rule in the current recognition rule base, and use it as the corresponding similarity index.

[0012] In one embodiment, the historical account behavior set includes a historical normal account behavior set, and the preset test indicators include a false alarm rate indicator; The candidate identification rules are tested based on the historical normal account behavior set to obtain the false positive rate index, including: The candidate identification rule is executed on the set of historical normal account behaviors; The number of accounts that triggered the candidate identification rules was counted to obtain the number of false alarms; The ratio of the number of false alarms to the total number of accounts in the historical normal account behavior set is calculated as the false alarm rate indicator.

[0013] In one embodiment, the historical account behavior set further includes a historical abnormal account behavior set, and the preset test index further includes a detection rate index; The candidate identification rules are tested based on the historical abnormal account behavior set to obtain the detection rate index, including: The candidate identification rules are executed for the set of historical abnormal account behaviors; The number of accounts that trigger the candidate identification rules is counted to obtain the number of detected accounts; The ratio of the number of detected accounts to the total number of accounts in the historical abnormal account behavior set is calculated as the detection rate indicator.

[0014] In one embodiment, the preset test index meets preset conditions including: The false alarm rate is less than the first threshold and the detection rate is greater than the second threshold.

[0015] In one embodiment, after adding the candidate recognition rule to the current recognition rule base, the method further includes: Obtain the early warning information and corresponding review results generated by the candidate recognition rule within a preset recognition period; The number of warning messages that were false alarms after the review was counted to obtain the number of false alarms after review; Calculate the ratio of the number of false alarms to the total number of warning messages; If the ratio is greater than the misjudgment threshold, the candidate recognition rule is removed from the current recognition rule base.

[0016] Secondly, this application also provides a financial account anomaly identification device, the device comprising: The data acquisition module is used to acquire multi-source data on newly added abnormal accounts; A candidate rule generation module is used to identify suspicious behavior patterns from the multi-source data and generate candidate identification rules based on the suspicious behavior patterns. The similarity comparison module is used to perform a similarity comparison between the candidate recognition rules and each recognition rule in the current recognition rule library of the rule engine to obtain the corresponding similarity index; the recognition rules in the current recognition rule library are all generated based on historical abnormal behavior patterns, which are identified from multi-source data of historical abnormal accounts; The testing module is used to test the candidate recognition rules based on the historical account behavior set if all similarity indicators are less than the similarity threshold, and obtain preset test indicators; if the preset test indicators meet preset conditions, the candidate recognition rules are added to the current recognition rule library. The real-time analysis module is used to respond to the received target financial account behavior data and perform anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

[0017] Thirdly, embodiments of this application provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of a financial account anomaly identification method.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a financial account anomaly identification method.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of a financial account anomaly identification method.

[0020] One of the above technical solutions has the following advantages or beneficial effects: By acquiring multi-source data on newly added abnormal accounts, suspicious behavior patterns can be identified from the multi-source data, and candidate identification rules can be generated based on the suspicious behavior patterns. This enables the automatic and efficient learning of new rules from new cases. Through similarity comparison and validity testing, the candidate identification rules, after rigorous screening, can be added to the current identification rule base for real-time analysis and application. This solution avoids the problems of identification rules relying on manual summarization and long update cycles, which lead to a disconnect between model analysis and rule judgment, and delayed updates. By automating the transformation from data to usable rules, it ensures the quality and necessity of new rules, ultimately enabling the system's analytical capabilities to keep up with and even anticipate changes in fraud methods, significantly improving the timeliness and intelligence level of bank anti-fraud identification. Attached Figure Description

[0021] Figure 1 This is an application environment diagram of a financial account anomaly identification method in one embodiment; Figure 2 This is a flowchart illustrating a financial account anomaly identification method in one embodiment; Figure 3 This is a flowchart illustrating a financial account anomaly identification method in another embodiment; Figure 4 This is a structural block diagram of a financial account anomaly identification device in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] It should be noted that all information (including but not limited to account opening behavior information, activation behavior information, transaction behavior information, credit limit increase behavior information and abnormal behavior information) and data (including but not limited to financial transaction data and judicial investigation and control data, etc., used for analysis, stored data, and displayed data) involved in this application are all information and data authorized by the customer or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0025] The financial account anomaly identification method provided in this application can be applied to, for example... Figure 1 In the application environment shown, mobile terminal 102 communicates with financial account anomaly identification server 104 via a network. Mobile terminal 102 initiates or associates various financial account transactions and uploads the resulting target financial account behavior data to financial account anomaly identification server 104 in real-time or near real-time. After receiving the target financial account behavior data from mobile terminal 102, financial account anomaly identification server 104 can call its internally built rule engine's latest identification rule library to identify anomalies in the target financial account behavior data. Financial account anomaly identification server 104 communicates with financial account behavior early warning platform 106 via a network, and can then upload the analysis results to financial account behavior early warning platform 106 for fraud early warning. Financial account behavior early warning platform 106 can be used for centralized display and distribution of risk warnings and scheduling of subsequent manual handling processes.

[0026] In such Figure 1 In the application environment shown, the mobile terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets and portable wearable devices; the financial account anomaly identification server 104 can be implemented by a standalone server or a server cluster consisting of multiple servers.

[0027] In one embodiment, such as Figure 2 As shown, a method for identifying anomalies in financial accounts is provided, which can be applied to... Figure 1 Taking the financial account anomaly detection server 104 in the system as an example, the following steps are included: S202, Obtain multi-source data for newly added abnormal accounts.

[0028] It should be explained that, in this embodiment, a newly added abnormal account can be a bank account that has been preliminarily identified by the risk identification system or investigated and controlled by an external authoritative institution (such as judicial or regulatory authorities) and reported to the financial institution, and is now confirmed to be involved in high-risk activities such as fraud and money laundering. Its multi-source data can be understood as a collection of data related to account behavior obtained from multiple independent sources, which may include at least internal bank financial transaction data and judicial investigation and control data from authorized authorities. Further, financial transaction data can refer to all fund transfer records and related information generated by the account within the banking system, including but not limited to all deposit, withdrawal, transfer, and consumption details since the account was opened; judicial investigation and control data can refer to account information, transaction records, case transcripts, case analysis data, etc., legally obtained by authorized authorities from financial institutions for case investigation purposes, including but not limited to abnormal amounts, case types such as telecommunications fraud, and fund freeze dates.

[0029] In this step, obtaining multi-source data can be understood as obtaining various aspects of the newly added abnormal account through reasonable, legal and compliant means, such as using data interfaces to extract the account's financial transaction data from the bank's core transaction system, and obtaining corresponding judicial investigation and control data from judicial cooperation platforms, etc.

[0030] S204 identifies suspicious behavior patterns from multi-source data and generates candidate identification rules based on the suspicious behavior patterns.

[0031] Understandably, this step aims to automatically extract key behavioral patterns that characterize the abnormal risks of newly added abnormal accounts from the massive and chaotic raw data. These patterns are then transformed into one or more identification rules that can be executed by the rule engine—i.e., candidate identification rules. This step automates the transformation from data to rules, eliminating reliance on manual experience to summarize rules, avoiding the lag in rule updates, facilitating the timely detection of new fraud patterns, and helping to improve the timeliness and intelligence of banks' anti-fraud identification efforts.

[0032] S206, perform a similarity comparison between the candidate identification rules and each identification rule in the current identification rule base of the rule engine to obtain the corresponding similarity index; the identification rules in the current identification rule base are all generated based on historical abnormal behavior patterns, which are identified from multi-source data of historical abnormal accounts.

[0033] The rule engine can be understood as a software component that separates business decision-making logic from application code. After receiving input data, it can reason and make decisions based on a predefined set of rules, namely the set of recognition rules in the current recognition rule base mentioned above. The rule engine can be the open-source Drools rule engine, or other rule engines can be set according to actual needs.

[0034] The current identification rule base stores all identification rules currently running online, generated based on historical abnormal account behavior patterns. Understandably, the acquisition of multi-source data for historical abnormal accounts can be found in the multi-source data acquisition scheme for newly added abnormal accounts in S202. The only difference between the two is the timing of multi-source data acquisition; the acquisition method and data type of the multi-source data can be configured to be consistent. Similarly, the identification method for historical abnormal behavior patterns can be found in the identification method for suspicious behavior patterns in S204, and will not be elaborated here.

[0035] The similarity comparison in this step is used to evaluate the similarity between the newly generated candidate recognition rule and each recognition rule in the existing rule base. The output is a series of similarity indicators. Based on these similarity indicators, it can be determined whether the candidate recognition rule is a new rule. This ensures that only candidate rules that are significantly different from existing recognition rules, i.e., may represent new fraud methods, can enter the subsequent process. This avoids the rule base being filled with a large number of similar or redundant rules, thus ensuring the simplicity and efficiency of the recognition rule base. The solution is reasonable and highly practical.

[0036] S208. If all similarity indicators are less than the similarity threshold, the candidate identification rules are tested based on the historical account behavior set to obtain the preset test indicators.

[0037] Based on the above analysis, it can be seen that all similarity indicators are less than the similarity threshold, which indicates that the candidate recognition rule is significantly different from the existing recognition rule, and is more likely to come from a new fraud method. Only in this case can the similarity threshold be used to test the candidate recognition rule.

[0038] The historical account behavior set used for testing is a dataset for evaluating rule performance, typically containing a large amount of historical behavioral data from normal accounts and known abnormal accounts. Candidate recognition rules are applied to this historical account behavior set to simulate their performance. Preset test metrics, such as false positive rate and detection rate, are used to measure the performance of the rule. This step validates the selected rules; only rules that perform well on the historical account behavior set, such as those with low false positive rates and high detection rates, can proceed to the next stage. The similarity threshold can be preset based on business scenarios, historical data testing, or expert experience; no restrictions are set here.

[0039] S210. If the preset test indicators meet the preset conditions, the candidate recognition rules will be added to the current recognition rule library.

[0040] The preset conditions are the final criteria for rule admission, such as a false positive rate below a certain threshold and / or a detection rate above a certain threshold. Only when a candidate rule meets both the requirements of being a new rule and a valid rule can it be added or hot-deployed to the online rule engine's rule base. This approach enables newly discovered fraud patterns to be analyzed by the system in real time, achieving synchronous updates of the analysis model and the evolution of fraud methods.

[0041] S212, in response to receiving target financial account behavior data, performs anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

[0042] The target financial account behavior data in this step can be understood as the transaction records and other behavioral data of any account generated in real time by a financial institution. The system continuously receives this data and calls upon the latest updated identification rule library, which includes newly added rules, for real-time scanning and matching. Once an account's behavior triggers any rule, a risk warning is immediately generated. This solution utilizes a dynamically evolving, up-to-date identification rule library to achieve real-time and accurate risk analysis of all accounts across the bank. Ultimately, based on the matching results from the rule engine, it can output analytical conclusions such as normal status or risk warnings for anti-fraud personnel to handle.

[0043] Taking the analysis of money laundering fraud involving digital collectibles as an example, assuming that the latest identification rule library of the rule engine already contains an identification rule dynamically added by the above method, its logic can be as follows: if an account receives a single deposit of more than 100,000 yuan and within 24 hours completes a closed-loop transaction of deposit, purchase, transfer, sale, and withdrawal across three or more digital collectible platforms, an alert is triggered. A specific implementation of this step is as follows: when the system receives real-time transaction data (i.e., behavioral data of the target financial account) of a target financial account, the rule engine can load and execute such rules one by one; furthermore, the rule engine will analyze the account's transaction sequence. If it identifies that the behavior fully meets all the conditions of the above rule—that is, a deposit of more than 100,000 yuan did indeed occur within the analysis window, and subsequently, a complete closed loop of buying and selling digital collectibles was quickly completed on multiple platforms—then all the conditions of the rule are met, the rule is triggered, and the system immediately generates a high-risk alert to achieve real-time identification and risk warning of accounts that conform to specific suspicious behavior patterns.

[0044] In the above embodiments of this application, the executing entity can be a computer device with certain computing capabilities. In the financial account anomaly identification method of the above embodiments, by acquiring multi-source data of newly added abnormal accounts, identifying suspicious behavior patterns from the multi-source data, and generating candidate identification rules based on the suspicious behavior patterns, new rules can be automatically and efficiently learned from new cases. Through similarity comparison and validity testing, the rigorously screened candidate identification rules can be added to the current identification rule base for real-time analysis and application. This solution avoids the problems of identification rules relying on manual summarization and long update cycles, leading to a disconnect between model analysis and rule judgment, and delayed updates. By automating the transformation from data to usable rules, the quality and necessity of newly added rules are ensured, ultimately enabling the system's analytical capabilities to keep pace with and even anticipate changes in fraud methods, significantly improving the timeliness and intelligence level of bank anti-fraud identification.

[0045] In one embodiment, the multi-source data includes financial transaction data and judicial investigation and control data; S204 specifically includes: based on the financial transaction data, obtaining the first data to be analyzed for newly added abnormal accounts, and extracting financial behavior characteristics from the first data to be analyzed; the first data to be analyzed includes account opening behavior information, activation behavior information, transaction behavior information, and credit limit increase behavior information; based on the judicial investigation and control data, obtaining the second data to be analyzed for newly added abnormal accounts, and extracting abnormal behavior characteristics from the second data to be analyzed; the second data to be analyzed includes abnormal behavior information; and generating a suspicious behavior pattern based on the financial behavior characteristics, abnormal behavior characteristics, and a preset behavior pattern template.

[0046] The first set of data to be analyzed is a subset of data focused on specific risk points, obtained after cleaning and structuring the original financial transaction data. This includes, but is not limited to, account opening information (such as account opening time and channel), activation information (such as activation time and method), transaction information (such as transaction time, amount, counterparty account, and transaction IP address), and credit limit increase information (such as credit limit increase application and approval time, and credit limit changes). Extracting financial behavior features from the first set of data to be analyzed can be understood as transforming each piece of information in the first set of data into quantifiable and calculable feature values. For example, the time difference between account opening and activation can be quantified as an activation delay of 5 days, and the first week of transactions after activation can be statistically analyzed as a transaction frequency of 10 times and an average amount of 500 yuan, etc. This step transforms the original financial transaction data into features with business meaning, which can lay the groundwork for the subsequent identification of suspicious behavior patterns.

[0047] In addition, the second set of data to be analyzed, such as Figure 3As shown, this can be understood as key information extracted from judicial investigation and control data. Key information includes, but is not limited to, abnormal behavior information, such as abnormal time, abnormal amount, and case type (e.g., fraudulent online order scams). Extracting abnormal behavior features from the second set of data to be analyzed can specifically include performing natural language processing on the case text to extract keywords as tags, or directly using abnormal amounts, dates, transaction frequencies, transaction IPs, etc.

[0048] It should be noted that the preset behavior pattern template used to generate suspicious behavior patterns can be a predefined, structured framework for describing account risk behavior. It can define multiple feature extraction dimensions, specifying which dimensions of features need to be extracted from account behavior. This step, by calling this template, combines and structures the extracted financial behavior features and abnormal behavior features according to the template requirements, ultimately generating a uniformly formatted suspicious behavior pattern. This pattern can be understood as a structured data object, such as a feature vector or a JSON object. The suspicious behavior pattern clearly describes the sequence of key risk behaviors of the account from account opening to the abnormal process. By introducing the preset behavior pattern template, the standardization and automation of risk feature extraction are achieved, allowing suspicious patterns from different accounts and cases to be compared and analyzed under the same set of standards. Understandably, introducing the preset behavior pattern template is the foundation for subsequent rule generation and similarity comparison in this solution.

[0049] In one embodiment, the preset behavior pattern template includes multiple feature extraction dimensions; S204 may further include: taking the account opening time as the starting time point, arranging the financial behavior features and abnormal behavior features in the order of the occurrence time of the behavior to form account behavior feature time series data; extracting feature values ​​of each feature extraction dimension from the account behavior feature time series data, combining each feature value according to the preset behavior pattern template to generate a target feature sequence; and using the target feature sequence as a suspicious behavior pattern.

[0050] Among them, account behavior characteristic time series data, that is, characteristic sequences organized along a time axis, arranges discrete financial behavior characteristics (such as a credit limit increase on a certain day) and abnormal characteristics (such as an account being frozen on a certain day) in an orderly manner, forming a complete behavior sequence from account opening to the point of abnormality. For example, account behavior characteristic time series data can be: [Day T: Account opening, Day T+5: Activation, Day T+10: First large payment received, ..., Day T+30: Abnormal account freeze].

[0051] By temporalizing features, it is helpful to capture the temporal correlation and sequential patterns between behaviors, thereby identifying fraud patterns.

[0052] As mentioned above, the feature extraction dimension is each item to be extracted defined in the preset behavior pattern template, such as the activation delay in days. The system scans the time-series data and calculates the specific feature value corresponding to each dimension; then, the feature values ​​are combined according to the structure and order specified by the preset behavior pattern template to generate the target feature sequence.

[0053] In one embodiment, multiple feature extraction dimensions include at least two of the following: activation delay days, post-activation transaction frequency, post-activation transaction amount, credit limit increase delay days, post-credit limit increase transaction type, and total duration from account opening to anomaly. Of course, new feature extraction dimensions can also be added based on other key observation points of high-risk behavior summarized from banking business and anti-fraud experience; there are no restrictions here. The activation delay days refer to the time interval from account opening to the first successful application for a credit limit increase; an abnormally short interval may indicate unauthorized operation. Post-activation transaction frequency and amount describe the activity and probing behavior of the account in the early stages of activation. The credit limit increase delay days refer to the time from activation to the first successful application for a credit limit increase. Post-credit limit increase transaction type mainly focuses on transactions made immediately after obtaining a higher credit limit, such as purchasing highly liquid goods. The dimension of total duration from account opening to anomaly reflects the length of the entire criminal cycle. By extracting features from the above dimensions, the behavioral profile of common credit card farming fraud accounts can be effectively depicted, providing elements for generating accurate identification rules.

[0054] For example, if a preset behavioral pattern template defines multiple feature extraction dimensions as: [activation delay days, transaction amount after activation, credit limit increase delay days, and type of large transaction after credit limit increase], then from the time-series data of a certain account, a sequence might be extracted: [activation delay days = 5, transaction amount after activation = 800, credit limit increase delay days = 15, type of large transaction after credit limit increase = purchase of gold / precious metals]. This sequence can be understood as a quantitative and structured representation of the account's suspicious behavioral pattern. The generated structured sequence can then be identified as the suspicious behavioral pattern of the newly added abnormal account.

[0055] In one embodiment, the rule engine is the Drools rule engine described above; S204 may further include: converting the target feature sequence corresponding to the suspicious behavior pattern into a conditional statement; and encapsulating the conditional statement into a candidate recognition rule based on the syntax rules of the Drools rule engine.

[0056] This step transforms a structured data schema into executable program rules. Specifically, each feature value in the target feature sequence is converted into a conditional clause in the Drools rule syntax.

[0057] For example, the feature sequence [activation delay days = 5, transaction type after credit limit increase = gold, precious metals] can first be converted into a conditional statement: Account(activationDelay==5&&postLimitIncreaseTransactionType==Gold, Precious Metals).

[0058] Subsequently, this conditional statement, along with the alert action, is encapsulated into a complete Drools rule script, namely the candidate identification rule. Because the Drools rule engine supports hot deployment, the generated candidate identification rule can be loaded and executed immediately after similarity comparison and validity testing.

[0059] In one embodiment, S206 specifically includes: based on a preset behavior pattern template, parsing the candidate recognition rules and each recognition rule in the current recognition rule base into corresponding condition feature sets; the condition feature set consists of multiple condition clauses, and the multiple condition clauses correspond to multiple feature extraction dimensions respectively; calculating the Jaccard similarity between the condition feature set of the candidate recognition rule and the feature set of each recognition rule in the current recognition rule base, as the corresponding similarity index.

[0060] Understandably, in this embodiment, both candidate rules and existing recognition rules are derived from feature sequences generated by the same set of preset behavioral pattern templates. Therefore, they can be reverse-parsed back into a structured set of conditional features based on this template. The essence of this set can be understood as the original feature dimensions and their values ​​corresponding to the rules. For example, a recognition rule might parse a set of conditional features as {activation delay = 5-7 days, transaction type = gold, precious metals}. Since all rules correspond to the same set of feature dimensions, their comparisons have a common basis. Jaccard similarity can be used to measure the similarity between two feature sets. Specifically, the similarity index can be obtained by calculating the ratio of the intersection size to the union size of the two sets. If the similarity index is high, it indicates that the risk characteristics judged by the old and new rules highly overlap, and the new rule may be redundant; if the similarity index is low, it indicates that the new rule may be a new combination of features, possessing rule novelty.

[0061] In one embodiment, the historical account behavior set includes the historical normal account behavior set, and the preset test indicators include the false positive rate indicator; S208 specifically includes: executing candidate identification rules for the historical normal account behavior set; counting the number of accounts that trigger the candidate identification rules to obtain the number of false positives; and calculating the ratio of the number of false positives to the total number of accounts in the historical normal account behavior set as the false positive rate indicator.

[0062] The historical normal account behavior set can be understood as consisting of a large amount of historical data from confirmed risk-free normal accounts. During testing, candidate identification rules can be simulated and executed on this dataset. The false positive rate (FPR) is the core metric for evaluating the accuracy of the rules. It is calculated as follows: Candidate identification rules are executed on the historical normal account behavior set, and the number of accounts triggering these rules is counted to obtain the number of false positives. The ratio of the number of false positives to the total number of accounts in the historical normal account behavior set is then used as the FPR. Through FPR testing, overly broad rules that lead to a large number of false alarms can be filtered out, ensuring the effectiveness of online analysis and user experience.

[0063] In one embodiment, the historical account behavior set further includes a historical abnormal account behavior set, and the preset test indicators further include a detection rate indicator; S208 may further include: executing candidate identification rules for the historical abnormal account behavior set; counting the number of accounts that trigger the candidate identification rules to obtain the number of detections; and calculating the ratio of the number of detections to the total number of accounts in the historical abnormal account behavior set as the detection rate indicator.

[0064] The historical abnormal account behavior set can be understood as consisting of account data that has been proven to be abnormal in the past. During testing, candidate rules can be executed on this dataset. The detection rate metric assesses the completeness of the rules, and its calculation method is as follows: execute candidate identification rules on the historical abnormal account behavior set; count the number of accounts that trigger the candidate identification rules to obtain the detection count; calculate the ratio of the detection count to the total number of accounts in the historical abnormal account behavior set, which is used as the detection rate metric. The detection rate metric and the false alarm rate metric can be used alone or in combination. When used in combination, this embodiment can constitute a dual assessment of rule performance, ensuring that the admission rules are both accurate and comprehensive.

[0065] In one embodiment, the preset test indicators in S210 meeting preset conditions may specifically include: the false positive rate indicator being less than a first threshold and the detection rate indicator being greater than a second threshold. The first and second thresholds can be set according to the acceptable false positive level and the expected minimum detection capability. For example, a false positive rate of less than 0.1% and a detection rate of more than 85% may be required. In this embodiment, only candidate identification rules that simultaneously meet both conditions are eligible for online operation. This scheme ensures that every new rule added to the rule base can contribute to actual analysis, improving the accuracy and reliability of the overall risk control system.

[0066] In one embodiment, after S210, the financial account anomaly identification method may further include: obtaining the early warning information and corresponding review results generated by the candidate identification rule within a preset identification period; counting the number of early warning information whose review results are false alarms to obtain the number of review false alarms; calculating the ratio of the number of review false alarms to the total number of early warning information; if the ratio is greater than the misjudgment threshold, removing the candidate identification rule from the current identification rule base.

[0067] The preset identification period is a timeframe for observing the effectiveness of a rule after its implementation, such as one week or one month, which can be configured as needed. During this period, the system collects all alerts triggered by the rule, as well as the manual review conclusions of anti-fraud specialists for each alert. The manual review conclusion can be "confirmed as a risk" or "confirmed as a false alarm." The false alarm threshold can be understood as the trigger condition for a rule to be phased out. If a rule generates too many false alarms in actual operation, it indicates that it may no longer be suitable for the latest normal transaction model, or that the initial testing failed to fully expose its defects. At this time, the system can automatically remove it from the rule base. This embodiment adds an effect tracking and phase-out mechanism to the rules, which, together with the previous generation and admission mechanisms, constitutes a complete lifecycle management of the rules. This scheme enables the identification rule base to have dynamic optimization capabilities, continuously maintaining high efficiency and accuracy, thereby being able to cope with the long-term changes in fraud methods.

[0068] In summary, this solution eliminates the need for manually written rules, significantly reducing the time lag between discovering new scams and establishing effective identification rules. This enables proactive and rapid evolution of risk control models and effectively addresses the issue of lagging analysis system updates. Specifically, based on judicial investigation and control data and account characteristic data, it continuously generates the latest analytical models with high timeliness and accuracy. Leveraging big data capabilities, it summarizes and forms new analytical models, enhancing account protection capabilities. Furthermore, it utilizes artificial intelligence models to complete data cleaning and feature extraction with high accuracy.

[0069] The deficiencies of the above solutions and the proposed solutions are the result of the inventor's practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventor's contribution to this disclosure.

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

[0071] Based on the same inventive concept, this application also provides a financial account anomaly identification device for implementing the above-described financial account anomaly identification method. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more financial account anomaly identification device embodiments provided below can be found in the limitations of the financial account anomaly identification method described above, and will not be repeated here.

[0072] In one embodiment, such as Figure 4 As shown, a financial account anomaly identification device 400 is provided, including: a data acquisition module 401, a candidate rule generation module 402, a similarity comparison module 403, a testing module 404, and a real-time analysis module 405, wherein: Data acquisition module 401 is used to acquire multi-source data of newly added abnormal accounts; The candidate rule generation module 402 is used to identify suspicious behavior patterns from multi-source data and generate candidate identification rules based on the suspicious behavior patterns. The similarity comparison module 403 is used to perform similarity comparison between the candidate recognition rules and each recognition rule in the current recognition rule library of the rule engine to obtain the corresponding similarity index; the recognition rules in the current recognition rule library are all generated based on historical abnormal behavior patterns, which are identified from multi-source data of historical abnormal accounts; The testing module 404 is used to test the candidate recognition rules based on the historical account behavior set if all similarity indicators are less than the similarity threshold, and obtain the preset test indicators; if the preset test indicators meet the preset conditions, the candidate recognition rules are added to the current recognition rule library. The real-time analysis module 405 is used to respond to the received target financial account behavior data and perform anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

[0073] In one embodiment, the multi-source data includes financial transaction data and judicial investigation and control data; the candidate rule generation module 402 is specifically used for: obtaining first data to be analyzed for newly added abnormal accounts based on financial transaction data, and extracting financial behavior characteristics from the first data to be analyzed; the first data to be analyzed includes account opening behavior information, activation behavior information, transaction behavior information, and credit limit increase behavior information; obtaining second data to be analyzed for newly added abnormal accounts based on judicial investigation and control data, and extracting abnormal behavior characteristics from the second data to be analyzed; the second data to be analyzed includes abnormal behavior information; and generating a suspicious behavior pattern based on the financial behavior characteristics, abnormal behavior characteristics, and a preset behavior pattern template.

[0074] In one embodiment, the preset behavior pattern template includes multiple feature extraction dimensions; the candidate rule generation module 402 can be further used to: arrange financial behavior features and abnormal behavior features in the order of the occurrence time of the behavior, taking the account opening time as the starting time point, to form account behavior feature time series data; extract feature values ​​of each feature extraction dimension from the account behavior feature time series data, combine each feature value according to the preset behavior pattern template, and generate a target feature sequence; and use the target feature sequence as a suspicious behavior pattern.

[0075] In one embodiment, the multiple feature extraction dimensions include at least two of the following: activation delay days, transaction frequency after activation, transaction amount after activation, credit limit increase delay days, transaction type after credit limit increase, and total time from account opening to anomaly.

[0076] In one embodiment, the rule engine is the Drools rule engine; the candidate rule generation module 402 can also be used to: convert the target feature sequence corresponding to the suspicious behavior pattern into a conditional statement; and encapsulate the conditional statement into a candidate recognition rule based on the syntax rules of the Drools rule engine.

[0077] In one embodiment, the similarity comparison module 403 is specifically used to: based on a preset behavior pattern template, parse the candidate recognition rules and each recognition rule in the current recognition rule library into corresponding condition feature sets; the condition feature set consists of multiple condition clauses, and the multiple condition clauses correspond to multiple feature extraction dimensions respectively; calculate the Jaccard similarity between the condition feature set of the candidate recognition rule and the feature set of each recognition rule in the current recognition rule library, as the corresponding similarity index.

[0078] In one embodiment, the historical account behavior set includes the historical normal account behavior set, and the preset test indicators include the false positive rate indicator; the test module 404 is specifically used to: execute candidate identification rules for the historical normal account behavior set; count the number of accounts that trigger the candidate identification rules to obtain the number of false positives; and calculate the ratio of the number of false positives to the total number of accounts in the historical normal account behavior set as the false positive rate indicator.

[0079] In one embodiment, the historical account behavior set also includes a historical abnormal account behavior set, and the preset test indicators also include a detection rate indicator; the test module 404 can also be used to: execute candidate identification rules for the historical abnormal account behavior set; count the number of accounts that trigger the candidate identification rules to obtain the number of detections; and calculate the ratio of the number of detections to the total number of accounts in the historical abnormal account behavior set as the detection rate indicator.

[0080] In one embodiment, the preset test indicators meeting the preset conditions may specifically include: the false alarm rate indicator being less than a first threshold and the detection rate indicator being greater than a second threshold.

[0081] In one embodiment, the financial account anomaly identification device 400 may further include a rule removal module, which can be used to: obtain the early warning information and corresponding review results generated by the candidate identification rule within a preset identification period; count the number of early warning information whose review results are false alarms to obtain the number of review false alarms; calculate the ratio of the number of review false alarms to the total number of early warning information; if the ratio is greater than the misjudgment threshold, remove the candidate identification rule from the current identification rule library.

[0082] Each module in the aforementioned financial account anomaly identification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0083] Furthermore, in the above-described implementation of the financial account anomaly identification device, the logical division of each program module is merely illustrative. In actual applications, the above functions can be assigned to different program modules as needed, for example, for the sake of corresponding hardware configuration requirements or the convenience of software implementation. That is, the internal structure of the financial account anomaly identification device can be divided into different program modules to complete all or part of the functions described above.

[0084] In one embodiment, a computer device is provided, the internal structure of which can be as follows: Figure 5As shown, the computer device includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a method for identifying abnormal financial accounts.

[0085] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0086] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

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

[0088] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0089] It should be noted that in the embodiments of this application, certain existing solutions in the industry, such as software, components, and models, may be mentioned. These should be considered as exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions. The methods described in this application are all independently developed executable software algorithms, all implemented using general-purpose high-level languages, and do not involve software licensing or other intellectual property issues.

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

[0091] The terms “comprising” and “having”, and any variations thereof, in the embodiments herein are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or (module) units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0092] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0093] The terms "first" and "second" used herein are merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" can be interchanged in a specific order or sequence where permissible. It should be understood that the objects distinguished by "first" and "second" can be interchanged where appropriate so that the embodiments described herein can be implemented in an order other than those illustrated or described herein.

[0094] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for identifying anomalies in financial accounts, characterized in that, The method includes: Obtain multi-source data on newly added abnormal accounts; Identify suspicious behavior patterns from the multi-source data, and generate candidate identification rules based on the suspicious behavior patterns; The candidate identification rules are compared with the identification rules in the current identification rule base of the rule engine to obtain the corresponding similarity index; the identification rules in the current identification rule base are all generated based on historical abnormal behavior patterns, which are identified from multi-source data of historical abnormal accounts; If all similarity indicators are less than the similarity threshold, the candidate identification rules are tested based on the historical account behavior set to obtain the preset test indicators. If the preset test index meets the preset conditions, the candidate recognition rule is added to the current recognition rule library; In response to receiving target financial account behavior data, the system performs anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

2. The method according to claim 1, characterized in that, The multi-source data includes financial transaction data and judicial investigation and control data; The step of identifying suspicious behavior patterns from the multi-source data of the newly added abnormal accounts includes: Based on the financial transaction data, the first data to be analyzed for the newly added abnormal account is obtained, and financial behavior characteristics are extracted from the first data to be analyzed; the first data to be analyzed includes account opening behavior information, activation behavior information, transaction behavior information, and credit limit increase behavior information; Based on the judicial investigation and control data, the second data to be analyzed for the newly added abnormal account is obtained, and abnormal behavior characteristics are extracted from the second data to be analyzed; the second data to be analyzed includes abnormal behavior information. Based on the financial behavior characteristics, the abnormal behavior characteristics, and the preset behavior pattern template, a suspicious behavior pattern is generated.

3. The method according to claim 2, characterized in that, The preset behavior pattern template includes multiple feature extraction dimensions; Based on the financial behavior characteristics, the abnormal behavior characteristics, and the preset behavior pattern template, a suspicious behavior pattern is generated, including: Starting from the account opening time, the financial behavior characteristics and abnormal behavior characteristics are arranged in chronological order of the occurrence of the behaviors to form time-series data of account behavior characteristics. Feature values ​​of each feature extraction dimension are extracted from the time-series data of account behavior characteristics, and the feature values ​​are combined according to the preset behavior pattern template to generate a target feature sequence. The target feature sequence is used as a suspicious behavior pattern.

4. The method according to claim 3, characterized in that, The multiple feature extraction dimensions include at least two of the following: activation delay days, transaction frequency after activation, transaction amount after activation, credit limit increase delay days, transaction type after credit limit increase, and total time from account opening to abnormality.

5. The method according to claim 3, characterized in that, The rule engine is the Drools rule engine; The step of generating candidate identification rules based on the suspicious behavior pattern includes: Convert the target feature sequence corresponding to the suspicious behavior pattern into a conditional statement; Based on the syntax rules of the Drools rule engine, the conditional statement is encapsulated into candidate recognition rules.

6. The method according to claim 5, characterized in that, The candidate recognition rule is compared with each recognition rule in the current recognition rule base to obtain the corresponding similarity index, including: Based on the preset behavior pattern template, the candidate recognition rules and each recognition rule in the current recognition rule base are respectively parsed into corresponding condition feature sets; the condition feature set consists of multiple condition clauses, and the multiple condition clauses correspond to the multiple feature extraction dimensions respectively; Calculate the Jaccard similarity between the condition feature set of the candidate recognition rule and the feature set of each recognition rule in the current recognition rule base, and use it as the corresponding similarity index.

7. The method according to any one of claims 1 to 6, characterized in that, The historical account behavior set includes the historical normal account behavior set, and the preset test indicators include the false alarm rate indicator; The candidate identification rules are tested based on the historical normal account behavior set to obtain the false positive rate index, including: The candidate identification rule is executed on the set of historical normal account behaviors; The number of accounts that triggered the candidate identification rules was counted to obtain the number of false alarms; The ratio of the number of false alarms to the total number of accounts in the historical normal account behavior set is calculated as the false alarm rate indicator.

8. The method according to claim 7, characterized in that, The historical account behavior set also includes the historical abnormal account behavior set, and the preset test indicators also include the detection rate indicator; The candidate identification rules are tested based on the historical abnormal account behavior set to obtain the detection rate index, including: The candidate identification rules are executed for the set of historical abnormal account behaviors; The number of accounts that trigger the candidate identification rules is counted to obtain the number of detected accounts; The ratio of the number of detected accounts to the total number of accounts in the historical abnormal account behavior set is calculated as the detection rate indicator.

9. The method according to claim 8, characterized in that, The preset test indicators must meet the preset conditions, including: The false alarm rate is less than the first threshold and the detection rate is greater than the second threshold.

10. The method according to any one of claims 1 to 6, characterized in that, After adding the candidate recognition rule to the current recognition rule base, the method further includes: Obtain the early warning information and corresponding review results generated by the candidate recognition rule within a preset recognition period; The number of warning messages that were false alarms after the review was counted to obtain the number of false alarms after review; Calculate the ratio of the number of false alarms to the total number of warning messages; If the ratio is greater than the misjudgment threshold, the candidate recognition rule is removed from the current recognition rule base.

11. A financial account anomaly identification device, characterized in that, The device includes: The data acquisition module is used to acquire multi-source data on newly added abnormal accounts; A candidate rule generation module is used to identify suspicious behavior patterns from the multi-source data and generate candidate identification rules based on the suspicious behavior patterns. The similarity comparison module is used to perform a similarity comparison between the candidate recognition rules and each recognition rule in the current recognition rule library of the rule engine to obtain the corresponding similarity index; the recognition rules in the current recognition rule library are all generated based on historical abnormal behavior patterns, which are identified from multi-source data of historical abnormal accounts; The testing module is used to test the candidate recognition rules based on the historical account behavior set if all similarity indicators are less than the similarity threshold, and obtain preset test indicators; if the preset test indicators meet preset conditions, the candidate recognition rules are added to the current recognition rule library. The real-time analysis module is used to respond to the received target financial account behavior data and perform anomaly identification on the target financial account behavior data based on the latest identification rule base of the rule engine.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

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

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images