Method and device for determining whether transaction flow exceeds limit or not, storage medium and equipment

Abstract

The invention provides a method and device for determining whether transaction flow exceeds a limit or not, a storage medium and equipment, and the method comprises the steps: obtaining transaction information of a target transaction, and matching a corresponding flow control scene which at least comprises a transaction region, a transaction channel and a transaction type according to the transaction information; according to the traffic control scene and the transaction information, determining a plurality of corresponding traffic control rules and priorities thereof, and performing over-limit check on a traffic accumulation value and a transaction accumulation number of times of the target transaction in a traffic accumulation table according to the traffic control rules, the traffic control rules at least comprising the maximum transaction traffic and the maximum transaction number of times of the target transaction; and determining that the traffic accumulated value and the transaction accumulated number of times do not exceed the limit under the condition that the traffic accumulated value and the transaction accumulated number of times meet all traffic control rules, and determining that the traffic accumulated value exceeds the limit and / or the transaction accumulated number of times exceeds the limit under the condition that the traffic accumulated value does not meet at least one rule and / or the transaction accumulated number of times does not meet at least one rule. According to the method, efficient, flexible and expandable flow control is realized.

Description

Technical Field

[0001] This application relates to the field of financial information technology, and more specifically, to a method for determining whether transaction flow exceeds the limit, a device for determining whether transaction flow exceeds the limit, a computer-readable storage medium, and an electronic device. Background Technology

[0002] In large-scale financial transaction systems, traffic control is a crucial element in ensuring the security, compliance, and efficiency of transactions. However, traditional traffic control methods have several shortcomings. First, most traditional traffic control systems employ a centralized database architecture, which faces performance bottlenecks and single points of failure when dealing with large-scale transaction data and high-concurrency requests. Second, traditional traffic control rules are not flexible enough to adapt to complex and ever-changing business scenarios and personalized control needs. Furthermore, traditional systems are constrained by fixed code logic and struggle to achieve precise traffic control across different business levels. Summary of the Invention

[0003] The main objective of this application is to provide a method, apparatus, computer-readable storage medium, and electronic device for determining whether transaction traffic exceeds the limit, so as to at least solve the problems of performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies.

[0004] To achieve the above objectives, according to one aspect of this application, a method for determining whether transaction traffic exceeds limits is provided, comprising: obtaining transaction information of a target transaction, and matching a corresponding traffic control scenario based on the transaction information, wherein the transaction information includes at least a transaction region, a transaction channel, and a transaction type; determining multiple corresponding traffic control rules and the priority of each traffic control rule based on the traffic control scenario and the transaction information, and performing an over-limit check on the cumulative traffic value and cumulative transaction count of the target transaction in a traffic accumulation table based on all the traffic control rules and the priority of each traffic control rule, wherein the traffic control rules include at least the maximum transaction traffic and the maximum number of transactions of the target transaction; determining that the cumulative traffic value and the cumulative transaction count do not exceed limits if both the cumulative traffic value and the cumulative transaction count satisfy all the traffic control rules, and determining that the cumulative traffic value exceeds limits and / or the cumulative transaction count exceeds limits if the cumulative traffic value does not satisfy at least one of the traffic control rules and / or the cumulative transaction count does not satisfy at least one of the traffic control rules.

[0005] According to another aspect of this application, a device for determining whether transaction traffic exceeds limits is provided, comprising: an acquisition unit, configured to acquire transaction information of a target transaction and match a corresponding traffic control scenario based on the transaction information, wherein the transaction information includes at least a transaction region, a transaction channel, and a transaction type; a first determination unit, configured to determine multiple corresponding traffic control rules and the priority of each traffic control rule based on the traffic control scenario and the transaction information, and to perform an over-limit check on the cumulative traffic value and cumulative transaction count of the target transaction in a traffic accumulation table based on all the traffic control rules and the priority of each traffic control rule, wherein the traffic control rules include at least the maximum transaction traffic and the maximum number of transactions of the target transaction; and a second determination unit, configured to determine that the cumulative traffic value and the cumulative transaction count are not exceeded if both the cumulative traffic value and the cumulative transaction count satisfy all the traffic control rules, and to determine that the cumulative traffic value exceeds the limit and / or the cumulative transaction count exceeds the limit if the cumulative traffic value does not satisfy at least one of the traffic control rules and / or the cumulative transaction count does not satisfy at least one of the traffic control rules.

[0006] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute any of the methods for determining whether the transaction flow exceeds the limit.

[0007] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for performing any of the methods for determining whether the transaction flow exceeds the limit.

[0008] Applying the technical solution of this application, the method for determining whether transaction traffic exceeds limits first obtains the transaction information of the target transaction and matches the corresponding traffic control scenario based on the transaction information. The transaction information includes at least the transaction region, transaction channel, and transaction type. Based on the traffic control scenario and transaction information, multiple corresponding traffic control rules and their priorities are determined. The cumulative traffic value and cumulative transaction count of the target transaction in the traffic accumulation table are then checked for exceeding limits based on all traffic control rules and their priorities. The traffic control rules include at least the maximum transaction traffic and maximum transaction count of the target transaction. If both the cumulative traffic value and the cumulative transaction count satisfy all traffic control rules, it is determined that the cumulative traffic value and the cumulative transaction count have not exceeded limits. If the cumulative traffic value does not satisfy at least one traffic control rule and / or the cumulative transaction count does not satisfy at least one traffic control rule, it is determined that the cumulative traffic value and / or the cumulative transaction count have exceeded limits. This method achieves efficient, flexible, and scalable traffic control, solving the problems of performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies. Attached Figure Description

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

[0010] Figure 1 A hardware block diagram of a mobile terminal for determining whether transaction traffic exceeds the limit, according to an embodiment of this application, is shown.

[0011] Figure 2 A flowchart illustrating a method for determining whether transaction flow exceeds limits according to an embodiment of this application is shown.

[0012] Figure 3 An engine-based traffic control data flow diagram is shown for a method for determining whether transaction traffic exceeds limits according to an embodiment of this application;

[0013] Figure 4 An engine-based traffic scenario management diagram is shown, illustrating a method for determining whether transaction traffic exceeds limits according to an embodiment of this application;

[0014] Figure 5 The diagram illustrates an engine-based traffic scenario and rule matching diagram for a method for determining whether transaction traffic exceeds limits, according to an embodiment of this application.

[0015] Figure 6 A diagram of an engine-based traffic checking module is shown, illustrating a method for determining whether transaction traffic exceeds limits according to an embodiment of this application.

[0016] Figure 7 The diagram illustrates a database sharding and table partitioning method for determining whether transaction traffic exceeds limits, according to an embodiment of this application.

[0017] Figure 8 A flowchart illustrating an engine-based traffic control method for determining whether transaction traffic exceeds limits, according to an embodiment of this application, is shown.

[0018] Figure 9 A system apparatus diagram is shown for a method of determining whether a transaction flow exceeds a limit, according to an embodiment of this application;

[0019] Figure 10 A structural block diagram of a device for determining whether a transaction flow exceeds a limit, according to an embodiment of this application, is shown.

[0020] The above figures include the following reference numerals:

[0021] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

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

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

[0025] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0026] Sharded databases: Sharded databases refer to the technique of splitting a large database into multiple small, independent database instances. Each shard is only responsible for storing and querying a portion of the data, and these shards can be deployed on different physical servers to achieve distributed data storage and processing.

[0027] Engine-ization: Engine-ization refers to the process of abstracting and encapsulating the complex logic of a certain type of problem or business process to form a stable and reusable solution or tool.

[0028] Traffic control: A technical means of monitoring, analyzing and restricting data transmission or transaction requests in a system, network or business in real time through preset rules to ensure stability, security and reasonable allocation of resources.

[0029] A positive transaction refers to the initial transaction that generates actual fund changes. It is characterized by two points: first, a clear fund flow, meaning a positive transaction has a definite direction of fund transfer, such as expenditure or income; and second, it is the first recorded transaction, meaning a positive transaction is the first complete transaction record established in the transaction system. Typical positive transactions include: consumer transactions, pre-authorizations, cash withdrawals, and transfers.

[0030] Reverse transactions refer to corrective operations that cancel out existing positive transactions. They are characterized by two points: first, reverse adjustment, meaning the changes in funds generated by the original transaction are adjusted in the opposite direction; and second, correlation and traceability, meaning they must be linked to specific positive transaction records. Typical reverse transactions include: transaction cancellation, transaction reversal, and returns.

[0031] As described in the background section, in existing technologies, traffic control is a crucial element in ensuring the security, compliance, and efficiency of large-scale financial transaction systems. However, traditional traffic control methods have several shortcomings. First, most traditional traffic control systems employ a centralized database architecture, which faces performance bottlenecks and single points of failure when dealing with large-scale transaction data and high-concurrency requests. Second, traditional traffic control rules are not flexible enough to adapt to complex and ever-changing business scenarios and personalized control needs. Furthermore, traditional systems are constrained by fixed code logic and struggle to achieve precise traffic control across different business levels.

[0032] To address the performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies, embodiments of this application provide a method for determining whether transaction traffic exceeds limits, a device for determining whether transaction traffic exceeds limits, a computer-readable storage medium, and an electronic device.

[0033] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0034] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of determining whether transaction traffic exceeds the limit, according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0035] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the method for determining whether transaction traffic exceeds the limit in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-described networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the above-described networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0036] This embodiment provides a method for determining whether transaction traffic running on a mobile terminal, computer terminal or similar computing device exceeds the limit. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] Figure 2 This is a flowchart illustrating a method for determining whether transaction traffic exceeds limits according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0038] Step S201: Obtain the transaction information of the target transaction and match the corresponding traffic control scenario based on the transaction information. The transaction information includes at least the transaction region, transaction channel and transaction type.

[0039] Specifically, the system first receives and parses information about a target transaction. This information includes at least the geographical location, channel, and specific type of transaction, such as consumption, cash withdrawal, or transfer. Based on the parsing results, the system matches the transaction with preset traffic control scenarios. These scenarios are defined based on historical data analysis and business rules, aiming to identify specific combinations of transaction types requiring traffic control, thereby providing early warnings and control for potential excessive transactions. Through this matching process, the system can accurately pinpoint which preset rules the transaction should be checked under, improving the targeting and efficiency of traffic checks. This allows transaction traffic checks to more quickly and accurately locate the scenarios requiring control, avoiding indiscriminate checks on all transactions, reducing unnecessary computational costs, and enhancing the system's response speed and processing capacity.

[0040] Step S202: Based on the above traffic control scenario and the above transaction information, determine the corresponding multiple traffic control rules and the priority of each of the above traffic control rules, and perform an over-limit check on the traffic accumulation value and transaction accumulation number of the target transaction in the traffic accumulation table according to all the above traffic control rules and the priority of each of the above traffic control rules. The above traffic control rules include at least the maximum transaction traffic and the maximum transaction number of the target transaction.

[0041] Specifically, after matching a traffic control scenario, the system further determines a series of traffic control rules applicable to that scenario. These rules clearly specify the traffic limits for transactions under specific scenarios and conditions, such as daily limits, monthly limits, and frequency limits, such as the maximum number of transactions per day. Next, the system prioritizes these rules to ensure that when multiple rules apply to a transaction simultaneously, it can determine which rule should be given priority according to a predefined order. Then, the system checks whether the target transaction's cumulative traffic and number of transactions exceed the limits in the traffic accumulation table, referring to the priority and restrictions of these rules. The traffic accumulation table records the cumulative traffic and number of transactions for each transaction under various control scenarios and is a key data source for determining whether a transaction exceeds the limits.

[0042] By prioritizing and comprehensively checking rules, the system can make rapid and accurate traffic control decisions when dealing with complex transaction scenarios. Even in environments with highly complex transaction information, it can ensure the rationality of decisions and avoid erroneous judgments or decision delays caused by rule conflicts or unclear priorities.

[0043] Step S203: If the cumulative traffic value and the cumulative number of transactions both satisfy all of the above traffic control rules, determine that the cumulative traffic value and the cumulative number of transactions have not exceeded the limit. If the cumulative traffic value does not satisfy at least one of the above traffic control rules and / or the cumulative number of transactions does not satisfy at least one of the above traffic control rules, determine that the cumulative traffic value exceeds the limit and / or the cumulative number of transactions exceeds the limit.

[0044] Specifically, after the system completes its check of all traffic control rules for the target transaction, if it finds that the cumulative traffic value and the cumulative number of transactions for the transaction do not exceed the limits set by any rule, the system determines that the transaction has not exceeded the limits in terms of traffic and number of transactions, and can continue. Conversely, if the cumulative traffic value or the cumulative number of transactions exceeds the limit of any rule, the system will immediately determine that the transaction has exceeded the limits and corresponding control measures need to be taken.

[0045] Through this rigorous inspection process, the system can instantly identify and block transactions that exceed preset limits, effectively preventing financial risks and violations, and ensuring the stable operation of the financial platform and the security of user funds. Especially in high-concurrency and high-volume trading environments, it can significantly reduce the risk of fund loss and enhance user trust and satisfaction.

[0046] Traffic control is a crucial component of financial transaction systems, its core being the monitoring and management of transaction traffic based on pre-defined rules. With increasing financial transaction volume and business complexity, efficient traffic control methods are essential for handling large data volumes and high-concurrency scenarios. Traffic control prohibits transactions exceeding limits, including limits on transaction amounts and frequency. While limits on transaction amounts and frequency can be viewed, they cannot be monitored or historical transaction data can be viewed; only the final total amount or number of transactions can be viewed. Once pre-authorization is complete, installment payments, settlement notifications, Easy Loans, and merchants on the QR code tax payment whitelist are exempt from engine-based traffic control; all other transactions are subject to traffic control. For example... Figure 3 As shown, firstly, transaction elements are matched against traffic control scenarios to determine whether to enter the traffic inspection process. Then, in successfully matched scenarios, applicable specific rules are further mapped. Next, rule fusion and priority processing are performed to ensure transactions are correctly classified and assigned to the corresponding cumulative entities. After completing the above process, the critical traffic inspection stage begins, including traffic rule query, traffic accumulation and over-limit checks, and anomaly handling. Finally, the traffic accumulation value is updated based on the positive and negative types of transactions, completing the entire traffic control process. Transaction matching with traffic control scenarios: Based on transaction region, channel, type, and other factors, traffic control scenarios are matched. If the match is successful, the traffic inspection process begins; if the match fails, traffic control ends. Scenario and rule matching: In successfully matched scenarios, rule mapping is performed based on transaction elements to determine the applicable specific rules.

[0047] The method for determining whether transaction traffic exceeds limits as described in this application first obtains the transaction information of the target transaction and matches it with the corresponding traffic control scenario. The transaction information includes at least the transaction region, transaction channel, and transaction type. Based on the traffic control scenario and transaction information, multiple corresponding traffic control rules and their priorities are determined. Then, based on all traffic control rules and their priorities, the cumulative traffic value and cumulative number of transactions for the target transaction in the traffic accumulation table are checked for exceeding limits. The traffic control rules include at least the maximum transaction traffic and the maximum number of transactions for the target transaction. If both the cumulative traffic value and the cumulative number of transactions satisfy all traffic control rules, it is determined that the cumulative traffic value and the cumulative number of transactions have not exceeded limits. If the cumulative traffic value does not satisfy at least one traffic control rule and / or the cumulative number of transactions does not satisfy at least one traffic control rule, it is determined that the cumulative traffic value and / or the cumulative number of transactions have exceeded limits. This method achieves efficient, flexible, and scalable traffic control. It solves the problems of performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies.

[0048] In this embodiment, a method for determining whether transaction traffic exceeds limits is implemented. Its core lies in matching the target transaction's transaction information with a traffic control scenario, and determining multiple traffic control rules and their priorities based on the scenario and information. This allows for precise checking of the cumulative traffic value and cumulative transaction count in the traffic accumulation table. This method overcomes the performance bottleneck caused by centralized database architecture in existing technologies. Especially when handling large-scale, high-concurrency transactions, the efficient read / write capabilities of a sharded database and the flexible configuration of the rule engine significantly improve the response speed and accuracy of traffic checks. Simultaneously, the priority processing mechanism ensures that when multiple rules are matched, the system prioritizes the application of stricter traffic control rules, enhancing the flexibility and targeting of traffic control. Through the technical solution of this application, the traffic check system can better cope with complex and ever-changing business needs, achieving the goals of high-performance, high-reliability, and high-precision traffic control.

[0049] The above embodiments, based on a sharded database, ensure rapid read and write of relevant data under high concurrency modes. They also engineize the control rules, enabling flexible rule configuration, effectively supporting changes in business scenarios, avoiding code redundancy, and reducing the difficulty of secondary development. This provides an effective method for efficient traffic control in large-scale business systems. This method improves the read / write performance and concurrent processing capabilities of traffic data by adopting a sharded database architecture; it meets complex and ever-changing business scenarios and personalized needs through engine-based configuration and flexible rule configuration; it achieves precise traffic control at different levels through precise hierarchical management; and it employs a traffic update mechanism to dynamically update the cumulative traffic value based on transaction type (positive or negative transaction) and control level.

[0050] In some embodiments, matching the corresponding traffic control scenario based on the above transaction information includes the following steps:

[0051] Step S301: Based on the transaction information of the target transaction, determine control identification codes for multiple screening levels. The multiple screening levels include transaction region level, transaction channel level, transaction type level, transaction method level, and identification factor level. The identification factor level is a screening level that filters based on the identification factors of the target transaction. The identification factors are used to characterize the transaction data of the target transaction at least. The total length of the control identification code represents the total number of all level types of the corresponding screening level. Each digit of the control identification code represents whether the corresponding level type needs to be controlled.

[0052] Step S302: Based on the control identification codes of all the above-mentioned screening levels, determine the traffic control scenario corresponding to the above-mentioned transaction information.

[0053] This embodiment provides a multi-level transaction traffic scenario extraction method. By parsing transaction information and filtering layer by layer, it extracts transaction traffic scenarios that meet the conditions from the transaction region layer, channel layer, and category layer, and finally achieves the matching of transaction information and traffic control scenarios.

[0054] Based on the identification rules at different levels, scenarios that meet the conditions are filtered out from the traffic inspection scenario table, and scenario numbers are obtained. Each scenario number is labeled with a scenario, facilitating subsequent matching of scenarios with scenario identification rules. The specific rules for identifying scenarios are as follows: Figure 4 As shown, the transaction inspection scenario table has dedicated fields for storing the control identification codes corresponding to each level. The value of each control code can be determined by the transaction elements, thereby filtering out scenarios and their numbers that meet the value criteria.

[0055] The control identifier is a binary string. The total length of the string represents the total number of different categories under that level. Each binary digit represents whether a certain category under that level needs to be controlled; 0 means no control is required, and 1 means control is required. For example, the regional control identifier has two digits, representing domestic and overseas regions. The first digit indicates whether domestic transactions are controlled, and the second digit indicates whether overseas transactions are controlled.

[0056] Regional-level filtering: From the traffic inspection scenario table, filter scenario data based on the regional-level control identifier code. For identified domestic transactions, filter scenario data where the corresponding bit in the control identifier code is 1; for identified overseas transactions, filter scenario data where the corresponding bit in the control identifier code is 1. Specifically, if the control identifier code is empty or all zeros, it means that no regional-level control is required for either domestic or overseas transactions, and such cases should also be filtered out to avoid missing other scenarios.

[0057] Channel-level filtering, such as card group channels, UnionPay, and Connect: Based on the regional filtering results, scenario data is further filtered according to the channel-level control identifier. Each digit of the channel-level control identifier corresponds to a different transaction channel, and data that meets the criteria is filtered based on the actual source channel of the transaction.

[0058] Category-level filtering: Based on the channel-level filtering results, data is further filtered according to the category-level control identifier. Each digit of the category-level control identifier corresponds to a different transaction type, such as consumption, cash withdrawal, transfer, repayment, etc., and data that meets the criteria is filtered accordingly.

[0059] Sub-level filtering: Based on the results of the category-level filtering, data is further filtered according to the sub-level control identifier code. Each digit of the sub-level control identifier code corresponds to a different sub-transaction type, such as facial recognition payment, online transaction, magnetic stripe transaction, chip transaction, and non-magnetic / chipless transaction, etc., filtering out data that meets the criteria.

[0060] Identification Factor Filtering: Based on the results of the sub-layer filtering, identification factor filtering is performed on each piece of scene data. The set of identification factor indices is split into a list using a delimiter, and this list is traversed. Identification factors are part of the scene; the scene is considered compliant only if the constraints configured on the page are met.

[0061] For each identification factor number: if the first two digits are not the sub-trading type (AT), trading category (AS), or trading channel (CH), then it is considered invalid and the current number is skipped.

[0062] Based on the type of identification factor (AT, AS, CH) and the matching method (e.g., greater than or equal to, greater than, equal to, less than, less than or equal to), combined with the standard value of the identification factor, the transaction data is further filtered. If the matching conditions are met, the data is added to the final traffic scenario list.

[0063] At this point, all traffic scenarios that meet the criteria have been identified and stored in the traffic scenario list.

[0064] In this embodiment, based on the transaction information of the target transaction, control identifiers are determined for multiple screening levels, including transaction region, transaction channel, transaction type, transaction method, and identification factor layers. These control identifiers are binary codes, with their total length reflecting the number of all levels within the corresponding screening level. Each digit indicates whether traffic control is required for that level type: 0 represents no control, and 1 represents control. By comprehensively considering the control identifiers of all screening levels, the traffic control scenario matching the transaction information can be accurately located. This design allows the system to quickly identify and apply the correct traffic control strategy when processing transactions, avoiding transaction delays or security risks caused by improper rule configuration. Precise matching ensures the efficient execution of traffic control rules, improving the security and compliance of transaction processing. This multi-layer identifier matching-based traffic control scenario determination mechanism not only simplifies the complexity of rule configuration but also improves the speed and accuracy of the system's transaction response, effectively addressing the challenges posed by massive transactions and diverse business rules in financial transaction systems.

[0065] In some embodiments, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions of the target transaction in the traffic accumulation table according to all the above-described traffic control rules and the priority of each of the above-described traffic control rules, including the following steps:

[0066] Step S401: If multiple traffic control rules have the same priority, retain the traffic control rules that meet the first preset condition and remove the traffic control rules that do not meet the first preset condition. The first preset condition is the smallest traffic limit value and the smallest transaction number limit.

[0067] Step S402: The above-mentioned traffic control rules are applied sequentially in order of priority from low to high to check the above-mentioned cumulative traffic value and the above-mentioned cumulative number of transactions for exceeding the limit. The above-mentioned limit check includes whether the above-mentioned cumulative traffic value exceeds the limit and whether the above-mentioned cumulative number of transactions exceeds the limit.

[0068] Among them, engine-based traffic scenarios and rule matching, such as Figure 5 As shown, in the scenario and rule matching stage, the traffic inspection rule configuration information is queried based on the scenario number in the traffic inspection scenario table to obtain the rule number corresponding to the scenario. Subsequently, based on these rule numbers, all rules marked as active are extracted from the traffic inspection rule library, and a set of rules related to the current trading currency is further filtered out.

[0069] In the traffic inspection and processing flow, the system will skip the following types of rules: rules whose effective time is later than the current time, rules whose expiration time is earlier than the current time, and rules whose transaction traffic scenario control layer code is empty, thereby ensuring that only truly effective rules are applied.

[0070] The transaction traffic control hierarchy code is divided into multiple levels, specifically: Level 0 (Bank Level), Level 1 (Customer Level), Level 2 (Card Product Level), Level 3 (Card Level), Level 4 (Account Level), Level 5 (Merchant Level), and Level 6 (Account Product Level). The application logic differs for each level: Bank-level rules control all customers, while rules for other levels (Levels 1-6) verify whether the current transaction's customer number, card product number, card number, account number, merchant number, or account product number exists in the set of numbers recorded in the traffic check rule. If not, the rule for that level is ineffective. Furthermore, when processing rules matched from different levels, a merging operation is performed, retaining a smaller limit value to achieve stricter limit control. Through this method, this application achieves flexible rule configuration without storing a large number of duplicate records, which is convenient for use and significantly saves storage space.

[0071] In this embodiment, based on all traffic control rules and their priorities, the cumulative traffic value and cumulative number of transactions for the target transaction in the traffic accumulation table are checked for exceeding limits. This includes: when multiple traffic control rules have the same priority, retaining the traffic control rules that meet a first preset condition and removing those that do not. The first preset condition is the minimum traffic limit and the minimum transaction limit. Traffic control rules are then applied sequentially from lowest to highest priority to check the cumulative traffic value and cumulative number of transactions for exceeding limits. This check includes whether the cumulative traffic value and the cumulative number of transactions exceed the limit. This mechanism, through priority sorting and limit filtering, ensures that the strictest traffic control rules are applied, avoiding rule conflicts and unnecessary redundancy, and achieving precise control over transaction traffic. Furthermore, the use of rule priority sorting and minimum limit selection further improves the flexibility and efficiency of traffic control, ensuring smooth transactions under the constraints of traffic rules, while also reducing the complexity of system maintenance and updates.

[0072] In some embodiments, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions of the target transaction in the traffic accumulation table according to all the above-described traffic control rules and the priority of each of the above-described traffic control rules, including the following steps:

[0073] Step S501: Based on all the above-mentioned traffic control rules and the priority of each of the above-mentioned traffic control rules, determine the transaction scenario code, rule level code, and overdraft attribute code. The above-mentioned rule level code represents the priority of the above-mentioned traffic control rules.

[0074] Step S502: Based on the above transaction scenario code, the above rule level code, and the above overdraft attribute code, perform a transaction query in the above traffic accumulation table to obtain the query results;

[0075] Step S503: If the above query result is an empty set, determine that the above target transaction is the first transaction, and directly compare the cumulative traffic value and cumulative number of transactions of the above target transaction with the traffic limit value and transaction number limit in all the above traffic control rules.

[0076] Step S504: If the query result is not an empty set, perform an over-limit check on the cumulative traffic value and cumulative number of transactions of the target transaction in the cumulative traffic table based on the transaction information of all the target transactions in the cumulative traffic table, all the traffic control rules, and the priority of each traffic control rule.

[0077] This application proposes an innovative method for managing transaction traffic scenarios. This method achieves efficient integration and priority ranking of various transaction traffic scenarios by constructing a clear priority rule system. Specifically, this application predefines seven transaction traffic scenario management levels, identified by codes 0 to 6, each code corresponding to a different management level and its corresponding cumulative target. It should be noted that these codes are not arranged in a simple order, but are set based on specific business logic and priority relationships. Regarding priority determination, this application follows these principles: the managed traffic of the bank level (code 0) is accumulated to the customer level (code 1). Simultaneously, the management of the customer level itself is independent, and the customer level has a higher priority than the bank level when accumulating traffic; the management priority of the card level (code 3) is higher than that of the card product level (code 2), and both accumulate traffic data to the card dimension; the management priority of the account level (code 4) is higher than that of the account product level (code 6), and both accumulate traffic data to the account dimension; the merchant level (code 5) is an independent management level, and its traffic data is accumulated to a specific cumulative target level. When a transaction triggers multiple control rules at the same level, this application employs a "minimum limit selection" strategy. That is, the system automatically compares the limit values ​​of each rule within the same level and selects the smallest limit value as the final traffic control limit for that transaction. This design aims to ensure that transaction traffic is controlled in a more stringent and secure environment. In summary, by introducing transaction traffic scenario control level codes and priority processing mechanisms, this application achieves refined and intelligent management of transaction traffic, effectively improving the efficiency and accuracy of transaction traffic control.

[0078] The engine-based traffic inspection module diagram is shown below. Figure 6 As shown, after completing the matching of traffic control scenarios, mapping of matching results to control rules, and effective integration and priority processing of rules, it is also necessary to configure and perform multiple verifications on the rules to ensure their effectiveness and accuracy.

[0079] When configuring flow rules, the first step in rule checking is to set control dimensions within the flow rules. These rules are stored in specific parameter tables in the database, covering various limit settings such as single transaction limits, daily limits, and monthly limits. Exceedance checks are used to verify the number and amount of transactions.

[0080] The rules support multiple levels, such as card level, customer level, account level, and multiple periods, such as daily, monthly, and yearly settings, to adapt to different business needs and scenarios.

[0081] The rule checking process includes the following steps:

[0082] Step 1: Traffic scenario matching and verification. Execute the rule verification program on successfully matched transaction traffic scenarios to generate a set containing records of the matched scenarios.

[0083] ① Traverse the collection and perform the following operations for each scenario record: When a record matches the current transaction information and does not exist in the traffic scenario table, add the record to a specific list (such as the scenario key ID list and the traffic scenario list) so that the traffic inspection rule configuration table can be queried later to achieve traffic control.

[0084] ② If the set of authorized transaction sub-category identification factor numbers is empty, then check whether the record exists in the traffic scenario table. If it does not exist, continue to perform the above traversal operation.

[0085] Step 2: Preprocessing and rule configuration query. When the traffic scenario list is not empty, it means that the transaction has matched the corresponding traffic control scenario, and the engine-based traffic control process is started:

[0086] Based on the preprocessed list of traffic scenarios, the traffic inspection rule configuration table is queried three times, with the following query conditions:

[0087] ① The rule must be in a valid state (not logically deleted);

[0088] ② The traffic inspection scenario number is included in the traffic scenario list;

[0089] ③ Perform queries for the three control dimensions of overdraft (1), overpayment (2), and mixed status (0);

[0090] In step 2 above, the three queries are processed in a time-sharing parallel manner to generate rule subsets corresponding to different fund statuses.

[0091] Step 3: Rule Query and Timeliness Verification. After querying the rule configuration table in Step 2, it is also necessary to query the traffic inspection rule table for multi-dimensional matching and verify the timeliness of the rules. In this step, the traffic inspection rule table needs to be queried first to obtain the set of rules that match the current transaction. The specific query conditions are as follows:

[0092] ① The rule must be in a valid state (not logically deleted and in an active state);

[0093] ② The currency code must match the currency currently being traded;

[0094] ③ The overdraft attribute code of the traffic inspection rule must match the current execution count. This attribute code contains multi-level control identifiers, and the system can automatically match the corresponding control level according to the threshold range of the transaction amount.

[0095] ④ The traffic inspection rule number must be included in the rule number set obtained in step 2.

[0096] After obtaining the set of matching rules, this step requires validating the validity of these rules. When a rule contains multiple time conditions, a time window overlap algorithm is used to verify the intersection of the rules' validity periods. The verification process includes the following steps:

[0097] ① Rules that exclude situations where the effective time is empty or the current time is earlier than the effective time;

[0098] ② Exclude rules where the expiration time is empty or the current time is later than the expiration time;

[0099] ③ Exclude rules where the transaction flow scenario control layer code is empty.

[0100] Step 4: Rule Application:

[0101] The valid rule set verified in step 3 is applied to the flow control processing of the current transaction. This mechanism ensures the accuracy and timeliness of the flow control rules through triple verification of scenario screening, multi-dimensional matching, and timeliness verification, forming a complete rule decision chain.

[0102] In this embodiment, for traffic control of the target transaction, the system performs over-limit checks based on all traffic control rules and their priorities. First, based on each traffic control rule, the system determines the transaction scenario code, rule level code, and overdraft attribute code, where the rule level code reflects the rule's priority. Then, combining the transaction scenario code, rule level code, and overdraft attribute code, the system queries the traffic accumulation table for the target transaction to obtain the corresponding query results. If the query results are empty, the system identifies the target transaction as a first-time transaction and directly compares the target transaction's accumulated traffic value and accumulated transaction count with the traffic limit and transaction count limit in all traffic control rules to determine if it exceeds the prescribed range. If the query results are not empty, the system performs further over-limit checks on the target transaction's accumulated traffic value and accumulated transaction count based on all relevant transaction information in the traffic accumulation table, all traffic control rules, and rule priorities, ensuring that the transaction traffic meets multi-level and multi-dimensional traffic control requirements. This design not only improves the accuracy of traffic control but also optimizes the transaction processing flow, effectively preventing over-limit transactions and ensuring the stable operation of the financial system.

[0103] In some embodiments, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions of the target transactions in the cumulative traffic table based on the transaction information of all the target transactions in the cumulative traffic table, all the traffic control rules, and the priority of each of the traffic control rules. This includes the following steps:

[0104] Step S601: Determine the transaction inspection period corresponding to the above traffic control rules;

[0105] Step S602: Determine the target transaction quantity and determine whether each of the above target transactions is a positive transaction or a negative transaction. The target transaction quantity is the number of the above target transactions in the transaction inspection period in the above flow accumulation table.

[0106] Step S603: Perform a preset calculation on all the target transactions corresponding to the transaction inspection period to obtain the cumulative flow value of the target transactions. In the case that the target transaction is a positive transaction, the preset calculation is an addition calculation. In the case that the target transaction is a negative transaction, the preset calculation is a subtraction calculation.

[0107] Step S604: Compare the above-mentioned cumulative traffic value with the maximum traffic limit of the above-mentioned traffic control rules to check if the cumulative traffic value of the above-mentioned target transaction exceeds the limit, and compare the above-mentioned target transaction quantity with the maximum transaction number limit of the above-mentioned traffic control rules to check if the cumulative number of transactions of the above-mentioned target transaction exceeds the limit.

[0108] The database sharding diagram is as follows: Figure 7 As shown, this application relates to an efficient and accurate traffic control system, the first step of which is to query the cumulative traffic information closely related to the current transaction. The traffic accumulation table, as a table involving sharding, has a large data volume and requires frequent updates and queries. Therefore, a sharding strategy is adopted to achieve efficient updates and queries under high concurrency and effectively avoid system-wide failures caused by single points of failure. Sharded databases require many configuration rules and complex judgment logic. Each sub-item in the rule needs to be judged individually. Configuration is flexible, but the logic implementation is complex. The more flexible, the more complex the code logic. Flexible configuration requires manual configuration and cannot be automatically set; limit rules or scenarios can be changed on the page, and the addition, deletion, modification, and query of rules and scenarios can all be modified on the page.

[0109] The specific search criteria are as follows:

[0110] ① Transaction flow scenario control level code: Matches the corresponding code in the rule data.

[0111] ② Hierarchical codes, such as card number, customer number, account number, etc., are uniformly identified and are consistent with the hierarchical codes in the rule data.

[0112] ③ Traffic check rule overdraft attribute code: Same as the overdraft attribute code in the rule data.

[0113] ④ Traffic inspection scenario number: matches the scenario number in the rule data.

[0114] Based on the above conditions, the system will query the cumulative traffic information. Depending on the query results, the system will adopt differentiated processing strategies:

[0115] ① If the query result is empty, that is, no matching cumulative traffic record is found, the system will directly compare the amount of the current transaction with the various limits;

[0116] ② If the query result is not empty, meaning a matching cumulative traffic record is found, the system needs to further distinguish the transaction type, such as positive or negative transactions, and based on the transaction date, such as whether it is in the same year, half-year, month, or day, to accumulate or subtract the traffic within the corresponding time period. A transaction will directly report an error once it reaches a certain limit or frequency limit.

[0117] Cumulative traffic:

[0118] In engine-based traffic management, this application first accurately determines traffic rules based on time conditions and assigns values ​​to seven key level variables (ruleDate0 to ruleDate6). These variables represent different levels of traffic control: 0 for bank level, 1 for customer level, 2 and 3 for card product level and card level respectively (traffic is accumulated to the card level), 4 for account level (traffic is accumulated to the account level), 5 for merchant category level (traffic is accumulated to the card level, but priority judgment is independent), and 6 for account product level (traffic is accumulated to the account level). These level codes provide clear guidance for subsequent traffic accumulation and control.

[0119] During the traffic accumulation phase, this application employs an intelligent and flexible accumulation logic, namely, performing a traffic table query operation to determine whether a record associated with the current transaction exists. If the query result is empty, indicating that the current transaction is the first record, the system will execute the add logic to create a brand new traffic accumulation record for the transaction. Conversely, if the query result is not empty, indicating that a historical record associated with the current transaction exists, the system will execute the update logic to update the existing traffic accumulation record. Specifically:

[0120] ① When no record is found, if the current transaction is a cancellation, return, or reversal transaction, the system will not perform any operation and will return directly. If the engine-based traffic mandatory verification flag is active, the verification will be deemed successful. If the flag is inactive, the system will compare the current transaction's recorded amount with the various limits in the rule data. If the verification passes, a new traffic accumulation record will be created; if the verification fails, the system will return an error message indicating "Engine-based traffic limit exceeded".

[0121] ② When a record is found, the system will execute a more refined flow accumulation strategy based on the transaction type (positive or negative transaction) and the transaction date.

[0122] For positive transactions, the system meticulously examines the transaction date, such as whether it falls within the same year, half-year, month, or day; it also checks if the transaction occurred on the same day. For example, if a purchase occurs, it checks if it happened on the same day as the previous transaction. If so, it first adds the transaction amount, then checks the limit, and finally records it in the database. Controlled transactions that fail are not recorded in the database. For reverse transactions, the system performs a subtraction, which does not require limit checks. However, it checks if the value after subtraction is negative, with a minimum record value of 0. Specifically, when the transaction date is the same year, half-year, month, and day, the system determines whether to directly pass the verification or add the transaction amount to the traffic accumulation table and compare it with the preset limit based on the status of the forced authorization switch. If they match, the system updates the data; otherwise, it reports an error.

[0123] For reverse transactions, the existing accumulated amount and number of transactions are reduced accordingly. No matching of positive transactions is required; the system directly performs flow reduction, decreasing the accumulated flow record by the transaction amount. Furthermore, if the current transaction date differs from the previous transaction date, the system will clear the relevant records before accumulating the flow, ensuring accurate and timely flow accumulation.

[0124] Traffic flow check:

[0125] This application relates to a traffic accumulation and inspection mechanism. After the traffic accumulation operation is completed, the system automatically initiates a traffic verification process to ensure that all transaction traffic strictly complies with multiple preset limit standards. These limit standards specifically cover multiple dimensions, including single transaction limit, daily transaction limit, monthly transaction limit, semi-annual transaction limit, and annual transaction limit, and also include corresponding transaction frequency restrictions.

[0126] If all preset limit conditions are met, the system will proceed with the accumulation or update of transaction volume normally.

[0127] Specifically, this application includes a mandatory authorization switch. When the switch is activated, the system will skip all limit verification steps and allow the transaction to proceed directly. Conversely, if the mandatory authorization switch is not activated and any transaction limit is exceeded, the system will immediately trigger an error reporting mechanism and record the error information in detail.

[0128] In summary, this application proposes an innovative flow accumulation and inspection mechanism, which enables comprehensive monitoring and management of transaction flow. This not only significantly improves the efficiency and accuracy of transaction processing but also effectively avoids potential flow over-limit risks, providing strong protection for the security and stability of financial transactions.

[0129] Exception handling:

[0130] ① No matching rule: If the transaction does not match the traffic check rule, the check will pass and subsequent processing will proceed normally.

[0131] ② Traffic check rejection: If the traffic check fails, record the reason for rejection and return relevant information for business personnel to understand the transaction details.

[0132] Traffic update:

[0133] Based on the aforementioned traffic accumulation check results, the system enters the traffic update phase. This module identifies the positive and negative types of transactions, executes differentiated accumulation value update strategies, and works in conjunction with a sharded database architecture to achieve efficient data persistence of the traffic accumulation table. The traffic update in this application adopts a bidirectional update mechanism, intelligently adjusting the traffic accumulation value according to the transaction type to ensure data real-time performance and accuracy. The specific implementation method is as follows:

[0134] ① Positive Transaction Update: Positive transactions, such as consumption, pre-authorization, cash withdrawal, and transfer, will have their transaction amount / number of transactions accumulated into the corresponding traffic control rule data accumulation value.

[0135] ② Reverse Transaction Update: Reverse transactions, such as canceling or reversing transactions, deduct the transaction amount / number of transactions from the cumulative value of the corresponding traffic control rule data.

[0136] In this embodiment, based on the transaction information of all target transactions in the traffic accumulation table, all relevant traffic control rules, and the priority among the rules, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions for the target transactions in the traffic accumulation table. The specific implementation process includes determining the transaction check period corresponding to each traffic control rule, counting the number of target transactions, and identifying whether each target transaction is a positive or negative transaction. For positive transactions, the cumulative traffic value is updated using an additive calculation; for negative transactions, a subtractive calculation is performed to dynamically reflect changes in transaction traffic. Subsequently, the updated cumulative traffic value is compared with the preset maximum traffic limit to perform an over-limit check on the cumulative traffic value of the target transactions. Simultaneously, the number of target transactions is checked to ensure that the transaction activities comply with the prescribed traffic control standards. This refined traffic control mechanism not only effectively prevents the risks caused by exceeding transaction traffic limits but also adapts to the needs of diverse transaction scenarios, improving the accuracy and efficiency of traffic control.

[0137] In some embodiments, after determining that the cumulative traffic value exceeds the limit and / or the cumulative number of transactions exceeds the limit, the method further includes: when determining that the cumulative traffic value exceeds the limit, increasing the maximum traffic limit of the corresponding traffic control rule to obtain an updated traffic limit of the traffic control rule, wherein the updated traffic limit is greater than the cumulative traffic value of the target transaction at the current time; and / or, when determining that the cumulative number of transactions exceeds the limit, increasing the maximum transaction number limit of the corresponding traffic control rule to obtain an updated transaction number limit of the traffic control rule, wherein the updated transaction number limit is greater than the cumulative number of transactions of the target transaction exceeding the limit at the current time.

[0138] In this embodiment, when the transaction traffic check determines that the cumulative traffic value exceeds the limit and / or the cumulative number of transactions exceeds the limit, the method further includes a step of dynamically adjusting the traffic control rule limits. Specifically, when the cumulative traffic value exceeds the limit, the system automatically adjusts the corresponding traffic control rules, increases the maximum traffic limit, and generates an updated traffic limit to ensure that this limit is higher than the current cumulative traffic value of the target transaction. Similarly, when the cumulative number of transactions exceeds the limit, the system also increases the maximum transaction number limit to obtain an updated transaction number limit, ensuring that its value is greater than the current cumulative number of transactions of the target transaction. Through this dynamic adjustment mechanism, the system can flexibly respond to sudden large-volume transaction scenarios while ensuring transaction compliance, avoid transaction interruptions caused by improper rule settings, and effectively improve the system's fault tolerance and business continuity.

[0139] In some embodiments, after determining the corresponding multiple traffic control rules and the priority of each of the traffic control rules based on the above traffic control scenario and the above transaction information, and before performing an over-limit check on the traffic accumulation value and transaction accumulation number of the target transaction in the traffic accumulation table according to all the above traffic control rules and the priority of each of the above traffic control rules, the above method further includes the following steps:

[0140] Step S701: If there is no matching information between the target transaction and the traffic control scenario in the traffic scenario table, store the matching information between the target transaction and the traffic control scenario in the traffic scenario table.

[0141] Step S702: Parallel verification of the rule validity status, currency code consistency, and overdraft attribute code matching degree of the above traffic control rules. The currency code consistency indicates whether the currency code of the above traffic control rules is consistent with the currency of the above target transaction. The overdraft attribute code matching degree indicates whether the overdraft attribute code of the above traffic control rules matches the current execution number of the above target transaction. If the above traffic control rules meet the second preset condition, the rule validity status of the above traffic control rules is invalid. The second preset condition is: the effective period of the above traffic control rules is empty or the current time is earlier than the effective period of the above traffic control rules; the expiration period of the above traffic control rules is empty or the current time is later than the expiration period of the above traffic control rules; and the transaction traffic scenario control level code of the above traffic control rules is empty.

[0142] In this embodiment, after determining multiple traffic control rules and their priorities based on the traffic control scenario and transaction information, and before performing over-limit checks on the cumulative traffic value and cumulative number of transactions for the target transaction, the method further includes updating the traffic scenario table and validating the rules. Specifically, if the matching information between the target transaction and the traffic control scenario cannot be found in the traffic scenario table, then the matching information will be stored in the traffic scenario table. This step ensures the coverage of the new scenario and the integrity of the database. Next, the applicability and validity of the rules are ensured by performing parallel checks on the rule validity status, currency code consistency, and overdraft attribute code matching degree of the traffic control rules. The currency code consistency check ensures that the rule matches the currency of the target transaction, while the overdraft attribute code matching degree ensures that the rule can accurately match based on the number of executions of the target transaction. It is worth noting that when a rule meets specific conditions, such as the rule's effective period being empty or the current time being earlier than the rule's effective period, the rule's expiration period being empty or the current time being later than the rule's expiration period, or the rule's transaction traffic scenario control level code being empty, these rules will be considered invalid. These steps effectively eliminate inapplicable or expired rules, ensuring the accurate application of traffic control rules and improving the reliability and efficiency of the traffic control system.

[0143] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the method for determining whether the transaction flow exceeds the limit will be described in detail below with reference to specific embodiments.

[0144] This embodiment relates to a specific method for determining whether transaction traffic has exceeded the limit, such as... Figure 8 As shown, it includes the following steps:

[0145] Step S1: Enter the transaction matching traffic control scenario and perform scenario and rule matching;

[0146] Step S2: Perform rule fusion and priority processing again;

[0147] Step S3: Perform traffic rule checks and traffic accumulation checks again;

[0148] Step S4: Finally, perform a traffic update.

[0149] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0150] This embodiment also relates to a structural block diagram of a device for determining whether transaction flow exceeds the limit, as shown in the figure. Figure 9 As shown, the system includes the following modules: Transaction Matching and Traffic Control Scenario Module: This module matches predefined traffic control scenarios based on transaction characteristics such as transaction type, amount, and channel, generates a candidate scenario set, and performs initial screening to ensure the accuracy of subsequent rule verification. Scenario and Rule Matching Module: Based on the matched traffic scenarios, this module queries rule configuration information and filters the applicable rule set for the current transaction using multi-dimensional conditions such as logical deletion flags, effective time ranges, currency types, and overdraft attributes. Rule Fusion and Priority Processing Module: This module performs conflict detection and priority sorting on multiple matched rules. Based on preset strategies such as control intensity and time priority, it merges or selects the optimal rule to ensure that the final executed rule is unambiguous and meets business control requirements. Traffic Rule Configuration and Inspection Module: This module is responsible for configuring, managing, and inspecting traffic rules, supporting multi-dimensional rule settings and inspections, such as customer level, account level, and multiple periods, such as daily, monthly, and yearly. Traffic Accumulation and Inspection Module: This module queries traffic accumulation data, performs traffic statistics and rule verification, and ensures that transaction traffic complies with preset limits. Traffic update module: Dynamically adjusts the cumulative traffic value based on transaction type (positive or negative transaction) to ensure the real-time accuracy of traffic data. Anomaly handling module: Handles anomalies where traffic validation fails, records the reason for rejection, and returns relevant information to support subsequent problem tracking and analysis.

[0151] This application also provides a device for determining whether transaction traffic exceeds the limit. It should be noted that this device can be used to execute the method provided in this application for determining whether transaction traffic exceeds the limit. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0152] The following describes the device for determining whether transaction traffic exceeds the limit provided in the embodiments of this application.

[0153] Figure 10 This is a schematic diagram of a device for determining whether transaction flow exceeds the limit according to an embodiment of this application. Figure 10 As shown, the device includes: an acquisition unit 10, a first determination unit 20, and a second determination unit 30. The acquisition unit 10 is used to acquire transaction information of a target transaction and match the corresponding traffic control scenario according to the transaction information. The transaction information includes at least the transaction region, transaction channel, and transaction type. The first determination unit 20 is used to determine multiple corresponding traffic control rules and the priority of each traffic control rule according to the traffic control scenario and the transaction information. It also performs an over-limit check on the cumulative traffic value and cumulative transaction count of the target transaction in the traffic accumulation table according to all the traffic control rules and the priority of each traffic control rule. The traffic control rules include at least the maximum transaction traffic and the maximum number of transactions of the target transaction. The second determination unit 30 is used to determine that the cumulative traffic value and the cumulative transaction count are not over-limit if both the cumulative traffic value and the cumulative transaction count satisfy all the traffic control rules. If the cumulative traffic value does not satisfy at least one of the traffic control rules and / or the cumulative transaction count does not satisfy at least one of the traffic control rules, it determines that the cumulative traffic value exceeds the limit and / or the cumulative transaction count exceeds the limit.

[0154] The device for determining whether transaction traffic exceeds limits as described in this application includes an acquisition unit, a first determination unit, and a second determination unit. The acquisition unit acquires transaction information of the target transaction and matches it with a corresponding traffic control scenario. The transaction information includes at least the transaction region, transaction channel, and transaction type. The first determination unit determines multiple corresponding traffic control rules and their priorities based on the traffic control scenario and transaction information. It then checks the cumulative traffic value and cumulative transaction count of the target transaction in the traffic accumulation table for exceeding limits based on all traffic control rules and their priorities. The traffic control rules include at least the maximum transaction traffic and the maximum number of transactions for the target transaction. The second determination unit determines that the cumulative traffic value and cumulative transaction count are within limits if both meet all traffic control rules, and determines that the cumulative traffic value and / or the cumulative transaction count exceed limits if the cumulative traffic value does not meet at least one traffic control rule and / or the cumulative transaction count does not meet at least one traffic control rule. This device achieves efficient, flexible, and scalable traffic control, solving the problems of performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies.

[0155] In some embodiments, the acquisition unit includes a first determining module and a second determining module. The first determining module is used to determine control identification codes for multiple screening levels based on the transaction information of the target transaction. These multiple screening levels include a transaction region layer, a transaction channel layer, a transaction type layer, a transaction method layer, and an identification factor layer. The identification factor layer is a screening level based on the identification factors of the target transaction. The identification factors at least characterize the transaction data of the target transaction. The total length of the control identification code represents the total number of all level types corresponding to the screening level. Each digit of the control identification code represents whether the corresponding level type needs to be controlled. The second determining module is used to determine the traffic control scenario corresponding to the transaction information based on the control identification codes of all the screening levels. This improves the security and compliance of transaction processing.

[0156] In some embodiments, the first determining unit includes a third determining module and a fourth determining module. The third determining module is used to retain the traffic control rules that meet a first preset condition and remove the traffic control rules that do not meet the first preset condition when multiple traffic control rules have the same priority. The first preset condition is the smallest traffic limit value and the smallest transaction count limit. The fourth determining module is used to perform the above-mentioned over-limit checks on the above-mentioned cumulative traffic value and the above-mentioned cumulative transaction count using the above-mentioned traffic control rules in order of priority from low to high. The over-limit checks include whether the above-mentioned cumulative traffic value exceeds the limit and whether the above-mentioned cumulative transaction count exceeds the limit. This improves the flexibility and efficiency of traffic control, ensures that transactions proceed smoothly under the restrictions of traffic rules, and also reduces the complexity of system maintenance and updates.

[0157] In some embodiments, the first determining unit further includes a fifth determining module, a first obtaining module, a sixth determining module, and a seventh determining module. The fifth determining module is used to determine the transaction scenario code, rule level code, and overdraft attribute code based on all the above-mentioned traffic control rules and the priority of each of the above-mentioned traffic control rules. The rule level code represents the priority of the above-mentioned traffic control rules. The first obtaining module is used to perform a transaction query in the above-mentioned traffic accumulation table based on the above-mentioned transaction scenario code, the above-mentioned rule level code, and the above-mentioned overdraft attribute code to obtain the query result. The sixth determining module is used to determine that the above-mentioned target transaction is the first transaction when the above-mentioned query result is an empty set, and directly compare the traffic accumulation value and transaction accumulation number of the above-mentioned target transaction with the traffic limit value and transaction number limit in all the above-mentioned traffic control rules. The seventh determining module is used to perform an over-limit check on the traffic accumulation value and transaction accumulation number of the above-mentioned target transaction in the traffic accumulation table based on the transaction information of all the above-mentioned target transactions in the above-mentioned traffic accumulation table, all the above-mentioned traffic control rules, and the priority of each of the above-mentioned traffic control rules when the above-mentioned query result is not an empty set. It improved the accuracy of traffic control and optimized the transaction processing flow, effectively preventing excessive transactions and ensuring the stable operation of the financial system.

[0158] In some embodiments, the seventh determining module includes an eighth determining module, a ninth determining module, a tenth determining module, and an eleventh determining module. The eighth determining module is used to determine the transaction inspection period corresponding to the above-mentioned traffic control rules; the ninth determining module is used to determine the target transaction quantity and determine whether each of the above-mentioned target transactions is a positive transaction or a negative transaction, wherein the target transaction quantity is the number of the above-mentioned target transactions in the above-mentioned traffic accumulation table within the above-mentioned transaction inspection period; the tenth determining module is used to perform a preset calculation on all the above-mentioned target transactions corresponding to the above-mentioned transaction inspection period to obtain the above-mentioned traffic accumulation value of the above-mentioned target transactions, wherein, when the above-mentioned target transaction is the above-mentioned positive transaction, the above-mentioned preset calculation is an additive calculation, and when the above-mentioned target transaction is the above-mentioned negative transaction, the above-mentioned preset calculation is a subtractive calculation; the eleventh determining module is used to compare the above-mentioned traffic accumulation value with the size of the maximum traffic limit of the above-mentioned traffic control rules to perform an over-limit check on the traffic accumulation value of the above-mentioned target transactions, and to compare the above-mentioned target transaction quantity with the size of the size of the maximum transaction number limit of the above-mentioned traffic control rules to perform an over-limit check on the cumulative number of transactions of the above-mentioned target transactions. This not only effectively prevents the risks caused by transaction traffic exceeding limits, but also adapts to the needs of diverse transaction scenarios, improving the accuracy and efficiency of traffic control.

[0159] In some embodiments, the above-mentioned apparatus further includes a twelfth determining module and a thirteenth determining module. The twelfth determining module is used to, after determining that the cumulative traffic value exceeds the limit and / or the cumulative number of transactions exceeds the limit, increase the maximum traffic limit of the corresponding traffic control rule to obtain an updated traffic limit for the traffic control rule, wherein the updated traffic limit is greater than the cumulative traffic value of the target transaction at the current time. The thirteenth determining module is used to, after determining that the cumulative number of transactions exceeds the limit, increase the maximum transaction number limit of the corresponding traffic control rule to obtain an updated transaction number limit for the traffic control rule, wherein the updated transaction number limit is greater than the cumulative number of transactions of the target transaction exceeding the limit at the current time. This effectively improves the system's fault tolerance and business continuity.

[0160] In some embodiments, the above-described apparatus further includes a fourteenth determining module and a fifteenth determining module. The fourteenth determining module is used to, after determining the corresponding multiple traffic control rules and the priority of each of the traffic control rules according to the traffic control scenario and the transaction information, and before performing an over-limit check on the traffic accumulation value and transaction accumulation number of the target transaction in the traffic accumulation table according to all the traffic control rules and the priority of each of the traffic control rules, store the matching information between the target transaction and the traffic control scenario in the traffic scenario table if there is no matching information between the target transaction and the traffic control scenario in the traffic scenario table. The fifteenth determining module is used to verify the rule validity status and currency of the traffic control rules in parallel. Code consistency and overdraft attribute code matching are assessed. The currency code consistency indicates whether the currency code of the traffic control rule matches the currency of the target transaction. The overdraft attribute code matching indicates whether the overdraft attribute code of the traffic control rule matches the current execution count of the target transaction. If the traffic control rule meets a second preset condition, its effective state is invalid. The second preset condition is: the effective period of the traffic control rule is empty or the current time is earlier than the effective period of the traffic control rule; the expiration period of the traffic control rule is empty or the current time is later than the expiration period of the traffic control rule; and the transaction traffic scenario control level code of the traffic control rule is empty. This ensures the accurate application of traffic control rules and improves the reliability and efficiency of the traffic control system.

[0161] The device for determining whether the transaction flow exceeds the limit includes a processor and a memory. The determining units are all stored as program units in the memory, and the processor executes these program units to achieve the corresponding functions. All of the above modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0162] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies.

[0163] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0164] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to execute a method for determining whether the transaction flow exceeds the limit.

[0165] This invention provides a processor for running a program, wherein the program executes a method for determining whether the transaction flow exceeds the limit.

[0166] This invention provides a device comprising one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include steps for implementing the method for determining whether transaction traffic exceeds limits. The device described herein may be a server, PC, PAD, mobile phone, etc.

[0167] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform a method step of initializing a determination of whether at least the transaction flow exceeds a limit.

[0168] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0169] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0170] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0171] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0172] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0173] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0174] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0175] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0176] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0177] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0178] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0179] The method for determining whether transaction traffic exceeds limits as described in this application first obtains the transaction information of the target transaction and matches it with the corresponding traffic control scenario. The transaction information includes at least the transaction region, transaction channel, and transaction type. Based on the traffic control scenario and transaction information, multiple corresponding traffic control rules and their priorities are determined. Then, based on all traffic control rules and their priorities, the cumulative traffic value and cumulative number of transactions for the target transaction in the traffic accumulation table are checked for exceeding limits. The traffic control rules include at least the maximum transaction traffic and the maximum number of transactions for the target transaction. If both the cumulative traffic value and the cumulative number of transactions satisfy all traffic control rules, it is determined that the cumulative traffic value and the cumulative number of transactions have not exceeded limits. If the cumulative traffic value does not satisfy at least one traffic control rule and / or the cumulative number of transactions does not satisfy at least one traffic control rule, it is determined that the cumulative traffic value and / or the cumulative number of transactions have exceeded limits. This method achieves efficient, flexible, and scalable traffic control, solving the problems of performance bottlenecks, poor scalability, complex rule management, and low traffic accumulation efficiency in existing traffic control technologies.

[0180] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining whether transaction flow exceeds the limit, characterized in that, include: Obtain transaction information of the target transaction and match the corresponding traffic control scenario based on the transaction information. The transaction information includes at least the transaction region, transaction channel, and transaction type. Based on the traffic control scenario and the transaction information, multiple corresponding traffic control rules and the priority of each traffic control rule are determined. Based on all the traffic control rules and the priority of each traffic control rule, the traffic accumulation value and transaction accumulation number of the target transaction in the traffic accumulation table are checked for exceeding the limit. The traffic control rules include at least the maximum transaction traffic and the maximum transaction number of the target transaction. If both the cumulative traffic value and the cumulative number of transactions satisfy all the traffic control rules, it is determined that the cumulative traffic value and the cumulative number of transactions have not exceeded the limits. If the cumulative traffic value does not satisfy at least one of the traffic control rules and / or the cumulative number of transactions does not satisfy at least one of the traffic control rules, it is determined that the cumulative traffic value has exceeded the limits and / or the cumulative number of transactions has exceeded the limits.

2. The method according to claim 1, characterized in that, Matching the corresponding traffic control scenarios based on the transaction information includes: Based on the transaction information of the target transaction, control identification codes for multiple screening levels are determined. The multiple screening levels include a transaction region layer, a transaction channel layer, a transaction type layer, a transaction method layer, and an identification factor layer. The identification factor layer is a screening level that filters based on the identification factors of the target transaction. The identification factors are used to characterize at least the transaction data of the target transaction. The total length of the control identification code represents the total number of all level types of the corresponding screening level. Each digit of the control identification code represents whether the corresponding level type needs to be controlled. Based on the control identifier codes of all the filtering levels, the traffic control scenario corresponding to the transaction information is determined.

3. The method according to claim 1, characterized in that, Based on all the aforementioned traffic control rules and their respective priorities, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions for the target transaction in the traffic accumulation table, including: If multiple traffic control rules have the same priority, the traffic control rules that meet the first preset condition will be retained, and the traffic control rules that do not meet the first preset condition will be removed. The first preset condition is that the traffic limit value is the smallest and the transaction number limit is the smallest. The traffic control rules are applied sequentially in order of priority from low to high to perform the over-limit checks on the cumulative traffic value and the cumulative number of transactions. The over-limit checks include whether the cumulative traffic value and the cumulative number of transactions exceed the limit.

4. The method according to claim 1, characterized in that, Based on all the aforementioned traffic control rules and their respective priorities, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions for the target transaction in the traffic accumulation table, including: Based on all the traffic control rules and the priority of each traffic control rule, determine the transaction scenario code, rule level code, and overdraft attribute code, whereby the rule level code represents the priority of the traffic control rule. Based on the transaction scenario code, the rule level code, and the overdraft attribute code, a transaction query is performed in the traffic accumulation table to obtain the query results; If the query result is an empty set, the target transaction is determined to be the first transaction, and the cumulative traffic value and cumulative number of transactions of the target transaction are directly compared with the traffic limit value and transaction number limit in all the traffic control rules; If the query result is a non-empty set, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions of the target transaction in the cumulative traffic table based on the transaction information of all the target transactions in the cumulative traffic table, all the traffic control rules, and the priority of each traffic control rule.

5. The method according to claim 4, characterized in that, Based on the transaction information of all target transactions in the traffic accumulation table, all traffic control rules, and the priority of each traffic control rule, an over-limit check is performed on the cumulative traffic value and cumulative number of transactions of the target transactions in the traffic accumulation table, including: Determine the transaction inspection period corresponding to the traffic control rules; Determine the target transaction quantity, and determine whether each target transaction is a positive transaction or a negative transaction. The target transaction quantity is the number of target transactions within the transaction inspection period in the traffic accumulation table. A preset calculation is performed on all the target transactions corresponding to the transaction inspection period to obtain the cumulative traffic value of the target transactions. Wherein, when the target transaction is the positive transaction, the preset calculation is an addition calculation, and when the target transaction is the negative transaction, the preset calculation is a subtraction calculation. The cumulative traffic value is compared with the maximum traffic limit of the traffic control rule to check if the cumulative traffic value of the target transaction exceeds the limit, and the number of target transactions is compared with the maximum number of transactions limit of the traffic control rule to check if the cumulative number of transactions of the target transaction exceeds the limit.

6. The method according to claim 1, characterized in that, After determining that the cumulative traffic value has exceeded the limit and / or the cumulative number of transactions has exceeded the limit, the method further includes: If it is determined that the cumulative traffic value exceeds the limit, the maximum traffic limit of the corresponding traffic control rule is increased to obtain the updated traffic limit of the traffic control rule, wherein the updated traffic limit is greater than the cumulative traffic value of the target transaction at the current time. And / or, If it is determined that the cumulative number of transactions exceeds the limit, the maximum transaction limit of the corresponding traffic control rule is increased to obtain the update transaction limit of the traffic control rule, wherein the update transaction limit is greater than the cumulative number of transactions of the target transaction exceeding the limit at the current time.

7. The method according to any one of claims 1 to 6, characterized in that, After determining multiple corresponding traffic control rules and their priorities based on the traffic control scenario and the transaction information, and before performing an over-limit check on the cumulative traffic value and cumulative number of transactions of the target transaction in the traffic accumulation table based on all the traffic control rules and their priorities, the method further includes: If no matching information exists between the target transaction and the traffic control scenario in the traffic scenario table, the matching information between the target transaction and the traffic control scenario is stored in the traffic scenario table. The validity status, currency code consistency, and overdraft attribute code matching degree of the traffic control rule are verified in parallel. The currency code consistency indicates whether the currency code of the traffic control rule is consistent with the currency of the target transaction. The overdraft attribute code matching degree indicates whether the overdraft attribute code of the traffic control rule matches the current execution number of the target transaction. If the traffic control rule meets a second preset condition, the validity status of the traffic control rule is invalid. The second preset condition is: the effective period of the traffic control rule is empty or the current time is earlier than the effective period of the traffic control rule; the expiration period of the traffic control rule is empty or the current time is later than the expiration period of the traffic control rule; and the transaction traffic scenario control level code of the traffic control rule is empty.

8. A device for determining whether a transaction flow exceeds a limit, characterized in that, include: The acquisition unit is used to acquire transaction information of the target transaction and match the corresponding traffic control scenario based on the transaction information. The transaction information includes at least the transaction region, transaction channel and transaction type. The first determining unit is configured to determine multiple corresponding traffic control rules and the priority of each traffic control rule according to the traffic control scenario and the transaction information, and to perform an over-limit check on the cumulative traffic value and cumulative number of transactions of the target transaction in the traffic accumulation table according to all the traffic control rules and the priority of each traffic control rule. The traffic control rules include at least the maximum transaction traffic and the maximum number of transactions of the target transaction. The second determining unit is configured to determine that the cumulative traffic value and the cumulative number of transactions have not exceeded the limit if both the cumulative traffic value and the cumulative number of transactions satisfy all the traffic control rules, and to determine that the cumulative traffic value and / or the cumulative number of transactions have exceeded the limit if the cumulative traffic value does not satisfy at least one of the traffic control rules and / or the cumulative number of transactions does not satisfy at least one of the traffic control rules.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the method for determining whether the transaction flow exceeds the limit as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a method for performing a determination method for whether the transaction flow is exceeded as described in any one of claims 1 to 7.

Images