Business rule configuration method, apparatus, device, and program product

Abstract

The application discloses a business rule configuration method, device, equipment and program product, the method is through obtaining the transaction data of target transaction, and calculating its multi-dimensional deviation characteristics relative to the behavior baseline of associated transaction subject, the quantification characterization of the deviation degree of each transaction is realized; on the basis, according to multi-dimensional deviation characteristics, risk transaction is automatically filtered from mass target transaction, the inefficient mode of artificial one by one is avoided; by clustering analysis to the multi-dimensional deviation characteristics of risk transaction, the transaction with similar abnormal mode can be merged into the same clustering cluster, so as to overcome the limitation that artificial experience is difficult to find the implicit rule from mass data; for each clustering cluster, the corresponding multi-dimensional deviation condition and the scene constraint condition based on transaction subject attribute information are extracted, and the structured risk control business rule is generated accordingly, the efficiency of rule configuration and the accuracy of rule determination are significantly improved.

Description

Technical Field

[0001] This application belongs to the field of transaction risk control technology, and in particular relates to a business rule configuration method, device, equipment and program product. Background Technology

[0002] In the current field of transaction risk control, the configuration of risk control business rules typically relies on human experience. Technical personnel need to manually set various thresholds and judgment conditions by combining business knowledge with historical transaction data, and write execution logic adapted to the rule engine. This manual configuration mode is not only inefficient, but also limited by the boundaries of human knowledge and experience, making it impossible to automatically summarize effective rule conditions from massive amounts of historical transaction data, thus making it difficult to guarantee the efficiency and accuracy of rule configuration.

[0003] Based on this, this application provides a method for configuring business rules. Summary of the Invention

[0004] This application provides a business rule configuration method, apparatus, device, and program product, which can significantly improve the efficiency of rule configuration and the accuracy of rule determination.

[0005] In a first aspect, embodiments of this application provide a business rule configuration method, the method comprising: For each target transaction's transaction data, calculate the multidimensional deviation features of the target transaction's transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction; Based on the multidimensional deviation characteristics corresponding to each of the target transactions, multiple risky transactions are selected from the multiple target transactions; Cluster the multidimensional deviation features corresponding to each of the aforementioned risk transactions to obtain at least one cluster; For each cluster, rules are extracted based on the multidimensional deviation features within the cluster to determine the multidimensional deviation conditions corresponding to the cluster, and the scenario constraints corresponding to the cluster are determined based on the attribute information of the transaction entities associated with each risk transaction within the cluster. Based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, risk control business rules corresponding to each cluster are generated and output.

[0006] Secondly, embodiments of this application provide a business rule configuration device, the device comprising: The deviation feature calculation module is used to calculate the multidimensional deviation features of the transaction data of each target transaction relative to the behavioral baseline of the transaction entity associated with the target transaction for each target transaction. The risk transaction screening module is used to screen out multiple risk transactions from multiple target transactions based on the multidimensional deviation characteristics corresponding to each target transaction; The deviation feature clustering module is used to cluster the multidimensional deviation features corresponding to each of the risk transactions to obtain at least one cluster. The rule condition determination module is used to extract rules based on the multidimensional deviation features within each cluster for each cluster, determine the multidimensional deviation conditions corresponding to the cluster, and determine the scenario constraint conditions corresponding to the cluster based on the attribute information of the transaction entities associated with each risk transaction within the cluster. The business rule output module is used to generate risk control business rules corresponding to each cluster based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, and output each risk control business rule.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements any of the possible implementations of the first aspect described above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the method in any of the possible implementations of the first aspect described above.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a method as described in any of the possible implementations of the first aspect above.

[0010] In this embodiment, by acquiring transaction data of target transactions and calculating their multidimensional deviation features relative to the baseline behavior of related transaction entities, a quantitative representation of the deviation degree of each transaction is achieved. Based on this, risky transactions are automatically screened from a massive number of target transactions according to the multidimensional deviation features, avoiding the inefficient method of manual, one-by-one screening. By performing cluster analysis on the multidimensional deviation features of risky transactions, transactions with similar abnormal patterns can be grouped into the same cluster, overcoming the limitation that human experience is insufficient to discover hidden patterns in massive amounts of data. For each cluster, the corresponding multidimensional deviation conditions and scenario constraints based on transaction entity attribute information are extracted, and structured risk control business rules are generated accordingly. Therefore, this embodiment significantly improves the efficiency of rule configuration and the accuracy of rule determination, reducing bias caused by subjective human judgment. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 An application environment diagram of a business rule configuration method in one embodiment; Figure 2 A flowchart illustrating a business rule configuration method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the overall process of a business rule configuration method provided in an embodiment of this application; Figure 4 A schematic diagram of a business rule configuration device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] Furthermore, the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant national laws and regulations.

[0016] As described in the background section, in the current field of transaction risk control, especially in the scenario of interbank card transactions, existing risk control systems mainly rely on two technical solutions. The first is an online real-time risk control solution with manually configured fixed rules. Risk control experts manually set single-dimensional threshold rules (such as single transaction limits or daily transaction limits) based on their business experience and deploy them to an online rule engine to intercept and judge real-time transactions. In this model, all judgment conditions and rule logic rely on manual writing by technical personnel, resulting in low efficiency and limitations imposed by personnel's cognitive and experience boundaries, making it difficult to summarize multi-dimensional effective rule combinations from massive amounts of data. The second is an online real-time risk scoring model solution, which uses machine learning models to dynamically score and identify risks from real-time transaction data. Its data processing and model calculations both run within the online transaction chain and only serve real-time interception.

[0017] However, both of these existing technologies have significant shortcomings. First, the rules heavily rely on human experience, with standardized and fixed thresholds, making it impossible to adapt to the personalized transaction patterns of different cardholders and merchants, resulting in high rates of missed and false positives. Second, the use of a one-size-fits-all judgment standard leads to insufficient accuracy in risk control. Third, both solutions are centered on online real-time processing and lack the ability to mine data offline. The massive amounts of historical archived transaction data cannot be used to optimize online risk control strategies, hindering the realization of data value. Furthermore, new types of cash-out schemes and cross-regional fraud exhibit multi-dimensional coupling and gradual shift characteristics, making it difficult for traditional single-dimensional rules to identify these hidden anomaly patterns.

[0018] In summary, existing risk control technologies have problems that urgently need to be addressed in terms of rule configuration efficiency, risk identification accuracy, and utilization of historical data.

[0019] Therefore, to address the problems of the prior art, embodiments of this application provide a business rule configuration method, apparatus, device, and program product. The business rule configuration method can be applied to any scenario where business rule configuration is required.

[0020] For example, the business rule configuration method provided in this application embodiment can be applied to, for example, Figure 1The application environment is shown. Terminal 110 communicates with server 120 via a network. A data storage system can store the data that server 120 needs to process. The data storage system can be integrated onto server 120 or placed on a cloud or other network server. For each target transaction, the server calculates the multidimensional deviation features of the transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction; based on the multidimensional deviation features of each target transaction, it selects multiple risky transactions from multiple target transactions; it clusters the multidimensional deviation features of each risky transaction to obtain at least one cluster; for each cluster, it extracts rules based on the multidimensional deviation features within the cluster to determine the multidimensional deviation conditions corresponding to the cluster, and determines the scenario constraints corresponding to the cluster based on the attribute information of the transaction entities associated with each risky transaction within the cluster; based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, it generates risk control business rules corresponding to each cluster and outputs these risk control business rules to terminal 110, which then configures these risk control business rules into its own business risk control system.

[0021] Terminal 110 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and other smart terminals. Server 120 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0022] The following section first introduces the business rule configuration method provided in the embodiments of this application.

[0023] Figure 2 This illustration shows a flowchart of a business rule configuration method provided in an embodiment of this application. Figure 2 As shown, the method includes the following steps: S210: For each target transaction's transaction data, calculate the multidimensional deviation characteristics of the target transaction's transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction.

[0024] S220: Based on the multidimensional deviation characteristics of each target transaction, select multiple risky transactions from multiple target transactions.

[0025] S230: Cluster the multidimensional deviation features corresponding to each risky transaction to obtain at least one cluster.

[0026] S240: For each cluster, extract rules based on the multidimensional deviation features within the cluster, determine the multidimensional deviation conditions corresponding to the cluster, and determine the scenario constraints corresponding to the cluster based on the attribute information of the trading entities associated with each risk transaction within the cluster.

[0027] S250: Based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, generate risk control business rules for each cluster and output each risk control business rule.

[0028] In this embodiment, by acquiring transaction data of target transactions and calculating their multidimensional deviation features relative to the baseline behavior of related transaction entities, a quantitative representation of the deviation degree of each transaction is achieved. Based on this, risky transactions are automatically screened from a massive number of target transactions according to the multidimensional deviation features, avoiding the inefficient method of manual, one-by-one screening. By performing cluster analysis on the multidimensional deviation features of risky transactions, transactions with similar abnormal patterns can be grouped into the same cluster, overcoming the limitation that human experience is insufficient to discover hidden patterns in massive amounts of data. For each cluster, the corresponding multidimensional deviation conditions and scenario constraints based on transaction entity attribute information are extracted, and structured risk control business rules are generated accordingly. Therefore, this embodiment significantly improves the efficiency of rule configuration and the accuracy of rule determination, reducing bias caused by subjective human judgment.

[0029] In S210 above, the target transaction is the single transaction object that is to be processed or judged and is targeted by the business rule configuration to be performed; the transaction data of the target transaction is the specific data content corresponding to the target transaction, including but not limited to information such as transaction amount and transaction time.

[0030] The transaction entities associated with the target transaction are the payers (e.g., users) or payees (e.g., merchants) associated with the target transaction, i.e., the initiator or recipient of the transaction. The behavioral baseline is a benchmark established based on the transaction data of the historical transactions corresponding to the transaction entities, representing their normal behavioral patterns.

[0031] Multidimensional deviation features are a set of features that include the degree of deviation of the target transaction from the behavioral baseline in multiple dimensions, such as transaction amount dimension, transaction frequency dimension, etc.

[0032] In some embodiments, for each target transaction's transaction data, the degree of deviation of the transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction is calculated in multiple dimensions to obtain the multidimensional deviation characteristics of the target transaction. The multidimensional deviation characteristics can be calculated using a difference ratio method, that is, the ratio of the difference between the current value and the baseline value to the baseline value is calculated as the deviation measure for each dimension. Other methods may also be used, and this embodiment does not limit this approach.

[0033] For example, in S220 above, the deviation features of each dimension can be weighted and summed according to the multidimensional deviation features corresponding to each target transaction to obtain a comprehensive risk score for each target transaction. Target transactions with scores exceeding a preset threshold are identified as risky transactions. Alternatively, corresponding judgment conditions can be set for each dimension of deviation features (e.g., setting judgment thresholds for each dimension). When the deviation feature of any dimension exceeds the corresponding judgment threshold, the corresponding target transaction is identified as a risky transaction. Here, a risky transaction is a target transaction whose multidimensional deviation features demonstrate abnormal behavior and have the potential for risk.

[0034] In some embodiments, in step S230 above, the multidimensional deviation features corresponding to each of the selected risky transactions are extracted as clustering input. A clustering algorithm is then used to group all the input multidimensional deviation features to obtain one or more clusters. Specifically, a partitioned clustering algorithm with a specified number of classes can be used to generate clusters based on multiple multidimensional deviation feature groups; alternatively, a density clustering algorithm can be used to automatically divide the clusters based on the distribution density of multiple multidimensional deviation features. Each cluster contains a set of risky transactions with similar feature distributions and a set of multidimensional deviation features corresponding to the risky transaction sets.

[0035] In S240 above, the multidimensional deviation condition is a combination of common conditions describing the multidimensional deviation characteristics of risky transactions within a cluster; the scenario constraint condition is a scenario constraint that limits the scope of application of the rules, determined based on the attribute information of the transaction entities associated with the risky transactions within the cluster; the attribute information of the transaction entity refers to the business attributes related to the transaction entity, including but not limited to the category of the transaction entity, the transaction scenario, and other information.

[0036] In some embodiments, for each cluster, deviation conditions of different dimensions are determined based on the feature distribution values ​​of all multidimensional deviation features within the cluster. The deviation conditions of all dimensions are summarized to obtain the multidimensional deviation conditions corresponding to the cluster. The attribute information of all risk transaction-related transaction entities within the cluster is statistically analyzed, and common attribute combinations with a proportion reaching a preset ratio are selected to determine the scenario constraints corresponding to the cluster.

[0037] In S250 above, the risk control business rules are structured rules consisting of scenario constraints and multi-dimensional deviation conditions. Specifically, for each cluster, the risk control business rules corresponding to that cluster are output as structured data (such as JSON), containing scenario constraint fields and deviation condition fields, which can be directly imported into the rule engine for execution; or, the risk control business rules are output as readable text describing natural language, and then converted into a language executable by the rule engine and configured into the rule engine.

[0038] In some embodiments, the multidimensional deviation features in S210 above include at least two of the following: transaction amount deviation features, transaction frequency deviation features, geographical deviation features, device deviation features, and transaction time deviation features.

[0039] The aforementioned transaction amount deviation features characterize the degree of deviation of the target transaction's transaction amount from the amount benchmark in the related party's behavioral baseline. The transaction frequency deviation feature characterizes the degree of deviation of the transaction frequency of the related party within a specific time window from the frequency benchmark in the related party's behavioral baseline. The geographic deviation feature characterizes the deviation of the geographic location of the target transaction from the historically reliable geographic range of the related party. The equipment deviation feature characterizes the deviation of the equipment used in the target transaction from the historically reliable equipment range of the related party. The transaction time deviation feature characterizes the deviation of the time period during which the target transaction occurs from the typical active periods of the related party.

[0040] The deviation features of the above five dimensions can be selected by combining at least two to form the multidimensional deviation features of the target transaction. Different combinations correspond to different dimensions of anomaly characterization: two-part combinations: for example, selecting transaction amount deviation features and transaction frequency deviation features to characterize transaction anomalies from the two core dimensions of amount and frequency, which can quickly screen for explicit abnormal transactions; or selecting geographical deviation features and transaction time deviation features to characterize anomalies from the spatial and temporal dimensions, which can identify scenarios such as anomalies in different locations and anomalies during inactive periods.

[0041] Three combinations: For example, selecting transaction amount deviation features, transaction frequency deviation features, and geographical deviation features, and integrating the three dimensions of amount, frequency, and space, can more precisely characterize abnormal cross-regional transaction behavior; or selecting transaction amount deviation features, device deviation features, and transaction time deviation features, and characterizing anomalies from the three dimensions of amount, device, and time, can identify abnormal scenarios such as fraudulent transactions.

[0042] Four combinations: For example, selecting deviation features of transaction amount, transaction frequency, geographical location, and device, and characterizing anomalies from four dimensions of amount, frequency, location, and device, can identify complex abnormal transactions with strong concealment.

[0043] Five-item combination: Simultaneously selecting deviation features of transaction amount, transaction frequency, geographical location, device, and transaction time, comprehensively quantifying the degree of deviation of the target transaction from the behavioral baseline from five dimensions: amount, frequency, location, device, and time. This can best characterize multi-dimensional coupled abnormal transaction behavior and improve the accuracy of risk identification.

[0044] In this embodiment, by combining at least two of the above five types of deviation features, the degree of deviation of the target transaction from the behavioral baseline can be comprehensively quantified from multiple dimensions. Compared with single-dimensional judgment, it can more comprehensively and accurately depict the abnormal characteristics of trading behavior, reduce the risk of misjudgment caused by single-dimensional random fluctuations, and improve the reliability of risk identification.

[0045] In some embodiments, the transaction entities include the transaction payer and the transaction payee; the transaction amount deviation characteristics include the transaction amount deviation ratio and the acquiring amount deviation ratio; the transaction frequency deviation characteristics include the transaction frequency deviation ratio and the acquiring frequency deviation ratio.

[0046] The aforementioned transaction amount deviation ratio quantifies the degree of deviation of the target transaction's transaction amount from the daily average transaction amount benchmark of the payer's behavior baseline associated with the target transaction, reflecting the deviation multiple of the payer's single expenditure amount from its historical normal expenditure level. The acquiring amount deviation ratio quantifies the degree of deviation of the target transaction's transaction amount from the daily average acquiring amount benchmark of the payee's behavior baseline associated with the transaction, reflecting the deviation multiple of the payee's single receipt amount from its historical normal acquiring level.

[0047] The transaction frequency deviation ratio quantifies the degree of deviation of the cumulative number of transactions of the payer associated with the target transaction within a target time window from the daily average transaction frequency benchmark of the payer's behavioral baseline. It reflects the deviation multiple of the payer's transaction frequency within a certain time window from its historical normal frequency. The acquiring frequency deviation ratio quantifies the degree of deviation of the cumulative number of acquiring transactions of the payee associated with the target transaction within a target time window from the daily average acquiring frequency benchmark of the payee's behavioral baseline. It reflects the deviation multiple of the payee's acquiring frequency within the target time window from its historical normal frequency.

[0048] The calculation process for the aforementioned transaction amount deviation ratio includes: calculating the transaction amount deviation ratio based on the transaction amount in the target transaction's transaction data and the average daily transaction amount in the behavioral baseline corresponding to the payment party associated with the target transaction. The specific calculation formula can be as follows: ,in, This indicates the deviation rate of the transaction amount; This indicates the transaction amount in the transaction data of the target transaction; This represents the average daily transaction amount in the behavioral baseline corresponding to the payment party of the target transaction.

[0049] The calculation process for the above-mentioned transaction frequency deviation ratio includes: calculating the transaction frequency deviation ratio based on the cumulative number of transactions of the transaction payer associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline of the corresponding transaction payer. The specific calculation formula can be as follows: ,in, Indicates the deviation ratio of trading frequency; This indicates the cumulative number of transactions made by the payer associated with the target transaction within the target time window. This indicates the average daily transaction frequency in the behavioral baseline corresponding to the payment party of the target transaction.

[0050] The calculation process for the above-mentioned order amount deviation ratio includes: calculating the order amount deviation ratio based on the transaction amount in the transaction data of the target transaction and the average daily order amount in the behavioral baseline corresponding to the transaction payee associated with the target transaction. The specific calculation formula is as follows: ,in, This indicates the deviation ratio of the received amount; This indicates the transaction amount in the transaction data of the target transaction; This represents the average daily transaction amount received by the corresponding behavioral baseline of the transaction payee associated with the target transaction.

[0051] The calculation process for the above-mentioned transaction frequency deviation ratio includes: calculating the transaction frequency deviation ratio based on the cumulative number of transactions by the transaction payee associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline corresponding to the transaction payee. The specific calculation formula is as follows: ,in, This indicates the deviation ratio of the frequency of acquiring orders; The cumulative number of transactions received by the payee associated with the target transaction within the target time window; This indicates the average daily transaction frequency in the behavioral baseline corresponding to the payee of the target transaction.

[0052] The above-mentioned regional deviation characteristics The calculation process includes: if the transaction region corresponding to the target transaction does not belong to the set of trusted regions of the payment party associated with the target transaction, the regional deviation feature is determined as a first preset value; if the transaction region corresponding to the target transaction belongs to the set of trusted regions of the payment party associated with the target transaction, the regional deviation feature is determined as a fourth preset value. The first preset value can be set to 1, and the fourth preset value can be set to 0, indicating that if the transaction region corresponding to the target transaction does not belong to the set of trusted regions of the payment party associated with the target transaction, then the target transaction is at risk of fraudulent use.

[0053] The above-mentioned equipment deviates from the characteristics The calculation process includes: if the transaction device corresponding to the target transaction does not belong to the trusted device set of the transaction payer associated with the target transaction, the device deviation characteristic is determined to be a second preset value; if the transaction device corresponding to the target transaction belongs to the trusted device set of the transaction payer associated with the target transaction, the device deviation characteristic is determined to be a fifth preset value. The second preset value can be set to 1, and the fifth preset value can be set to 0, indicating that if the transaction device corresponding to the target transaction does not belong to the trusted device set of the transaction payer associated with the target transaction, then the target transaction is at risk of fraud.

[0054] The above time period deviation characteristics The calculation process includes: when the target transaction's trading time falls within a preset abnormal period, the time period deviation characteristic is determined to be a third preset value; when the target transaction's trading time does not fall within a preset abnormal period, the time period deviation characteristic is determined to be a sixth preset value. The third preset value can be set to 1, and the sixth preset value can be set to 0, indicating that when the target transaction's corresponding trading time falls within a preset abnormal period, the target transaction faces a time period abnormality risk.

[0055] Among them, the average daily transaction amount is a baseline value reflecting the normal transaction amount level of the payer based on the transaction data of the payer's historical transactions; the average daily transaction frequency is a baseline value reflecting the normal transaction frequency level of the payer based on the transaction data of the payer's historical transactions; the average daily acquiring amount is a baseline value reflecting the normal acquiring amount level of the payee based on the transaction data of the payee's historical transactions; and the average daily acquiring frequency is a baseline value reflecting the normal acquiring frequency level of the payee based on the transaction data of the payee's historical transactions.

[0056] The target time window is a time interval used to count the cumulative number of transactions or orders received by the current payer or payee within a recent period. The target time window can be set starting from the moment the baseline is established and with a preset duration as the step size.

[0057] The trusted geographic set is a collection of regions where the payer's historical transactions have occurred, representing the geographical range in which they frequently appear. The trusted device set is a collection of commonly used devices used by the payer in their historical transactions, representing the range of their commonly used devices. The preset abnormal time period is a pre-defined period of unusual activity, such as from 0:00 to 6:00 AM.

[0058] For example, the multidimensional deviation features of the target transaction may include transaction amount deviation ratio, order amount deviation ratio, transaction frequency deviation ratio, order frequency deviation ratio, geographical deviation features, device deviation features, and transaction time deviation features, specifically in the form of [ This allows for a comprehensive quantification of the multidimensional deviation of the target transaction from the behavioral baseline, considering both the payer and payee, the transaction amount and frequency, as well as multiple perspectives such as region, device, and time period. This provides a rich feature base for subsequent risk transaction screening.

[0059] In this embodiment, by separating the transaction amount deviation feature and transaction frequency deviation feature into independent deviation ratios for the payer and payee, respectively, the degree of expenditure anomaly of the payer and the degree of acquisition anomaly of the payee can be quantified separately. This enables cross-validation of abnormal behavior by both parties, improving the precision of identifying abnormal behavior in complex transaction scenarios. Furthermore, by setting the geographical deviation feature, device deviation feature, and time period deviation feature as a binary judgment method based on a trusted set or preset conditions, abnormal states of transactions in the geographical, device, and time period dimensions can be quickly identified. This reduces the complexity of feature calculation and improves the efficiency and interpretability of multi-dimensional deviation feature extraction.

[0060] In some embodiments, the aforementioned transaction parties include the payer and the payee; The behavioral baselines corresponding to the aforementioned transaction entities can be constructed in the following manner: For each payer in the first preset transaction window, based on the transaction data corresponding to multiple historical transactions of the payer in the first preset transaction window, the total transaction amount and total number of transactions of the payer in the first preset transaction window are calculated, and the behavioral baseline of the payer is constructed based on the total transaction amount and total number of transactions. For each transaction payee existing in the second preset transaction window, based on the transaction data corresponding to multiple historical transactions of the transaction payee in the second preset transaction window, the total amount of transactions received and the total number of transactions received by the transaction payee in the second preset transaction window are counted, and the behavioral baseline of the transaction payee is constructed based on the total amount of transactions received and the total number of transactions received.

[0061] The first preset transaction window is a preset time interval used to statistically analyze the historical transaction behavior of the payer; the second preset transaction window is a preset time interval used to statistically analyze the historical transaction behavior of the payee. The first and second preset transaction windows can have the same time interval, or they can be set differently according to needs. For example, the first preset transaction window can be a 90-day time interval defined backward from a certain point in time; the second preset transaction window can be a 30-day time interval defined backward from a certain point in time.

[0062] Specifically, it acquires transaction data of all historical transactions within the first and second preset transaction windows, as well as attribute information and historical transaction behavior information of the transaction entities associated with each historical transaction.

[0063] Clean historical transaction data: remove historical transactions marked as system tests, historical transactions associated with specific types of payees (such as large chain merchants), etc.; remove dirty data with empty or garbled characters in key fields (such as card number, merchant number, transaction amount, etc.); filter out invalid transaction records that are not in the final settlement state, such as failed transactions, pre-authorization freezes, and pre-authorization revocations.

[0064] Next, the attribute information of the transaction entity is standardized by unifying the standard format of each field, such as the format of fields like card type, MCC (Merchant Category Code), transaction scenario identifier, device terminal number, and transaction time, to obtain the standardized attribute information of the transaction entity.

[0065] After data cleaning and field standardization, the transaction data of all historical transactions are grouped and aggregated according to the transaction payer and the transaction payee, respectively, to obtain the transaction data of each transaction payer and its corresponding multiple historical transactions in the first preset transaction window, and the transaction data of each transaction payee and its corresponding multiple historical transactions in the second preset transaction window, which are used as offline transaction datasets.

[0066] For each payer in the first preset transaction window, based on the payer's historical transaction data in the first preset transaction window, the total transaction amount of the payer in all historical transactions in the window is calculated to obtain the total transaction amount of the payer; the total number of transactions of the payer in all historical transactions in the window is calculated to obtain the total number of transactions of the payer, thereby constructing the behavioral baseline of the payer.

[0067] For each transaction payee within the second preset transaction window, based on the historical transaction data of that transaction payee within the second preset transaction window, the sum of the total amount of all historical transactions of that transaction payee within the window is calculated to obtain the total amount of transactions of that transaction payee; the sum of the total number of transactions of all historical transactions of that transaction payee within the window is calculated to obtain the total number of transactions of that transaction payee, thereby constructing the behavioral baseline of that transaction payee.

[0068] Furthermore, for each payer within the first preset transaction window, a trusted geographic set, a trusted device set, and a preset abnormal time period are constructed based on the payer's historical transaction behavior information. Specifically, the trusted geographic set is constructed based on regions where the proportion of times each region appears in the payer's historical transactions exceeds a first preset threshold (e.g., 80%); the trusted device set is constructed based on devices where the proportion of times each device is used in the payer's historical transactions exceeds a second preset threshold (e.g., 80%); and the preset abnormal time period is constructed based on time periods where the proportion of transactions in each time period within the payer's historical transactions is less than a third preset threshold (e.g., 5%).

[0069] In this embodiment, by separately calculating the total historical transaction amount and total number of transactions for the payer and payee in different preset transaction windows to construct behavioral baselines, personalized behavioral benchmarks can be established for both parties, improving the refinement and accuracy of behavioral baseline construction.

[0070] In some embodiments, the behavioral baseline of the transaction payer includes the transaction payer's average daily transaction amount and average daily transaction frequency; the behavioral baseline of the transaction payee includes the transaction payee's average daily transaction amount and average daily transaction frequency.

[0071] For each payer within a preset transaction window: based on the total transaction amount within the first preset transaction window and the total number of days in the first preset transaction window, calculate the average daily transaction amount for that payer. The specific calculation formula is as follows: ,in This indicates the average daily transaction amount; This indicates the total number of days in the first preset transaction window; Indicates the first party to pay in the transaction Total transaction amount for the day.

[0072] For each payer within the first preset transaction window: based on the total number of transactions within the first preset transaction window and the total number of days in the first preset transaction window, calculate the average daily transaction frequency for that payer. The specific calculation formula is as follows: ,in Indicates the average daily transaction frequency; This indicates the total number of days in the first preset transaction window; Indicates the first party to pay in the transaction Total number of transactions per day.

[0073] For each transaction recipient within the second preset transaction window: based on the total transaction amount within the second preset transaction window and the total number of days in the second preset transaction window, calculate the average daily transaction amount for that recipient. The specific calculation formula is as follows: ,in This indicates the average daily transaction amount. Indicates the total number of days in the second preset trading window; Indicates the first party to receive payment in the transaction Total daily transaction amount.

[0074] For each transaction recipient within the second preset transaction window: based on the total number of transactions within the second preset transaction window and the total number of days in the second preset transaction window, calculate the average daily transaction frequency for that transaction recipient. The specific calculation formula is as follows: ,in This indicates the average daily order frequency. Indicates the total number of days in the second preset trading window; Indicates the first party to receive payment in the transaction Total number of transactions received on a given day.

[0075] In this embodiment, by constructing a behavioral baseline for the payer of a transaction that includes the average daily transaction amount and the average daily transaction frequency, and constructing a behavioral baseline for the payee of a transaction that includes the average daily transaction amount and the average daily transaction frequency, the transaction habits of both parties within a unit of time can be accurately depicted. This provides an accurate basis for quickly identifying risks such as abnormal amounts, abnormal frequencies, or deviations from historical habits in subsequent real-time transactions.

[0076] In some embodiments, the above-described S220 may specifically include the following steps: For each target transaction, the risk score of the target transaction is obtained by weighting and summing the deviation feature values ​​in the multidimensional deviation features corresponding to the target transaction with the preset weights corresponding to each deviation feature value. Target transactions with risk scores greater than a preset score threshold are selected as candidate transactions; Based on the attribute information of the transaction entities associated with each candidate transaction, multiple candidate transactions are sampled and selected to obtain multiple risky transactions.

[0077] The aforementioned deviation feature values ​​are the specific numerical values ​​corresponding to each dimension in the multidimensional deviation feature, such as the deviation multiple of transaction amount, the deviation multiple of transaction frequency, and the geographical deviation feature. The preset weights are the weight coefficients of each deviation feature value in the risk score calculation, used to reflect the importance of different deviation features in contributing to risk.

[0078] For example, the preset weights can be obtained through offline training of logistic regression using a historical risk sample set, with higher weights assigned to high-risk features, and the sum of all weights being 1. The preset weights corresponding to each deviation feature value can also be set in other ways, and this embodiment does not limit this.

[0079] In some embodiments, for each target transaction, the deviation feature values ​​in the multidimensional deviation features corresponding to the target transaction are obtained; each deviation feature value is multiplied by its corresponding preset weight, and the product results are summed to obtain the risk score of the target transaction; the higher the risk score, the higher the degree of abnormality of the target transaction.

[0080] For example, the multidimensional deviation feature corresponding to the target transaction is [ Risk score of the target transaction The specific calculation formula is as follows: ,in This represents the preset weight corresponding to each deviation feature value.

[0081] The risk score of each target transaction is compared with a preset scoring threshold. If the risk score is greater than the preset scoring threshold, it indicates that the transaction has a high risk and the target transaction is identified as a candidate transaction. If the risk score is less than or equal to the preset scoring threshold, the target transaction is identified as a normal transaction and is filtered out.

[0082] Specifically, the risk score can be divided into three risk levels. If the risk score of the target transaction is... If the target transaction is normal, it can be filtered directly; if the target transaction's risk score is... If the risk score of the target transaction is [missing information], it indicates that the target transaction is a suspected abnormal sample; if the risk score of the target transaction is [missing information], it indicates that the target transaction is a suspected abnormal sample. If so, it indicates that the target transaction is a highly anomalous sample. The preset scoring threshold is... Target transactions identified as suspected or highly abnormal samples will be considered as candidate transactions.

[0083] For multiple candidate transactions, aggregate and statistically analyze candidate transactions under the same transaction entity based on the attribute information of the transaction entities associated with each candidate transaction. If the number of candidate transactions associated with the same transaction entity reaches a preset threshold (e.g., at least 2), it indicates that the transaction entity is exhibiting continuous abnormal behavior rather than a single, accidental anomaly, and the candidate transactions under that transaction entity are retained as risky transactions; if only one candidate transaction is associated with the same transaction entity, it is filtered out as a noise sample of a single, accidental anomaly.

[0084] This implementation method obtains a comprehensive risk score by weighting and summing the deviation feature values ​​in the multidimensional deviation features with their corresponding preset weights, thereby achieving a comprehensive assessment of the degree of transaction anomaly. Based on this, candidate transactions are initially screened through preset scoring thresholds, and then a second screening is performed on the candidate transactions in combination with the attribute information of the transaction entity. This can effectively filter out noise samples such as single-time accidental anomalies, retain high-risk transactions with continuity and representativeness, thereby improving the accuracy and reliability of risk transaction screening and providing a high-quality data foundation for subsequent offline rule mining.

[0085] In some embodiments, the above-mentioned sample screening of multiple candidate transactions based on the attribute information of the transaction entities associated with each candidate transaction yields multiple risky transactions. Specifically, this can be done in the following manner: For each candidate transaction, based on the attribute information of the transaction entity associated with the candidate transaction, the historical risk label corresponding to the attribute information is matched in the historical risk sample set to obtain the historical risk label corresponding to the candidate transaction. Candidate transactions that meet preset conditions are selected as risky transactions.

[0086] The aforementioned historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entities associated with each sample transaction, and historical risk labels corresponding to each sample transaction; this sample set may consist of existing transactions that have been reviewed and labeled with risk labels within a certain period of time (e.g., 3 to 6 months).

[0087] Among them, the historical risk label is a classification identifier for sample transactions, used to characterize the risk attribute category corresponding to the transaction, such as fraud risk, card skimming risk, normal transaction, etc.

[0088] For each candidate transaction, the attribute information of the transaction entity associated with the candidate transaction (such as merchant MCC code, transaction scenario, etc.) is obtained; sample transactions that match the above attribute information are searched in the historical risk sample set, and the historical risk tag corresponding to the sample transaction is extracted as the historical risk tag of the candidate transaction. In this embodiment, the matching judgment condition can be set to consistent attribute information, or it can be set to other conditions, and this embodiment does not limit it.

[0089] Candidate transactions are screened based on preset criteria, which include that the historical risk tags corresponding to the candidate transactions belong to a preset category, and that there are at least two candidate transactions under the transaction entity associated with each candidate transaction. Specifically, The historical risk label corresponding to the candidate transaction is a preset category, such as the "risk" category, indicating that the transaction entity has historically exhibited risky behavior; there are at least two candidate transactions under the transaction entity associated with the candidate transaction, that is, the transaction entity has had multiple abnormal transactions in the current batch, which is a continuous deviation from the sample rather than a single accidental anomaly.

[0090] Candidate transactions that simultaneously meet both of the above conditions are identified as risky transactions; otherwise, they are filtered out as noise samples. The preset categories are pre-defined risk label categories that indicate potential risk, such as fraud risk or credit card fraud risk.

[0091] For example, a candidate transaction is associated with a merchant whose MCC code is 1234, and the transaction scenario is online money transfer. In the historical risk sample set, a sample transaction with the same merchant MCC code and transaction scenario is matched, and its historical risk label is "fraudulent risk." Simultaneously, if the recipient of this candidate transaction has three candidate transactions in the current batch, then this candidate transaction simultaneously meets both of the above preset conditions and is identified as a risky transaction. Conversely, if the recipient of this candidate transaction has only one candidate transaction, then the condition of "at least two candidate transactions" is not met, and this candidate transaction will be considered a single, accidental anomaly and filtered out.

[0092] This implementation method matches the attribute information of the transaction entity associated with the candidate transaction with the historical risk sample set to obtain the corresponding historical risk label. Based on two conditions, label category and number of candidate transactions under the transaction entity, it can accurately identify transaction entities with historical risk background and exhibit continuous abnormal behavior, effectively filtering noisy samples such as single accidental anomalies, thereby improving the targeting of risk transaction screening and providing more reliable input data for rule mining.

[0093] In some embodiments, the implementation process of S230 described above may be as follows: Clustering is performed on the multidimensional deviation features corresponding to each risk transaction based on the number of candidate clusters, and the clustering results corresponding to each number of candidate clusters are obtained. The clustering effect is evaluated by using the silhouette coefficient to assess the clustering results corresponding to the number of candidate clusters, and the silhouette coefficient corresponding to the number of candidate clusters is obtained. The number of candidate clusters with the largest silhouette coefficient is determined as the target number of clusters, and clustering is performed on the multidimensional deviation features corresponding to each risky transaction based on the target number of clusters to obtain multiple initial clusters; The initial clusters with more risky transactions within a cluster than a preset threshold are designated as clusters.

[0094] The number of candidate clusters mentioned above is a pre-set candidate value for the number of clusters to be divided into for risky transactions before clustering. Multiple different candidate values ​​(e.g., an integer sequence from 2 to 10) can be selected and clustering can be performed separately for comparison and evaluation.

[0095] The silhouette coefficient is a quantitative indicator used to evaluate the quality of clustering, with a value ranging from -1 to 1. The closer the value is to 1, the higher the similarity of samples within a cluster and the better the separation between clusters, indicating a better clustering effect; the closer the value is to -1, the worse the clustering effect.

[0096] In some embodiments, a set of values ​​for the number of candidate clusters is predefined (e.g., K=2,3,4,...,10). For each candidate cluster number, using the multidimensional deviation features of each risky transaction as the input vector, an unsupervised clustering algorithm (e.g., K-Means clustering algorithm) is used to perform clustering processing, dividing all risky transactions into multiple clusters, thus obtaining the clustering result corresponding to that candidate cluster number. The clustering result is the grouping result obtained after performing clustering processing on a certain candidate cluster number, containing all clusters under that candidate cluster number and the risky transaction sets contained in each cluster.

[0097] For each candidate cluster size, calculate the overall silhouette coefficient of the clustering results corresponding to that number of candidate clusters, and use this as the silhouette coefficient corresponding to that number of candidate clusters. The specific calculation process can be as follows: for each risk transaction in the clustering results... Calculate risky transactions The average distance to all other risky transactions within the same cluster is used to obtain the risky transaction. Intra-cluster average distance ; Calculate risky transactions The risk transaction is obtained by averaging its distance to all other risk transactions within the nearest cluster. closest distance between clusters Then risky trading contour coefficient The calculation formula is: .

[0098] When risky transactions Intra-cluster average distance Less risky trades closest distance between clusters At that time, risky trading contour coefficient A value close to 1 indicates a good clustering effect; when risk transactions... Intra-cluster average distance Greater than risky trading closest distance between clusters At that time, risky trading contour coefficient A value close to -1 indicates poor clustering performance. For each candidate cluster number, the silhouette coefficient of all risky transactions is averaged to obtain the silhouette coefficient corresponding to that candidate cluster number.

[0099] Compare the silhouette coefficients corresponding to the number of candidate clusters, and select the candidate cluster number with the largest silhouette coefficient value as the target number of clusters; use the target number of clusters as the number of clusters, and again use the multidimensional deviation features of each risk transaction as input to perform clustering processing to obtain multiple initial clusters of the target number of clusters.

[0100] The number of risky transactions within each initial cluster is counted. Initial clusters with a number of risky transactions exceeding a preset threshold are retained as the final clusters. Initial clusters with a number of risky transactions less than or equal to the preset threshold (i.e., sparse clusters) are removed. The retained clusters represent abnormal transaction groups with scalable risk patterns and are used for subsequent rule extraction. In this embodiment, the preset threshold can be dynamically adjusted according to actual business needs; this embodiment does not impose any restrictions on it.

[0101] In this embodiment, by performing clustering processing on multiple candidate cluster numbers separately and using the silhouette coefficient to quantitatively evaluate each clustering result, the optimal target number of clusters can be automatically determined. On this basis, by removing sparse clusters with a sample size below a preset threshold and retaining only clusters with large-scale risk patterns, occasional abnormal noise can be effectively filtered out, ensuring that the clusters entering the subsequent rule extraction stage have sufficient sample representativeness and statistical significance, thereby improving the reliability and applicability of the risk control business rules obtained by automatic mining.

[0102] In some embodiments, in S240 above, rule extraction is performed based on the multidimensional deviation features within each cluster to determine the multidimensional deviation conditions corresponding to the cluster. This may specifically include the following steps: Based on the multidimensional deviation characteristics within the cluster, determine multiple deviation feature values ​​for each continuous numerical dimension within the cluster and multiple deviation feature values ​​for each discrete dimension within the cluster; For each continuous numerical dimension, the deviation feature value that is located at a preset quantile among the multiple deviation feature values ​​corresponding to the continuous numerical dimension is used as the rule critical threshold corresponding to the continuous numerical dimension. For each discrete dimension, if the proportion of outliers among the multiple deviation feature values ​​corresponding to the discrete dimension exceeds a preset ratio, the discrete dimension will be used as a constraint condition. Based on the rule-based critical thresholds and constraints corresponding to each continuous numerical dimension, the multidimensional deviation conditions corresponding to the clusters are determined.

[0103] The aforementioned continuous numerical dimension refers to the dimension in the multidimensional deviation feature that takes continuous numerical values, such as transaction amount deviation ratio, order amount deviation ratio, transaction frequency deviation ratio, and order frequency deviation ratio. The discrete dimension refers to the dimension in the multidimensional deviation feature that takes discrete categories, such as geographical deviation feature, device deviation feature, and transaction time period deviation feature.

[0104] In some embodiments, for each cluster, multidimensional deviation features of all risky transactions within the cluster are extracted. For each continuous numerical dimension (such as the transaction amount deviation ratio), deviation feature values ​​of all risky transactions within the cluster on that dimension are collected to form a numerical set. For each discrete dimension (such as the geographical deviation feature), deviation feature values ​​of all risky transactions within the cluster on that dimension are collected to form a category set.

[0105] For each continuous numerical dimension, sort the multiple deviation feature values ​​corresponding to the continuous numerical dimension by size, and take the deviation feature value located at a preset quantile (e.g., the 90th quantile) as the rule critical threshold corresponding to the continuous numerical dimension.

[0106] For example, a cluster contains 100 risky transactions with a set of transaction amount deviation ratio values ​​of [0.5, 0.8, 1.2, ..., 3.5]. After sorting them from smallest to largest, the 90th quantile corresponds to a value of 2.1. Therefore, the rule threshold for the transaction amount deviation ratio is 2.1, meaning that the condition for this dimension in the risk control business rules is that the transaction amount deviation ratio is greater than 2.1.

[0107] For each discrete dimension, the percentage of outliers (e.g., values ​​of 1) among the multiple deviation feature values ​​corresponding to that discrete dimension is calculated. If this percentage exceeds a preset proportion (e.g., 90%), the discrete dimension is used as a constraint condition, meaning that the risk control business rules mandate that this dimension be an outlier. In this embodiment, the values ​​of the preset proportion and preset quantile can be dynamically adjusted according to actual business needs, and this embodiment does not impose any restrictions on them.

[0108] Outlier values ​​are the values ​​representing abnormal states in the discrete dimension. For example, a regional deviation value of 1 indicates an abnormal transaction region, while a value of 0 indicates normal; a device deviation value of 1 indicates an abnormal transaction device, while a value of 0 indicates normal; and a transaction time deviation value of 1 indicates an abnormal transaction time, while a value of 0 indicates normal.

[0109] For example, if 95 out of 100 risky transactions in a cluster have a regional deviation feature value of 1 (abnormal), the abnormal value rate is 95%, which exceeds the preset ratio of 90%. In this case, "regional deviation = 1 (abnormal transaction region)" will be included as a constraint in the risk control business rules corresponding to the current cluster.

[0110] Based on the rule-based critical thresholds corresponding to each continuous numerical dimension and the constraints corresponding to each discrete dimension, the multidimensional deviation conditions corresponding to the cluster are summarized to obtain the multidimensional deviation conditions for that cluster. Specifically, for each cluster, the multidimensional deviation conditions are a combination of conditions that describe the common performance of risky transactions within the cluster in terms of multidimensional deviation characteristics, consisting of the rule-based critical thresholds corresponding to each continuous numerical dimension and the constraints corresponding to each discrete dimension.

[0111] For example, the multidimensional deviation conditions for a certain cluster can be: "the transaction amount deviation ratio is greater than 2.1, the transaction frequency deviation ratio is greater than 1.5, the geographical deviation = 1 (abnormal transaction geographical location), and the equipment deviation = 1 (abnormal transaction equipment)".

[0112] This implementation method uses the deviation feature value of the preset quantile within the cluster as the rule critical threshold for the continuous numerical dimension, and uses the outlier ratio of the discrete dimension as the constraint condition. It can automatically extract statistically significant multidimensional deviation conditions from the cluster, without the need for manual preset rule templates, and realizes the automatic summarization of rule conditions from the data, thereby improving the objectivity and efficiency of rule generation.

[0113] In some embodiments, in S240 above, determining the scenario constraints corresponding to each cluster based on the attribute information of the transaction entities associated with each risk transaction within the cluster may specifically include the following steps: Based on the attribute information of the transaction entities associated with each risk transaction within the cluster, determine the frequency of occurrence of at least one attribute value corresponding to each attribute dimension within the cluster. For each attribute dimension, attribute values ​​that appear more frequently than a preset proportion threshold will be used as the preconditions for that attribute dimension. Based on the pre-constraints corresponding to each attribute dimension, determine the scenario constraints corresponding to the clusters.

[0114] The aforementioned attribute dimensions include at least one of the following: transaction payee category code, transaction scenario, and transaction account type. The transaction payee category code is a code that identifies the category to which the transaction payee belongs, such as MCC; the transaction scenario identifies the specific business channel or type of business where the transaction occurs, such as online transfer, offline card payment, or QR code payment; and the transaction account type identifies the account category used by the payer or payee, such as debit card account or corporate account.

[0115] For each attribute dimension within each cluster, the frequency of each attribute value in all risky transactions within that cluster is counted, and then divided by the number of risky transactions in that cluster to obtain the frequency of each attribute value. For example, for the transaction payee category code, the frequency of each category code value in all risky transactions within that cluster is counted, and then divided by the number of risky transactions in that cluster to obtain the frequency of each category code. Similarly, the same statistics are performed for attribute dimensions such as transaction scenario and transaction account type.

[0116] For each attribute dimension, attribute values ​​that occur more than a preset percentage threshold (e.g., 80%) are used as pre-constraints for that attribute dimension to limit the scope of business scenarios to which the risk control business rules apply. The pre-constraints for all attribute dimensions are then aggregated to obtain the scenario constraints for that cluster. In this embodiment, the preset percentage threshold can be dynamically adjusted according to actual business needs; this embodiment does not impose any restrictions on it.

[0117] For example, in a cluster of 100 risky transactions, 85 transactions have the payee category code 1234, with a frequency of 85%, exceeding the preset threshold of 80%. Therefore, "payee category code 1234" is used as a precondition for this attribute dimension. 82 transactions have the scenario of "online transfer," with a frequency of 82%, exceeding 80%. Therefore, "transaction scenario is online transfer" is used as a precondition. Ultimately, the scenario constraint for this cluster can be: the payee category code is 1234, and the transaction scenario is online transfer.

[0118] This implementation method statistically analyzes the frequency of occurrence of transaction entities associated with each risk transaction within a cluster across various attribute dimensions. Attribute values ​​with a frequency exceeding a preset threshold are used as pre-defined constraints. This automatically extracts the scenario constraints corresponding to the cluster, giving the generated rules a clear scope of application for specific business scenarios and improving the rules' relevance and interpretability.

[0119] In some embodiments, the risk control business rules corresponding to the above clusters also include the risk types corresponding to the clusters; the risk types corresponding to the clusters can be determined in the following manner: For each risky transaction within a cluster, based on the attribute information of the transaction entity associated with the risky transaction, historical risk labels corresponding to the attribute information are matched in the historical risk sample set to obtain the historical risk label corresponding to the risky transaction. For each tag category, the occurrence rate of the tag category is calculated based on the historical risk tags corresponding to each risky transaction; The risk type corresponding to each cluster is determined based on the occurrence ratio of each label category.

[0120] The aforementioned historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entities associated with each sample transaction, and historical risk labels corresponding to each sample transaction; the label category is the specific value category of the historical risk label, that is, the specific label value that the historical risk label can take, such as fraud risk, credit card fraud risk, etc.

[0121] In some embodiments, for each risky transaction within a cluster, based on the attribute information of the transaction entity associated with the risky transaction, a sample transaction matching the aforementioned attribute information is searched in the historical risk sample set, and the historical risk label corresponding to the sample transaction is extracted as the historical risk label corresponding to the risky transaction. In this embodiment, the matching judgment condition can be set to consistent attribute information, or it can be set to other conditions; this embodiment does not limit this.

[0122] For each label category, iterate through all historical risk labels of risk transactions within the cluster, count each specific label category, divide by the number of risk transactions within the cluster to obtain the occurrence ratio of each label category, and determine the label category with the highest occurrence ratio as the risk type corresponding to the cluster.

[0123] For example, the historical risk labels obtained from matching 100 risky transactions within a certain cluster are as follows: "Fraud Risk" label category: 78, occurrence rate 78%; "Gambling Risk" label category: 15, occurrence rate 15%; "Credit Card Theft Risk" label category: 5, occurrence rate 5%; "Normal Transaction" label category: 2, occurrence rate 2%. Among all label categories, "Fraud Risk" has the highest occurrence rate of 78%, therefore, the risk type corresponding to this cluster is determined to be "Fraud Risk".

[0124] In this embodiment, for each risk transaction within a cluster, the corresponding historical risk label is matched in the historical risk sample set based on the attribute information of the transaction subject, and the occurrence ratio of each label category is counted. The label category with the highest occurrence ratio is determined as the risk type corresponding to the cluster, which can achieve accurate determination of risk type.

[0125] In some embodiments, for each cluster, risk control business rules corresponding to that cluster are generated according to the multidimensional deviation conditions, scenario constraints, and risk types. Specifically, a unified paradigm is adopted, in which the scenario constraints and multidimensional deviation conditions constitute the pre-judgment logic of the rules, and corresponding risk type conclusions are generated. One risk control business rule is generated for each cluster.

[0126] For example, if the scenario constraints for a certain cluster are: the transaction recipient's category code is 1234, the transaction scenario is online transfer, and the multidimensional deviation conditions are: the transaction occurred during an abnormal period in the early morning, an unfamiliar risky device was used, the deviation multiple of the transaction recipient's daily transaction amount is greater than 2.1, and the deviation multiple of the transaction recipient's daily transaction frequency is greater than 1.7, then the generated risk type conclusion is "fraudulent risk transaction". Afterwards, the generated risk rules are converted into JSON format that the rule engine can recognize.

[0127] In some embodiments, prior to S250 above, the business rule configuration method further includes the following process: Perform performance evaluations on each risk control business rule and determine the performance evaluation results for each risk control business rule. Based on the performance evaluation results of each risk control business rule, select at least one target business rule from multiple risk control business rules; Based on this, the aforementioned S250 specifically refers to: outputting the business rules for each target.

[0128] Specifically, after generating the risk control business rules corresponding to each cluster, the performance of each risk control business rule is evaluated through offline backtracking verification to obtain the performance evaluation result of the risk control business rule; from multiple risk control business rules, the risk control business rules that meet the performance standards are selected as the target business rules and output.

[0129] This implementation method performs performance evaluation on each risk control business rule before outputting it, and selects target business rules based on the performance evaluation results. This effectively identifies and eliminates low-quality rules before they go online, avoiding the problem of false blocking caused by unverified rules going online directly, and improving the quality and reliability of the final output rules.

[0130] In some embodiments, the performance evaluation of each of the aforementioned risk control business rules, and the determination of the performance evaluation result corresponding to each risk control business rule, can be performed in the following manner: Obtain the test sample set; The statistical test sample set includes the total number of real risk samples with positive label categories and the total number of normal samples with negative label categories. For each risk control business rule, the test transaction data of each test transaction is matched according to the risk control business rule to determine the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule. For each risk control business rule, the performance evaluation result is determined based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule.

[0131] The aforementioned test sample set includes transaction data from multiple test transactions and test risk labels corresponding to each test transaction. The test sample set can be obtained by dividing the full historical transaction data into time slices, such as transaction data from historical transactions within the past 8 months, and it does not overlap with the transaction dataset of the target transactions used for rule mining or the transaction data of historical transactions used for constructing behavioral baselines.

[0132] The test risk label is a classification identifier for each test transaction in the test sample set, used to characterize the risk attribute category of the transaction, such as fraud risk, card fraud risk, and normal transaction. Test risk labels include positive and negative labels. Positive labels are those indicating a risky transaction, such as fraud risk or card fraud risk; test transactions corresponding to positive labels are real risk samples. Negative labels are those indicating a normal transaction, such as a normal transaction; test transactions corresponding to negative labels are normal samples.

[0133] In some embodiments, the total number of samples in the test sample set whose label category is positive for the risk label is counted to obtain the total number of real risk samples; the total number of samples in the test sample set whose label category is negative for the risk label is counted to obtain the total number of normal samples.

[0134] For each risk control business rule, apply the risk control business rule to all test transactions in the test sample set, and determine whether the transaction data of each test transaction meets the scenario constraints and multidimensional deviation conditions of the risk control business rule. If they meet, the test transaction is determined to be hit by the rule. Count the number of all hit test transactions to obtain the total number of samples hit by the risk control business rule.

[0135] For each risk control business rule, based on the label category of the test risk label of the hit test transaction, the number of real risk samples and the number of normal samples are counted separately. The number of samples with positive test risk labels in the test transactions hit by the risk control business rule is taken as the number of real risk samples hit by the risk control business rule; the number of samples with negative test risk labels in the test transactions hit by the risk control business rule is taken as the number of normal samples hit by the risk control business rule.

[0136] For example, a test sample set contains 10,000 test transactions, of which 800 samples have positive risk labels (e.g., risk of fraud, risk of theft, etc.) and 9,200 samples have negative risk labels (i.e., normal transactions). For a certain risk control business rule R, the total number of matched samples is 200, of which 160 samples have positive labels and 40 samples have negative labels. Therefore, the statistical results for rule R are: the total number of samples matched by the risk control business rule is 200, the number of real risk samples matched by the risk control business rule is 160, and the number of normal samples matched by the risk control business rule is 40.

[0137] For each risk control business rule, metrics (such as recall rate, false positive rate, etc.) are calculated based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule, so as to obtain the performance evaluation result corresponding to the risk control business rule.

[0138] This implementation method obtains a test sample set containing positive and negative labeled samples, and for each risk control business rule, it calculates the total number of hit samples, the number of hit real risk samples, and the number of hit normal samples. This provides an accurate statistical data basis for subsequent calculation of performance evaluation results such as recall rate, precision rate, and false positive rate, thus enabling the performance evaluation of the rule to have an objective quantitative basis.

[0139] In some embodiments, the performance evaluation results include recall rate, false positive rate, and overall score; determining the performance evaluation results of each risk control business rule based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule includes the following steps: The recall rate of risk control business rules is obtained by calculating the ratio of the number of hit real risk samples to the total number of real risk samples. The accuracy of the risk control business rules is obtained by calculating the ratio of the number of actual risk samples that are hit to the total number of hit samples. The comprehensive score of the risk control business rules is determined based on the ratio of the first indicator to the second indicator. The misjudgment rate of risk control business rules is obtained by calculating the ratio of the number of hit normal samples to the total number of normal samples.

[0140] The first metric is the product of recall, precision, and a preset coefficient; the second metric is the sum of recall and precision. The specific calculation formulas are: First metric = Recall × Precision × Preset coefficient; Second metric = Recall + Precision. In this embodiment, the preset coefficient can be set to 2, or it can be dynamically adjusted according to actual business needs; this embodiment does not impose any restrictions on this.

[0141] In some embodiments, for each risk control business rule, the ratio of the number of hit real risk samples to the total number of real risk samples is calculated to obtain the recall rate of the risk control business rule. The specific calculation formula is: Recall rate = Number of hit real risk samples / Total number of real risk samples.

[0142] Recall rate is used to measure the ability of risk control business rules to cover real risk samples. The higher the recall rate, the more real risk samples the risk control business rule can cover, that is, the higher the risk identification coverage of the rule, and the better the risk coverage performance of the corresponding rule.

[0143] The accuracy rate of risk control business rules is obtained by calculating the ratio of the number of actual risk samples that are hit to the total number of samples that are hit. The specific calculation formula is: Accuracy rate = Number of actual risk samples that are hit / Total number of samples that are hit.

[0144] Precision rate is used to measure the accuracy of the hit results of risk control business rules. The higher the precision rate, the higher the proportion of real risk samples in the hit results of the risk control business rules, that is, the higher the accuracy of the rule hit.

[0145] The comprehensive score of the risk control business rule is determined based on the ratio of the first indicator and the second indicator. The specific calculation formula is: Comprehensive Score = First Indicator / Second Indicator. The comprehensive score is used to measure the coverage and accuracy of the risk control business rule. The higher the comprehensive score, the better the risk control business rule performs in terms of both risk coverage and accuracy, that is, the stronger the rule's overall identification performance.

[0146] The false positive rate of a risk control rule is calculated by dividing the number of correctly identified normal samples by the total number of normal samples. The specific formula is: False Positive Rate = Number of Correctly Identified Normal Samples / Total Number of Normal Samples. The false positive rate measures the degree to which a risk control rule misjudges normal transactions. A higher false positive rate indicates a higher probability of the rule misjudging normal transactions, meaning a greater likelihood of the rule mistakenly blocking normal transactions, and consequently, poorer rule performance. Conversely, a lower false positive rate indicates a smaller impact of the rule's misjudgment on normal transactions, and consequently, better rule performance.

[0147] For each risk control business rule, the recall rate, false positive rate, precision rate and comprehensive score corresponding to that risk control business rule are integrated to obtain the performance evaluation result of that risk control business rule.

[0148] This implementation method calculates four core performance indicators—recall rate, precision rate, overall score, and false positive rate—based on statistical data of the total number of real risk samples, the total number of normal samples, and rule hit rate. This allows for multi-dimensional and objective quantification of the identification capability of each risk control business rule, providing a comprehensive evaluation basis for subsequent selection of high-quality rules based on performance evaluation results. This ensures that the final output rules can balance risk coverage and false positive control capabilities.

[0149] In some embodiments, the above-mentioned selection of at least one target business rule from multiple risk control business rules based on the performance evaluation results corresponding to each risk control business rule includes: Risk control business rules with a recall rate greater than or equal to a preset recall rate threshold and a false positive rate less than or equal to a preset false positive rate threshold will be used as candidate business rules. Based on the comprehensive score of each candidate business rule, a preset number of target business rules are selected from multiple candidate business rules.

[0150] For example, for each risk control business rule, it is determined whether its recall rate meets the condition of being greater than or equal to a preset recall rate threshold, and at the same time, it is determined whether its false positive rate meets the condition of being less than or equal to a preset false positive rate threshold. Rules that meet both conditions are retained as candidate business rules; rules that do not meet either condition are directly eliminated and archived.

[0151] The preset recall rate threshold is a pre-set minimum recall rate required for risk control business rules to be retained, such as 80%. Rules below this threshold will be directly eliminated. The preset false positive rate threshold is a pre-set maximum allowed false positive rate for risk control business rules to be retained, such as 5%. Rules above this threshold will be directly eliminated. The preset recall rate threshold and the preset false positive rate threshold can be dynamically adjusted according to actual business needs, and this embodiment does not impose any restrictions on this.

[0152] All selected candidate business rules are sorted in descending order of their comprehensive scores, and a predetermined number of these rules are selected as target business rules. Finally, all target business rules and their performance evaluation results are output, and these target business rules are configured into the risk control system.

[0153] The aforementioned preset quantity refers to the number or proportion of target business rules ultimately selected from the candidate business rules. For example, it can be set to the top 30% of the candidate business rules in terms of comprehensive score.

[0154] Afterwards, the remaining candidate business rules that were not selected as target business rules can be monitored offline or directly archived with the reasons recorded. Specifically, offline monitoring can re-evaluate the performance of the remaining candidate business rules based on newly collected transaction data within a preset time period (e.g., 1 month). If their recall rate and false positive rate both meet the corresponding threshold conditions, they can be output as supplementary target business rules; otherwise, they are eliminated.

[0155] In this implementation, by setting both recall and false positive thresholds, rules that fail to meet performance standards are eliminated first, and then the rules with the highest overall scores are selected as the target business rules in descending order of comprehensive scores. This ensures that the rules have basic risk identification capabilities, while prioritizing the output of the rules with the best overall performance. This effectively reduces the risk of false blocking caused by the deployment of low-quality rules and improves the overall accuracy of the risk control system.

[0156] For ease of understanding, let's take... Figure 3 The overall process of the business rule configuration method provided in this embodiment is described, specifically including the following steps: S310: For each payer in the first preset transaction window, based on the transaction data corresponding to multiple historical transactions of the payer in the first preset transaction window, calculate the total transaction amount and total number of transactions of the payer in the first preset transaction window, and construct the behavioral baseline of the payer based on the total transaction amount and total number of transactions. S320: For each transaction payee existing in the second preset transaction window, based on the transaction data corresponding to multiple historical transactions of the transaction payee in the second preset transaction window, calculate the total amount of transactions received and the total number of transactions received by the transaction payee in the second preset transaction window, and construct the behavioral baseline of the transaction payee based on the total amount of transactions received and the total number of transactions received. S330: For each target transaction's transaction data, calculate the multidimensional deviation features of the target transaction's transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction; the multidimensional deviation features include transaction amount deviation ratio, order amount deviation ratio, transaction frequency deviation ratio, order frequency deviation ratio, geographical deviation features, device deviation features, and transaction time period deviation features; S340: For each target transaction, the risk score of the target transaction is obtained by weighting and summing the deviation feature values ​​in the multidimensional deviation features corresponding to the target transaction with the preset weights corresponding to each deviation feature value. S350: Target transactions with risk scores greater than the preset score threshold are selected as candidate transactions; based on the attribute information of the transaction entities associated with each candidate transaction, multiple candidate transactions are sampled and selected to obtain multiple risky transactions; S360: Cluster the multidimensional deviation features corresponding to each risky transaction to obtain at least one cluster; S370: For each cluster, extract rules based on the multidimensional deviation features within the cluster to determine the multidimensional deviation conditions corresponding to the cluster, and determine the scenario constraints corresponding to the cluster based on the attribute information of the trading entities associated with each risk transaction within the cluster; determine the risk type corresponding to the cluster based on the attribute information of the trading entities associated with each risk transaction within the cluster and the historical risk sample set. S380: Generate risk control business rules for each cluster based on the multidimensional deviation conditions, scenario constraints, and risk types corresponding to each cluster.

[0157] S390: Perform performance evaluation on each risk control business rule and determine the performance verification result corresponding to each risk control business rule; based on the performance verification result corresponding to each risk control business rule, select at least one target business rule from multiple risk control business rules; output each target business rule.

[0158] For example, S310 to S390 are all offline batch processing operations, which do not occupy real-time transaction link resources and do not affect the stability of the production system. Furthermore, an iterative task can be initiated according to a preset cycle (e.g., monthly) to re-execute S310 to S390, generating new risk control business rules based on the updated behavioral baseline. The newly generated risk control business rules are then merged with the target business rules configured in the previous cycle for joint offline backtesting. Based on the latest performance verification results of each rule, rules with recall rates below a preset threshold or false positive rates above a preset threshold are eliminated, while rules that meet the performance standards are used as updated target business rules. Finally, the updated target business rules and their corresponding performance evaluation results are output, forming a periodic risk control rule iteration report.

[0159] This implementation method achieves the following technical effects through the above process: First, it automatically mines risk control business rules based on offline data, reducing reliance on expert experience and significantly improving rule output efficiency; second, it determines behavioral deviations based on the behavioral baselines of both the payer and payee, and combined with multi-dimensional deviation features, it can effectively identify concealed and progressive abnormal transactions; third, the risk control business rules undergo multiple rounds of offline backtesting and verification before going live, improving the quality and reliability of the final output rules, significantly reducing transaction anomalies and improving user experience; and fourth, by automatically updating the baseline and rule base periodically, it can continuously adapt to dynamically changing abnormal transaction methods, ensuring the long-term effectiveness of the risk control system.

[0160] Based on the business rule configuration method provided in the above embodiments, this application also provides specific implementations of the business rule configuration device. Please refer to the following embodiments.

[0161] like Figure 4 As shown in the embodiment of this application, the business rule configuration device 400 includes the following modules: The deviation feature calculation module 410 is used to calculate the multidimensional deviation features of the transaction data of each target transaction relative to the behavioral baseline of the transaction entity associated with the target transaction for each target transaction. The risk transaction screening module 420 is used to screen out multiple risk transactions from multiple target transactions based on the multidimensional deviation characteristics corresponding to each target transaction; Deviation feature clustering module 430 is used to cluster the multidimensional deviation features corresponding to each of the risk transactions to obtain at least one cluster; The rule condition determination module 440 is used to extract rules based on the multidimensional deviation features within each cluster for each cluster, determine the multidimensional deviation conditions corresponding to the cluster, and determine the scenario constraint conditions corresponding to the cluster based on the attribute information of the transaction entities associated with each risk transaction within the cluster. The business rule output module 450 is used to generate risk control business rules corresponding to each cluster based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, and output each risk control business rule.

[0162] The above-mentioned business rule configuration device 400 is described in detail below: Optionally, the rule condition determination module 440 is specifically used to determine multiple deviation feature values ​​of each continuous numerical dimension and multiple deviation feature values ​​of each discrete dimension in the cluster based on the multidimensional deviation features in the cluster. For each continuous numerical dimension, the deviation feature value located at a preset quantile among the multiple deviation feature values ​​corresponding to the continuous numerical dimension is used as the rule critical threshold corresponding to the continuous numerical dimension. For each of the discrete dimensions, if the proportion of outliers in the multiple deviation feature values ​​corresponding to the discrete dimension exceeds a preset ratio, the discrete dimension is used as a constraint condition. Based on the rule-based critical thresholds corresponding to each of the continuous numerical dimensions and the constraints, the multidimensional deviation conditions corresponding to the clusters are determined.

[0163] Optionally, the rule condition determination module 440 is specifically used to determine the frequency of occurrence of at least one attribute value corresponding to each attribute dimension in the cluster based on the attribute information of the transaction entities associated with each risk transaction in the cluster; the attribute dimension includes at least one of the following: transaction payee category code, transaction scenario, and transaction account type. For each attribute dimension, attribute values ​​that appear more frequently than a preset proportion threshold are used as the preconditions for the attribute dimension. Based on the pre-constraints corresponding to each attribute dimension, the scenario constraints corresponding to the cluster are determined.

[0164] Optionally, the rule condition determination module 440 is further configured to, for each risk transaction within the cluster, match historical risk labels corresponding to the attribute information in the historical risk sample set based on the attribute information of the transaction entity associated with the risk transaction, thereby obtaining the historical risk label corresponding to the risk transaction; wherein, the historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entity associated with each sample transaction, and historical risk labels corresponding to each sample transaction; For each tag category, based on the historical risk tags corresponding to each risk transaction, the occurrence rate of the tag category is calculated; The risk type corresponding to the cluster is determined based on the occurrence ratio of each of the aforementioned label categories.

[0165] Optionally, the risk transaction screening module 420 is specifically used to, for each target transaction, perform a weighted summation of each deviation feature value in the multidimensional deviation features corresponding to the target transaction with the preset weight corresponding to each deviation feature value, to obtain the risk score of the target transaction; Target transactions with risk scores greater than a preset score threshold are selected as candidate transactions; Based on the attribute information of the transaction entities associated with each candidate transaction, multiple candidate transactions are sampled and selected to obtain multiple risky transactions.

[0166] Optionally, the risk transaction screening module 420 is specifically used to, for each candidate transaction, match the historical risk label corresponding to the attribute information in the historical risk sample set according to the attribute information of the transaction entity associated with the candidate transaction, and obtain the historical risk label corresponding to the candidate transaction; wherein, the historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entity associated with each sample transaction, and historical risk label corresponding to each sample transaction. Candidate transactions that meet preset conditions are selected as risky transactions; wherein, the preset conditions are that the label category of the historical risk label corresponding to the candidate transaction is a preset category, and there are at least two candidate transactions under the transaction entity associated with the candidate transaction.

[0167] Optionally, the deviation feature calculation module 410 is specifically used to calculate the transaction amount deviation ratio based on the transaction amount in the transaction data of the target transaction and the average daily transaction amount in the behavioral baseline corresponding to the transaction payer associated with the target transaction. The transaction frequency deviation ratio is calculated based on the cumulative number of transactions of the transaction payer associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline corresponding to the transaction payer. The deviation rate of the transaction amount is calculated based on the transaction amount in the transaction data of the target transaction and the average daily transaction amount in the behavioral baseline of the transaction payee associated with the target transaction. The transaction frequency deviation ratio is calculated based on the cumulative number of transactions received by the transaction payee associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline corresponding to the transaction payee. If the transaction region corresponding to the target transaction does not belong to the trusted region set of the transaction payer associated with the target transaction, the region deviation feature is determined to be a first preset value. If the transaction device corresponding to the target transaction does not belong to the trusted device set of the transaction payer associated with the target transaction, the device deviation feature is determined to be a second preset value. If the transaction time of the target transaction falls within a preset abnormal period, the time period deviation characteristic is determined to be a third preset value.

[0168] Optionally, the service configuration device 400 also includes: The behavior baseline construction module is used to, for each payer in a first preset transaction window, calculate the total transaction amount and total number of transactions for that payer within the first preset transaction window based on transaction data corresponding to multiple historical transactions within the first preset transaction window, and construct the behavior baseline for that payer based on the total transaction amount and the total number of transactions; and to, for each payee in a second preset transaction window, calculate the total order amount and total number of orders received for that payee within the second preset transaction window based on transaction data corresponding to multiple historical transactions within the second preset transaction window, and construct the behavior baseline for that payee based on the total order amount and the total number of orders received.

[0169] Optionally, the deviation feature clustering module 430 is specifically used to perform clustering processing on the multidimensional deviation features corresponding to each of the risk transactions according to the number of multiple candidate clusters, so as to obtain the clustering results corresponding to the number of each candidate cluster; The clustering effect is evaluated by using the silhouette coefficient to assess the clustering results corresponding to each number of candidate clusters, and the silhouette coefficient corresponding to each number of candidate clusters is obtained. The number of candidate clusters with the largest silhouette coefficient is determined as the target number of clusters, and clustering processing is performed on the multidimensional deviation features corresponding to each risk transaction according to the target number of clusters to obtain multiple initial clusters; The initial clusters with more risky transactions within a cluster than a preset threshold are designated as clusters.

[0170] Optionally, the business rule output module 450 is also used to perform performance evaluation on each of the risk control business rules and determine the performance evaluation result corresponding to each of the risk control business rules. Based on the performance evaluation results corresponding to each of the risk control business rules, at least one target business rule is selected from the multiple risk control business rules; Output the target business rules as described.

[0171] Optionally, the business rule output module 450 is specifically used to obtain a test sample set, which includes transaction data of multiple test transactions and test risk labels corresponding to each test transaction. The label categories of the test risk labels include positive labels and negative labels. The total number of real risk samples with positive label categories and the total number of normal samples with negative label categories in the test sample set are counted. For each of the risk control business rules, the test transaction data of each test transaction is matched according to the risk control business rules to determine the total number of samples hit by the risk control business rules, the number of real risk samples hit by the risk control business rules, and the number of normal samples hit by the risk control business rules. For each of the risk control business rules, the performance evaluation result of each risk control business rule is determined based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule.

[0172] Optionally, the business rule output module 450 is specifically used to calculate the ratio of the number of hit real risk samples to the total number of real risk samples, so as to obtain the recall rate of the risk control business rule; The accuracy of the risk control business rule is obtained by calculating the ratio of the number of actual risk samples that are hit to the total number of hit samples. The comprehensive score of the risk control business rule is determined based on the ratio of the first indicator and the second indicator; the first indicator is the product of the recall rate, the precision rate and the preset coefficient, and the second indicator is the sum of the recall rate and the precision rate. The misjudgment rate of the risk control business rule is obtained by calculating the ratio of the number of hit normal samples to the total number of normal samples.

[0173] Optionally, the business rule output module 450 is specifically used to take risk control business rules with a recall rate greater than or equal to a preset recall rate threshold and a false positive rate less than or equal to a preset false positive rate threshold as candidate business rules. Based on the comprehensive score of each candidate business rule, a preset number of target business rules are selected from the multiple candidate business rules.

[0174] In this embodiment, by acquiring transaction data of target transactions and calculating their multidimensional deviation features relative to the baseline behavior of related transaction entities, a quantitative representation of the deviation degree of each transaction is achieved. Based on this, risky transactions are automatically screened from a massive number of target transactions according to the multidimensional deviation features, avoiding the inefficient method of manual, one-by-one screening. By performing cluster analysis on the multidimensional deviation features of risky transactions, transactions with similar abnormal patterns can be grouped into the same cluster, overcoming the limitation that human experience is insufficient to discover hidden patterns in massive amounts of data. For each cluster, the corresponding multidimensional deviation conditions and scenario constraints based on transaction entity attribute information are extracted, and structured risk control business rules are generated accordingly. Therefore, this embodiment significantly improves the efficiency of rule configuration and the accuracy of rule determination, reducing bias caused by subjective human judgment.

[0175] Based on the business rule configuration method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 5 A schematic diagram of an electronic device 500 provided in an embodiment of this application is shown.

[0176] Electronic device 500 may include processor 510 and memory 520 storing computer program instructions.

[0177] Specifically, the processor 510 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0178] Memory 520 may include mass storage for data or instructions. For example, and not limitingly, memory 520 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 520 may include removable or non-removable (or fixed) media. Where appropriate, memory 520 may be internal or external to electronic device 500. In a particular embodiment, memory 520 is a non-volatile solid-state memory.

[0179] In a specific embodiment, the memory 520 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 520 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 520 and executed by the processor 510. The processor 510 implements any of the business rule configuration methods in the above embodiments by reading and executing the computer program instructions stored in the memory 520.

[0180] The processor 510 reads and executes computer program instructions stored in the memory 520 to implement any of the business rule configuration methods in the above embodiments.

[0181] In one example, electronic device 500 may also include communication interface 530 and bus 540. Wherein, as... Figure 5 As shown, the processor 510, memory 520, and communication interface 530 are connected through bus 540 and complete communication with each other.

[0182] The communication interface 530 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0183] Bus 540 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 540 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0184] For example, the electronic device 500 can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0185] The electronic device can execute the business rule configuration method in the embodiments of this application, thereby achieving the combination Figures 2 to 3 The described business rule configuration method, and the beneficial effects of the corresponding method implementation, will not be elaborated here.

[0186] Furthermore, in conjunction with the business rule configuration methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the business rule configuration methods in the above embodiments.

[0187] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0188] The computer program instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the business rule configuration method as shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0189] Based on the business rule configuration methods in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, they implement any of the business rule configuration methods in the above embodiments.

[0190] The computer program products of the above embodiments are used to implement the business rule configuration method shown in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0191] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0192] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0193] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0194] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable business rule configuration apparatus to produce a machine such that these instructions, executed via the processor of the computer or other programmable business rule configuration apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0195] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for configuring business rules, characterized in that, The method includes: For each target transaction's transaction data, calculate the multidimensional deviation features of the target transaction's transaction data relative to the behavioral baseline of the transaction entity associated with the target transaction; Based on the multidimensional deviation characteristics corresponding to each of the target transactions, multiple risky transactions are selected from the multiple target transactions; Cluster the multidimensional deviation features corresponding to each of the aforementioned risk transactions to obtain at least one cluster; For each cluster, rules are extracted based on the multidimensional deviation features within the cluster to determine the multidimensional deviation conditions corresponding to the cluster, and the scenario constraints corresponding to the cluster are determined based on the attribute information of the transaction entities associated with each risk transaction within the cluster. Based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, risk control business rules corresponding to each cluster are generated and output.

2. The method according to claim 1, characterized in that, The step of extracting rules based on the multidimensional deviation features within the clusters to determine the multidimensional deviation conditions corresponding to the clusters includes: Based on the multidimensional deviation characteristics within the cluster, determine multiple deviation feature values ​​for each continuous numerical dimension and multiple deviation feature values ​​for each discrete dimension within the cluster; For each continuous numerical dimension, the deviation feature value located at a preset quantile among the multiple deviation feature values ​​corresponding to the continuous numerical dimension is used as the rule critical threshold corresponding to the continuous numerical dimension. For each of the discrete dimensions, if the proportion of outliers in the multiple deviation feature values ​​corresponding to the discrete dimension exceeds a preset ratio, the discrete dimension is used as a constraint condition. Based on the rule-based critical thresholds corresponding to each of the continuous numerical dimensions and the constraints, the multidimensional deviation conditions corresponding to the clusters are determined.

3. The method according to claim 1, characterized in that, The step of determining the scenario constraints corresponding to the cluster based on the attribute information of the transaction entities associated with each risk transaction within the cluster includes: Based on the attribute information of the transaction entities associated with each risk transaction within the cluster, determine the frequency of occurrence of at least one attribute value corresponding to each attribute dimension within the cluster; the attribute dimension includes at least one of the following: transaction payee category code, transaction scenario, and transaction account type. For each attribute dimension, attribute values ​​that appear more frequently than a preset proportion threshold are used as the preconditions for the attribute dimension. Based on the pre-constraints corresponding to each attribute dimension, the scenario constraints corresponding to the cluster are determined.

4. The method according to claim 1, characterized in that, The risk control business rules corresponding to the clusters also include the risk types corresponding to the clusters; The determination of the risk type includes: For each risky transaction within the cluster, based on the attribute information of the transaction entity associated with the risky transaction, a historical risk label corresponding to the attribute information is matched in the historical risk sample set to obtain the historical risk label corresponding to the risky transaction; wherein, the historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entity associated with each sample transaction, and historical risk labels corresponding to each sample transaction. For each tag category, based on the historical risk tags corresponding to each risk transaction, the occurrence rate of the tag category is calculated; The risk type corresponding to the cluster is determined based on the occurrence ratio of each of the aforementioned label categories.

5. The method according to claim 1, characterized in that, The step of selecting multiple risky transactions from multiple target transactions based on the multidimensional deviation characteristics corresponding to each target transaction includes: For each target transaction, the risk score of the target transaction is obtained by weighting and summing each deviation feature value in the multidimensional deviation features corresponding to the target transaction with the preset weight corresponding to each deviation feature value. Target transactions with risk scores greater than a preset score threshold are selected as candidate transactions; Based on the attribute information of the transaction entities associated with each candidate transaction, multiple candidate transactions are sampled and selected to obtain multiple risky transactions.

6. The method according to claim 5, characterized in that, The step involves filtering multiple candidate transactions based on the attribute information of the transaction entities associated with each candidate transaction to obtain multiple risky transactions, including: For each candidate transaction, based on the attribute information of the transaction entity associated with the candidate transaction, a historical risk label corresponding to the attribute information is matched in the historical risk sample set to obtain the historical risk label corresponding to the candidate transaction; wherein, the historical risk sample set includes transaction data of multiple sample transactions, attribute information of the transaction entity associated with each sample transaction, and historical risk labels corresponding to each sample transaction. Candidate transactions that meet preset conditions are selected as risky transactions; wherein, the preset conditions are that the label category of the historical risk label corresponding to the candidate transaction is a preset category, and there are at least two candidate transactions under the transaction entity associated with the candidate transaction.

7. The method according to any one of claims 1 to 6, characterized in that, The multidimensional deviation features include at least two of the following: transaction amount deviation features, transaction frequency deviation features, geographical deviation features, device deviation features, and transaction time deviation features.

8. The method according to claim 7, characterized in that, The transaction entities include the payer and the payee; the transaction amount deviation characteristics include the transaction amount deviation ratio and the acquiring amount deviation ratio; the transaction frequency deviation characteristics include the transaction frequency deviation ratio and the acquiring frequency deviation ratio. The calculation process for the transaction amount deviation ratio includes: The transaction amount deviation ratio is calculated based on the transaction amount in the transaction data of the target transaction and the average daily transaction amount in the behavioral baseline corresponding to the transaction payer associated with the target transaction. The calculation process for the transaction frequency deviation ratio includes: The transaction frequency deviation ratio is calculated based on the cumulative number of transactions of the transaction payer associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline corresponding to the transaction payer. The calculation process for the order amount deviation ratio includes: The deviation rate of the transaction amount is calculated based on the transaction amount in the transaction data of the target transaction and the average daily transaction amount in the behavioral baseline of the transaction payee associated with the target transaction. The calculation process for the order frequency deviation ratio includes: The transaction frequency deviation ratio is calculated based on the cumulative number of transactions received by the transaction payee associated with the target transaction within the target time window and the average daily transaction frequency in the behavioral baseline corresponding to the transaction payee. The calculation process for the regional deviation characteristics includes: If the transaction region corresponding to the target transaction does not belong to the trusted region set of the transaction payer associated with the target transaction, the region deviation feature is determined to be a first preset value. The calculation process for the device deviation characteristics includes: If the transaction device corresponding to the target transaction does not belong to the trusted device set of the transaction payer associated with the target transaction, the device deviation feature is determined to be a second preset value. The calculation process for the time period deviation feature includes: If the transaction time of the target transaction falls within a preset abnormal period, the time period deviation characteristic is determined to be a third preset value.

9. The method according to claim 1, characterized in that, The transaction parties include the payer and the payee; The construction of the behavioral baseline corresponding to the transaction entity includes: For each payer in the first preset transaction window, based on the transaction data corresponding to multiple historical transactions of the payer in the first preset transaction window, the total transaction amount and total number of transactions of the payer in the first preset transaction window are counted, and the behavioral baseline of the payer is constructed based on the total transaction amount and the total number of transactions. For each transaction payee existing in the second preset transaction window, based on the transaction data corresponding to multiple historical transactions of the transaction payee in the second preset transaction window, the total amount of transactions received and the total number of transactions received by the transaction payee in the second preset transaction window are counted, and the behavioral baseline of the transaction payee is constructed based on the total amount of transactions received and the total number of transactions received.

10. The method according to claim 9, characterized in that, The behavioral baseline of the transaction payer includes the transaction payer's average daily transaction amount and average daily transaction frequency; The behavioral baseline of the transaction payee includes the transaction payee's average daily transaction amount and average daily transaction frequency.

11. The method according to claim 1, characterized in that, The clustering of the multidimensional deviation features corresponding to each of the aforementioned risk transactions to obtain at least one cluster includes: Clustering processing is performed on the multidimensional deviation features corresponding to each of the risk transactions based on the number of candidate clusters, and the clustering results corresponding to each number of candidate clusters are obtained. The clustering effect is evaluated by using the silhouette coefficient to assess the clustering results corresponding to each number of candidate clusters, and the silhouette coefficient corresponding to each number of candidate clusters is obtained. The number of candidate clusters with the largest silhouette coefficient is determined as the target number of clusters, and clustering processing is performed on the multidimensional deviation features corresponding to each risk transaction according to the target number of clusters to obtain multiple initial clusters; The initial clusters with more risky transactions within a cluster than a preset threshold are designated as clusters.

12. The method according to claim 1, characterized in that, Before outputting each of the aforementioned risk control business rules, the method further includes: Perform a performance evaluation on each of the aforementioned risk control business rules, and determine the performance evaluation result corresponding to each of the aforementioned risk control business rules; Based on the performance evaluation results corresponding to each of the risk control business rules, at least one target business rule is selected from the multiple risk control business rules; The output of each of the risk control business rules includes: Output the target business rules as described.

13. The method according to claim 12, characterized in that, The step of performing performance evaluation on each of the aforementioned risk control business rules and determining the performance evaluation result corresponding to each of the aforementioned risk control business rules includes: Obtain a test sample set, which includes transaction data of multiple test transactions and test risk labels corresponding to each test transaction. The test risk labels include positive labels and negative labels. The total number of real risk samples with positive label categories and the total number of normal samples with negative label categories in the test sample set are counted. For each of the risk control business rules, the test transaction data of each test transaction is matched according to the risk control business rules to determine the total number of samples hit by the risk control business rules, the number of real risk samples hit by the risk control business rules, and the number of normal samples hit by the risk control business rules. For each of the risk control business rules, the performance evaluation result of each risk control business rule is determined based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rule, the number of real risk samples hit by the risk control business rule, and the number of normal samples hit by the risk control business rule.

14. The method according to claim 13, characterized in that, The performance evaluation results include recall rate, false positive rate, and overall score; The process of determining the performance evaluation result of each risk control business rule based on the total number of real risk samples, the total number of normal samples, the total number of samples hit by the risk control business rules, the number of real risk samples hit by the risk control business rules, and the number of normal samples hit by the risk control business rules includes: The recall rate of the risk control business rule is obtained by calculating the ratio of the number of hit real risk samples to the total number of real risk samples. The accuracy of the risk control business rule is obtained by calculating the ratio of the number of actual risk samples that are hit to the total number of hit samples. The comprehensive score of the risk control business rule is determined based on the ratio of the first indicator and the second indicator; the first indicator is the product of the recall rate, the precision rate and the preset coefficient, and the second indicator is the sum of the recall rate and the precision rate. The misjudgment rate of the risk control business rule is obtained by calculating the ratio of the number of hit normal samples to the total number of normal samples.

15. The method according to claim 14, characterized in that, The step of selecting at least one target business rule from multiple risk control business rules based on the performance evaluation results corresponding to each of the aforementioned risk control business rules includes: Risk control business rules with a recall rate greater than or equal to a preset recall rate threshold and a false positive rate less than or equal to a preset false positive rate threshold will be used as candidate business rules. Based on the comprehensive score of each candidate business rule, a preset number of target business rules are selected from the multiple candidate business rules.

16. A business rule configuration device, characterized in that, The device includes: The deviation feature calculation module is used to calculate the multidimensional deviation features of the transaction data of each target transaction relative to the behavioral baseline of the transaction entity associated with the target transaction for each target transaction. The risk transaction screening module is used to screen out multiple risk transactions from multiple target transactions based on the multidimensional deviation characteristics corresponding to each target transaction; The deviation feature clustering module is used to cluster the multidimensional deviation features corresponding to each of the risk transactions to obtain at least one cluster. The rule condition determination module is used to extract rules based on the multidimensional deviation features within each cluster for each cluster, determine the multidimensional deviation conditions corresponding to the cluster, and determine the scenario constraint conditions corresponding to the cluster based on the attribute information of the transaction entities associated with each risk transaction within the cluster. The business rule output module is used to generate risk control business rules corresponding to each cluster based on the multidimensional deviation conditions and scenario constraints corresponding to each cluster, and output each risk control business rule.

17. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the business rule configuration method as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the business rule configuration method as described in any one of claims 1-15.

19. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the business rule configuration method as described in any one of claims 1-15.

Images