Transaction early warning generation method and system based on rule engine

Abstract

The application discloses a transaction early warning generation method and system based on a rule engine, relates to the technical field of transaction early warning, and has the technical scheme as follows: target transaction data is dynamically collected from a plurality of heterogeneous external data sources; the target transaction data is standardized to generate to-be-analyzed data; early warning rules are configured according to the target transaction data; wherein the early warning rules at least include differentiated trigger conditions based on transaction dimensions and early warning levels associated with the trigger conditions; the to-be-analyzed data is input into a rule engine and matched with the early warning rules in real time; when the to-be-analyzed data meets the early warning rules, the rule engine generates and outputs early warning information containing early warning levels according to the early warning rules, so that the transaction early warning system can continuously adapt to business development requirements.

Description

Technical Field

[0001] This invention relates to the field of transaction alert technology, and more specifically, to a method and system for generating transaction alerts based on a rule engine. Background Technology

[0002] Traditional transaction early warning methods are ill-suited to increasingly complex business scenarios and risk control needs. They fail to adequately consider the differences in transaction regions, transaction methods, and transaction varieties, and apply uniform thresholds to all transaction scenarios. This can easily lead to missed warnings in high-risk scenarios and frequent false alarms in low-risk scenarios. They cannot accurately capture core risks, increase the handling burden on operations and maintenance personnel, and are prone to data processing delays during peak transaction periods. They cannot meet the timeliness requirements of real-time risk control, and the lack of hierarchical management of early warning information makes it impossible to distinguish the severity of risks, resulting in unreasonable allocation of handling resources. Summary of the Invention

[0003] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a transaction early warning generation method and system based on a rule engine.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A method for generating transaction alerts based on a rules engine, comprising the following steps:

[0006] Target transaction data is dynamically collected from multiple heterogeneous external data sources; the target transaction data is standardized to generate data to be analyzed.

[0007] Configure early warning rules based on target transaction data; wherein, the early warning rules include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions;

[0008] After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time. When the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information containing the warning level according to the warning rules.

[0009] Preferably, target transaction data is dynamically collected from multiple heterogeneous external data sources, specifically including the following steps:

[0010] Connect to data sources with different protocols via a pre-defined data source connector;

[0011] According to the collection template configured in the visualization, target transaction data for specified fields are collected from the data source. The collection template includes at least the data source, field mapping relationship and collection frequency.

[0012] Preferably, the target transaction data is standardized to generate data to be analyzed, specifically as follows:

[0013] The data collection template predefines cleaning rules;

[0014] The initial target transaction data is cleaned according to the cleaning rules to generate data to be analyzed; wherein, the cleaning rules include deduplication, null value processing and format conversion.

[0015] Preferably, it further includes:

[0016] The differentiated triggering conditions include thresholds set for different combinations of trading dimensions; wherein, the trading dimensions include trading region, trading method, and trading instrument.

[0017] Preferably, the data to be analyzed is input into the rule engine and then matched with the early warning rules in real time, specifically including the following steps:

[0018] Compile the warning rules into rule objects that the rule engine can recognize;

[0019] The data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects.

[0020] Preferably, the early warning rules are compiled into rule objects that the rule engine can recognize, specifically including the following steps:

[0021] The early warning rules are broken down into layers to form a layered logical decomposition result;

[0022] Logical association tags are applied to the results of hierarchical logic decomposition to obtain a hierarchical logic structure with association tags;

[0023] The hierarchical logical structure with associated tags is processed to obtain the rule object recognized by the rule engine.

[0024] Preferably, the early warning rules are compiled into rule objects that the rule engine can recognize, specifically including the following steps:

[0025] The early warning rules are broken down into layers to form a layered logical decomposition result;

[0026] Logical association tags are applied to the results of hierarchical logic decomposition to obtain a hierarchical logic structure with association tags;

[0027] The hierarchical logical structure with associated tags is processed to obtain the rule object recognized by the rule engine.

[0028] Preferably, the data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects. This specifically includes the following steps:

[0029] Extract the target analysis field from the data to be analyzed, and generate the field parsing result after confirming that the target analysis field is consistent with the preset matching field dimension of the rule object;

[0030] Based on the field parsing results, the data to be analyzed is format-standardized to generate a standardized set of fields to be analyzed.

[0031] After determining whether the standardized fields to be analyzed meet the matching requirements, the real-time matching evaluation results are output.

[0032] Preferably, the method further includes the following steps:

[0033] Configure the rules engine using parameters;

[0034] The parameterized configuration includes setting the warning priority.

[0035] A rules-based transaction alert generation system includes:

[0036] Data acquisition configuration module: dynamically acquires target transaction data from multiple heterogeneous external data sources; standardizes the target transaction data to generate data to be analyzed;

[0037] Early warning rule configuration module: Configures early warning rules based on target transaction data; wherein, the early warning rules include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions;

[0038] Rule engine processing module: After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time; when the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information including the warning level according to the warning rules.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] This invention dynamically collects target transaction data from multiple heterogeneous external data sources, integrating transaction information from different systems and channels. It standardizes the target transaction data, unifying the format and language of different data sources, improving data quality, reducing false alarms caused by data inconsistencies, and ensuring the accuracy of early warning judgments. By setting differentiated thresholds for different transaction dimensions, it matches the risk characteristics of different business scenarios. This allows for timely detection of abnormal transactions in high-risk scenarios while reducing false alarms in low-risk scenarios, improving the targeting and effectiveness of early warnings. The associated warning levels clearly define the severity of the risk. Relying on a rule engine, it achieves real-time matching between the data to be analyzed and the warning rules, ensuring the timeliness and efficiency of early warnings. The rule engine quickly loads and executes warning rules, promptly completing risk assessment after a transaction occurs, generating and outputting warning information including the warning level, enabling early risk detection and intervention. It also enhances flexibility and scalability, reduces maintenance costs, and allows the transaction early warning system to continuously adapt to business development needs. Attached Figure Description

[0041] Figure 1 A schematic diagram illustrating the steps of a transaction alert generation method based on a rule engine, as provided in an embodiment of the present invention;

[0042] Figure 2 A schematic diagram of a transaction alert generation system based on a rule engine is provided for embodiments of the present invention. Detailed Implementation

[0043] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0044] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0045] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0046] Reference Figures 1-2 As shown.

[0047] The embodiments further illustrate the transaction early warning generation method and system based on the rule engine proposed in this invention.

[0048] A method for generating transaction alerts based on a rules engine, comprising the following steps:

[0049] Target transaction data is dynamically collected from multiple heterogeneous external data sources; the target transaction data is standardized to generate data to be analyzed.

[0050] Configure early warning rules based on target transaction data; wherein, the early warning rules shall include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions;

[0051] After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time. When the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information containing the warning level according to the warning rules.

[0052] Dynamically collecting target transaction data from multiple heterogeneous external data sources specifically includes the following steps:

[0053] Connect to data sources with different protocols via a pre-defined data source connector;

[0054] Based on the collection template configured in the visualization, target transaction data for specified fields are collected from the data source. The collection template includes at least the data source, field mapping relationship, and collection frequency.

[0055] By using pre-defined data source connectors to interface with data sources of different protocols, these connectors adapt to different types of data source protocols and can establish connection channels with various external data sources. For example, they adapt to dedicated connection protocols for relational databases, file transfer protocols for file service data sources, and network request protocols for open interface data sources, ensuring that data sources with different architectures and transmission methods can be effectively accessed.

[0056] The collection of target transaction data is carried out using visually configurable collection templates, with template parameters set according to actual needs. Each collection template must contain at least the target transaction data and include at least the data source, field mapping relationships, and collection frequency. The data source is used to identify the specific data source object from which data needs to be collected, such as specifying a database table in a bank's transaction system or a transaction data interface of an e-commerce platform. The field mapping relationship is used to associate fields with varying formats and names from external data sources with standard fields; for example, mapping the transaction location field from an external data source to the transaction region field within the system, ensuring a consistent standard for data collected from different data sources. The collection frequency setting allows for real-time or scheduled collection based on business needs; for example, setting second-level real-time collection for high-frequency trading scenarios and daily scheduled collection for statistical analysis scenarios. This template configuration enables the extraction of target transaction data with specified fields from data sources, ensuring targeted and efficient data collection while adapting to the collection needs of different business scenarios, achieving dynamic and standardized collection of multi-source heterogeneous transaction data.

[0057] The target transaction data is standardized to generate data to be analyzed, specifically as follows:

[0058] Predefined cleaning rules for the collection template;

[0059] The initial target transaction data is cleaned according to the cleaning rules to generate data to be analyzed; the cleaning rules include deduplication, null value processing and format conversion.

[0060] Cleaning rules are predefined in the data collection template. These rules are set specifically for the business characteristics and analysis needs of the transaction data to ensure that the data processing direction is consistent with the requirements of subsequent early warning analysis.

[0061] The data cleaning rules include deduplication, null value handling, and format conversion rules. Deduplication rules identify and remove duplicate records from the initial target transaction data, preventing the same transaction data from being collected or stored repeatedly. For example, if the same transaction is repeatedly pushed due to network latency, duplicate entries are identified based on the transaction's unique identifier, and only one valid entry is retained, ensuring data uniqueness and accuracy. Null value handling rules address missing fields in the initial data. Appropriate processing methods are selected based on business needs, such as completing or marking null values ​​in key transaction fields, and filtering or filling null values ​​in non-core fields with default values, preventing alerts from failing due to missing data. Format conversion rules standardize the format of data collected from different data sources, converting heterogeneous time formats, numerical formats, and text formats into a recognized standard format.

[0062] Based on these rules, the initially collected target transaction data is automatically cleaned. During the process, deduplication, null value processing, and format conversion are performed sequentially to gradually remove invalid data, fill in missing information, and unify data format, ultimately generating clean, standardized, and uniform data to be analyzed.

[0063] Also includes:

[0064] Differentiated trigger conditions include thresholds set for different combinations of trading dimensions; among which, trading dimensions include trading region, trading method, and trading instrument.

[0065] By setting thresholds for different combinations of transaction dimensions, early warning judgments are made more closely aligned with actual business scenarios. Transaction dimensions include transaction region, transaction method, and transaction type. The transaction region is used to differentiate the transaction characteristics of different areas. Market conditions, policy requirements, and transaction activity vary across regions; therefore, early warning thresholds are set for different regions. For example, the price thresholds for similar transactions in core urban areas differ from those in remote suburbs to adapt to different regional market patterns. The transaction method dimension corresponds to different transaction execution paths, such as online transactions, offline transactions, batch transactions, and single transactions. Differentiated thresholds are set based on the risk characteristics of each transaction method. For example, stricter thresholds are set for batch transactions to prevent risks associated with large-scale operations. The transaction type dimension focuses on the category of the transaction object. Different types of instruments have different trading patterns and risk levels. For example, the trading volume and price fluctuation thresholds of high-value instruments differ significantly from those of ordinary circulating instruments to match the business characteristics of different instruments.

[0066] In practical configuration, these three transaction dimensions are freely combined to form specific business scenarios. For each scenario, a corresponding trigger threshold is set. For example, a stricter price fluctuation threshold is set for high-value commodities traded offline in remote areas, while a relatively lenient threshold is set for ordinary commodities traded online in core urban areas. This method of combining dimensions and differentiating thresholds allows the alert rules to match the risk characteristics of different business scenarios, improving the targeting and effectiveness of alerts. It can capture abnormal transactions in high-risk scenarios while preventing low-risk scenarios from being misjudged and triggering alerts.

[0067] After the data to be analyzed is input into the rule engine, it is matched with the early warning rules in real time. The specific steps include:

[0068] The process of compiling alert rules into rule objects that the rule engine can recognize includes the following steps:

[0069] The early warning rules are broken down into layers to form a layered logical decomposition result;

[0070] Logical association tags are applied to the results of hierarchical logic decomposition to obtain a hierarchical logic structure with association tags;

[0071] The hierarchical logical structure with associated tags is processed to obtain the rule object that the rule engine can recognize;

[0072] The data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects.

[0073] The configured early warning rules are broken down into hierarchical units, dividing the original complete business rules into multiple levels of logical units. After the hierarchical decomposition, the logical decomposition results at each level are logically associated and marked to clarify the dependencies and execution order between different logical units. For example, marking a threshold judgment logic as requiring execution only after the corresponding transaction dimension matching logic is completed, and marking an early warning level associated logic as requiring triggering only when all threshold judgment logics are satisfied. This association marking forms a hierarchical logical structure with association markings, ensuring that the rule logic will not have problems with disordered order or logical omissions during execution.

[0074] The hierarchical logical structure with associated tags is further processed and encapsulated into rule objects that the rule engine can directly recognize. The hierarchical logical structure is transformed into executable code or data structures that conform to the rule engine's syntax specifications, so that the rule engine can directly load and parse these rule objects.

[0075] The standardized data to be analyzed is input into the rule engine, which loads the compiled rule objects and performs real-time matching and evaluation of the data according to the order and dependencies defined by the logical association tags. It verifies whether the data meets the various logical conditions defined by the rule objects one by one, and finally outputs the matching results, providing a basis for the generation of subsequent early warning information. The whole process not only ensures the accuracy and efficiency of rule execution, but also decouples business rules from execution logic.

[0076] The process of compiling alert rules into rule objects that the rule engine can recognize includes the following steps:

[0077] The early warning rules are broken down into layers to form a layered logical decomposition result;

[0078] Logical association tags are applied to the results of hierarchical logic decomposition to obtain a hierarchical logic structure with association tags;

[0079] The hierarchical logical structure with associated tags is processed to obtain the rule object recognized by the rule engine.

[0080] This technical solution compiles early warning rules into rule objects that a rule engine can recognize. Through layered decomposition, logical association marking, and structured processing, business-oriented early warning rules are transformed into machine-executable logical units. The early warning rules are decomposed into multiple levels of logical fragments, thus forming a layered logical decomposition result. The rules are divided according to their inherent logical structure. For example, complex rules that include transaction dimension matching, threshold judgment, and early warning level association are decomposed into logical units of basic dimension matching layer, threshold verification layer, and result association layer, making the originally abstract business rules clear and organized.

[0081] After completing the layered decomposition, the logical decomposition results of each layer are logically associated and marked to clarify the dependencies and execution order between different logical units, thus obtaining a layered logical structure with associated tags. The sequential triggering relationship of each level of logic is clearly defined. For example, marking a threshold verification logic as requiring execution only after the corresponding transaction dimension matching logic is completed, or marking a warning level-related logic as requiring triggering only when all threshold verification logics meet their conditions, ensures that the rule logic does not experience sequential confusion or logical omissions during execution, making the rule execution process more rigorous and controllable.

[0082] The hierarchical logical structure with associated tags is further processed and encapsulated into rule objects that the rule engine can directly recognize. This hierarchical logical structure is transformed into executable data structures or code units that conform to the rule engine's syntax specifications, achieving a seamless conversion from business logic to machine-executable logic. This allows the rule engine to directly load and parse the rule objects, enabling efficient execution and real-time matching of alert rules.

[0083] The data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects. This process includes the following steps:

[0084] Extract the target analysis field from the data to be analyzed, and generate the field parsing result after confirming that the target analysis field is consistent with the preset matching field dimension of the rule object;

[0085] Based on the field parsing results, the data to be analyzed is format-standardized to generate a standardized set of fields to be analyzed.

[0086] After determining whether the standardized fields to be analyzed meet the matching requirements, the real-time matching evaluation results are output.

[0087] The target analysis fields are extracted from the data to be analyzed. These target analysis fields are core data items directly related to the preset matching fields of the alert rules, including transaction amount, transaction time, and transaction region. During the extraction process, the consistency of the dimensions of the target analysis fields and the preset matching fields in the rule object is simultaneously verified, ensuring that the field names, types, and business definitions remain consistent. If there are dimensional differences, adjustments are made to adapt them, ultimately generating standardized field parsing results.

[0088] Based on the field parsing results, the data to be analyzed undergoes in-depth format standardization processing. For the extracted target analysis fields, the format differences left over from different data sources are eliminated. For example, transaction amounts in different formats are uniformly converted into a standard numerical format, various time expressions are uniformly converted into a unified timestamp format, and text fields are uniformly standardized into a standard character format. Through standardization processing, matching errors caused by chaotic data formats are eliminated, and finally a standardized set of fields to be analyzed with a unified structure and clear definition is generated, ensuring that the format of the data to be analyzed is fully adapted to the parsing requirements of the rule engine.

[0089] Based on a standardized set of fields to be analyzed, the system performs matching and verification against the rule objects of the rule engine. The rule engine compares each standardized field to be analyzed according to the preset rule logic to see if it meets the triggering conditions defined in the rule, including numerical threshold matching, dimension matching, and logical relationship matching. After completing the determination of all verification items, it outputs a clear real-time matching evaluation result.

[0090] It also includes the following steps:

[0091] Configure the rules engine using parameters;

[0092] The parameterized configuration includes setting the alert priority.

[0093] The parameterized configuration of the rules engine allows managers to customize the operation logic and early warning processing flow of the rules engine according to business needs and risk control strategies. This configuration method does not require modification of the underlying code, thus adapting to the risk control requirements at different stages.

[0094] Different types or levels of early warning rules are assigned corresponding priority labels. The priority is directly related to the degree of risk of the warning. For example, early warning rules involving large abnormal transactions or high-risk areas are set to the highest priority, while early warning rules for ordinary volatile transactions are set to a lower priority. The rule engine sorts early warning information according to the preset priority, prioritizing the push of high-priority early warning information to the processing terminal. This ensures that high-risk transactions can be detected and processed as soon as possible, avoiding delays in handling high-risk events due to the accumulation of early warning information. Priority configuration affects the notification method and processing flow of early warning information. High-priority early warnings trigger more urgent notification channels and stricter processing time requirements, while low-priority early warnings are processed according to the regular process. This achieves reasonable allocation of early warning resources and improves the accuracy and efficiency of overall risk prevention and control. It ensures both the orderly processing of early warnings and the differentiated management of risk disposal, making the transaction early warning system more flexible and efficient.

[0095] A rules-based transaction alert generation system includes:

[0096] Data acquisition configuration module: dynamically acquires target transaction data from multiple heterogeneous external data sources; standardizes the target transaction data to generate data to be analyzed;

[0097] Early warning rule configuration module: Configures early warning rules based on target transaction data; wherein, the early warning rules include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions;

[0098] Rule engine processing module: After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time; when the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information including the warning level according to the warning rules.

[0099] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0101] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A transaction alert generation method based on a rule engine, characterized in that, The method includes the following steps: Target transaction data is dynamically collected from multiple heterogeneous external data sources; the target transaction data is standardized to generate data to be analyzed. Configure early warning rules based on target transaction data; wherein, the early warning rules include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions; After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time. When the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information containing the warning level according to the warning rules.

2. The transaction alert generation method based on a rule engine according to claim 1, characterized in that, Dynamically collecting target transaction data from multiple heterogeneous external data sources specifically includes the following steps: Connect to data sources with different protocols via a pre-defined data source connector; According to the collection template configured in the visualization, target transaction data for specified fields are collected from the data source. The collection template includes at least the data source, field mapping relationship and collection frequency.

3. The transaction alert generation method based on a rule engine according to claim 2, characterized in that, The target transaction data is standardized to generate data to be analyzed, specifically as follows: The data collection template predefines cleaning rules; The initial target transaction data is cleaned according to the cleaning rules to generate data to be analyzed; wherein, the cleaning rules include deduplication, null value processing and format conversion.

4. The transaction alert generation method based on a rule engine according to claim 1, characterized in that, Also includes: The differentiated triggering conditions include thresholds set for different combinations of trading dimensions; wherein, the trading dimensions include trading region, trading method, and trading instrument.

5. The transaction alert generation method based on a rule engine according to claim 1, characterized in that, After the data to be analyzed is input into the rule engine, it is matched with the early warning rules in real time. The specific steps include: Compile the warning rules into rule objects that the rule engine can recognize; The data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects.

6. The transaction alert generation method and system based on a rule engine according to claim 5, characterized in that, The process of compiling alert rules into rule objects that the rule engine can recognize includes the following steps: The early warning rules are broken down into layers to form a layered logical decomposition result; Logical association tags are applied to the results of hierarchical logic decomposition to obtain a hierarchical logic structure with association tags; The hierarchical logical structure with associated tags is processed to obtain the rule object recognized by the rule engine.

7. The transaction alert generation method based on a rule engine according to claim 6, characterized in that, The hierarchical logical structure with associated tags is processed to obtain the rule object recognized by the rule engine. This process includes the following steps: A basic framework is built based on a hierarchical logical structure with associated tags. The logical nodes of the triggering logic layer are embedded into the triggering units of the basic framework, and the warning levels and linkage identifiers of the hierarchical association layer are embedded into the hierarchical association units of the basic framework to form preliminary rule objects. The initial rule object is subjected to adaptation processing to obtain the rule object recognized by the rule engine.

8. The transaction alert generation method based on a rule engine according to claim 7, characterized in that, The data to be analyzed is input into the rule engine, which then performs real-time matching and evaluation based on the rule objects. This process includes the following steps: Extract the target analysis field from the data to be analyzed, and generate the field parsing result after confirming that the target analysis field is consistent with the preset matching field dimension of the rule object; Based on the field parsing results, the data to be analyzed is format-standardized to generate a standardized set of fields to be analyzed. After determining whether the standardized fields to be analyzed meet the matching requirements, the real-time matching evaluation results are output.

9. The transaction alert generation method based on a rule engine according to claim 8, characterized in that, It also includes the following steps: Configure the rules engine using parameters; The parameterized configuration includes setting the warning priority.

10. A rule-engine-based transaction alert generation system, applied to the rule-engine-based transaction alert generation method according to any one of claims 1 to 9, characterized in that, include: Data acquisition configuration module: dynamically acquires target transaction data from multiple heterogeneous external data sources; Standardize the target transaction data to generate data to be analyzed; Early warning rule configuration module: Configures early warning rules based on target transaction data; wherein, the early warning rules include at least: differentiated trigger conditions based on transaction dimensions, and early warning levels associated with the trigger conditions; Rule engine processing module: After the data to be analyzed is input into the rule engine, it is matched with the warning rules in real time; when the data to be analyzed meets the warning rules, the rule engine generates and outputs warning information including the warning level according to the warning rules.

Images