Transaction monitoring methods, electronic devices and computer-readable media

Abstract

This invention discloses a transaction monitoring method, electronic device, and computer-readable medium, relating to the field of transaction risk control technology. The method includes: upon detecting a transaction activity event, obtaining the historical single transaction amount sequence of the corresponding user and the number of historical transaction requests within the corresponding historical statistical time period based on the user identifier corresponding to the transaction activity event; determining a transaction amount threshold and a target statistical time window based on the historical single transaction amount sequence and the number of historical transaction requests; obtaining all transaction activity events within the target statistical time window; clustering all transaction activity events within the target statistical time window to obtain multiple transaction activity event groups, and calculating the total transaction amount corresponding to each transaction activity event group; and outputting an amount split to avoid alarms if the total transaction amount of any transaction activity event group exceeds the transaction amount threshold. This invention can avoid falsely reporting or omitting risky users.

Description

Technical Field

[0001] This invention relates to the field of transaction risk control technology, specifically to transaction monitoring methods, electronic devices, and computer-readable media. Background Technology

[0002] In the fields of cross-border payments, e-commerce, and financial risk control, to prevent the illegal transfer of funds, a threshold amount is typically set for each user's transaction. When a user's single transaction is detected to exceed the set threshold, the transaction will be blocked, reviewed, or flagged.

[0003] However, in actual risk control processes, there are still cases of falsely reporting or omitting risky users. Summary of the Invention

[0004] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a transaction monitoring method, electronic device, and computer-readable medium, which have the advantage of avoiding false positives or false negatives of risky users.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A transaction monitoring method, comprising: Upon detecting a transaction activity, based on the user identifier corresponding to the transaction activity, obtain the historical single transaction amount sequence of the corresponding user and the number of historical transaction requests within the corresponding historical statistical time period; A target statistical time window is determined based on the number of historical transaction requests within a historical statistical period, wherein the occurrence time of the target statistical time window is later than the historical statistical period. Based on the historical sequence of single transaction amounts, a critical threshold for transaction amount is determined; Obtain all transaction events within the target statistical time window; All transaction events within the target statistical time window are clustered to obtain multiple transaction event groups, and the total transaction amount corresponding to each transaction event group is calculated; If the total transaction amount in any transaction event group exceeds the transaction amount threshold, an amount splitting alarm will be output.

[0006] Optionally, the step of determining the target statistical time window based on the number of historical transaction requests within a historical statistical period includes: The ratio of the number of historical transaction requests to the length of time corresponding to the historical statistical period is used as the current transaction rate; The ratio of the number of transactions within the preset target window to the current transaction rate is used as the initial statistical time window; If the length of the initial statistical time window is greater than the length of the maximum statistical time window or less than the length of the minimum statistical time window, the maximum statistical time window or the minimum statistical time window shall be used as the target statistical time window. If the length of the initial statistical time window is greater than the length of the minimum statistical time window but less than the length of the maximum statistical time window, the initial statistical time window shall be used as the target statistical time window.

[0007] Optionally, after outputting the amount splitting avoidance alarm when the total transaction amount of any transaction event group exceeds the transaction amount threshold, the method further includes: When the account corresponding to the transaction event is marked as a high-risk account, the node corresponding to the high-risk account is taken as the risk source node, and the target path from the risk source node to the target node is determined from the pre-constructed multi-dimensional lineage heterogeneous graph. The multi-dimensional lineage heterogeneous graph includes account nodes and entity nodes, and weighted association edges are constructed between each node based on real business relationships. The target node is the account node that is reached from the risk source node after passing through a preset number of association edges and intermediate nodes. Based on the preset risk score of the risk source node and the weight of the associated edge in the target path, the risk score of the target node is calculated. The risk level of the target node is determined based on its risk score. Based on the risk level, determine the account control recommendations for the target node and output the account control recommendations.

[0008] Optionally, the step of calculating the risk score of the target node based on the preset risk score of the risk source node and the weights of the associated edges in the target path includes: When there is at most one target path from the risk source node to the target node, the product of the preset risk score and the weights of all associated edges in the target path is used as the risk score of the target node. When there are at least two target paths from the risk source node to the target node, the product of the preset risk score under each target path and the weight of all associated edges in the path is calculated, and the scores of all target paths are summed to obtain the risk score of the target node.

[0009] Optionally, after determining the user identifier corresponding to the transaction event upon detecting the transaction event, the method further includes: Identify the transaction channel identifier corresponding to the transaction event; If the transaction channel identifier is not the preset transaction channel identifier, the multi-dimensional lineage heterogeneous graph is updated using the transaction information corresponding to the transaction event to obtain a new multi-dimensional lineage heterogeneous graph. Starting from the account node corresponding to the transaction event, trace the funds in the new multi-dimensional heterogeneous lineage graph to generate a detailed fund flow graph and output the detailed fund flow graph.

[0010] Optionally, after determining the user identifier corresponding to the transaction event upon detecting the transaction event, the method further includes: Upon detecting a transaction event, a transaction identifier corresponding to the transaction event is determined; Based on the transaction identifier, determine whether there is a corresponding adjudication event in the idle monitoring pool; If an adjudication event corresponding to the transaction identifier exists, determine whether the adjudication event is consistent with the transaction activity of the transaction activity event; If the transaction behavior of the adjudication event and the transaction event are inconsistent, an transaction alert will be output.

[0011] Optionally, after determining whether a corresponding adjudication event exists in the idle monitoring pool based on the transaction identifier, the method further includes: If no ruling event corresponding to the transaction identifier exists, query the ruling log database to see if a ruling event corresponding to the transaction identifier exists. If there is an adjudication log corresponding to the transaction identifier, and the adjudication result in the adjudication log is inconsistent with the transaction behavior of the transaction event, an transaction alarm will be output. If no ruling event corresponds to the transaction identifier, the transaction event will be written into the pending ruling related data table; At a preset time, the transaction events in the pending related data table are matched for adjudication. If no adjudication event corresponding to the transaction event is matched and the duration of the transaction event written into the pending related data table is longer than the preset duration, a bypass transaction alarm is output.

[0012] Optionally, after determining the user identifier corresponding to the transaction event upon detecting the transaction event, the method further includes: Upon detecting a new ruling to be issued, replicate the real-time transaction request from the production environment to generate shadow ruling traffic that is consistent with the real-time transaction request. The shadow adjudication traffic is input into the shadow adjudication environment running new adjudication rules to be issued, resulting in a first adjudication event; the corresponding production adjudication request is input into the production adjudication environment running currently effective rules, resulting in a second adjudication event; Based on the tolerance matrix, the tolerance strategy and tolerance threshold corresponding to the combination of the first adjudication event and the second adjudication event are determined; wherein, the tolerance matrix includes the severity level and tolerance strategy corresponding to the combination of the comparison results of the currently running adjudication rule and the new adjudication rule to be issued, and the tolerance strategy includes the prohibition strategy, the ratio strategy and the logging strategy. The system counts the number of times the prohibition policy is triggered and the frequency of the rate policy being triggered within a preset observation window. If the number of discrepancies exceeds the preset number of discrepancies, or the frequency of discrepancies exceeds the preset frequency of discrepancies, the verification of the new rules to be issued will fail and the circuit breaker will be triggered.

[0013] Furthermore, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the transaction monitoring method described in any of the above claims.

[0014] In addition, the present invention also provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the transaction monitoring method described in any of the above claims.

[0015] In this invention, by acquiring the number of transaction requests made by users within a historical statistical time period, the length of the target statistical time window is dynamically calculated. This allows the window to adapt to the transaction frequency of different users; that is, the window for high-frequency transaction users is automatically shortened, and the window for low-frequency transaction users is automatically extended. This ensures that the number of transactions contained in each detection window remains relatively stable, avoiding the problem of excessive sample size fluctuations caused by differences in user transaction frequency in a fixed window. Simultaneously, based on the user's own historical single transaction amount sequence, this invention estimates an individualized transaction amount threshold, accurately distinguishing between normal large transactions and malicious splitting behavior, overcoming the deficiency of large estimation bias for extreme values ​​under the traditional normal distribution assumption. Furthermore, by performing cluster analysis on transactions within the dynamic window and comparing the total group amount with the individualized threshold, it can accurately identify evasion behavior of splitting large transactions into multiple small transactions, significantly reducing false positive and false negative rates and improving the risk control system's ability to detect complex evasion methods.

[0016] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings: Figure 1 A flowchart illustrating one embodiment of the transaction monitoring method provided by the present invention; Figure 2 This is a flowchart illustrating the process of determining the target statistical time window based on the number of historical transaction requests within a historical statistical period, as provided by the present invention. Figure 3 This is a schematic diagram of the process for identifying risky accounts provided by the present invention; Figure 4 This is a schematic diagram of the multidimensional heterogeneous lineage diagram provided by the present invention; Figure 5 This is a schematic diagram of the process for calculating the risk score of a target node based on the number of target paths provided by the present invention; Figure 6 An example diagram for calculating risk scores using the multi-dimensional heterogeneous lineage graph provided by this invention; Figure 7 This is a schematic diagram of the process for generating a detailed funding chain diagram provided by the present invention; Figure 8 This is a schematic diagram of the process for triggering verification of account activity events provided by the present invention; Figure 9 This is a schematic diagram of the process for determining bypass transactions provided by the present invention; Figure 10 This is a schematic diagram of the process for verifying new rules to be issued, as provided by the present invention. Figure 11 A schematic diagram of the electronic device provided by the present invention; Figure 12 This is a schematic diagram of a computer-readable medium provided by the present invention.

[0018] Explanation of reference numerals in the attached figures: 101. Processor; 102. Memory; 103. I / O interface; 104. Bus. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0020] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0021] In the fields of cross-border payments, e-commerce, and financial risk control, transaction amount thresholds are typically set for users to prevent illicit fund transfers. When a user's single transaction is detected to exceed the set threshold, the transaction will be blocked, reviewed, or flagged.

[0022] However, in actual risk control processes, malicious users may exploit data delays, state synchronization gaps, or rule loopholes to bypass effective restrictions by transferring funds between linked accounts across currencies, splitting large transactions into multiple smaller transactions to circumvent amount thresholds, or making rush transactions during the control window.

[0023] In response to this situation, most related technologies use fixed time windows and fixed risk thresholds for screening, which are difficult to adapt to the differences in transaction frequency among different users. As a result, they cannot accurately distinguish between normal large transactions and malicious splitting behavior, leading to false positives or false negatives of risky users.

[0024] In view of this, the present invention provides a transaction monitoring method, such as... Figure 1 As shown, the method includes: In step S110, when a transaction event is detected, the historical single transaction amount sequence of the corresponding user and the number of historical transaction requests within the corresponding historical statistical time period are obtained based on the user identifier corresponding to the transaction event.

[0025] In step S120, a critical threshold for transaction amount is determined based on the historical single transaction amount sequence.

[0026] In step S130, the target statistical time window is determined based on the number of historical transaction requests within the historical statistical time period.

[0027] The target statistical time window occurs later than the historical statistical time period.

[0028] In this embodiment, the transaction event can be a record of actual fund changes that occur in the business database, such as account deductions, deposits, adjustments, and settlements. Each transaction event includes at least the following information: transaction identifier (trade_id), transaction amount, transfer-out / transfer-in account, timestamp, transaction channel identifier, and user identifier.

[0029] Specifically, when a business system running on an electronic device performs a corresponding operation based on a ruling event or bypasses the ruling to directly perform a fund transfer operation, it will update the account balance or insert transaction records in the business database. These operations will generate binlogs, which can be captured using technologies such as CDC (Change Data Capture) and the captured binlogs can be parsed to obtain the transaction events.

[0030] Considering the high availability, low latency requirements, and open-source ecosystem of cross-border payment systems, this embodiment recommends using Alibaba Canal or Debezium as the core components of CDC. Taking Alibaba Canal as an example, the architecture can be illustrated by deploying a Canal Server instance on a dedicated server, configuring it to connect to the business database master, specifying the databases and tables to be monitored, and setting the output target to a Kafka message queue with the corresponding Topic name. Simultaneously, the Canal Server simulates the MySQL Slave protocol, sending binlog pull requests to the business data master, receiving binlog events in real time; parsing the RowData before and after each event change, extracting the field values ​​before and after the change; serializing the parsing results line by line into JSON format, and sending it to the specified Topic via Kafka Producer. Subsequently, the Sentinel system, acting as a Kafka Consumer, subscribes to the aforementioned Topic, continuously pulls raw binlog messages in JSON format from Kafka, and extracts fields such as trade_id, amount, account, timestamp, and optional channel_id from the binlog's RowData. It then creates standardized objects according to the predefined FlowEvent data format to obtain the transaction event.

[0031] After detecting a transaction event and identifying the corresponding user ID, the system can retrieve the total amount of all historical single transactions for that user within a given period from the historical transaction log, forming a sequence of historical single transaction amounts, such as all historical single transaction amounts for the user within the last 3 months. Simultaneously, the system can retrieve the number of historical transaction requests for the user within a specific historical statistical time period from the transaction log or transaction event cache, i.e., historical transaction events, such as all historical transaction events for the user within the past 24 hours or 1 hour.

[0032] After obtaining the historical sequence of single transaction amounts, extreme value theory can be used to calculate the high quantile of a user's historical amounts as the upper limit for an individual single transaction amount. For example, if the upper limit for an individual single transaction amount fitted by the generalized Pareto distribution is the 99.5th quantile, it means that there is only a 0.5% probability that the user's transaction amount will exceed the upper limit. After obtaining the upper limit for an individual single transaction amount, the larger value between the upper limit and a preset upper limit can be used as the critical threshold for the transaction amount.

[0033] After obtaining the critical threshold for transaction amount, a target statistical time window can be determined based on the number of historical transaction requests within the historical statistical period. When determining the target statistical time window, to balance personalized user behavior with system stability and risk control effectiveness—ensuring it doesn't deviate from the actual user transaction rhythm while avoiding abnormal window failure—further, as an optional implementation method, refer to... Figure 2 As shown, Figure 2 This is a flowchart illustrating the process of determining the target statistical time window based on the number of historical transaction requests within a historical statistical period. Step S130 specifically includes: In step S210, the ratio of the number of historical transaction requests to the length of time corresponding to the historical statistical time period is used as the current transaction rate.

[0034] In step S220, the ratio of the number of transactions within the preset target window to the current transaction rate is used as the initial statistical time window.

[0035] In step S230, if the length of the initial statistical time window is greater than the length of the maximum statistical time window or less than the length of the minimum statistical time window, the maximum statistical time window or the minimum statistical time window is used as the target statistical time window.

[0036] In step S240, if the length of the initial statistical time window is greater than the length of the minimum statistical time window and less than the length of the maximum statistical time window, the initial statistical time window is used as the target statistical time window.

[0037] Specifically, after obtaining the number of historical transaction requests by a user within the historical statistical period, the ratio of the number of historical transaction requests to the length of the corresponding historical statistical period can be used as the current transaction rate. For example, if the length of the corresponding historical statistical period is 1 hour and the number of historical transaction requests is 30, the current transaction rate can be calculated to be 0.5 transactions / minute.

[0038] Subsequently, the electronic device can read the number of transactions within the preset target window from the local device. The preset number of transactions within the target window represents the approximate number of transactions that the detection window is expected to contain. It can be set according to actual needs, such as 3 or 5 transactions. The ratio of the preset number of transactions within the target window to the current transaction rate is used as the initial statistical time window.

[0039] Finally, the target statistical time window is determined using the lengths of the initial statistical time window, the maximum statistical time window, and the minimum statistical time window. Specifically, if the length of the initial statistical time window is greater than the length of the maximum statistical time window or less than the length of the minimum statistical time window, the maximum statistical time window or the minimum statistical time window is used as the target statistical time window. In other words, if the length of the initial statistical time window is greater than the length of the maximum statistical time window, the maximum statistical time window is used as the target statistical time window; if the length of the initial statistical time window is less than the length of the minimum statistical time window, the minimum statistical time window is used as the target statistical time window. If the length of the initial statistical time window is greater than the length of the minimum statistical time window and less than the length of the maximum statistical time window, the initial statistical time window is used as the target statistical time window.

[0040] In this embodiment, by acquiring the number of user transaction requests within a historical statistical time period, the current transaction rate is dynamically calculated. Combined with the number of transactions within the system's preset expected window, a target statistical time window is adaptively generated. Simultaneously, maximum and minimum boundary restrictions are applied to the window length of the target statistical time window. On one hand, this allows for automatic adjustment of the detection window size based on the user's real-time transaction frequency; that is, the window for high-frequency transaction users is automatically shortened, and the window for low-frequency transaction users is automatically extended. This ensures that the number of transactions within each window remains relatively stable, avoiding drastic fluctuations in the sample size within a fixed time window due to differences in user transaction frequency. This solves the technical problems of clustering difficulties caused by excessive transactions within the window for high-frequency users and statistical inconsistencies due to insufficient transactions within the window for low-frequency users. On the other hand, by setting maximum and minimum window boundaries, extreme situations are prevented, such as sudden silence or sudden high frequency, which could lead to insufficient samples and unreliable statistics due to excessively short windows, or excessively long windows resulting in large detection delays and the inclusion of too many irrelevant transactions. This improves the adaptability and accuracy of transaction splitting evasion detection.

[0041] In step S140, all transaction events within the target statistical time window are obtained.

[0042] In step S150, all transaction events within the target statistical time window are clustered to obtain multiple transaction event groups, and the total transaction amount corresponding to each transaction event group is calculated.

[0043] In step S160, if the total transaction amount of any transaction event group is greater than the transaction amount threshold, an amount splitting avoidance alarm is output.

[0044] After obtaining the target statistical time window, all transaction events for that user within the target statistical time window can be retrieved from the transaction event storage based on the user identifier. For all transaction events within the target statistical time window, multi-dimensional features such as time difference, amount difference, counterparty, and IP can be used to cluster all transaction events within the target statistical time window. For example, if the time difference between two transaction events is less than a preset time difference, the amount difference is less than a preset amount difference, and the counterparty or IP is the same or similar, then the two transaction events are grouped into the same transaction event group.

[0045] After obtaining multiple transaction event groups, the transaction amounts within each group are summed to obtain the total transaction amount for each group. Then, the total transaction amount for each transaction event is iterated. If the total transaction amount of any transaction event group exceeds a critical threshold, that transaction event group is determined to be a suspected transaction splitting circumvention, and a transaction splitting circumvention alarm is generated and output. The transaction splitting circumvention alarm content includes at least the user identifier, the target statistical time window, the transaction events included in the transaction event group that triggered the alarm, the total transaction amount, the transaction amount critical threshold, and suggested remedial measures.

[0046] In addition, since the upper limit for individual single transactions reflects a user's long-term normal transaction habits, the preset upper limit for individual single transactions serves as a rigid risk control boundary. When the ratio between the upper limit for individual single transactions and the preset upper limit for individual single transactions is much less than 1, the user's historical transaction amount is significantly lower than the business limit, indicating that their daily behavior is characterized by small amounts and low risk. Once a single transaction or cumulative transaction amount approaches or exceeds the preset upper limit for individual single transactions, it is highly likely to be malicious splitting behavior. Therefore, a stricter freezing threshold is required, such as freezing after 3 cumulative alerts, to achieve rapid interception. When the ratio between the upper limit for individual single transactions and the preset upper limit for individual single transactions is close to or equal to 1, the user's transaction amount is basically matched with the business limit, and their behavior pattern is consistent with the risk control boundary. A standard strategy can be adopted, such as freezing after 5 transactions, to balance interception efficiency and false alarm risk. When the ratio between the upper limit of a single individual transaction and the preset upper limit of a single individual transaction is greater than 1, it indicates that the user has a large number of legitimate large transactions exceeding the limit in their history, such as high-net-worth clients or special business scenarios. If a strict threshold is still used, it will lead to frequent false alarms. Therefore, the freezing threshold should be relaxed, such as 8 alarms, to give more tolerance and avoid affecting normal business. That is, the monitoring sensitivity should be dynamically adjusted according to the user's own transaction habits, so as to accurately crack down on malicious splitting and protect legitimate large transaction users to the greatest extent, thereby achieving refined and intelligent risk control.

[0047] To facilitate a better understanding of this embodiment, a specific example is provided below: Assuming user Zhang San has 30 historical transaction requests within a 1-hour historical statistical period, his current transaction rate is determined to be 0.5. Meanwhile, Zhang San's preset individual single transaction amount limit is $10,000, and the preset target window number of transactions is 4. Subsequently, by using extreme value theory to analyze Zhang San's historical single transaction amount sequence, the individual single transaction amount limit is found to be $9,500.

[0048] Based on the aforementioned information, the critical threshold for transaction amount can be determined to be $10,000, the initial statistical time window is 8 minutes, and it is assumed that the length of the initial statistical time window is greater than the length of the minimum statistical time window and less than the length of the maximum statistical time window.

[0049] Within 8 minutes, Zhang San initiated 4 transactions, which are 4 transaction events: Transaction 1: $4,800, counterparty: Company A, IP 1.1.1.1; Transaction 2: $3,200, counterparty: Company A, IP 1.1.1.1; Transaction 3: $2,500, counterparty: Company A, IP 1.1.1.1; Transaction 4: $1,000, counterparty: Company B, IP 2.2.2.2.

[0050] For all transaction events within the target statistical time window, they are clustered. Since transactions 1, 2, and 3 are close in time, have the same counterparty, and the same IP address, they can be grouped into transaction event group 1. Transaction 4 is grouped separately into transaction event group 2. For transaction event group 1, the total transaction amount can be determined to be $10,500, and for transaction event group 2, the total transaction amount is $1,000.

[0051] Because the total transaction amount in transaction event group 1 exceeds the transaction amount threshold, a suspected splitting circumvention alarm is triggered, i.e., an amount splitting circumvention alarm, and a P2 level alarm is immediately generated to notify risk control personnel for review. Furthermore, if Zhang San triggers this type of alarm multiple times within a short period, such as 5 times within three days, Zhang San's account can be frozen.

[0052] In this embodiment, by acquiring the number of transaction requests made by users within a historical statistical time period, the length of the target statistical time window is dynamically calculated. This allows the window to adapt to the transaction frequency of different users; that is, the window for high-frequency transaction users is automatically shortened, and the window for low-frequency transaction users is automatically extended. This ensures that the number of transactions included in each detection window remains relatively stable, avoiding the problem of excessive sample size fluctuations caused by differences in user transaction frequency in a fixed window. Simultaneously, this embodiment estimates individualized transaction amount thresholds based on the user's own historical single transaction amount sequence. This accurately distinguishes between normal large transactions and malicious splitting behavior, overcoming the deficiency of large estimation bias for extreme values ​​under the traditional normal distribution assumption. Furthermore, by performing cluster analysis on transactions within the target statistical time window and comparing the total amount of the groups with the individualized threshold, the system can accurately identify evasion behavior of splitting large transactions into multiple small transactions, significantly reducing the false positive and false negative rates and improving the risk control system's ability to detect complex evasion methods.

[0053] It is understandable that after identifying malicious users who attempt to circumvent regulations through the aforementioned operations and taking measures such as marking them as high-risk or restricting their accounts, it is possible that before their accounts are restricted, these malicious users may have already established multiple shadow accounts through multi-currency, shared devices, or the same legal entity. Therefore, even after their accounts are restricted, they can still use their indirectly related accounts and multi-currency channels to continue transferring funds, such as different currency accounts of the same user, other accounts sharing the same device, or other entities under the same legal entity. Therefore, to achieve proactive risk diffusion identification from a single high-risk account to its associated network and effectively prevent users from circumventing controls by using related accounts, further, as an optional implementation method, refer to... Figure 3 As shown, Figure 3 To illustrate the process for identifying risky accounts, after step S170, the following steps are also included: In step S310, if the account corresponding to the transaction event is marked as a high-risk account, the node corresponding to the account of the transaction event is taken as the risk source node, and the target path from the risk source node to the target node is determined from the pre-constructed multi-dimensional lineage heterogeneous graph.

[0054] The multi-dimensional lineage heterogeneous graph includes account nodes and entity nodes. Weighted association edges are constructed between each node based on real business relationships. The target node is an account node that is reached from the risk source node after passing through a preset number of association edges and intermediate nodes.

[0055] In step S320, the risk score of the target node is calculated based on the preset risk score of the risk source node and the weight of the associated edges in the target path.

[0056] In step S330, the risk level of the target node is determined based on the risk score of the target node.

[0057] In step S340, an account control recommendation for the target node is determined based on the risk level, and the account control recommendation is output.

[0058] In this embodiment, the multi-dimensional heterogeneous lineage graph can be a graph data structure used to represent the complex relationships between account nodes and entity nodes, consisting of a node set and an edge set. The node set includes account nodes and entity nodes. Account nodes are granular, with each account node uniquely corresponding to an account under a specific currency. Entity nodes include at least one of the following: device fingerprint nodes, IP address nodes, physical address nodes, and legal person or identification number nodes, used to represent external entities with indirect associations with the accounts.

[0059] The edge set comprises multiple edges constructed based on real business relationships, connecting account nodes to account nodes, account nodes to entity nodes, and entity nodes. Each edge is configured with a dynamically adjustable contamination coefficient to quantify the intensity of risk propagation along that edge. If an account corresponding to a certain account node is considered a contamination source, then the risk can propagate backward along the entity edge to the accounts corresponding to other account nodes under that entity. (See reference...) Figure 4 As shown, Figure 4 This is a schematic diagram of a multidimensional heterogeneous lineage map.

[0060] The edge set includes the following edge types: 1. Multi-currency associated edge for the same user: Connects nodes of different currency accounts of the same user; 2. Funds Transfer Side: Connects two account nodes that have had direct transfers. 3. Same legal entity edge: Connects account nodes corresponding to the same legal entity or certificate number, or indirectly connects two account nodes through a legal entity node; 4. Shared Device Edge: Connects an account node or a device node, indirectly connecting two account nodes through the device node; 5. Shared IP edge: Connects account nodes and IP nodes, or indirectly connects two account nodes through IP nodes; 6. Temporary association edges: such as occasional associations that briefly share an IP address.

[0061] For different types of edges, an initial contamination coefficient can be set for each edge based on its type. This initial contamination coefficient can then be adjusted based on actual business data to adapt to real business patterns. For example, the initial contamination coefficient for edges with multiple currencies associated with the same user can be set to 0.95, for edges with fund transfers to 0.9, for edges with the same legal entity to 0.8, for edges with shared equipment to 0.7, for edges with shared IP addresses to 0.5, and for edges with temporary associations to 0.3.

[0062] The pollution coefficient is adjusted through the following steps: 1. Obtain positive samples from historical monitoring records. Positive samples represent avoidance cases that have been manually verified, indicating a genuine risk transmission relationship between the pollution source account and its associated accounts. Positive samples must at least include the pollution source account identifier, the associated account identifier, and the connection path between them. 2. For each positive sample, perform association path analysis and list all possible association paths. For example, if account node Account_A_USD causes account node Account_B_EUR to be identified as circumventing the rules, all possible association paths are listed as follows: Path 1: Multi-currency association; Path 2: Shared device, i.e., account node Account_A_USD→Device_X→Account_B_EUR; Path 3: Same legal entity, i.e., Account_A_USD→legal_Y→Account_B_EUR.

[0063] After listing all possible association paths, the frequency and percentage of each association path type in all positive samples were counted. For example, multi-currency association appeared 80 times, accounting for 60%; equipment association appeared 35 times, accounting for 26%; and legal person association appeared 18 times, accounting for 14%. The frequency or percentage of each association path type was used as the actual contribution of each association path type.

[0064] 3. For each type of associated path, the adjusted pollution coefficient can be calculated using the current pollution coefficient, preset contribution, and actual contribution of each type of associated path, through the following formula: (1), This represents the adjusted pollution coefficient. Indicates the current pollution level. Indicates the learning rate. It can be configured according to actual needs. Indicates the actual contribution. Indicates the preset contribution level. This represents the number of positive samples. The preset contribution rate and learning rate can be set according to actual needs; this embodiment does not impose any special restrictions on them.

[0065] For example, after collecting 100 confirmed circumvention cases, the actual contribution of multi-currency association was determined to be 75%, with an initial pollution coefficient of 0.95; the actual contribution of equipment association was 10%, with an initial pollution coefficient of 0.70; the actual contribution of legal person association was 12%, with an initial pollution coefficient of 0.80; and the actual contribution of IP association was 3%, with an initial pollution coefficient of 0.50. The adjusted pollution coefficients of multi-currency association, equipment association, legal person association, and IP association were calculated using formula (1) to be 0.97, 0.67, 0.76, and 0.48 respectively.

[0066] Specifically, when the account corresponding to the transaction event is marked as a high-risk account, the account identifier and currency of the marked high-risk account can be obtained, the account node corresponding to the high-risk account can be designated as the risk source node, and its preset risk score can be set to 1.0.

[0067] After identifying the risk source node, the electronic device can read a pre-constructed multi-dimensional heterogeneous lineage graph locally. Starting from the risk source node, and using a preset number of associated edges and a preset number of intermediate nodes as search constraints, it traverses the multi-dimensional heterogeneous lineage graph to filter out other account nodes that originate from the risk source node, pass through a preset number of hop edges, and reach a preset number of intermediate nodes. These account nodes are then designated as target nodes, and the fully connected links are extracted as the target path. The preset number of hop edges and intermediate nodes can be set according to actual needs; this embodiment does not impose any special restrictions on them.

[0068] When obtaining the target path and calculating the risk score of the target node based on the preset risk score of the risk source node and the weight of the associated edges in the target path, considering that the risk source node can reach the same target node through at least one business path, and that transaction splitting evasion behavior is often accompanied by gang-related operations, in order to accurately identify multi-layered and intertwined illegal fund transfers and accurately lock down all associated risk accounts within the gang, further, as an optional implementation method, refer to... Figure 5 As shown, Figure 5 This is a flowchart illustrating the process of calculating the risk score of a target node based on the number of target paths. Step S320 specifically includes: In step S510, when there is at most one target path from the risk source node to the target node, the product of the preset risk score and the weights of all associated edges in the target path is used as the risk score of the target node.

[0069] In step S520, when there are at least two target paths from the risk source node to the target node, the product of the preset risk score under each target path and the weight of all associated edges in the path is calculated, and the scores of all target paths are summed to obtain the risk score of the target node.

[0070] Specifically, when there is only one target path from the risk source node to the target node, the risk score of the target node can be obtained by multiplying the preset risk score by the weights of all associated edges in the target path. Conversely, if there are at least two target paths from the risk source node to the target node, the risk score of the target node is obtained by multiplying the preset risk score of each target path by the weights of all associated edges in the path and summing the scores of all target paths.

[0071] It is worth noting that in the actual process of risk transmission, risks are not transmitted infinitely without loss or discount, but rather gradually weaken with the distance of association and the closeness of business. Therefore, when calculating the score corresponding to each target path, in order to accurately reflect the degree of involvement of different levels of nodes by the risk source, effectively avoid risk control misjudgments caused by indiscriminate risk transmission, and achieve a reasonable gradient division of risk levels from near to far, it is necessary to perform a step-by-step attenuation reduction of the basic risk score through the weight of the associated edges, that is: (2), This represents the base score of the nth node in the target path. This represents the base score of the (n-1)th node in the target path. This represents the weight of the edge connecting the nth node and the (n-1)th node. This represents the attenuation factor, where the number of nodes between the (n-1)th node and the risk source node is less than the number of nodes between the nth node and the risk source node. In this embodiment, by distinguishing the number of paths between the risk source node and the target node, a differentiated risk score calculation method is adopted: when there is only a single path, the risk score is directly calculated as the product of the weights of all edges on the path; when there are multiple paths, the score contribution of each path is calculated separately and then accumulated. This accurately reflects the actual effect of risk propagation along multiple paths in the graph. In real business scenarios, risks can often be transmitted to the same related account through different related channels, such as through shared equipment and financial transactions. The multi-path accumulation mechanism fully considers this multi-channel risk superposition effect and avoids the risk underestimation caused by single-path calculation. At the same time, the direct product calculation of a single path maintains the simplicity and interpretability of risk transmission. Through the above method, the comprehensive risk level of related accounts can be quantified more accurately, providing a more scientific quantitative basis for subsequent risk level determination and differentiated management, and effectively improving the identification and handling accuracy of complex related risk scenarios.

[0072] After obtaining the risk score of the target node, a pre-set score cap can be used to normalize the risk score, resulting in a normalized risk score. Then, based on the normalized risk score and a threshold range, the risk level is determined: a normalized risk score greater than 0.7 indicates a high risk level; a score greater than 0.4 and less than 0.7 indicates a medium risk level; a score greater than 0.2 and less than 0.4 indicates a low risk level; and a score less than 0.2 indicates no risk.

[0073] Finally, based on the risk level, account control recommendations for the target node are determined and output. For high-risk scenarios, the account is immediately frozen or forced to undergo manual review; for medium-risk scenarios, large transfers are restricted and multiple verifications are performed; for low-risk scenarios, the account is flagged.

[0074] To facilitate a better understanding of this embodiment, a specific example is provided below: Reference Figure 6 As shown, Figure 6 This is a multi-dimensional heterogeneous lineage diagram for this example. Figure 6 In this scenario, we assume that the account node corresponding to UserA's USD account is the risk source node, and the account node corresponding to UserA's EUR account is the target node. We assign an initial risk score of 1.0, set the maximum propagation jump number to 3, and the decay factor per jump to 0.5.

[0075] The target path from the risk source node to the target node can be determined as follows: Target path 1: UserA_USD→UserA_EUR; Target path 2: UserA_USD→Device_123→UserA_EUR.

[0076] Subsequently, based on formula (2), the score of target path 1 can be calculated to be 0.97, that is... The score for target path 2 is 0.22445, which is... The scores of target path 1 and target path 2 are summed to calculate the risk score of the target node as 1.19445. Assuming the maximum possible score is preset to be 1.5, the risk score of the target node is normalized, and the normalized risk score is 0.80.

[0077] Based on the normalized risk score and threshold range, the risk level is determined to be high risk. At this point, a P1 level alarm and corresponding execution control suggestions can be generated. The alarm content can include the account corresponding to the risk source node, the account corresponding to the target node, the risk score, and the target path. The execution control suggestions can be to implement large-amount transfer restrictions on UserA_EUR, such as requiring manual review for a single transaction exceeding $5,000, or to increase the level limit on UserA_USD, such as reducing it from $100 to $50.

[0078] In this embodiment, after identifying and outputting the alarm for splitting the amount to avoid risk, the risk link is further traced and the associated risk is assessed for the risky account. On the one hand, relying on the pre-built multi-dimensional heterogeneous lineage graph containing account nodes and entity nodes and configured with weighted associated edges, it can accurately lock various target nodes within the radiation range of the risk source node according to the preset link jump conditions, realizing the extension from the assessment of a single abnormal account to the investigation of risks in the entire business-related network, breaking through the limitation of only issuing warnings for a single splitting transaction, and can efficiently uncover hidden group-based and chain-like illegal fund transfer behaviors.

[0079] On the other hand, based on the preset risk score of the risk source node, the risk score is calculated by combining the weight of the related edges in the path. By using the weight, the risk is reasonably attenuated along the transmission link. It can objectively distinguish the degree of connection between different related nodes and the risk source and the strength of the risk involved. Based on the quantified risk score, the corresponding risk level is accurately divided, and then differentiated account control suggestions are matched and output.

[0080] This approach avoids the bias issues inherent in relying solely on subjective experience to assess the risks of related accounts. It also enables the implementation of tiered control strategies based on the risk transmission hierarchy. While precisely blocking transaction splitting to circumvent violations, it achieves early warning and comprehensive collaborative prevention and control of related risks. This effectively enhances the comprehensiveness of financial transaction risk identification, the accuracy of risk quantification, and the pertinence of risk control measures, significantly strengthening the overall security and prevention capabilities of fund transactions.

[0081] Understandably, in distributed financial systems, various bypass channels exist that can directly trigger fund changes without going through the adjudication system, such as internal account adjustments, inter-system clearing, emergency intervention channels, and manual account reconciliation. While these channels provide necessary support for business flexibility, they also bring serious security risks. Malicious users may exploit these channels to bypass risk control adjudication and directly modify account balances or transfer funds, completely undetected by the adjudication system. Therefore, to identify and mark bypass irregular fund movements in real time, a visualized fund flow system is used to assist manual personnel in quickly locating fund destinations, providing accurate evidence for subsequent stop-loss operations such as account freezing and transaction reversal. Furthermore, as an optional implementation method, refer to... Figure 7 As shown, Figure 7 To illustrate the process of generating a detailed funding chain diagram, after step S110, the following steps are also included: In step S710, the transaction channel identifier corresponding to the transaction event is determined.

[0082] In step S720, if the transaction channel identifier is not a preset transaction channel identifier, the multi-dimensional lineage heterogeneous graph is updated using the transaction information corresponding to the transaction event to obtain a new multi-dimensional lineage heterogeneous graph.

[0083] In step S730, the account node corresponding to the transaction event is taken as the starting point, and the new multi-dimensional lineage heterogeneous graph is traced to generate a detailed fund flow graph, and the detailed fund flow graph is output.

[0084] Specifically, upon detecting a transaction event, the transaction channel identifier can be extracted. After obtaining the channel identifier, the electronic device can read the maintained list of authorized transaction channels locally, including the preset channel identifier, channel name, authorization level, validity period, and status. The extracted channel identifier is then compared with the list of authorized transaction channels. If the channel identifier matches the preset channel identifier and its status is valid, the transaction event is considered compliant, and a log is generated. Conversely, if the channel identifier is not the preset channel identifier, or if the preset channel identifier has expired or is deactivated, the transaction event is considered unauthorized.

[0085] If the transaction channel identifier corresponding to the transaction event is not the preset transaction channel identifier, the transaction information corresponding to the transaction event can be extracted, such as the transaction initiating account information, transaction receiving account information, the entity operating entity information corresponding to the transaction, the transaction time, transaction amount, transaction business type, transaction frequency, fund flow direction, device fingerprint, physical address, legal person identification number, and the degree of business cooperation between the two parties.

[0086] Subsequently, the transaction information from the transaction event is used to update the pre-constructed multi-dimensional heterogeneous lineage graph. First, it checks whether the account nodes and entity nodes involved in the current transaction already exist in the multi-dimensional heterogeneous lineage graph. If not, corresponding nodes are added to the graph; if they exist, the original node attributes are retained. Then, based on the actual business relationships of the current transaction, new association edges are created between the corresponding nodes, or existing historical association edges are modified to eliminate invalid and outdated associations. This process corrects the graph structure and node relationships, resulting in a new multi-dimensional heterogeneous lineage graph.

[0087] After obtaining the new multi-dimensional lineage heterogeneous graph, the account node corresponding to the account in the new multi-dimensional lineage heterogeneous graph of the transaction event can be set as the tracing starting node. Based on the new multi-dimensional lineage heterogeneous graph, a topological path tracing traversal can be carried out according to the flow of funds in and out. After completing the tracing traversal, all the account nodes, entity nodes, node sequence, and related edges involved in the tracing process are summarized and integrated to form a standard fund flow detail graph, which is then output for risk control staff to review, verify, and assess risks.

[0088] In this embodiment, after determining the user identifier corresponding to the transaction event, the transaction channel to which the transaction event belongs is further accurately identified. For non-preset non-standard transaction channels, a dynamic update process of the multi-dimensional lineage heterogeneous graph is triggered. It can rely on real-time transaction data to promptly supplement newly added business related entities, correct the business relationship and related edges between nodes, and effectively overcome the defects of traditional static multi-dimensional lineage heterogeneous graphs, such as delayed updates of related relationships, inability to record new transaction relationships in a timely manner, and disconnect between link description and actual fund transactions. This ensures that the multi-dimensional lineage heterogeneous graph always conforms to the actual business transaction status. Simultaneously, based on the updated multi-dimensional lineage heterogeneity graph, full-dimensional automatic traceability of fund flows can be carried out. It can completely and clearly restore the complete flow path of funds and all related entities under unconventional channels, eliminating the need for manual sorting of fund flow relationships one by one. This significantly reduces the workload of fund traceability and investigation, improves the efficiency of fund flow verification, and can quickly uncover hidden fund transfers and abnormal fund transfers in non-mainstream transaction channels. This broadens the scope of transaction risk traceability and supervision, effectively improves the comprehensiveness, accuracy, and timeliness of fund flow traceability in financial transaction scenarios, and strengthens the ability to identify and supervise abnormal transaction behaviors across all channels.

[0089] Understandably, in a distributed risk control scenario, the adjudication and transaction processing for each transaction are independent of each other, and the normal transaction process in the risk control system is as follows: After receiving a transaction request submitted by a user on the front end, the business system running on the electronic device generates a unique transaction identifier for the request, along with information such as the transaction amount, receiving account, sending account, and currency. It then forwards the transaction identifier and the attached information to the adjudication system. The adjudication system makes a judgment based on preset risk control rules, obtaining a corresponding judgment result. The adjudication result, the transaction identifier, and the adjudication time are recorded as an adjudication event, which is then fed back. The adjudication result can be either "allow normal transaction" (ALLOW), "reject transaction" (BLOCK), or "requires manual review" (REVIEW). Upon receiving the adjudication event, the business system performs corresponding transaction operations based on the judgment result. Specifically, if the adjudication event indicates "allow normal transaction," it performs operations such as deduction and transfer; if the adjudication event indicates "reject transaction," it freezes the amount and prohibits deductions and transfers.

[0090] However, in reality, due to reasons such as program errors, network timeouts, human intervention, or malicious bypass, there may be situations where the ruling result is inconsistent with the transaction operation. For example, the ruling result is to refuse the transaction but funds are transferred, or the ruling result is to allow the normal transaction but the transaction is not executed.

[0091] Such discrepancies between the ruling and the actual transaction render risk control ineffective, leading to serious risks such as financial losses. Therefore, to promptly detect such violations, ensure consistency between the ruling and the transaction, and prevent risk control failures caused by data silos, further, as an optional implementation method, refer to... Figure 8 As shown, Figure 8 The flowchart for triggering verification for transaction events includes the following steps after step S110: In step S810, if a transaction event is detected, a transaction identifier corresponding to the transaction event is determined.

[0092] In step S820, it is determined whether there is a corresponding adjudication event in the idle monitoring pool based on the transaction identifier.

[0093] In step S830, if there is an adjudication event corresponding to the transaction identifier, it is determined whether the adjudication event is consistent with the transaction action of the transaction event.

[0094] In step S840, if the transaction behavior of the adjudication event and the transaction event are inconsistent, an transaction alarm is output.

[0095] In this embodiment, the idle monitoring pool can be used to cache the cache structure of adjudication events where the adjudication result is a transaction rejection but no corresponding transaction event has been matched. It uses the transaction identifier as the key and the value as the adjudication event where the adjudication result is a transaction rejection but no corresponding transaction event has been matched. Its data structure is defined as follows: Map<String,DecisionEvent> decisionExecutionMap. / / DecisionEvent contains: tradeId, decisionResult, decisionTime, expiryTime, checkStatus.

[0096] Specifically, after receiving a transaction request submitted by a user on the front end, the business system running on the electronic device generates a unique transaction identifier for the request, along with information such as the transaction amount, receiving account, sending account, and currency. It then forwards the transaction identifier and the accompanying information to the adjudication system. The adjudication system makes a decision based on preset risk control rules, generating an adjudication event. Simultaneously with returning the adjudication event to the business system, it also sends the event to the Kafka / RockTMQ topic_decision. The adjudication event includes the transaction identifier, the adjudication result, and the adjudication time.

[0097] Correspondingly, when the business system performs transaction processing in response to a user's transaction request, it normally executes the corresponding transaction processing based on the received adjudication event. However, due to the aforementioned abnormal situations such as program errors, network timeouts, human intervention, or malicious bypass, the business system will perform the transaction processing before receiving the adjudication event. Regardless of whether the transaction processing is performed under normal or abnormal circumstances, after completing the transaction processing, the business system will insert a transaction record into the transaction log table of the business database, including the transaction identifier, transaction amount, receiving account, sending account, and transaction time, and write each transaction record to the binlog.

[0098] After electronic devices collect transaction records from binlog using CDC technology, they parse information such as transaction identifier, transaction amount, receiving account, sending account, and transaction time from the transaction records, serialize the parsing results into JSON format, and send them to Kafka's topic_binlog.

[0099] The sentinel system running on electronic devices reads and parses JSON data from the topic_binlog, converting it into standard transaction events to extract transaction identifiers. After identifying the transaction identifier corresponding to a transaction event, the sentinel system can access the idle monitoring pool, using the transaction identifier as the key to search for a corresponding adjudication event.

[0100] If a corresponding decision event exists, retrieve the decision event from the idle monitoring pool and read the decision_result field. Compare the decision result with the actual transaction activity of the transaction event. If the decision result matches the actual transaction activity, it complies with business specifications, the verification passes, the decision event is removed from the idle monitoring pool, and a corresponding log is generated. If the decision result does not match the actual transaction activity, such as a decision result prohibiting the transaction but an actual transaction activity occurred, the business system has incorrectly executed the rejected transaction, which constitutes a serious violation. In this case, a P1 level alarm is triggered, generating and outputting a transaction alarm. The transaction alarm content includes at least the transaction identifier, the corresponding decision event, the actual transaction activity, and suggested remedial measures.

[0101] Correspondingly, in distributed risk control scenarios, the adjudication event may arrive later than the transaction event, resulting in no corresponding adjudication event in the idle monitoring pool, or the adjudication event may be permanently lost due to network or system failures. To address these situations and avoid delayed alarms due to message delays, or situations where unauthorized transactions may never be detected due to message loss, further, as an optional implementation method, refer to... Figure 9 As shown, Figure 9 To determine the flowchart for bypass account adjustments, the process includes the following after step S720: In step S910, if there is no adjudication event corresponding to the transaction identifier, the adjudication log database is queried to see if there is an adjudication log corresponding to the transaction identifier.

[0102] In step S920, if there is an adjudication log corresponding to the transaction identifier, and the adjudication result in the adjudication log is inconsistent with the transaction behavior of the transaction event, an transaction alarm is output.

[0103] In step S930, if there is no adjudication log corresponding to the transaction identifier, the transaction event is written into the pending adjudication related data table.

[0104] In step S940, the transaction events in the pending related data table are matched for adjudication at a preset time. If no adjudication event corresponding to the transaction event is matched and the duration of the transaction event written into the pending related data table is longer than the preset duration, a bypass transaction alarm is output.

[0105] Specifically, if no adjudication event corresponds to the transaction identifier, the transaction identifier can be used as the search key to query the adjudication log library to see if an adjudication log corresponding to the transaction identifier exists. If an adjudication log corresponding to the transaction identifier exists in the adjudication log library, and the adjudication result in the adjudication log is inconsistent with the transaction operation of the transaction event, a P1 level alarm can be triggered, and a transaction event alarm can be output. Conversely, if an adjudication log corresponding to the transaction identifier exists in the adjudication log library, and the adjudication result in the adjudication log is consistent with the transaction operation of the transaction event, a corresponding log can be generated to record the MQ delay.

[0106] If no adjudication log corresponding to the transaction identifier exists in the adjudication log repository, the transaction event can be written to the pending adjudication related data table and its status marked as pending reconciliation (PENDING_RECONCILIATION). The pending adjudication related data table is used to temporarily store transaction events that have undergone transaction operations but have not yet been matched with a corresponding adjudication event. Its table structure can be set as follows: Map<String,TradeEvent> pendingDecisionMap; / / TradeEvent contains: tradeId,flowTime,amount,account,status(PENDING_RECONCILIATION).

[0107] For transaction events in the related data table to be adjudicated, the transaction events with the status of PENDING_RECONCILIATION can be traversed periodically. Then, the adjudication log library interface can be called in batches to query whether there is a corresponding adjudication event by the transaction identifier of the transaction event.

[0108] If a corresponding ruling event is found, it indicates a significant delay in the ruling message, and a consistency check is performed. Specifically, if the ruling event results in a transaction rejection but the transaction activity has already occurred, a P1-level alarm is triggered, and a transaction activity alarm is output. If the ruling event results in a transaction allowance and the transaction activity has already occurred, a corresponding log is generated to record the delay time of the ruling event and the completion status of the check.

[0109] If no corresponding adjudication event is found, check the dwell time of the transaction event with the status PENDING_RECONCILIATION in the pending adjudication related data table. If the dwell time of the transaction event in the pending adjudication related data table exceeds the preset time, such as 1 hour, the possibility of message delay can be ruled out. It is highly likely that the transaction event has bypassed the adjudication operation, triggering a P4 level alarm and outputting a bypass transaction alarm.

[0110] It's worth noting that the aforementioned operation is a detection process triggered by a transaction event. Correspondingly, as an alternative implementation, the same detection process can be triggered by an adjudication event. When the sentinel system running on the electronic device detects an adjudication event via MQ, it can use the transaction identifier in the adjudication event as the key to search the pending adjudication related data table for any transaction events that have occurred but do not match an adjudication event. If a transaction event corresponding to the adjudication event exists in the pending adjudication related data table, the adjudication result is compared with the actual transaction behavior of the transaction event. If the adjudication result matches the actual transaction behavior, it conforms to business specifications, the verification passes, the transaction event is removed from the pending adjudication related data table, and a corresponding log is generated. If the adjudication result does not match the actual transaction behavior, such as an adjudication result prohibiting the transaction but an actual transaction has occurred, the business system has incorrectly executed the rejected transaction, constituting a serious violation. In this case, a P1 level alarm is triggered, generating and outputting a transaction alarm. The transaction alarm content includes at least the transaction identifier, the corresponding adjudication event, the actual transaction situation, and suggested handling measures.

[0111] If no corresponding adjudication event exists in the pending adjudication data table, and the adjudication result of the adjudication event is "allow transaction," then the transaction is allowed to proceed without strong monitoring, and a corresponding log can be generated. If the adjudication result of the adjudication event is "prohibit transaction," then the adjudication event is stored in the idle monitoring pool and pushed to the delayed check task. For example, five minutes later, the task searches the pending adjudication data table again using the transaction identifier in the adjudication event as the key to see if there is an account movement event that has occurred but does not match an adjudication event. During the delayed check, if the corresponding account movement event still does not exist in the pending adjudication data table, it is considered that the business system has performed a rejection operation, and a corresponding log is generated. If the corresponding account movement event exists in the pending adjudication data table, it is determined that an account movement has occurred, and a P1 level alarm is triggered, and an account movement event alarm is output.

[0112] In this embodiment, upon detecting a transaction activity, the system prioritizes matching the adjudication events in the idle monitoring pool with the transaction identifier, and compares the consistency between the regulated behavior corresponding to the adjudication event and the current actual transaction activity in real time. When a deviation occurs, a transaction activity alarm is promptly output. The idle monitoring pool caches generated adjudication records that have not yet been matched with corresponding transaction activities, enabling a reverse verification mechanism that prioritizes adjudication rules and retrospectively verifies transaction activities, effectively covering asynchronous business time-series scenarios where adjudication precedes transaction activity. Compared to traditional one-way risk control identification relying solely on real-time transaction features, this embodiment can accurately identify hidden violations such as users unauthorized changes to transaction activity patterns and deliberate deviations from established adjudication rules under the same transaction identifier, preventing unscrupulous entities from circumventing risk control supervision by exploiting transaction time-series differences and rule rigidity defects. Simultaneously, relying on real-time adjudication data within the pool for instant comparison and verification significantly improves the sensitivity and efficiency of identifying abnormal transaction activities, effectively filling the technical gap in traditional risk control's inability to conduct behavioral verification of established adjudication rules, and enhancing the real-time risk interception capability and the rigor of behavioral compliance verification in financial transactions.

[0113] Furthermore, when no corresponding adjudication event is matched in the idle monitoring pool, the historical adjudication log is reviewed by backtracking, and new transaction events without any adjudication records are collected and stored in the database. A bypass alarm mechanism for timeout failure to match is also added. On the one hand, by backtracking the adjudication log database, the historical adjudication standards for the same transaction identifier throughout its entire lifecycle are reused and verified, avoiding the problem of missed judgments due to historical behavior variations caused by relying solely on real-time cached data, thus achieving continuous monitoring of transaction behavior throughout its entire lifecycle. On the other hand, newly added transaction events without adjudication records are uniformly written into the pending adjudication related data table for centralized management, achieving the orderly collection and retention of unknown transaction patterns and new transaction behaviors, solving the control blind spot of no rules to match and no fixed-point monitoring for newly added unknown transaction events. Meanwhile, by matching timed adjudications and monitoring overdue durations, bypass alarms are triggered for transaction events that cannot be matched with valid adjudications for a long period of time. This can promptly detect potential risks such as new types of hidden illegal transactions and unadjudicated transactions with abnormal links. It achieves multi-level closed-loop risk control, including routine behavior verification, historical behavior backtracking, new behavior aggregation, and overdue risk mitigation. This significantly improves the comprehensiveness, comprehensiveness, and robustness of financial transaction risk identification and effectively reduces the risk of missing new and variant illegal transactions.

[0114] It is understandable that rule changes and adjustments are common in risk control scenarios. However, there may be logical conflicts or unexpected side effects between the new rules to be issued and the currently effective rules. Directly applying the new rules to be issued could lead to large-scale false negatives or serious underreporting, such as misjudging a large number of normal transactions as rejections or mistakenly allowing risky transactions that should have been rejected, resulting in irreparable business losses. Therefore, to avoid the aforementioned situations, further, as an optional implementation method, refer to... Figure 10As shown, Figure 10 The flowchart illustrates the process of verifying new rules to be issued in response to a ruling. After step S110, the following steps are also included: In step S1010, if a new ruling to be issued is detected, the real-time transaction request in the production environment is copied to generate a shadow ruling traffic that is consistent with the real-time transaction request.

[0115] In step S1020, the shadow adjudication traffic is input to the shadow adjudication environment running the new adjudication rules to be issued, and a first adjudication event is obtained; the corresponding production adjudication request is input to the production adjudication environment running the currently effective rules, and a second adjudication event is obtained.

[0116] In step S1030, the tolerance policy and tolerance threshold corresponding to the combination of the first adjudication event and the second adjudication event are determined according to the tolerance matrix; wherein, the tolerance matrix includes the severity level and tolerance policy corresponding to the combination of the comparison results of the currently running adjudication rule and the new adjudication rule to be issued, and the tolerance policy includes the prohibition policy, the ratio policy and the logging policy.

[0117] In step S1040, the number of times the prohibition policy is triggered and the frequency of the difference in triggering the ratio policy are counted within the preset observation window.

[0118] In step S1050, if the number of differences is greater than the preset number of differences, or the frequency of differences is greater than the preset frequency of differences, the verification of the new rules to be issued will fail and the circuit breaker will be triggered.

[0119] Specifically, when the sentinel system running in the electronic device detects a rule change event in the adjudication system, such as a new rule version being uploaded or a configuration update, it immediately activates the traffic splitter and copies the real-time transaction requests entering the adjudication system from the production environment according to the sampling rate. The copied real-time transaction requests are used as shadow adjudication traffic. That is, when a new adjudication rule to be released is detected, the real-time transaction requests in the production environment are copied to generate shadow adjudication traffic that is consistent with the production requests.

[0120] After receiving the shadow adjudication traffic, it is input into the shadow adjudication environment running new adjudication rules to be released. The new adjudication rules to be released in the shadow adjudication environment independently adjudicate each real-time transaction request in the shadow adjudication traffic, generating a first adjudication event. Correspondingly, the production adjudication environment running the currently effective rules processes the real-time transaction requests normally, using the currently effective old rules to independently adjudicate the real-time transaction requests, generating a second adjudication event.

[0121] After obtaining the first and second adjudication events, a tolerance strategy and tolerance threshold corresponding to the combination of the first and second adjudication events for the same real-time transaction request can be determined based on a predefined tolerance matrix. The predefined tolerance matrix is ​​shown in Table 1, which is a schematic table of the tolerance matrix: Table 1:

[0122] For the combination of the first and second adjudication events of a real-time transaction request, an observation window can be set, such as 1 hour or a cumulative processing of 10,000 transactions. Within the observation window, for each comparison result, if the tolerance policy of the comparison result is a prohibition policy, the cumulative count is incremented by one to obtain the number of differences that trigger the prohibition policy; if the tolerance policy of the comparison result is a ratio policy, the number of occurrences of the ratio policy is recorded, and the ratio of the total number of occurrences of the ratio policy to the total number of comparisons is the difference occurrence frequency of the ratio policy.

[0123] After obtaining the number of differences and frequency of differences between the proposed new ruling and the currently effective rules, if the number of differences exceeds a preset number, a prohibition policy is triggered (e.g., BLOCK becomes ALLOW or ALLOW becomes BLOCK). Alternatively, if the frequency of differences exceeds a preset frequency (e.g., the frequency of differences exceeds 1%), such as the proportion of REVIEW becoming BLOCK exceeding 1%, then the proposed new ruling fails verification and triggers circuit breaker processing, immediately blocking the formal release process of the proposed new ruling. A P2-level alarm is generated, including the transaction identifier of the conflicting real-time transaction requests, comparison result details, etc., and shadow traffic data and conflicting real-time transaction requests are retained for subsequent offline analysis. Conversely, if the number of differences does not exceed a preset number (i.e., no prohibition policy is triggered, such as no BLOCK becoming ALLOW or ALLOW becoming BLOCK), or the frequency of differences does not exceed a preset frequency (e.g., the frequency of differences does not exceed 1%), such as the proportion of REVIEW becoming BLOCK not exceeding 1%, then the proposed new ruling passes verification and can be allowed to enter the formal release process.

[0124] In this embodiment, upon detecting a new rule to be issued, shadow traffic is generated by replicating the real-time ruling request from the production environment. This shadow traffic is then input into both the shadow environment running the new rule and the production environment running the old rule, generating a first ruling event and a second ruling event in parallel. The differences between the two are compared in real-time based on a predefined tolerance matrix, and the number of prohibited differences and the frequency of ratio-based differences within the observation window are statistically analyzed. When a prohibited or ratio-based difference exceeds a threshold, a circuit breaker is immediately triggered to prevent the new rule from being issued. This allows for a race-like verification of the new and old rules using real production traffic before the rule goes live, automatically identifying and blocking potential large-scale false alarms, such as allowing changes to denying, or missed detections, such as denying changes to allowing. Compared to traditional offline testing or manual review, comparing full or sampled real traffic covers complex online business scenarios, significantly improving the authenticity and coverage of rule verification. Meanwhile, through a configurable tolerance matrix and circuit breaker mechanism, it ensures zero tolerance for serious conflicts while allowing a certain percentage of fluctuations for acceptable differences, such as approval turning into rejection. This avoids frequent release blockages caused by minor differences, effectively solving the consistency guarantee problem in the process of risk control rule upgrades, significantly reducing business losses and customer complaints caused by rule errors, and improving the security and automation of the risk control system evolution.

[0125] It is worth noting that in the existing financial transaction risk control architecture, traditional risk control decisions mostly rely on preset fixed rules to complete risk assessment and disposal output. The overall decision-making logic is rigid and inflexible, unable to adapt to increasingly diversified and concealed abnormal fund flow behaviors. At the same time, the existing risk control system lacks a unified central decision-making and scheduling capability. Various business links such as transaction behavior identification, fund link tracing, risk transmission of related nodes, consistency verification of adjudication results, and transaction anomaly alarms are independent and isolated, and data cannot be interconnected and linked, making it difficult to form an integrated risk control and judgment system.

[0126] Furthermore, traditional risk control decisions suffer from response lag, failing to quickly issue disposal instructions for real-time abnormal account movements and account risk transmission behaviors. They also lack the functions of rule iteration self-testing, risk parameter adaptive adjustment, and dynamic optimization and upgrading of risk control capabilities. This makes it difficult to effectively prevent and control emerging risk behaviors such as new types of transaction splitting, cross-link group fund anomalies, and channel-variant illegal transactions. Relying solely on static judgment models is prone to drawbacks such as missed risk detection, delayed disposal, and single control strategies. Overall, the real-time performance, flexibility, and scalability of risk control decisions are significantly deficient, failing to meet the comprehensive and multi-layered fund security prevention and control needs in high-frequency real-time trading scenarios.

[0127] Therefore, to overcome the above-mentioned shortcomings, alarms are uniformly accessed, policies are centrally orchestrated, and reliable execution is guaranteed, forming a closed loop of alarm → decision → execution → feedback. Furthermore, as an optional implementation method, when any type of alarm is output, the following operations are performed: 1. Detect any alarm event output, where each alarm event includes risk type, risk score and evidence graph, the evidence graph includes a list of affected accounts, transaction identifiers and risk paths, etc.; 2. For any alarm event, analyze the alarm event to extract key variables. For example, for riskType=EVASION_GRAPH, extract the source account (rootAccount), the list of related accounts (affectedAccounts), and the account risk score (riskScore); for riskType=DECISION_FAIL, extract the transaction identifier (tradeID), the expected ruling result (expectedResult), and the actual transaction behavior (actualResult). 3. After extracting key variables, corresponding action templates can be matched based on variables such as riskType and riskScore. For example, if riskType=EVASION_GRAPH and riskScore≥0.7, the action template Batch Freeze Accounts (TEMPLATE_BATCH_FREEZE) is matched; if riskType=EVASION_SPLIT and is triggered 3 times consecutively, a temporary freeze for 24 hours (TEMPLATE_TEMP_FREEZE) is matched; if riskType=DECISION_FAIL and expectedResult=REJECT and actualResult=moving account, the transaction reversal (TEMPLATE_REVERSE_TX) and account lock (TEMPLATE_ACCOUNT_LOCK) are matched. 4. Based on the specific business data extracted in step 2, such as account ID and trade ID, fill in the placeholders in the action template to generate an executable plan. For example, the content of the template TEMPLATE_BATCH_FREEZE is: {action:freeze_accounts,targets: {{affectedAccounts}}}, which, after binding, becomes {action:freeze_accounts,targets: [UserA_EUR, UserB_USD]}.

[0128] 5. The ExecutionPlan is sent to the execution engine. For each subtask in the ExecutionPlan, the execution engine calls the corresponding business interface and adopts a best-effort delivery strategy, that is, it attempts to execute each subtask. If successful, the status is recorded as SUCCESS; if it fails, such as due to network timeout or interface error, the task is put into the RetryQueue and the reason for failure is recorded. The background thread asynchronously consumes the retry queue and adopts an exponential backoff strategy, such as delaying for 1 second, 2 seconds, 4 seconds, etc., to retry, with a maximum of 3 retries. If it still fails after 3 retries, a manual intervention ticket is generated, which includes the failed task, the reason for failure, the affected account, etc., and is pushed to the risk control ticket system.

[0129] 6. For irreversible operations such as reversing transactions, if the execution fails, for example, if the counterparty's account balance is insufficient or the funds have been transferred out, the system will not retry indefinitely, but will immediately execute automatic stop loss, that is, call TEMPLATE_ACCOUNT_LOCK to lock the transferring account to prevent the loss from expanding, generate an emergency work order, and notify risk control and legal personnel to activate the manual emergency plan, such as contacting the payee and reporting to the police.

[0130] 7. Write the final execution status of all subtasks, such as success / retry failure / manual handling, back to the alarm event table to form a closed-loop record.

[0131] In this embodiment, upon detecting any type of alarm event, the risk type, risk score, and evidence graph are extracted through context parsing. An action template is then matched based on the strategy decision tree to generate an execution plan containing parameters such as specific account identifiers and transaction representations. The execution engine employs a best-effort delivery strategy, performing exponential backoff asynchronous retries on subtasks. Upon retry failure, a manual work order is automatically generated. Simultaneously, for irreversible operations, such as failed transaction reversal, the account is immediately locked to stop losses, triggering emergency manual intervention. This technical solution achieves automated and precise mapping from risk alarms to control actions, solving the technical problems of existing risk control systems that rely on manual handling, have large response delays, and low execution reliability. Through the exponential backoff retries and manual work order fallback mechanism, it ensures that most tasks can be completed automatically in high-concurrency scenarios while providing closed-loop protection for extreme failure situations, avoiding risk control omissions due to interface timeouts or network jitter. For irreversible operations, this embodiment employs a rapid response logic of immediate stop-loss upon execution failure, locking the account immediately when funds cannot be recovered, effectively controlling the spread of losses. Compared with existing technologies, this embodiment significantly improves the automation capabilities and execution reliability of the risk control system, reduces the frequency of manual intervention and emergency response costs, and provides highly available and traceable execution assurance for the last mile of risk control decision-making.

[0132] It should be noted that most existing financial transaction risk control systems rely solely on online real-time rule-based judgments and decision-making to complete risk prevention and control. The overall risk control logic is highly dependent on manually preset rules and established business models, lacking independent offline data analysis and mining mechanisms and model iteration and optimization mechanisms. The risk control rules, risk scoring standards, fund flow identification standards, and abnormal behavior identification thresholds that operate online remain fixed for a long time. They can only adapt to traditional illegal transaction patterns that have been discovered, and cannot deeply mine the hidden risk characteristics in massive amounts of historical transaction data, historical risk sample data, historical decision deviation data, and abnormal fund flow logs.

[0133] Meanwhile, traditional risk control models struggle to systematically review and summarize past missed or misjudged events and rule mismatch scenarios. They cannot automatically extract the characteristics of new types of illegal transactions and the patterns of hidden risk transmission. Relying solely on manual experience to adjust rules is not only inefficient but also suffers from inconsistent standards, delayed optimization, and limited coverage. This makes it difficult to keep up with the ever-evolving and evolving nature of illegal transaction methods. Consequently, online real-time risk control systems have been unable to achieve autonomous iteration of capabilities for a long time. The accuracy of risk identification, the coverage of risk interception, and the adaptability to different scenarios are difficult to continuously improve, making it impossible to achieve a long-term evolution of the risk control system from passive defense to proactive prediction.

[0134] To overcome the aforementioned shortcomings of existing technologies, as an alternative implementation method, an integrated architecture for offline learning and continuous optimization can be constructed, as follows: 1. Collect multi-source data offline to construct a feature wide table. Historical data is retrieved daily from the following sources: alarm events, including raw features such as multi-dimensional lineage heterogeneous graph risk scores (graph_risk_score) and split risk scores (split_risk_score); decision response records, including executed actions and their success status, manual review labels (1 indicates real risk, 0 indicates normal transaction), and normal events adjudicated by the business system. This data is partitioned by event_day, cleaned, and correlated to construct a feature wide table (sentinel_feature_evolution). Each record in the table includes an event identifier (event_id), a real label, scores for each feature, and contextual information.

[0135] 2. Configure weighting coefficients according to business strategies. This represents the risk interception weight and the coefficient of recall. , representing the false positive penalty weight, and the coefficient of the false positive rate. , representing the performance-cost weight. Define the overall revenue function. ,in Let be the parameter vector to be optimized, containing risk thresholds, contamination coefficients of various associated edges, etc. The optimization objective is to search within the parameter space for... Largest parameter combination , It is a comprehensive return function used to quantify a set of candidate parameters. The overall performance, such as risk threshold and pollution coefficient, is considered. This represents the optimal combination of parameters, which is the combination of parameters found in a predefined parameter search space by a parameter optimization algorithm (such as Bayesian optimization) that maximizes the overall benefit function. The parameter vector that yields the maximum value.

[0136] 3. Set reasonable upper and lower boundaries for each parameter to be optimized. For example: risk threshold risk_threshold∈[0.5,0.9]; multi_currency_weight∈[0.8,0.99]; device_weight∈[0.5,0.85]; minimum dynamic window length window_min∈[1, 10] minutes, etc. 4. Call a pre-packaged parameter optimization module, such as a Bayesian optimization algorithm library like Optuna. In each iteration: the module generates a set of candidate parameters based on historical evaluation results. ;Will Configure the shadow detection engine; inject the shadow engine with the full historical transaction data of the past N days, including all transaction requests and transaction records; the shadow engine outputs alert results, and the recall rate under this parameter combination is calculated by combining the real labels in the feature wide table. False alarm rate and cost And then find The score is fed back to the optimization module, which adjusts its search direction accordingly, moving towards a better region. This process is repeated until convergence or the preset maximum number of iterations is reached. If the score does not improve significantly after several consecutive rounds or the number of iterations is not less than 100, the parameter combination with the highest score is output. ; 5. Compare with the parameters currently being used online. With optimization results Calculate the changes in each parameter and the expected effects, such as a 2% increase in recall and a 0.5% decrease in false positive rate, and generate a readable optimization report for risk control personnel to review; 6. Combine the optimal parameters Package the data into a configuration version (ConfigVersion) and upload it to a configuration center such as Apollo. Adopt a canary release strategy: route 1% to 5% of online real-time traffic to the canary group applying the new parameters via the configuration center, while the remaining 99% to 95% continue using the old parameters; monitor the performance metrics of the canary group in real time: P99 Latency, Error Rate, and False Positive Rate changes, etc.; if the canary group remains within the observation window and the metrics are stable and without abnormal fluctuations over 24 hours, gradually increase the traffic ratio, such as 10%, 50%, 100%, until full deployment; if abnormal metrics occur, such as a sudden spike in the False Positive Rate exceeding 50%, automatically trigger a circuit breaker, switch the canary group back to the old parameters via the configuration center, and record the failure log for the next round of optimization analysis; 7. Repeat steps one through six daily or weekly to continuously approximate the actual business patterns. Simultaneously, incorporate failed cases during the canary release process, such as scenarios requiring rollback, as negative samples into the next round of training.

[0137] In this embodiment, an offline evolution layer is constructed to collect alarm events from the detection layer, response records from the decision layer, and normal events from the business system on a T+1 cycle, and associates these with manually reviewed labels to form a feature wide table. A parameter optimization module, such as Bayesian optimization, iteratively generates candidate parameter vectors within a preset search space, and injects historical full transaction data into the shadow detection engine for replay evaluation. Using a comprehensive profit function as the optimization objective, the optimal parameter combination is automatically searched. Finally, the optimal parameters are hot-updated to the online detection engine via a canary release through the configuration center, with an automatic rollback mechanism. This achieves closed-loop self-evolution of various parameters, such as risk thresholds and pollution coefficients of various related edges, solving the technical problems of traditional manual parameter tuning relying on experience and being difficult to adapt to dynamic business changes. Compared with existing technologies, this embodiment ensures the authenticity and security of parameter optimization through offline data-driven and shadow replay verification; avoids the optimization process impacting online business through canary release and automatic rollback; and through continuous iteration, it can adapt to the evolution of transaction behavior and new avoidance methods, significantly improving recall and reducing false positive rates, thereby enhancing the long-term stability and adaptability of the risk control system.

[0138] Meanwhile, this embodiment also provides an electronic device, referring to Figure 11 As shown, Figure 11 This is a schematic diagram of the structure of an electronic device, which includes: One or more processors; A memory having stored one or more computer programs that, when executed by one or more processors, cause the one or more processors to implement the transaction monitoring method according to the first aspect of the invention.

[0139] The electronic device may also include one or more I / O interfaces connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0140] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the first memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the processor and the memory, including but not limited to the data bus (Bus).

[0141] In some embodiments, the processor, memory, and I / O interfaces are interconnected via a bus, and thus connected to other components of the computing device.

[0142] As a third aspect of the present invention, a computer-readable medium is provided, with reference to... Figure 12 As shown, Figure 12 This is a schematic diagram of a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the transaction monitoring method provided in the first aspect of this disclosure.

[0143] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0144] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A transaction monitoring method, characterized in that, include: Upon detecting a transaction activity, based on the user identifier corresponding to the transaction activity, obtain the historical single transaction amount sequence of the corresponding user and the number of historical transaction requests within the corresponding historical statistical time period; Based on the historical sequence of single transaction amounts, a critical threshold for transaction amount is determined; A target statistical time window is determined based on the number of historical transaction requests within a historical statistical period, wherein the occurrence time of the target statistical time window is later than the historical statistical period. Obtain all transaction events within the target statistical time window; All transaction events within the target statistical time window are clustered to obtain multiple transaction event groups, and the total transaction amount corresponding to each transaction event group is calculated; If the total transaction amount in any transaction event group exceeds the transaction amount threshold, an amount splitting alarm will be output.

2. The method according to claim 1, characterized in that, The step of determining the target statistical time window based on the number of historical transaction requests within a historical statistical period includes: The ratio of the number of historical transaction requests to the length of time corresponding to the historical statistical period is used as the current transaction rate; The ratio of the number of transactions within the preset target window to the current transaction rate is used as the initial statistical time window; If the length of the initial statistical time window is greater than the length of the maximum statistical time window or less than the length of the minimum statistical time window, the maximum statistical time window or the minimum statistical time window shall be used as the target statistical time window. If the length of the initial statistical time window is greater than the length of the minimum statistical time window but less than the length of the maximum statistical time window, the initial statistical time window shall be used as the target statistical time window.

3. The method according to claim 1, characterized in that, After outputting an amount splitting avoidance alarm when the total transaction amount of any transaction event group exceeds the transaction amount threshold, the method further includes: When the account corresponding to the transaction event is marked as a high-risk account, the node corresponding to the high-risk account is taken as the risk source node, and the target path from the risk source node to the target node is determined from the pre-constructed multi-dimensional lineage heterogeneous graph. The multi-dimensional lineage heterogeneous graph includes account nodes and entity nodes, and weighted association edges are constructed between each node based on real business relationships. The target node is the account node that is reached from the risk source node after passing through a preset number of association edges and intermediate nodes. Based on the preset risk score of the risk source node and the weight of the associated edge in the target path, the risk score of the target node is calculated. The risk level of the target node is determined based on its risk score. Based on the risk level, determine the account control recommendations for the target node and output the account control recommendations.

4. The method according to claim 3, characterized in that, The step of calculating the risk score of the target node based on the preset risk score of the risk source node and the weight of the associated edges in the target path includes: When there is at most one target path from the risk source node to the target node, the product of the preset risk score and the weights of all associated edges in the target path is used as the risk score of the target node. When there are at least two target paths from the risk source node to the target node, the product of the preset risk score under each target path and the weight of all associated edges in the path is calculated, and the scores of all target paths are summed to obtain the risk score of the target node.

5. The method according to claim 3, characterized in that, After determining the user identifier corresponding to the detected transaction event, the method further includes: Identify the transaction channel identifier corresponding to the transaction event; If the transaction channel identifier is not the preset transaction channel identifier, the multi-dimensional lineage heterogeneous graph is updated using the transaction information corresponding to the transaction event to obtain a new multi-dimensional lineage heterogeneous graph. Starting from the account node corresponding to the transaction event, trace the funds in the new multi-dimensional heterogeneous lineage graph to generate a detailed fund flow graph and output the detailed fund flow graph.

6. The method according to claim 1, characterized in that, After determining the user identifier corresponding to the detected transaction event, the method further includes: Upon detecting a transaction event, a transaction identifier corresponding to the transaction event is determined; Based on the transaction identifier, determine whether there is a corresponding adjudication event in the idle monitoring pool; If an adjudication event corresponding to the transaction identifier exists, determine whether the adjudication event is consistent with the transaction activity of the transaction activity event; If the transaction behavior of the adjudication event and the transaction event are inconsistent, an transaction alert will be output.

7. The method according to claim 6, characterized in that, After determining whether a corresponding adjudication event exists in the idle monitoring pool based on the transaction identifier, the process further includes: If no ruling event corresponds to the transaction identifier, query the ruling log database to see if there is a ruling log corresponding to the transaction identifier. If there is an adjudication log corresponding to the transaction identifier, and the adjudication result in the adjudication log is inconsistent with the transaction behavior of the transaction event, an transaction alarm will be output. If there is no adjudication log corresponding to the transaction identifier, the transaction event will be written into the pending adjudication related data table; At a preset time, the transaction events in the pending related data table are matched for adjudication. If no adjudication event corresponding to the transaction event is matched and the duration of the transaction event written into the pending related data table is longer than the preset duration, a bypass transaction alarm is output.

8. The method according to claim 1, characterized in that, After determining the user identifier corresponding to the detected transaction event, the method further includes: Upon detecting a new ruling to be issued, replicate the real-time transaction request from the production environment to generate shadow ruling traffic that is consistent with the real-time transaction request. The shadow adjudication traffic is input into the shadow adjudication environment running new adjudication rules to be issued, resulting in a first adjudication event. The corresponding real-time transaction request is input into the production adjudication environment running currently effective rules, resulting in a second adjudication event. Based on the tolerance matrix, the tolerance strategy and tolerance threshold corresponding to the combination of the first adjudication event and the second adjudication event are determined; wherein, the tolerance matrix includes the severity level and tolerance strategy corresponding to the combination of the comparison results of the currently running adjudication rule and the new adjudication rule to be issued, and the tolerance strategy includes the prohibition strategy, the ratio strategy and the logging strategy. The system counts the number of times the prohibition policy is triggered and the frequency of the rate policy being triggered within a preset observation window. If the number of discrepancies exceeds the preset number of discrepancies, or the frequency of discrepancies exceeds the preset frequency of discrepancies, the verification of the new rules to be issued will fail and the circuit breaker will be triggered.

9. An electronic device, characterized in that, include: One or more processors; A memory having stored one or more computer programs thereon, which, when executed by the one or more processors, cause the one or more processors to implement the transaction monitoring method according to any one of claims 1 to 8.

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

Images