Payment system service monitoring method, device, equipment, storage medium and product

Abstract

The application discloses a payment system service monitoring method and device, equipment, a storage medium and a product, relates to the technical field of payment transaction system data security, and the method comprises the steps of acquiring payment system multi-source service monitoring index data, obtaining to-be-judged index data through timed polling consumption, index code grouping parallel operation; then generating a preliminary abnormal alarm event through multi-rule branch routing judgment and alarm suppression; finally, according to the expert model linkage atomic index verification, completing abnormal root cause tracing and outputting the monitoring result. Therefore, the grouping parallel operation improves the mass data processing efficiency, the rules and the alarm suppression reduce invalid alarms and reduce false positives; the expert model linkage verification accurately traces the fault, the intelligent research and judgment replaces manual troubleshooting, the general model adaptation short board is improved, the operation and maintenance cost is reduced, and the payment monitoring precision and the intelligent level are improved.

Description

Technical Field

[0001] This application relates to the field of data security technology for payment transaction systems, and in particular to a method, apparatus, equipment, storage medium, and product for monitoring payment system business. Background Technology

[0002] With the expansion of transaction volume in industries such as finance, government affairs, and banking, payment systems carry massive amounts of transaction data. System malfunctions, transaction fluctuations, and potential transaction risks occur frequently, placing extremely high demands on the monitoring systems of the payment industry and their ability to identify anomalies and trace faults.

[0003] To ensure the stable operation of the payment system and timely detection of transaction anomalies, the industry currently uses traditional manual inspection and general AI intelligent alarm analysis as monitoring methods. However, existing technical solutions mostly rely on manual inspection of faults by operations and maintenance personnel or general time series prediction and unsupervised clustering black box AI models. These methods are time-consuming, have limited recognition dimensions, and often rely on simple judgments based on single indicators. They cannot adapt to new payment risks, resulting in low overall inspection efficiency and high operation and maintenance costs, making it difficult to meet the high-precision and high-efficiency monitoring needs of complex payment scenarios. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment, storage medium and product for monitoring payment system business, which aims to solve the problems of time-consuming manual investigation, high false alarm rate, difficulty in root cause location and high operation and maintenance cost in traditional payment monitoring.

[0005] To achieve the above objectives, this application proposes a method for monitoring payment system transactions, the method comprising: Obtain multi-source business monitoring indicator data from the payment system; The monitoring indicator data is subjected to timed polling and parallel processing of indicator code grouping to obtain batch monitoring indicator data to be judged; The batch of monitoring indicator data to be judged is subjected to multi-rule branch routing judgment and fine-grained alarm suppression processing to obtain preliminary abnormal alarm events; The initial abnormal alarm events are verified by combining a preset expert model with atomic indicators to trace the root cause of the abnormality and obtain the final payment business monitoring results.

[0006] In one embodiment, the step of obtaining multi-source business monitoring indicator data of the payment system includes: Real-time indicator data is collected by connecting to the payment system data source through the real-time database transaction synchronization tool OGG. By connecting to the payment system's data source through the network traffic bypass listener, near real-time indicator data is collected. The offline accounting data is collected by connecting to the payment system data source through the DDH offline accounting data acquisition adapter; Multi-source business monitoring indicator data is generated based on real-time indicator data, near-real-time indicator data, and offline accounting data. This multi-source business monitoring indicator data is adapted to hierarchical heterogeneous storage, real-time streaming detection, and intelligent root cause analysis.

[0007] In one embodiment, after obtaining the multi-source business monitoring indicator data of the payment system, the process includes: The multi-source business monitoring indicator data is hierarchically stored and classified for management.

[0008] In one embodiment, the hierarchical heterogeneous storage classification and management of the multi-source business monitoring indicator data includes: Monitoring indicator data that conforms to the standardized contract will be stored as standard indicator data for structured querying and aggregation analysis. The monitoring indicator data that is not in a standard format or contains noise will be stored as non-standard indicator data for data analysis. Real-time indicator data that meets the criteria of high throughput and low latency, such as transaction peak data, are sampled and processed using a sliding window and then stored in a real-time indicator data table for real-time anomaly detection.

[0009] In one embodiment, the step of performing timed polling consumption and parallel processing of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged includes: The index information of standard indicator data, non-standard indicator data, and real-time indicator data is used to generate an indicator information table, which records the indicator code, business date, and indicator processing status. According to the system scheduling task trigger, the indicator information table of the monitoring indicator data is scanned in combination with the business date and indicator processing status. Unprocessed indicators are pushed to the analysis ready queue. If there is no data to be processed, the current processing task is terminated. The candidate indicator data in the analysis ready queue are hashed and grouped according to the indicator code, and the number of processing threads is allocated to the grouped indicator data in combination with the real-time data skew parameter. The analysis scenarios for different indicators are made independent of each other by traversing and performing calculations based on the indicator codes as data sharding dimensions. Based on the currently traversed indicator code, query the indicator definition table, extract the corresponding analysis rule identifier and rule version number, and output batch monitoring indicator data to be judged.

[0010] In one embodiment, the step of performing multi-rule branch routing determination and refined alarm suppression processing on the batch of monitoring indicator data to be determined, and generating preliminary abnormal alarm events, includes: Extract the corresponding indicator code and rule identifier from the batch of monitoring indicator data to be judged; Based on the rule identifier, the default rule table or no-signal rule table is matched to load the judgment logic and the corresponding weekday scheduling strategy, and the condition expression tree is generated by parsing. The valid abnormal indicator data are obtained by determining the anomaly of the indicator based on the conditional expression tree. For valid abnormal indicator data, alarm events are constructed according to their levels. The alarm push timing information is recorded and persistently stored to generate preliminary abnormal alarm events. Alarm silencing is then performed in conjunction with the workday scheduling strategy.

[0011] In one embodiment, the preliminary anomaly alarm event is verified by a preset expert model combined with atomic indicators to complete intelligent root cause tracing of the anomaly and output the final payment business monitoring result, including: Obtain the indicator code corresponding to the preliminary abnormal alarm event, wherein the indicator code has a corresponding deep analysis rule embedded in it, and the deep analysis rule is bound to at least one expert model; The initial abnormal alarm event and the indicator code are input into the analysis engine, which then retrieves the deep analysis rules. The expert model in the deep analysis rules is pre-configured with a retrieval and verification model, which encapsulates the handling logic and judgment strategy for specific alarm scenarios. The analysis engine calls the pre-configured retrieval and verification model in the expert model to retrieve and read the real-time status and historical records of the associated atomic indicators in the indicator information table. Based on the real-time status and historical records of the atomic indicators, a preset judgment condition is met. The analysis engine is used to locate the root cause of the anomaly and activate the corresponding handling plan, and the final payment business monitoring result is output.

[0012] Furthermore, to achieve the above objectives, this application also proposes a payment system business monitoring device, the device comprising: The data acquisition module is used to acquire multi-source business monitoring indicator data of the payment system; The parallel computing module is used to perform timed polling and parallel computing of the monitoring indicator data and indicator code grouping to obtain batch monitoring indicator data to be judged. The alarm generation module is used to perform multi-rule branch routing determination and fine-grained alarm suppression processing on the batch of monitoring indicator data to be determined, so as to obtain preliminary abnormal alarm events. The intelligent traceability module is used to verify the initial abnormal alarm events by combining a preset expert model with atomic indicators, complete the root cause tracing of the abnormality, and obtain the final payment business monitoring results.

[0013] In addition, to achieve the above objectives, this application also proposes a payment system business monitoring device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the payment system business monitoring method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the payment system business monitoring method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the payment system business monitoring method described above.

[0016] The one or more technical solutions proposed in this application have at least the following technical effects: By acquiring multi-source business monitoring indicator data from the payment system; performing periodic polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged; performing multi-rule branch routing judgment and refined alarm suppression processing on the batch monitoring indicator data to be judged to obtain preliminary abnormal alarm events; and verifying the preliminary abnormal alarm events through a preset expert model combined with atomic indicator linkage to complete the root cause tracing of the anomaly and obtain the final payment business monitoring result. Thus, by processing monitoring indicators through grouped parallel computation, the data processing speed is effectively improved; by using multi-rule routing and alarm suppression mechanisms, redundant alarms are effectively filtered, reducing the false alarm rate; by using expert models combined with atomic indicator linkage verification, the root cause tracing of the anomaly is accurately completed; and by replacing traditional investigation methods with intelligent business analysis, manual maintenance costs are reduced, the shortcomings of insufficient general model adaptation are improved, and the overall accuracy and intelligent effect of payment business monitoring are effectively enhanced. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the payment system business monitoring method of this application. Figure 2 This is a schematic diagram of the initial alarm event generation process of the payment system business monitoring method in this application.

[0020] Figure 3 This is a schematic diagram illustrating the in-depth analysis process of alarm causes in the payment system business monitoring method of this application; Figure 4 This is a schematic diagram demonstrating the effect and function of the payment business monitoring method in this application.

[0021] Figure 5 This is a schematic diagram of the module structure of the payment system business monitoring device in this application; Figure 6 This is a schematic diagram of the hardware structure of the payment system business monitoring equipment in this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: First, acquire multi-source business monitoring indicator data from the payment system. Second, perform periodic polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged. Third, perform multi-rule branch routing judgment and refined alarm suppression processing on the batch monitoring indicator data to obtain preliminary abnormal alarm events. Fourth, verify the preliminary abnormal alarm events using a preset expert model combined with atomic indicator linkage to complete the root cause tracing of the anomalies and obtain the final payment business monitoring result. Therefore, by processing monitoring indicators through grouped parallel computation, the processing speed of massive amounts of data is effectively improved; by using multi-rule routing and alarm suppression mechanisms, redundant alarms are effectively filtered, reducing the false alarm rate; by using expert models combined with atomic indicator linkage verification, the root cause tracing of anomalies is accurately completed; and by using intelligent business analysis to replace traditional investigation methods, manual maintenance costs are reduced, the shortcomings of insufficient general model adaptation are improved, and the overall accuracy and intelligent effect of payment business monitoring are effectively enhanced.

[0026] This application's embodiments take into account that, due to existing technologies, mainstream payment monitoring solutions mostly rely on manual log checks or general AI-based intelligent alarm analysis. These methods suffer from drawbacks such as limited analytical dimensions, weak business adaptability, slow fault location, high false alarm rates, and high maintenance costs, making it difficult to meet the high-precision, high-efficiency real-time monitoring needs of complex payment transactions. Specifically, this is manifested as follows: Low efficiency in troubleshooting: After traditional monitoring generates an alarm, it relies entirely on maintenance personnel to manually check massive amounts of logs and indicator data for experience-based troubleshooting. The fault location process is cumbersome and time-consuming, and it cannot achieve rapid closure of the anomaly.

[0027] Poor business adaptability and delayed risk response: Existing general AI alarms mostly use general algorithms such as time series prediction and unsupervised clustering, which only focus on changes in data distribution and cannot understand the real business meaning behind payment indicators; moreover, they are mostly fixed black box models with fixed logic after training, making it difficult to quickly adapt to new and dynamically changing payment risk scenarios.

[0028] Single analysis dimension and high false alarm rate: Traditional AI intelligent alarms are mostly based on single indicators or simple indicator correlation judgments, without combining core accounting, channel status, merchant transaction data and other multi-dimensional business data for comprehensive reasoning. The judgment logic is one-sided and is very easy to generate invalid alarms and false judgments.

[0029] High system resource consumption and limited processing capacity: Traditional monitoring relies on online applications and databases to directly process massive transaction indicators. In high-concurrency scenarios, resource consumption is high, computing pressure is high, and data processing efficiency is low, making it difficult to support the real-time monitoring needs of large-scale payment data streams.

[0030] High model development and maintenance costs: General AI model training, iteration and optimization have high barriers to entry and long cycles, resulting in high overall maintenance costs; moreover, model iteration is inflexible and cannot be quickly updated according to payment business scenarios.

[0031] This application provides a solution that addresses the problems of time-consuming manual investigation, high false alarm rates, difficulty in root cause identification, and high maintenance costs associated with traditional payment monitoring.

[0032] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, payment system business monitoring device, or system capable of performing the above functions. The following description uses a payment system business monitoring system as an example to illustrate this embodiment and the subsequent embodiments.

[0033] Based on this, the embodiments of this application provide a method for monitoring payment system business, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the payment system business monitoring method of this application.

[0034] In this embodiment, the payment system business monitoring method includes steps S10 to S40. The following provides a detailed explanation of each step.

[0035] like Figure 1As shown, the first embodiment of this application proposes a method for monitoring payment system business, the method comprising: Step S10: Obtain multi-source business monitoring indicator data of the payment system; Specifically, by connecting to the payment system's data sources through multiple data collection channels, real-time transaction indicator data, near real-time traffic indicator data, and offline accounting reconciliation data are collected and aggregated to form multi-source business monitoring indicator data covering the entire payment business chain. This multi-source data encompasses core business information such as transaction flow, interface status, channel connectivity, and accounting discrepancies, comprehensively covering various monitoring dimensions of the payment system's operation. It serves as the original data foundation for subsequent data governance, indicator calculation, and anomaly analysis.

[0036] Therefore, by comprehensively collecting multi-source heterogeneous payment business data, the problem of single data source and incomplete coverage in traditional monitoring is solved, providing complete and reliable data support for subsequent accurate monitoring and analysis.

[0037] Step S20: Perform timed polling consumption and parallel operation of indicator code grouping on the monitoring indicator data to obtain a batch of monitoring indicator data to be judged; Specifically, the system triggers the data processing flow periodically through preset scheduling tasks. Based on a pre-generated indicator information table, it batch-filters out unprocessed monitoring indicator data and sends it to the analysis-ready queue. Simultaneously, it hashes and groups the data in the queue according to unique indicator codes, dynamically allocating computation threads based on real-time data skew, enabling parallel sharding and processing of multiple groups of indicator data. Each indicator analysis scenario is independent and does not interfere with others. Furthermore, by matching indicator codes with a preset indicator definition table, it accurately binds the unique analysis rules and version information corresponding to each indicator, completing the preprocessing and rule matching encapsulation of monitoring data, and finally outputting standardized batch monitoring indicator data awaiting judgment.

[0038] Therefore, by using timed batch processing and grouped parallel computing, the problems of inefficient processing of massive payment indicator data and data skew and lag are solved, the efficiency of data preprocessing is greatly improved, and large batches of monitoring data are ensured to enter the anomaly judgment stage stably and orderly.

[0039] Step S30: Perform multi-rule branch routing determination and refined alarm suppression processing on the batch of monitoring indicator data to be determined to obtain preliminary abnormal alarm events; Specifically, for the pre-processed batch of monitoring indicator data to be judged, the corresponding indicator codes and rule identifiers are extracted. Based on the rule type, the system automatically routes and matches the corresponding default rule table or no-signal rule table, and parses to generate an executable conditional expression tree. The expression tree is used to automatically determine anomalies in the indicator data. Simultaneously, combined with a preset weekday scheduling strategy, alarms are silenced for invalid anomaly scenarios such as holidays and non-working hours, filtering out invalid data such as instantaneous fluctuations and non-business anomalies, and selecting truly valid anomaly indicator data. Finally, the valid anomaly data is hierarchically encapsulated according to anomaly level, alarm timing information is recorded and persistently stored, and preliminary anomaly alarm events are generated.

[0040] Therefore, by using multiple rule branches for precise judgment and a refined alarm suppression mechanism, the problems of single traditional monitoring rules and rampant invalid alarms are avoided, the false alarm rate is greatly reduced, and high-value abnormal alarms are screened out, which reduces the burden and increases efficiency for subsequent in-depth root cause tracing.

[0041] Step S40: The preliminary abnormal alarm event is verified by a preset expert model combined with atomic indicators to complete the root cause tracing of the abnormality and obtain the final payment business monitoring result.

[0042] Specifically, for the initial anomaly alarm event output in step S30, the core indicator code is extracted and the corresponding deep analysis rules are retrieved. The alarm information and indicator code are then synchronously input into the analysis engine. Through deep analysis rules, a pre-set operation and maintenance expert model is matched, and the model's built-in retrieval and verification logic is invoked to automatically query the real-time operating status and historical alarm records of various underlying atomic indicators associated with the anomaly. By combining multi-dimensional data of atomic indicators with pre-set business judgment conditions for cross-verification and comprehensive reasoning, the traditional single-indicator judgment and manual experience-based investigation mode is abandoned. This accurately locates the root cause of payment business anomalies and matches corresponding pre-set handling plans, completing automated closed-loop handling of the anomaly and ultimately outputting accurate final payment business monitoring results.

[0043] Therefore, by linking expert operation and maintenance experience models with underlying atomic indicators for verification, intelligent tracing from surface anomaly alarms to deep fault root causes can be achieved, making up for the shortcomings of general AI models that lack business semantics and have poor adaptability, and improving the accuracy of payment anomaly monitoring and intelligent handling capabilities.

[0044] This embodiment's technical solution acquires multi-source business monitoring indicator data from the payment system; performs periodic polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged; performs multi-rule branch routing judgment and refined alarm suppression processing on the batch monitoring indicator data to obtain preliminary abnormal alarm events; and completes the root cause tracing of the abnormality by verifying the preliminary abnormal alarm events through a preset expert model combined with atomic indicator linkage, thus obtaining the final payment business monitoring result. Therefore, by processing monitoring indicators through grouped parallel computation, the processing speed of massive amounts of data is effectively improved; by using multi-rule routing and alarm suppression mechanisms, redundant alarms are effectively filtered, reducing the false alarm rate; by using expert models combined with atomic indicator linkage verification, the root cause tracing of abnormalities is accurately completed; and by using intelligent business analysis to replace traditional investigation methods, manual maintenance costs are reduced, the shortcomings of insufficient general model adaptation are improved, and the overall accuracy and intelligent effect of payment business monitoring are effectively enhanced.

[0045] This embodiment provides a complete payment system business monitoring methodology, encompassing multi-source data acquisition, batch parallel processing, refined alarm filtering, and intelligent root cause analysis. This method strengthens the analytical foundation by aggregating comprehensive payment business data, improves data processing efficiency through grouped parallel processing, filters invalid anomalies using multi-rule routing and alarm suppression, and finally combines expert models with atomic indicator-based verification to complete intelligent fault assessment and root cause analysis. It provides a systematic, automated, and highly accurate intelligent solution for payment system business monitoring, overcoming the technical shortcomings of traditional monitoring methods, such as reliance on manual investigation, limited analytical dimensions, weak model adaptability, high false alarm rates, and high maintenance costs.

[0046] In this embodiment, based on the first embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, step S10, obtaining the multi-source business monitoring indicator data of the payment system, includes steps S101-S105: Step S101: Connect to the payment system data source through the real-time database transaction synchronization tool OGG to collect real-time indicator data; Specifically, OGG is Oracle's official log-based database synchronization software. It extracts incremental data by parsing database redo logs without locking the source database or interfering with online business operations. OGG real-time database synchronization tools are used to connect to the core payment transaction database. Based on log mining, it parses incremental database logs in real time, capturing new, modified, and updated data during payment transactions without intrusion or table locking. It continuously collects key real-time transaction metrics such as transaction success rate, transaction failure rate, single transaction response time, API call frequency, peak concurrency, and number of timeout transactions, achieving real-time synchronization of transaction data with business traffic and millisecond-level updates.

[0047] This enables the uninterrupted and low-latency capture of the actual transaction operation status of the payment system, ensuring that the monitoring data is fully aligned with the business timeline, and providing an accurate and continuous real-time data foundation for real-time anomaly identification and instantaneous fault capture.

[0048] Step S102: Connect to the payment system data source through the network traffic bypass listener (Bypass) to collect near real-time indicator data; Specifically, Bypass is a common bypass traffic acquisition solution in the industry. It uses switch port mirroring / hardware optical splitting to copy network traffic, collecting only the copy data without affecting the original service transmission.

[0049] By using a bypass traffic monitoring device, full traffic mirroring is performed on the payment system's external channels, bank front-end links, and gateway communication links without consuming business host resources or penetrating business logic. By parsing network packet protocols, message request packets, and response receipt packets, near real-time link indicator data such as link connectivity status, network latency, packet loss rate, retransmission count, channel response status, and interface throughput are continuously extracted, achieving minute-level data updates.

[0050] This overcomes the limitation of database collection in detecting network link anomalies, enabling full-dimensional monitoring from transaction applications to network links, effectively covering hidden fault scenarios such as link jitter, channel congestion, and external connection timeouts.

[0051] Step S103: Connect the offline accounting data acquisition adapter DDH to the payment system data source and collect offline accounting data; Specifically, DDH is a standardized offline ETL data collection component that relies on scheduled tasks to extract historical ledgers from the database in batches. It is mainly used for T+1 offline accounting data batch synchronization. Through the DDH big data offline collection adapter, it connects to the payment system's daily end-of-day clearing, reconciliation batches, netting, and fund flow records in batches on a scheduled basis. It automatically pulls batch offline data sources such as daily clearing files, reconciliation details, merchant settlement flow records, and general ledger and sub-account data, and collects offline statistical indicators such as batch processing time, accounting discrepancies, clearing success rate, number of reconciliation errors, and number of batch task failures.

[0052] This provides comprehensive coverage of offline business scenarios such as daily batch transactions, fund clearing, and account reconciliation in the payment system, making up for the shortcomings of real-time indicators in covering batch account anomalies and enabling data collection throughout the entire business cycle.

[0053] Step S104: Multi-source business monitoring indicator data is formed based on real-time indicator data, near-real-time indicator data, and offline accounting data. The multi-source business monitoring indicator data is adapted to hierarchical heterogeneous storage, real-time streaming detection, and intelligent root cause analysis.

[0054] Specifically, real-time transaction metrics collected by OGG, near-real-time metrics collected by Bypass, and offline accounting metrics collected by DDH are uniformly collected, with fields standardized, time-series aligned, and data deduplication performed. This results in a comprehensive, multi-source business monitoring metrics dataset covering the transaction, data link, and accounting layers. The dataset uses unified data definitions and formats, adapting to various technical scenarios such as real-time streaming computing, offline batch analysis, multi-dimensional correlation analysis, and fault root cause tracing.

[0055] This breaks through the problem of single traditional monitoring data and builds a multi-time series, multi-dimensional, and full-link payment business monitoring data foundation, providing complete data source support for subsequent batch processing, intelligent alarms, and in-depth tracing.

[0056] Step S105: Perform hierarchical heterogeneous storage classification and management on the multi-source business monitoring indicator data.

[0057] Specifically, the hierarchical heterogeneous storage and classification management of the multi-source business monitoring indicator data includes: Step S1051: The monitoring indicator data that conforms to the standard contract is stored as standard indicator data for structured query and aggregation analysis. Specifically, the system verifies the field completeness, format validity, and numerical rationality of multi-source indicator data. High-quality indicator data that fully conforms to the system's preset data specification contract, has complete fields, compliant values, and normal time sequence are classified and stored in a structured standard indicator database, which is specifically used for daily indicator statistics, structured condition queries, batch aggregation calculations, and routine anomaly detection.

[0058] This ensures the standardization and reliability of data in routine monitoring operations, and significantly improves the accuracy of batch indicator statistics, aggregation analysis, and routine alarm determination.

[0059] Step S1052: Store the monitoring indicator data that is not in a standard format or contains noise as non-standard indicator data for data analysis. Specifically, noisy and dirty data that do not conform to data standards, such as missing fields, incorrect format, abnormal encoding, numerical jumps, duplication and redundancy, and disordered time sequence, are filtered and separated and archived separately in the non-standard indicator database. They are not used for daily real-time alarms and batch statistical calculations, but only for post-fault review, data problem analysis, rule iteration optimization, and model training reference.

[0060] This completely isolates dirty data and abnormal noise data, prevents non-standard data from interfering with normal monitoring logic, and effectively reduces the probability of false alarms and misjudgments in the system.

[0061] Step S1053: The real-time indicator data of transaction peaks that meet the requirements of high throughput and low latency in the real-time indicator data are sampled and processed by a sliding window and then stored in the real-time indicator data table for real-time anomaly detection.

[0062] Specifically, for the massive high-throughput, low-latency real-time transaction indicator data generated during peak sales events and transaction surges, a sliding window statistical sampling mechanism is used to smooth and reduce noise in dense data streams, extract frames for compression, and remove redundancy. Valid peak feature data is retained, while instantaneous invalid spike data is removed. After processing, the data is stored in a dedicated real-time time series indicator data table.

[0063] Therefore, while preserving the characteristics of real transaction peaks, the pressure of massive real-time data storage and computation is reduced, ensuring the efficiency and low latency of real-time anomaly detection in high-concurrency scenarios.

[0064] Based on the first or second embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to the first or second embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, in the third embodiment of this application, step S20, which involves performing timed polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged, includes steps S201-S205: Step S201: Generate an indicator information table from the index information of standard indicator data, non-standard indicator data, and real-time indicator data. The indicator information table records the indicator code, business date, and indicator processing status. Specifically, for standard indicator data, non-standard indicator data, and real-time peak indicator data after hierarchical heterogeneous storage governance, the core index fields and metadata information of each type of indicator are uniformly extracted and centrally summarized to generate a globally unique indicator information table. Each table records the unique indicator code corresponding to each type of monitoring indicator, the corresponding business statistics date, the data source type, the data storage path, and the current processing status of the indicator, clearly marking three working states: unprocessed, processing, and processed, achieving a unified, structured management of all monitoring indicators.

[0065] This led to the construction of a complete data management ledger for monitoring indicators, enabling the querying, management, and traceability of massive amounts of multi-source indicator data. It provides a standardized data retrieval basis for subsequent scheduled operations, batch filtering, and grouped calculations, avoiding problems such as data omissions and duplicate processing.

[0066] Step S202: Based on the system scheduling task trigger, scan the indicator information table of the monitoring indicator data according to the business date and indicator processing status, push unprocessed indicators to the analysis ready queue, and terminate the current processing task if there is no data to be processed. Specifically, the system is configured with fixed-period scheduling task triggers that automatically initiate batch data consumption processes according to a preset polling frequency. Using both business date and indicator processing status as dual filtering conditions, it performs a full scan of all ledger data in the indicator information table. It accurately filters out valid monitoring indicator data that is currently unprocessed and packages it in batches, pushing it to the system's built-in analysis-ready queue for subsequent processing. If no indicator data is found in this scan, it automatically determines that there is no computational requirement for this round of tasks, directly terminating the processing flow and freeing up system computing resources.

[0067] This enables automated, periodic, and intelligent batch polling and consumption of monitoring indicator data, eliminating the need for manual intervention to start and stop tasks, effectively improving the automation level of data processing, while avoiding unnecessary idle calculations and saving system computing resources.

[0068] Step S203: The candidate indicator data in the analysis ready queue are hashed and grouped according to the indicator code, and the number of processing threads is allocated to the grouped indicator data in combination with the real-time data skew parameter. Specifically, for the batch of candidate indicator data accumulating in the analysis ready queue, consistent hashing grouping is performed using the unique indicator code of each indicator as the hash sharding key. This grouping of indicator data of the same type and business dimension into the same data group enables centralized processing of similar indicator data. Simultaneously, data skew parameters such as data volume, data complexity, and computation time are collected in real time for each group to dynamically identify uneven data accumulation. For groups with large data volumes and complex computations, processing threads are automatically expanded; for groups with small data volumes and simple computations, thread resources are streamlined, achieving dynamic adaptation of thread resources.

[0069] This effectively solves the data skew problem in the batch processing of massive monitoring indicator data, balances the computing pressure of each group, avoids processing lag and task timeout caused by the accumulation of data in a single group, and greatly improves the overall parallel processing efficiency of batch data.

[0070] Step S204: Perform calculations by traversing the data according to the indicator code as the data sharding dimension, and make the analysis scenarios of different indicators independent of each other; Specifically, each group's corresponding indicator code serves as an independent data sharding dimension. After hash grouping, multiple groups of indicator data are sharded one by one, and standardized calculation logic is executed. During the calculation process, an isolated sharding calculation mechanism is adopted. The business analysis scenarios, calculation logic, and data resources corresponding to different indicator codes are independent of each other and do not interfere with each other. This eliminates the problems of data cross-contamination and logical conflicts that may occur during the calculation of different types of indicator data, ensuring the independence and accuracy of the calculation of each type of indicator.

[0071] This enables isolated parallel computation of multiple types of monitoring indicators, avoiding logical interference and calculation errors caused by mixed computation in multiple scenarios, and ensuring that the computation process of various indicator data is stable, orderly, and accurate.

[0072] Step S205: Based on the currently traversed indicator code, query the indicator definition table, extract the analysis rule identifier and rule version number corresponding to the indicator, and output the batch monitoring indicator data to be judged.

[0073] Specifically, after the calculation of each segment of indicator data is completed, based on the unique indicator code currently being traversed and processed, the system's preset indicator definition table is precisely associated and retrieved. The system then retrieves the pre-configured exclusive business attributes, analysis rule identifiers, and corresponding rule iteration version numbers for that indicator, thereby completing the precise binding and matching encapsulation of indicator data and exclusive analysis rules, and uniformly standardizing the output format and rule attributes of all batch indicator data.

[0074] This enables precise matching and version control of indicator data and analysis rules, ensuring that each type of indicator uses exclusive and up-to-date analysis rules for subsequent anomaly detection, and ultimately outputs standardized and normalized batch monitoring indicator data that can be directly used for anomaly analysis.

[0075] Based on the first to third embodiments of this application, in the fourth embodiment of this application, the content that is the same as or similar to the first to third embodiments can be referred to the above description, and will not be repeated hereafter. On this basis, in the fourth embodiment of this application, step S30, which involves performing multi-rule branch routing determination and refined alarm suppression processing on the batch of monitoring indicator data to be determined, and generating preliminary abnormal alarm events, includes steps S301-S304: Step S301: Extract the corresponding indicator code and rule identifier from the batch of monitoring indicator data to be judged; Specifically, for batches of monitoring indicator data to be judged, the structured fields in the encapsulated data are parsed line by line to accurately extract the unique indicator code corresponding to each indicator data, as well as the exclusive analysis rule identifier pre-bound to that indicator. Among them, the rule identifier includes different types such as regular anomaly judgment identifier and no signal interruption judgment identifier, which can accurately distinguish the anomaly judgment scenarios of various indicators and provide a unique matching basis for subsequent branch rule matching.

[0076] This enables accurate field parsing and rule classification of batch indicator data, providing precise matching parameters for multi-rule branch routing determination, avoiding rule confusion and matching deviation, and ensuring the targeted nature of subsequent anomaly determination.

[0077] Step S302: Based on the rule identifier, load the judgment logic and the corresponding workday scheduling strategy by matching the default rule table or the no-signal rule table, and parse to generate a condition expression tree; Specifically, intelligent branch routing matching is performed based on the extracted rule identifiers. If it is a scenario of abnormal regular indicators, the system's preset default rule table is automatically matched, and conventional judgment logic such as threshold exceeding limits, indicator fluctuations, and data anomalies is loaded. If it is a scenario of indicator interruption, data missing, or no data update, the no-signal rule table is matched, and exclusive judgment logic such as data disconnection, task interruption, and collection anomalies is loaded. At the same time, the corresponding weekday, holiday, and business period scheduling strategies are retrieved synchronously, and the textual and configurable rule judgment conditions and time strategies are structured and parsed into a conditional expression tree that can be recognized by machines and executed line by line.

[0078] This enables precise rule-based adaptation for different abnormal scenarios, differentiates judgment logic between regular abnormalities and no-signal abnormalities, and solidifies judgment rules through expression trees to ensure that the judgment logic for batch indicators is unified, efficient, and reusable.

[0079] Step S303: Based on the conditional expression tree, determine the index anomalies to obtain valid abnormal index data; Specifically, using the parsed conditional expression tree as the core criterion, a batch of monitoring indicator data to be judged is compared and calculated one by one in an automated and standardized manner. Real-time indicator values, data status, and update frequency are comprehensively matched with preset thresholds, normal ranges, and data update rules. Abnormal indicators exceeding normal thresholds, those with abnormal data status, those not updated on time, and those with missing data are filtered out, while compliant indicator data with normal fluctuations and those fluctuating within the range are removed, accurately filtering out the truly valid abnormal indicator data.

[0080] This enables efficient and automated anomaly screening of batch monitoring indicators, accurately distinguishing between normal business fluctuations and real business anomalies, precisely extracting effective anomaly information from indicator data, and eliminating invalid data interference.

[0081] Step S304: Construct alarm events according to the level of valid abnormal indicator data, record the alarm push timing information and store it persistently, generate preliminary abnormal alarm events, and perform alarm silencing suppression in conjunction with the workday scheduling strategy.

[0082] Specifically, for the selected valid abnormal indicator data, based on the preset fault level classification standards, it is divided into high-risk, medium-risk, and low-risk levels according to the scope of the abnormality's impact, risk level, and urgency. The abnormal indicator content, abnormality type, occurrence time, relevant business scenario, and risk level are structurally encapsulated, and alarm events are constructed in a standardized manner. Simultaneously, the alarm generation time, pending push time, and push status are fully recorded and persistently stored. Furthermore, in conjunction with the preset weekday scheduling strategy, alarm silencing is implemented for non-fault scenarios such as holidays, non-working hours, and business maintenance windows, blocking unnecessary alarm pushes.

[0083] This enables standardized hierarchical management and refined noise reduction of abnormal alarms, effectively filtering out invalid, redundant, and non-business-related alarms, significantly reducing the false alarm rate and alarm proliferation problem, generating accurate and effective preliminary abnormal alarm events, and providing a reliable alarm data source for subsequent root cause tracing.

[0084] Based on the first to fourth embodiments of this application, in the fifth embodiment of this application, the content that is the same as or similar to the first to fourth embodiments can be referred to the above description, and will not be repeated hereafter. On this basis, in the fifth embodiment of this application, step S40, which involves verifying the preliminary abnormal alarm event by combining a preset expert model with atomic index linkage, completing the intelligent root cause tracing of the abnormality, and outputting the final payment business monitoring result, includes steps S401-S404: Step S401: Obtain the indicator code corresponding to the preliminary abnormal alarm event, wherein the indicator code has a corresponding deep analysis rule embedded in it, and the deep analysis rule is bound to at least one expert model. Specifically, the system receives initial anomaly alarm events, parses and reads the structured data of the alarm events, and accurately extracts the unique indicator code associated with the alarm. In this application, the indicator code corresponding to each type of business monitoring indicator is pre-bound and configured with embedded rules. The indicator codes for different anomaly types correspond to exclusive in-depth analysis rules, and each in-depth analysis rule is associated with one or more operation and maintenance expert models adapted to payment business scenarios. Each expert model corresponds to different anomaly scenarios such as transaction failures, link anomalies, accounting errors, and data disconnections, achieving scenario-specific model matching.

[0085] This enables a precise one-to-one correspondence between alarm events and in-depth analysis rules and expert models, breaking the drawback of indiscriminate judgment by traditional general AI models and providing accurate rules and model support for subsequent scenario-based in-depth tracing.

[0086] Step S402: Input the preliminary abnormal alarm event and the indicator code into the analysis engine. The analysis engine retrieves the deep analysis rules and pre-configures the retrieval and verification model within the expert model in the deep analysis rules. The model encapsulates the handling logic and judgment strategy for specific alarm scenarios. Specifically, the initial anomaly alert event carrying indicator code information is fully pushed to the system's built-in intelligent analysis engine. The analysis engine quickly retrieves and calls up the matching exclusive deep analysis rules based on the indicator code. The expert model bound to the deep analysis rules is a business model that has been iteratively built based on massive operational experience. The model pre-encapsulates exclusive retrieval and verification sub-models. Differentiated fault judgment logic, anomaly verification rules, scenario identification strategies, and standardized handling procedures are customized for different payment anomaly scenarios. Unlike general unsupervised and black-box AI algorithms, all judgment logic is interpretable, configurable, and iterative.

[0087] This modularizes, toolifies, and intelligentizes human operation and maintenance experience, enabling the model to possess semantic cognitive capabilities specific to payment business, effectively compensating for the shortcomings of general AI models such as poor adaptability, rigid logic, and inability to identify new payment risks.

[0088] Step S403: The analysis engine calls the pre-configured retrieval and verification model in the expert model to retrieve and read the real-time status and historical records of the associated atomic indicators in the indicator information table. Specifically, the analysis engine activates the built-in retrieval and verification model of the expert model. Taking the current abnormal indicator as the core correlation dimension, it traverses and queries the global indicator information table, horizontally and vertically retrieving all underlying atomic indicator data associated with this abnormal scenario. This includes multi-dimensional data such as core transaction atomic indicators, channel link atomic indicators, merchant transaction atomic indicators, and accounting reconciliation atomic indicators. It simultaneously reads the real-time operating status, current value, fluctuation, historical alarm records, and normal data samples from the same period of each type of atomic indicator, and constructs a multi-dimensional cross-verification data matrix.

[0089] Therefore, the traditional single-indicator, single-point judgment mode is abandoned, and the cross-verification of all-dimensional underlying atomic indicators is realized through single anomaly alarm linkage, which greatly improves the comprehensiveness of anomaly analysis and avoids omissions and misjudgments caused by one-sided judgment.

[0090] Step S404: Based on the preset judgment conditions for matching the real-time status and historical records of the atomic indicators, the analysis engine is used to locate the root cause of the anomaly and activate the corresponding handling plan, and the final payment business monitoring result is output.

[0091] Specifically, the analysis engine comprehensively matches and verifies the real-time status and historical operation records of the retrieved multi-dimensional atomic indicators with the preset scenario judgment conditions, fault thresholds, and anomaly association rules within the expert model. Through multi-indicator linkage and cross-validation, it eliminates normal interference factors layer by layer, accurately pinpointing the underlying fault root cause that triggers surface alarms, and distinguishing different problem scenarios such as human operation, system fluctuations, link failures, and accounting anomalies. Simultaneously, based on the anomaly type identified, it automatically matches and activates the corresponding standardized emergency response plan, completing anomaly classification and handling, risk alerts, and problem recording.

[0092] This enables fully automated, intelligent, and precise tracing of payment transaction anomalies, from surface-level alerts to deep-seated root causes. It replaces the inefficient traditional method of manually reviewing logs and relying on experience for troubleshooting, significantly reducing operational costs, improving the accuracy, real-time performance, and intelligence of payment monitoring, and outputting accurate and reliable final payment transaction monitoring results.

[0093] The process for generating a preliminary alarm event in this embodiment can be referred to. Figure 2 As shown. Figure 2 This is a schematic diagram of the initial alarm event generation process for the payment system business monitoring method involved in this application.

[0094] like Figure 2 As shown, this process fully covers the entire chain of processing logic for multi-source monitoring indicators, from access and collection, hierarchical storage and governance, batch scheduling and computation to dual-model anomaly judgment and alarm classification. Specifically, the system uses multiple methods such as OGG real-time database synchronization, Bypass network side-channel monitoring, and DDH offline collection, combined with CDC synchronization components and data sources aggregated by multiple front-end business applications via message Kafka, to connect in parallel with payment business scenarios, uniformly collecting monitoring indicator data from all dimensions, including real-time transactions, near-real-time links, and offline accounting. The system implements hierarchical heterogeneous classification and storage based on data format standardization, data quality, and real-time characteristics, archiving the differentiated data into non-standard indicator data tables, standard indicator data tables, and real-time indicator data tables, completing the standardized hierarchical governance of multi-source heterogeneous data; at the same time, it continuously pushes data to be processed to the indicator analysis application through timed triggering of synchronization tasks. The subsequent system relies on timed scheduling triggers to periodically scan the indicator information table, filter unprocessed indicators and send them to the analysis ready queue. By combining indicator code hash grouping with dynamic thread allocation, it realizes the parallel traversal and operation of batch indicator data. At the same time, it associates the indicator definition table to match the corresponding analysis rule identifier and version information, and outputs standardized indicator data to be judged. The indicator analysis application incorporates a dual-branch parallel analysis logic, relying on two judgment engines—the Nsigma statistical baseline model and the Default fixed threshold model—to perform rule calculations. The Nsigma model, based on the 3σ statistical principle, dynamically generates a floating baseline from historical data to accurately identify random anomalies in indicators. The Default model performs fallback verification of routine indicators based on preset fixed thresholds. The system routes branches according to rule identifiers, adaptively loading the judgment logic of default rule tables or no-signal rule tables, along with weekday scheduling strategies. It parses configurable rules into conditional expression trees to automate anomaly judgment and, combined with weekday scheduling strategies, performs alarm silencing, filtering invalid alarms from non-working hours and instantaneous business fluctuations. It generates multiple types of preliminary anomaly alarm events, such as over-limit alarms, network control alarms, and FTC alarms, according to anomaly levels, and persists these events in the database with time-series information. Finally, the system uses scheduled tasks to drive alarm push applications, distributing various alarm information to corresponding archiving modules for backup and simultaneously completing unified aggregation and retention of all alarm logs, achieving standardized and intelligent management of the entire payment business monitoring chain.

[0095] Supported by the aforementioned overall pre-process, this application achieves automated management of payment monitoring indicators, parallel computation, and intelligent initial alarm generation. Subsequent sub-processes for in-depth root cause tracing of alarms can be referenced. Figure 3 As shown, Figure 3 This is a flowchart illustrating the in-depth analysis of alarm causes in this application, corresponding to the core steps of the S40 intelligent root cause tracing in this application.

[0096] like Figure 3 As shown, Figure 3 This is a flowchart illustrating the in-depth analysis of alarm causes in this application, corresponding to the core steps of the S40 intelligent root cause tracing in this application. This sub-process abandons the traditional extensive monitoring mode of manual log investigation and simple threshold judgment of single indicators. It completes the entire process drive based on the three types of basic configuration forms pre-configured on the left: indicator definition, in-depth analysis rule definition, and analysis model definition. After retrieving the indicator data corresponding to the alarm to be processed from the akz_event_web_t interface event table, the system officially starts the in-depth analysis phase. akz_event_web_t is used to store all fields of the original alarms reported by the front end and generated by the system, recording the alarm source, indicator code, occurrence time, and original anomaly description. During the analysis initiation phase, the system sequentially queries the standard type indicator definition table, the akz_anarule_deeprule_t deep rule configuration table storing rule configuration information, and the analysis model definition table. Based on the pre-configured rule number, model code, and associated indicator range in the forms, it retrieves the underlying atomic indicator data and model running parameters for the corresponding business dimension. Subsequently, in the deep analysis and computation phase, the system loads the bound expert model and performs cross-verification and judgment based on multiple sets of associated atomic indicators. The entire analysis process, including event numbers, indicator codes, judgment results, and hit status, is recorded in real-time and stored in akz_analyse_deepr. The analysis process data table of ule_1 is completed and archived. After the analysis is completed, the system writes back the judgment results to the alarm event table. If the corresponding in-depth analysis rule is configured with a pending processing mark, the system generates a new pending alarm event based on the generated root cause conclusion and writes it back to the alarm event table. At the same time, the process has built-in priority scheduling logic. When the same alarm is bound to multiple expert models, they are executed in sequence according to the preset priority. The subsequent model calculation can be terminated as long as any model successfully outputs the root cause conclusion. While ensuring the accuracy of the judgment, redundant calculation overhead is simplified. Finally, the root cause of the anomaly is located based on the complete configuration drive and the multi-indicator cross-validation mechanism, and the final payment business monitoring results that can be explained and traced are output.

[0097] The algorithm performance of the above process can be referenced. Figure 4 As shown, Figure 4 This is a schematic diagram demonstrating the effect and function of the payment business monitoring method in this application.

[0098] like Figure 4As shown in the figure, this diagram illustrates the actual operational effectiveness of the overall solution in this application, covering core functional modules such as indicator monitoring and summarization, anomaly alarm display, in-depth analysis results, root cause tracing conclusions, and handling records. It intuitively demonstrates the application's end-to-end capabilities in automated data collection, intelligent analysis, root cause visualization, and verifiable results. Compared to the current situation where traditional manual investigation is chaotic and inefficient, general AI alarm results are uninterpretable, and alarms are rampant and unclassified, this application, through a configurable rule system and an expert model-linked atomic indicator verification mechanism, achieves orderly alarm convergence, precise anomaly location, and structured result output. The overall operation is stable, highly adaptable, and requires minimal operational intervention, fully meeting the high reliability, high real-time performance, and high compliance monitoring and maintenance needs of payment services.

[0099] Therefore, by encapsulating the aforementioned monitoring capabilities through a fully automated processing mechanism, lightweight, unmanned, and intelligent operation of the entire payment business monitoring chain is achieved, significantly reducing daily maintenance pressure. Multi-source data hierarchical governance standardizes data quality from the source, preventing dirty data from interfering with monitoring accuracy. Parallel computation through indicator code hashing and grouping solves the data skew and computing power bottleneck problems in processing massive indicators. Multi-rule branch routing and time-period silent suppression significantly reduce invalid alarms. Deep analysis through expert models and multi-atomic indicator linkage verification compensates for the shortcomings of traditional AI models, such as lack of business semantics, single analysis dimensions, and rigid iteration, achieving high-precision and interpretable intelligent fault tracing. This application effectively solves the industry pain points of traditional payment monitoring, such as delayed fault diagnosis, high false alarm rate, weak adaptation to new risks, and high model maintenance costs.

[0100] This embodiment fully considers the many shortcomings of existing payment monitoring technologies. Current mainstream payment monitoring solutions mostly rely on manual log review or general AI-based intelligent alarm analysis, which suffers from drawbacks such as limited analytical dimensions, weak business adaptability, slow fault location, high false alarm rates, and high maintenance costs. These shortcomings make it difficult to meet the high-precision, high-efficiency real-time monitoring needs of complex payment transactions. After a traditional monitoring alarm is generated, maintenance personnel mainly rely on experience to manually review a large number of logs and indicators, resulting in lengthy fault location processes. AI-based intelligent alarm analysis typically uses general time-series prediction or unsupervised clustering algorithms, focusing only on changes in data distribution and failing to understand the true business meaning behind the indicators. Furthermore, these are often end-to-end black-box models with fixed logic after training, making them unable to quickly respond to new payment risks. At the same time, traditional AI-based intelligent alarms are mostly based on single indicators or simple correlation judgments, resulting in a one-sided analytical dimension and a high risk of false positives and false negatives. Moreover, the development, training, and iteration of general AI models have high barriers to entry, and the overall maintenance cost is far higher than that of rule-based models.

[0101] Compared with the prior art, the technical solution of this embodiment has the following advantages: Intelligent troubleshooting and significantly improved efficiency: Traditional monitoring and alarm triggering heavily relies on maintenance personnel manually reviewing massive amounts of logs and indicator data, using subjective experience to troubleshoot, resulting in time-consuming and inefficient troubleshooting. This application automates the entire process of indicator calculation, anomaly judgment, and root cause tracing, eliminating the need for manual intervention. It can quickly complete anomaly location and problem closure, significantly improving the efficiency of handling payment business faults.

[0102] The business semantics are interpretable and the risk adaptability is strong: Traditional general-purpose AI intelligent alarms mostly use time-series prediction and unsupervised clustering algorithms, which only identify fluctuations in data distribution and cannot understand the real business logic corresponding to payment indicators. At the same time, general-purpose AI is mostly a fixed black box model, and the strategy is fixed after training, making it difficult to quickly adapt to new payment risk scenarios. This application adopts a business-driven expert model architecture, which is built entirely on payment business rules, has clear business semantics, and the rules can be flexibly configured and rapidly iterated, enabling timely response to dynamically changing new business risks.

[0103] Multi-dimensional comprehensive analysis for high alert accuracy: Traditional AI intelligent analysis often relies on single indicators or simple indicator correlations for anomaly detection, resulting in a one-sided analysis dimension and a tendency to make misjudgments or omissions. The deep analysis mechanism of this invention can link core accounting data, channel communication status, merchant transaction records, and other multi-dimensional atomic indicators for comprehensive cross-reasoning, verifying the authenticity of anomalies from multiple business perspectives, and significantly improving the accuracy and reliability of alert determination.

[0104] Lower development and maintenance costs: Compared to the high cost of traditional deep learning AI models that require a large number of samples for training, repeated tuning, and iterative optimization, the analysis architecture based on the linkage of expert rules and atomic indicators in this application is simple to build, easy to iterate, and has a low maintenance threshold. It does not require training with massive amounts of data, which can significantly reduce development costs and later maintenance costs while ensuring the adaptability of payment monitoring scenarios.

[0105] Furthermore, to achieve the above objectives, this application also proposes a payment system business monitoring device, such as... Figure 5 As shown, the device includes: Data acquisition module 10 is used to acquire multi-source business monitoring indicator data of the payment system; Parallel computing module 20 is used to perform timed polling consumption and parallel computing of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged; Alarm generation module 30 is used to perform multi-rule branch routing determination and fine-grained alarm suppression processing on the batch of monitoring index data to be determined, so as to obtain preliminary abnormal alarm events. The intelligent traceability module 40 is used to verify the preliminary abnormal alarm event by combining a preset expert model with atomic indicators, complete the root cause tracing of the abnormality, and obtain the final payment business monitoring result.

[0106] The payment system business monitoring device provided in this application, employing the payment system business monitoring method described in the above embodiments, can solve the problems of time-consuming manual investigation, high false alarm rates, difficulty in root cause location, and high operation and maintenance costs associated with traditional payment monitoring. Compared with the prior art, the beneficial effects of the payment system business monitoring device provided in this application are the same as those of the payment system business monitoring method provided in the above embodiments, and other technical features in the payment system business monitoring device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0107] In addition, to achieve the above objectives, this application also proposes a payment system business monitoring device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the payment system business monitoring method described above.

[0108] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a payment system business monitoring device suitable for implementing embodiments of this application. The payment system business monitoring device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 6 The payment system business monitoring device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0109] like Figure 6As shown, the payment system business monitoring equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the payment system business monitoring equipment. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the payment system business monitoring equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows payment system business monitoring equipment with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0110] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0111] The payment system business monitoring equipment provided in this application, employing the payment system business monitoring method described in the above embodiments, can solve the problems of time-consuming manual investigation, high false alarm rates, difficulty in root cause location, and high operation and maintenance costs associated with traditional payment monitoring. Compared with the prior art, the beneficial effects of the payment system business monitoring equipment provided in this application are the same as those of the payment system business monitoring method provided in the above embodiments, and other technical features of this payment system business monitoring equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0112] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0113] In addition, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the payment system business monitoring method described above.

[0114] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0115] The aforementioned computer-readable storage medium may be included in the payment system business monitoring equipment; or it may exist independently and not be assembled into the payment system business monitoring equipment.

[0116] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the payment system business monitoring equipment, the equipment performs the following actions: acquires multi-source business monitoring indicator data of the payment system; performs periodic polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged; performs multi-rule branch routing judgment and refined alarm suppression processing on the batch monitoring indicator data to obtain preliminary abnormal alarm events; and completes the root cause tracing of the abnormality by verifying the preliminary abnormal alarm events through a preset expert model combined with atomic indicator linkage, thus obtaining the final payment business monitoring result. Therefore, by processing monitoring indicators through grouped parallel computation, the processing speed of massive amounts of data is effectively improved; by using multi-rule routing and alarm suppression mechanisms, redundant alarms are effectively filtered, reducing the false alarm rate; by using expert models combined with atomic indicator linkage verification, the root cause tracing of abnormalities is accurately completed; and by replacing traditional investigation methods with intelligent business analysis, manual maintenance costs are reduced, the shortcomings of insufficient general model adaptation are improved, and the overall accuracy and intelligence of payment business monitoring are effectively enhanced.

[0117] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0118] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0119] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0120] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described payment system business monitoring method. This solves the problems of time-consuming manual investigation, high false alarm rates, difficulty in root cause localization, and high maintenance costs associated with traditional payment monitoring. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the payment system business monitoring method provided in the above embodiments, and will not be elaborated upon here.

[0121] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the payment system business monitoring method described above.

[0122] The computer program product provided in this application can solve the problems of time-consuming manual investigation, high false alarm rate, difficulty in root cause location, and high operation and maintenance cost in traditional payment monitoring. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the payment system business monitoring method provided in the above embodiments, and will not be repeated here.

[0123] The one or more technical solutions proposed in this application have at least the following technical effects: By acquiring multi-source business monitoring indicator data from the payment system; performing periodic polling consumption and parallel computation of indicator code grouping on the monitoring indicator data to obtain batch monitoring indicator data to be judged; performing multi-rule branch routing judgment and refined alarm suppression processing on the batch monitoring indicator data to be judged to obtain preliminary abnormal alarm events; and verifying the preliminary abnormal alarm events through a preset expert model combined with atomic indicator linkage to complete the root cause tracing of the anomaly and obtain the final payment business monitoring result. Thus, by processing monitoring indicators through grouped parallel computation, the processing speed of massive amounts of data is effectively improved; by using multi-rule routing and alarm suppression mechanisms, redundant alarms are effectively filtered, reducing the false alarm rate; by using expert models combined with atomic indicator linkage verification, the root cause tracing of the anomaly is accurately completed; and by replacing traditional investigation methods with intelligent business analysis, manual maintenance costs are reduced, the shortcomings of insufficient general model adaptation are improved, and the overall accuracy and intelligent effect of payment business monitoring are effectively enhanced.

[0124] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for monitoring business operations in a payment system, characterized in that, The method includes: Obtain multi-source business monitoring indicator data from the payment system; The monitoring indicator data is subjected to timed polling and parallel processing of indicator code grouping to obtain batch monitoring indicator data to be judged; The batch of monitoring indicator data to be judged is subjected to multi-rule branch routing judgment and fine-grained alarm suppression processing to obtain preliminary abnormal alarm events; The initial abnormal alarm events are verified by combining a preset expert model with atomic indicators to trace the root cause of the abnormality and obtain the final payment business monitoring results.

2. The method as described in claim 1, characterized in that, The steps for obtaining multi-source business monitoring indicator data of the payment system include: Real-time indicator data is collected by connecting to the payment system data source through the real-time database transaction synchronization tool OGG. By connecting to the payment system's data source through the network traffic bypass listener, near real-time indicator data is collected. The offline accounting data is collected by connecting to the payment system data source through the DDH offline accounting data acquisition adapter; Multi-source business monitoring indicator data is generated based on real-time indicator data, near-real-time indicator data, and offline accounting data. This multi-source business monitoring indicator data is adapted to hierarchical heterogeneous storage, real-time streaming detection, and intelligent root cause analysis.

3. The method as described in claim 2, characterized in that, After obtaining the multi-source business monitoring indicator data of the payment system, the following steps are included: The multi-source business monitoring indicator data is hierarchically stored and classified for management.

4. The method as described in claim 3, characterized in that, The hierarchical heterogeneous storage classification and management of the multi-source business monitoring indicator data includes: Monitoring indicator data that conforms to the standardized contract will be stored as standard indicator data for structured querying and aggregation analysis. The monitoring indicator data that is not in a standard format or contains noise will be stored as non-standard indicator data for data analysis. Real-time indicator data that meets the criteria of high throughput and low latency, such as transaction peak data, are sampled and processed using a sliding window and then stored in a real-time indicator data table for real-time anomaly detection.

5. The method as described in claim 1, characterized in that, The step of periodically polling and consuming the monitoring indicator data and performing parallel processing of indicator code grouping to obtain batch monitoring indicator data to be judged includes: The index information of standard indicator data, non-standard indicator data, and real-time indicator data is used to generate an indicator information table, which records the indicator code, business date, and indicator processing status. According to the system scheduling task trigger, the indicator information table of the monitoring indicator data is scanned in combination with the business date and indicator processing status. Unprocessed indicators are pushed to the analysis ready queue. If there is no data to be processed, the current processing task is terminated. The candidate indicator data in the analysis ready queue are hashed and grouped according to the indicator code, and the number of processing threads is allocated to the grouped indicator data in combination with the real-time data skew parameter. The analysis scenarios for different indicators are made independent of each other by traversing and performing calculations based on the indicator codes as data sharding dimensions. Based on the currently traversed indicator code, query the indicator definition table, extract the corresponding analysis rule identifier and rule version number, and output batch monitoring indicator data to be judged.

6. The method as described in claim 1, characterized in that, The process of performing multi-rule branch routing determination and refined alarm suppression on the batch of monitoring indicator data to be judged, generating preliminary abnormal alarm events, includes: Extract the corresponding indicator code and rule identifier from the batch of monitoring indicator data to be judged; Based on the rule identifier, the default rule table or no-signal rule table is matched to load the judgment logic and the corresponding weekday scheduling strategy, and the condition expression tree is generated by parsing. The valid abnormal indicator data are obtained by determining the anomaly of the indicator based on the conditional expression tree. For valid abnormal indicator data, alarm events are constructed according to their levels. The alarm push timing information is recorded and persistently stored to generate preliminary abnormal alarm events. Alarm silencing is then performed in conjunction with the workday scheduling strategy.

7. The method as described in claim 1, characterized in that, The preliminary anomaly alarm event is verified through a preset expert model combined with atomic indicators to complete intelligent root cause tracing of the anomaly and output the final payment business monitoring results, including: Obtain the indicator code corresponding to the preliminary abnormal alarm event, wherein the indicator code has a corresponding deep analysis rule embedded in it, and the deep analysis rule is bound to at least one expert model; The initial abnormal alarm event and the indicator code are input into the analysis engine, which then retrieves the deep analysis rules. The expert model in the deep analysis rules is pre-configured with a retrieval and verification model, which encapsulates the handling logic and judgment strategy for specific alarm scenarios. The analysis engine calls the pre-configured retrieval and verification model in the expert model to retrieve and read the real-time status and historical records of the associated atomic indicators in the indicator information table. Based on the real-time status and historical records of the atomic indicators, a preset judgment condition is met. The analysis engine is used to locate the root cause of the anomaly and activate the corresponding handling plan, and the final payment business monitoring result is output.

8. A payment system business monitoring device, characterized in that, The device includes: The data acquisition module is used to acquire multi-source business monitoring indicator data of the payment system; The parallel computing module is used to perform timed polling and parallel computing of the monitoring indicator data and indicator code grouping to obtain batch monitoring indicator data to be judged. The alarm generation module is used to perform multi-rule branch routing determination and fine-grained alarm suppression processing on the batch of monitoring indicator data to be determined, so as to obtain preliminary abnormal alarm events. The intelligent traceability module is used to verify the initial abnormal alarm events by combining a preset expert model with atomic indicators, complete the root cause tracing of the abnormality, and obtain the final payment business monitoring results.

9. A payment system business monitoring device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the payment system business monitoring method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the payment system business monitoring method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the payment system business monitoring method as described in any one of claims 1 to 7.

Images