Transaction service risk analysis method, device, equipment and storage medium

Abstract

The application discloses a transaction business risk analysis method, device, equipment and storage medium, relates to the technical field of risk analysis, and discloses a transaction business risk analysis method, which comprises the following steps: collecting business data according to a preset collection point to obtain transaction link collection data; performing task information aggregation statistics according to the transaction link collection data to obtain daily statistical index data; in a preset analysis period, generating period statistical index data according to the daily statistical index data, and constructing structured analysis prompt data according to the period statistical index data; and performing risk analysis on the transaction business according to the structured analysis prompt data. By applying the technical means of the scheme, continuous processing of transaction business operation data from collection, statistics, period arrangement to risk analysis can be realized, so that the efficiency, coverage range and identification ability for potential trend risks of transaction business risk analysis are improved.

Description

Technical Field

[0001] This application relates to the field of risk analysis technology, and in particular to risk analysis methods, apparatus, equipment and storage media for transaction business. Background Technology

[0002] With the continuous development of the online payment transaction business, the transaction system needs to simultaneously support multiple types of business such as quick payment, payment application, and refund transactions, and provide high-concurrency, low-latency online transaction processing capabilities for various application scenarios such as Alipay, Tenpay, other channels, and credit cards. In such business systems, transaction requests are typically characterized by long links, multiple calling stages, significant fluctuations in transaction volume, sensitivity to response time, and complex distribution of exception return codes. The system's operational status is reflected not only in whether a single transaction is successful, but also in multiple dimensions of indicators such as changes in transaction volume, response time distribution, maximum concurrent processing capacity, number of error logs, and success rate fluctuations.

[0003] Given the aforementioned technological background, traditional technical solutions typically rely on the transaction system's own logs, database records, monitoring platform reports, and periodic reviews by operations and maintenance personnel to statistically analyze data such as transaction volume, return codes, response times, and error logs. Related risk assessments largely depend on weekly or monthly evaluations by operations and maintenance personnel or risk control experts based on historical experience. However, as business scale continues to expand and the number of transaction channels and function codes increases, manual analysis methods are easily limited by the scope of analysis, differences in experience, and processing efficiency, making it difficult to timely and comprehensively identify hidden risk patterns and trend changes. Summary of the Invention

[0004] The main purpose of this application is to provide a risk analysis method, device, equipment and storage medium for trading business, which aims to solve the technical problems of low efficiency, limited coverage and difficulty in timely detection of potential trend risks in the statistical analysis of operational data and risk analysis of existing online fund trading business.

[0005] To achieve the above objectives, this application proposes a risk analysis method for transaction business, the method comprising: Business data is collected based on preset collection points to obtain transaction link collection data. The preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point. Based on the data collected from the transaction chain, task information is aggregated and statistically analyzed to obtain daily statistical indicator data; Within a preset analysis period, periodic statistical indicator data is generated based on the daily statistical indicator data, and structured analysis prompt data is constructed based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints. Risk analysis of transaction operations is performed based on the structured analysis data.

[0006] In one embodiment, the step of aggregating and statistically analyzing task information based on the transaction link data to obtain daily statistical indicator data includes: Based on the preset end-of-day task time and statistical date, query the transaction performance data from the data collected in the transaction link to obtain the end-of-day pending data; Based on the link identifier and link type in the end-of-day pending data, the request data and response data are integrated to obtain the integrated link data; The integrated link data is preprocessed to obtain end-of-day preprocessed data; The daily preprocessed data is aggregated and calculated according to preset statistical dimensions to obtain daily statistical indicator data.

[0007] In one embodiment, the step of aggregating and calculating the preprocessed data at the end of the day according to a preset statistical dimension to obtain daily statistical indicator data includes: Obtain preset statistical parameters, wherein the preset statistical parameters include the business transaction date and the transaction application name; Error log statistics are performed on the end-of-day preprocessed data based on the preset statistical parameters and transaction return codes to obtain error log indicator data. Based on the transaction count statistics of the end-of-day preprocessed data, transaction volume index data is obtained; Based on the preset statistical parameters, transaction function codes, and response time levels, the response time distribution of the end-of-day preprocessed data is statistically analyzed to obtain response time index data. Daily statistical data is generated based on the error log data, the transaction volume data, and the response time data.

[0008] In one embodiment, the steps of generating periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and constructing structured analysis prompt data based on the periodic statistical indicator data, wherein the structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints, include: The current period time range and the comparison period time range are determined according to the preset analysis period; Based on the current period time range and the comparison period time range, statistical data is extracted from the daily statistical indicator data to obtain periodic statistical indicator data; The periodic statistical indicator data is standardized based on the transaction application name, function code, indicator type, and transaction date to obtain standardized periodic indicator data. Generate tabular indicator text and natural language indicator descriptions based on the standardized periodic indicator data; Structured analysis prompt data is constructed based on the tabular indicator text, the natural language indicator description, the transaction role information, the transaction task information, the output format constraints, and the security constraints.

[0009] In one embodiment, the step of performing risk analysis on transaction business based on the structured analysis prompt data includes: The structured analysis prompts are input into a preset analysis model to obtain initial analysis conclusions. The initial analysis conclusion data is parsed to obtain the sub-analysis conclusion data; The sub-analysis conclusion data is formatted according to the preset output format to obtain formatted analysis conclusion data; Based on the formatted analysis conclusions, determine the transaction trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data; The transaction business risk analysis results are generated based on the transaction trend analysis data, the abnormal indicator analysis data, the risk issue list data, and the improvement suggestion data.

[0010] In one embodiment, the step of determining the trading trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data based on the formatted analysis conclusion data includes: Based on the changes in trading volume, success rate, and response time in the formatted analysis conclusion data, trend content is extracted to obtain trading trend analysis data. Based on the error log change information, response time change information, and indicator fluctuation information in the formatted analysis conclusion data, abnormal content is extracted to obtain abnormal indicator analysis data. Based on the abnormal content and risk description content in the formatted analysis conclusion data, the issues are sorted to obtain a risk issue list data; Based on the risk cause description and disposal suggestion description in the formatted analysis conclusion data, the suggestion content is extracted to obtain improvement suggestion data.

[0011] In one embodiment, the step of collecting business data according to preset collection points to obtain transaction link collection data, wherein the preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point, includes: Based on the transaction entry collection point in the preset collection points, entry collection data is collected, wherein the entry collection data includes: application name, function code, arrival timestamp, link identifier, transaction type code, request channel identifier, and requester network address; According to the first transaction exit collection point in the preset collection points, first exit collection data is collected, wherein the first transaction exit collection point is used to indicate the exit collection point where the transaction processing is successful and returned. According to the second transaction exit collection point in the preset collection points, collect the second exit collection data, wherein the second transaction exit collection point represents the exit collection point where the transaction processing is abnormal or failed; The ingress collection data, the first egress collection data, and the second egress collection data are sent to the message queue to obtain the transaction link collection data.

[0012] In addition, to achieve the above objectives, this application also proposes a risk analysis device for transaction business, which includes: a data acquisition module, used to collect business data according to preset acquisition points to obtain transaction link acquisition data, wherein the preset acquisition points include a transaction entry acquisition point, a first transaction exit acquisition point and a second transaction exit acquisition point; The aggregation and statistics module is used to aggregate and statistically analyze task information based on the data collected from the transaction link to obtain daily statistical indicator data. The data statistics module is used to generate periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and to construct structured analysis prompt data based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints. The risk analysis module is used to perform risk analysis on transaction business based on the structured analysis prompt data.

[0013] In addition, to achieve the above objectives, this application also proposes a risk analysis device for transaction business, 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 risk analysis method for transaction business as 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 risk analysis method for transaction business as 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 risk analysis method for transaction business as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By employing a technical approach that involves collecting business data from preset collection points to obtain transaction chain data, then aggregating and statistically analyzing the transaction chain data to form daily statistical indicators, generating periodic statistical indicators and structured analysis prompts based on the daily statistical indicators within a preset analysis period, and finally conducting transaction business risk analysis based on the structured analysis prompts, transaction business risk analysis is no longer limited to manual review of scattered logs or fragmented reports. Instead, it first establishes a data foundation covering the transaction chain through collection points, and then transforms the raw transaction data into indicator data that reflects the daily operational status through aggregation and statistics. Furthermore, by using periodic statistics, daily indicators are elevated to periodic analytical bases that can reflect time-varying trends. Structured analysis provides data with a unified, standardized, and processable input foundation for subsequent risk analysis. This solves the problems of low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in existing online fund trading operations' data statistics and risk analysis. Compared with existing technologies, this achieves continuous processing of trading operation data from collection, statistics, periodic organization to risk analysis, resulting in more complete data coverage, more concentrated analytical basis, and improved efficiency in identifying trend changes and potential risks in trading operations. 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 A flowchart illustrating the risk analysis method for the transaction business described in this application (Example 1); Figure 2 A flowchart illustrating the risk analysis method for the transaction business described in this application, as provided in Embodiment 2. Figure 3 A simplified flowchart illustrating the risk analysis method for transaction business provided in Embodiment 2 of this application; Figure 4 This is a schematic diagram of the module structure of the risk analysis device for transaction business in an embodiment of this application; Figure 5This is a schematic diagram of the hardware operating environment involved in the risk analysis method for transaction business in this application embodiment.

[0020] 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

[0021] 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.

[0022] 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.

[0023] The main solution of this application embodiment is as follows: Business data is collected based on preset collection points to obtain transaction link collection data, wherein the preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point; task information is aggregated and statistically analyzed based on the transaction link collection data to obtain daily statistical indicator data; within a preset analysis period, periodic statistical indicator data is generated based on the daily statistical indicator data, and structured analysis prompt data is constructed based on the periodic statistical indicator data, wherein the structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints; risk analysis of the transaction business is performed based on the structured analysis prompt data.

[0024] In this embodiment, for ease of description, the risk analysis device for identifying transaction business will be used as the subject of the explanation.

[0025] Because existing technologies for online fund transaction operations suffer from low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in data statistics and risk analysis, this application provides a solution. This solution employs a technical approach that involves collecting business data from preset collection points to obtain transaction link data; aggregating and statistically analyzing the transaction link data to form daily statistical indicators; generating periodic statistical indicators and structured analysis prompts based on the daily statistical indicators within a preset analysis period; and then conducting transaction risk analysis based on the structured analysis prompts. This approach moves transaction risk analysis beyond the manual review of scattered logs or fragmented reports, establishing a data foundation covering the entire transaction link through collection points. Then, through aggregation statistics, the raw transaction data is transformed into indicator data that can reflect the daily operational status. Further, through periodic statistics, the daily indicators are elevated to periodic analysis basis that can reflect the trend of time changes. Through structured analysis, the data prompts provide a unified, standardized and processable input basis for subsequent risk analysis. This solves the problems of low efficiency, limited coverage and difficulty in timely detection of potential trend risks in the operation data statistics and risk analysis of existing online fund transaction business. Compared with existing technologies, it realizes the continuous processing of transaction business operation data from collection, statistics, periodic processing to risk analysis, making the data coverage of the risk analysis process more complete, the analysis basis more concentrated, and improving the efficiency of identifying changes in transaction business trends and potential risks.

[0026] 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 or a risk analysis device for transaction business capable of performing the above functions. The following description uses a risk analysis device for transaction business as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide a risk analysis method for transaction business, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the risk analysis method for transaction business in this application.

[0028] In this embodiment, the risk analysis method for the transaction business includes steps S10 to S40: Step S10: Collect business data according to preset collection points to obtain transaction link collection data. The preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point.

[0029] It should be noted that the preset data collection points are fixed logical nodes pre-defined within the core transaction processing flow, used to collect transaction execution data. These preset collection points are distributed at the entry and exit points of the transaction processing flow, and each collection point collects a set of standardized transaction field information. The preset collection points provide a unified data source for subsequent link integration and performance statistics, ensuring the standardization and consistency of the collected data.

[0030] Additionally, business data acquisition involves extracting various technical indicators and business identifiers generated during the transaction process at corresponding nodes in the transaction workflow. Business data acquisition is implemented using Aspect-Oriented Programming (AOP) technology, ensuring that the acquisition process does not intrude on the original core transaction code. Business data acquisition can obtain full transaction execution data without affecting normal transaction processing, supporting subsequent statistical analysis.

[0031] Furthermore, the transaction link data is collected from various preset collection points, corresponding to the raw data of the entire operational status of a single transaction. The transaction link data includes three core categories: link identifier, transaction entry information, and transaction exit information. It can be linked together using a unified identifier to represent the entire process data of a single transaction. The transaction link data serves as the foundational data source for subsequent daily statistics and weekly analysis, directly impacting the accuracy of the analysis results.

[0032] Understandably, standardized data collection points are pre-set at three points: the entry point of the transaction processing flow, the successful transaction exit point, and the failed transaction exit point. Each collection point collects transaction information for fixed fields. Aspect-oriented programming (AOP) is used to weave the data collection logic before and after the execution of the transaction processing method. Data from each collection point is asynchronously sent to the link storage application (Apache Kafka) via a distributed message queue. The link storage application integrates the entry and exit data of the same transaction based on the link ID, matching them to form a complete execution record for a single transaction. Finally, all integrated transaction execution records are stored in a database, resulting in the transaction link collection data.

[0033] In one implementation, after sending the entry data, the first exit data, and the second exit data to the message queue, the link storage application can associate and cache the data collected from different collection points according to the link identifier, and determine the complete status of each transaction link based on the data source identifiers corresponding to the transaction entry collection point, the first transaction exit collection point, and the second transaction exit collection point. If both entry data and first exit data exist under the same link identifier, the transaction link corresponding to that link identifier is marked as a successful transaction link. If both entry data and second exit data exist under the same link identifier, the transaction link corresponding to that link identifier is marked as an abnormal transaction link. If only entry data exists under the same link identifier and no exit data is matched within a preset waiting time, the transaction link corresponding to that link identifier is marked as a link to be compensated, and the link to be compensated is written to the abnormal collection record table for supplementary verification in subsequent end-of-day tasks. Through this method, the transaction link collection data can simultaneously reflect the correlation between the transaction entry, successful transaction exit, and abnormal transaction exit, avoiding the problem that single-point collection data cannot support subsequent link statistics.

[0034] Step S20: Based on the data collected from the transaction link, perform task information aggregation and statistics to obtain daily statistical indicator data.

[0035] It should be noted that task information aggregation and statistics is a batch processing procedure that cleans, classifies, and summarizes daily transaction data according to preset statistical dimensions. Task information aggregation and statistics is triggered by a scheduled framework, and the processing object is all transaction data collected from the previous day. Task information aggregation and statistics can transform scattered individual transaction data into standardized dimensional statistical data, improving data usability and analysis efficiency.

[0036] In addition, the daily statistical indicator data is the statistical result obtained by aggregating the data collected from the transaction chain on a single day according to specified dimensions. The daily statistical indicator data covers four core indicators: error logs, transaction volume, maximum transactions per second (TPS), and response time. Each indicator corresponds to a different aggregation dimension. The daily statistical indicator data is stored according to the calendar day dimension, providing a standardized data foundation for subsequent weekly trend analysis and risk identification.

[0037] Understandably, the Spring task scheduling framework is used to manage the daily batch processing tasks, retrieving all transaction link data from the previous day at a fixed time in the early morning. First, the transaction link data is cleaned, discarding invalid records with timestamps outside the statistical period or with empty timestamps. Then, the cleaned data is aggregated and calculated according to the dimensions corresponding to four categories of indicators, yielding statistical results for each dimension. Finally, the statistical results from all dimensions are integrated and stored in the database to obtain complete daily statistical indicator data.

[0038] In one feasible implementation, step S20 may include steps S21 to S24: Step S21: Query transaction performance data from the transaction link data collected according to the preset end-of-day task time and statistical date to obtain the end-of-day pending data.

[0039] It should be noted that the preset end-of-day task time is a pre-set, fixed execution time used to trigger the daily data aggregation batch processing task. The preset end-of-day task time can be flexibly configured according to business operation conditions; in this embodiment, it is set to 3:00 AM daily. The preset end-of-day task time ensures that the end-of-day processing task is executed during off-peak transaction periods, avoiding impact on normal daytime transactions.

[0040] Additionally, the statistical date is a date parameter used to define the calendar day to which the data corresponding to this end-of-day processing belongs. The statistical date is usually the calendar day preceding the task execution date, i.e., T-1 day, used to clarify the time range of the data to be processed. The statistical date ensures that each end-of-day processing only targets transaction data for a specified date, avoiding data range confusion.

[0041] In addition, transaction performance data is the core data content reflecting the performance status of transaction operations within the data collected from the transaction chain. Transaction performance data includes key fields such as chain identifier, chain type, chain registration timestamp, processing time, and return code. Transaction performance data is the core foundational data for conducting daily performance statistics and subsequent risk analysis.

[0042] Additionally, the end-of-day pending data is a set of raw performance data extracted from transaction data collected according to the statistical date, awaiting subsequent cleaning and aggregation processing. The end-of-day pending data covers the performance records of all NetsUnion Funds transactions within a specified date, including both request and response data. This data is the direct processing object of the end-of-day batch processing workflow, providing a data source for subsequent integration and cleaning.

[0043] Understandably, the Spring task scheduling framework triggers a day-end processing task at a preset time, with the task carrying a specified statistical date parameter. Using the statistical date, application name, and function code as query criteria, it retrieves all transaction performance records for the corresponding date from the stored transaction chain data. All retrieved performance records are then aggregated and organized to form the day's pending processing data.

[0044] Step S22: Based on the link identifier and link type in the end-of-day pending data, integrate the request data and response data to obtain integrated link data.

[0045] It should be noted that the link identifier is a unique identifier used to mark the entire process of a single transaction. The link identifier is generated along with the transaction request and runs throughout the entire processing flow from the transaction entry point to the transaction exit point. The link identifier is the core basis for connecting data at different stages of a single transaction, enabling precise matching of request and response data.

[0046] Additionally, the link type is a classification identifier used to distinguish the processing stage of transaction data. Link types mainly include two categories: requests and responses, corresponding to data collected at the transaction entry point and data collected at the transaction exit point, respectively. The link type clearly identifies the stage of a single record in the transaction process, supporting subsequent data integration operations.

[0047] Additionally, the request data is collected at the transaction entry point and reflects the arrival status of the transaction request. The request data includes fields such as application name, function code, arrival timestamp, link identifier, and transaction type code. The request data records the basic attributes and time information at the time the transaction was initiated, and is one of the fundamental bases for calculating transaction processing time.

[0048] Additionally, response data is collected at the transaction exit point and reflects the link data of the transaction processing completion status. Response data includes fields such as application name, function code, response timestamp, processing time, return code, and link identifier. Response data records the transaction processing results and performance, serving as the core basis for performance statistics and error analysis.

[0049] Additionally, the link integration data is the complete transaction record data obtained by matching and merging the request and response data of the same transaction. Link integration data includes the full-process attributes, time information, performance parameters, and processing results of a single transaction. Link integration data eliminates the separation between request and response data, providing complete single-transaction data for subsequent cleaning and aggregation.

[0050] Understandably, the process involves iterating through all records in the end-of-day pending data, extracting the link identifier and link type fields from each record. Records with the same link identifier are grouped together as related data for the same transaction, and then the request and response data for the corresponding transaction are distinguished based on the link type. The request and response data fields for the same transaction are merged to form a single record containing complete transaction information. After all transactions are matched and merged, the complete link integration data is obtained.

[0051] Step S23: Preprocess the link integration data to obtain end-of-day preprocessed data.

[0052] It should be noted that preprocessing is a data cleaning operation that performs validity checks and removes outlier data from the integrated data. Preprocessing primarily verifies the validity and reasonableness of the time field, filtering out invalid records that do not meet statistical requirements. Preprocessing removes abnormal and interfering data, ensuring the validity and accuracy of the data used in subsequent aggregation calculations.

[0053] Additionally, the end-of-day preprocessed data is the set of valid transaction records retained after the integrated data has undergone preprocessing and cleaning. The end-of-day preprocessed data only includes valid transaction records with complete time fields and belonging to the statistical date. This data is the direct input for subsequent aggregation calculations and directly determines the quality of the daily statistical indicators.

[0054] Understandably, the request and response timestamps of each data link are verified sequentially, discarding invalid records with empty timestamps. Next, the dates corresponding to the two timestamps are verified, discarding records outside the current statistical date range. After all verifications are completed, all remaining valid records are aggregated to form the end-of-day preprocessing data.

[0055] In one implementation, when preprocessing the integrated link data, duplicate link records can be deduplicated based on the link identifier, retaining the link record with the most complete collection time or the latest response timestamp. Link records with missing return codes, processing times less than zero, empty transaction application names, or empty function codes can be marked as exceptions, and these marked link records are stored separately from normal link records. For link records with request and response timestamps but missing processing time fields, the processing time can be re-determined based on the request and response timestamps, and the re-determined processing time can be written into the corresponding link record. Through this preprocessing, the data entering the aggregation calculation can have a unified data caliber, and the interference of abnormal collection records on daily statistical indicator data can be reduced.

[0056] Step S24: Aggregate and calculate the preprocessed data at the end of the day according to the preset statistical dimensions to obtain daily statistical index data.

[0057] It should be noted that the preset statistical dimensions are pre-defined and serve as the statistical perspective and grouping basis for classifying and summarizing transaction data. Different indicator types correspond to different combinations of statistical dimensions, covering dimensions such as date, application name, function code, return code, and response time level. The preset statistical dimensions determine the granularity of daily statistical indicator data classification, supporting data analysis needs from different business perspectives.

[0058] Additionally, aggregation calculation is a process of grouping data according to preset statistical dimensions and performing statistical operations on the records within each group. Aggregation calculation performs corresponding operations for different indicator types, including counting, finding the maximum value, and interval grouping statistics. Aggregation calculation can transform scattered individual transaction records into statistical results summarized by dimensions, achieving data condensation and structuring.

[0059] In addition, the daily statistical indicators are the daily statistical results obtained by aggregating and calculating the pre-processed data at the end of the day according to preset statistical dimensions. The daily statistical indicators cover four core categories: error logs, transaction volume, maximum transactions per second, and response time. The daily statistical indicators are stored by calendar day, providing a standardized dimensional data foundation for subsequent weekly analysis.

[0060] Understandably, the pre-processed data at the end of the day is grouped according to the preset statistical dimensions corresponding to the four categories of indicators. Corresponding statistical operations are performed on each group: the error log indicator counts the number of records by dimension; the transaction volume indicator counts the number of transactions by dimension; the maximum transaction processing volume per second indicator takes the peak value by dimension; and the response time indicator counts the number of transactions in each time interval. The results of all the calculations are then integrated to form complete daily statistical indicator data, which is then stored in the database.

[0061] In one implementation, the daily statistical data may further include success rate data and maximum transaction volume per second (DPS) data. For the success rate data, the end-of-day preprocessed data can be grouped according to the business transaction date, transaction application name, and transaction function code. The success rate data for each group is determined based on the number of successful transactions indicated by return codes within each group and the total number of transactions within that group. For the maximum DPS data, the end-of-day preprocessed data can be grouped according to the business transaction date, transaction application name, and transaction function code. The transaction volume per second is determined based on the number of transactions corresponding to a unit time window within each group. The maximum DPS data is then determined from the transaction volumes corresponding to multiple unit time windows. Thus, the daily statistical data can cover multiple indicators such as error logs, transaction volume, success rate, response time, and maximum DPS, providing a more complete indicator foundation for subsequent periodic trend analysis.

[0062] In one feasible implementation, step S24 may include steps S241 to S245: Step S241: Obtain preset statistical parameters, wherein the preset statistical parameters include the business transaction date and the transaction application name.

[0063] It should be noted that the preset statistical parameters are pre-defined and serve as a set of basic parameters used to limit the scope and granularity of aggregated calculations. The preset statistical parameters include two core categories: time-based and business-based parameters, which are the prerequisites for conducting statistical analysis of various metrics. Preset statistical parameters ensure that the statistical analysis of all metrics maintains a consistent data range, avoiding inconsistencies in the statistical definitions of different metrics.

[0064] Additionally, the business transaction date is the calendar day on which the transaction occurred, corresponding to this daily statistical data; that is, the statistical date. The business transaction date is used to define the time range of the transaction data included in the statistics, ensuring that all indicators are calculated based on transaction data from the same date. The business transaction date is the core time identifier for daily statistical indicator data, used to distinguish statistical results from different dates.

[0065] Additionally, the transaction application name serves as an identifier to distinguish different transaction channels and business entities. Transaction application names include categories such as Alipay, Tenpay, other channels, and credit cards, corresponding to different fund transaction access channels. The transaction application name is one of the core grouping criteria for business-level statistics, supporting channel-specific performance analysis and risk assessment.

[0066] Understandably, pre-set statistical parameters are extracted from the configuration items of the end-of-day batch processing task. These extracted parameters include the business transaction date corresponding to this statistical analysis, as well as the names of all transaction applications to be analyzed. These extracted parameters serve as the unified basis for subsequent statistical analysis of various metrics, ensuring consistency in the statistical definitions of each metric.

[0067] Step S242: Perform error log statistics on the end-of-day preprocessed data according to the preset statistical parameters and transaction return codes to obtain error log indicator data.

[0068] It should be noted that transaction return codes are coded information used to identify the status of a single transaction processing result. Transaction return codes can distinguish between successful transaction processing and different types of processing failures or abnormal states, and are a core identifier for judging the health of transaction operations. Transaction return codes are a key basis for error statistics and anomaly troubleshooting, and can accurately locate different types of transaction failures.

[0069] Additionally, error log statistics are a statistical operation that categorizes and counts transaction failures and anomalies according to specified dimensions. Error log statistics use transaction return codes as the core classification basis, counting the number of transactions occurring for different error types. Error log statistics can quantify the scale of different errors, providing data support for anomaly analysis and risk identification.

[0070] Additionally, error log metrics data are statistical results obtained after performing error log statistics on the pre-processed data at the end of the day. Error log metrics data presents the number of transactions with various types of errors by date, application name, and return code, intuitively reflecting the occurrence of different errors. Error log metrics data is a core component of daily statistical metrics data and is used to assess the stability of transaction operations.

[0071] Understandably, transaction records within a specific range are filtered from the end-of-day preprocessing data using the transaction date and application name as filtering criteria. Within this filtered range, the data is grouped by transaction return code, and the number of transactions corresponding to each return code is counted. The date, application name, return code, and corresponding number of transactions are then associated and stored to form error log metrics data.

[0072] Step S243: Calculate the number of transactions based on the preprocessed data at the end of the day to obtain transaction volume index data.

[0073] It should be noted that transaction volume statistics are a statistical operation that counts valid transaction records according to specified dimensions. Transaction volume statistics use a single complete transaction chain as the counting unit, and count the total number of transactions under different business categories. Transaction volume statistics can reflect the transaction scale and activity level of different businesses, and are a basic indicator for assessing the operational status of the business.

[0074] Additionally, transaction volume metrics are statistical results obtained after performing transaction counts on the pre-processed data at the end of the day. Transaction volume metrics present the total number of transactions for each type of business, categorized by date, application name, and function code, providing a clear picture of the transaction scale of different business segments. Transaction volume metrics are a core component of daily statistical metrics, used to analyze business trends and traffic fluctuations.

[0075] Understandably, within the scope of the end-of-day preprocessing data, transactions are grouped by application name and transaction function code. Valid transaction records within each group are counted to obtain the total number of transactions for the corresponding business category that day. The date, application name, function code, and corresponding transaction count are then linked and stored to form transaction volume metrics data.

[0076] Step S244: Perform response time distribution statistics on the end-of-day preprocessed data according to the preset statistical parameters, transaction function code, and response time level to obtain response time index data.

[0077] It should be noted that the transaction function code is an coded identifier used to distinguish different transaction business types. The transaction function code corresponds to different business types such as UnionPay Quick Pay, UnionPay Payment Application, and UnionPay Quick Pay Refund Transaction, and is the core basis for detailed statistical analysis of business dimensions. The transaction function code enables the differentiation of different business types within the same application, supporting more granular performance analysis.

[0078] Additionally, response time levels are categorized according to the duration of transaction processing. There are six levels: less than 50 milliseconds, 50 to 100 milliseconds, 100 to 300 milliseconds, 300 to 500 milliseconds, 500 to 1 second, and greater than 1 second. Response time levels quantify the distribution of transaction performance, visually reflecting the speed structure of transaction processing.

[0079] Additionally, response time distribution statistics are a statistical operation that counts the number of transactions corresponding to each response time level according to a specified dimension. Response time distribution statistics can present the proportion and scale of transactions in different time intervals, and are a core tool for evaluating transaction processing performance. Response time distribution statistics can identify the scale of extremely time-consuming transactions, providing data direction for performance optimization.

[0080] Additionally, the response time metric data is a statistical result obtained by performing response time distribution statistics on the end-of-day preprocessed data. The response time metric data presents the number of transactions in each interval by date, application name, function code, and response time level. The response time metric data is a core component of the daily statistical metric data, used to evaluate transaction processing performance and identify time-consuming anomalies.

[0081] Understandably, transaction records within a specific range are filtered from the end-of-day preprocessing data using the transaction date and application name as filtering criteria. Within this filtered range, the data is grouped by application name, transaction function code, and response time level. The number of transactions for each group is counted, and the date, application name, function code, response time level, and corresponding number of transactions are associated and stored to form response time metric data.

[0082] Step S245: Generate daily statistical indicator data based on the error log indicator data, the transaction volume indicator data, and the response time indicator data.

[0083] It should be noted that the daily statistical indicator data is a complete daily transaction statistics dataset formed by integrating statistical results from all dimensions of the day. The daily statistical indicator data includes three core performance metrics: error logs, transaction volume, and response time, covering multi-dimensional grouped statistical results. The daily statistical indicator data is stored independently by calendar day, serving as the standardized data foundation for subsequent weekly analysis and risk assessment.

[0084] Understandably, the error log metrics, transaction volume metrics, and response time metrics calculated for the day are aggregated and integrated. These are then uniformly linked to basic attributes such as the corresponding business transaction date and transaction application name to form a complete set of multi-dimensional statistical data for the day. The integrated dataset is then written to the corresponding storage medium, completing the generation of the daily statistical metrics.

[0085] Step S30: Within a preset analysis period, generate periodic statistical indicator data based on the daily statistical indicator data, and construct structured analysis prompt data based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints.

[0086] It should be noted that the preset analysis period is a fixed time period set in advance for conducting centralized business analysis. The preset analysis period can be flexibly configured and adjusted according to business needs; in this embodiment, the natural week is used as the standard analysis period. The preset analysis period is used to define the data range for each analysis, ensuring the periodicity of the analysis process and the comparability of the data.

[0087] Additionally, periodic statistical indicator data is statistical data obtained by aggregating all daily statistical indicator data within a preset analysis period. Periodic statistical indicator data includes all daily statistics from the current and previous analysis periods, supporting month-on-month comparisons and trend analysis. It serves as a direct data source for weekly business analysis, covering core indicators such as transaction volume and response time.

[0088] Furthermore, structured analysis prompt data is input data formed by integrating periodic statistical indicator data, analysis task requirements, and output constraint rules in a format recognizable by the large language model. Structured analysis prompt data comprises five core components: role settings, data context, analysis instructions, format constraints, and security constraints. Structured analysis prompt data guides the large language model to complete the analysis task according to specified requirements, ensuring the standardization and validity of the output results.

[0089] Understandably, the analysis task is automatically triggered at a fixed time each week to extract all daily statistical indicator data for the previous two full natural weeks from the storage medium. The extracted multi-day statistical data is then standardized, converting the raw data into a combination of tabular format and natural language descriptions to form periodic statistical indicator data. An analysis framework is built based on this periodic statistical indicator data, sequentially setting five categories: analysis roles, data context, analysis tasks, output format, and security constraints. These five categories are then integrated into a unified input text, forming complete structured analysis prompt data.

[0090] In one feasible implementation, step S30 may include steps S31 to S35: Step S31: Determine the current cycle time range and the comparison cycle time range according to the preset analysis cycle.

[0091] It should be noted that the preset analysis period is a fixed time period set in advance for conducting centralized business analysis. The preset analysis period can be flexibly configured and adjusted according to business needs; in this embodiment, the natural week is used as the standard analysis period. The preset analysis period is used to define the data range for each analysis, ensuring the periodicity of the analysis process and the comparability of the data.

[0092] Additionally, the current period time range refers to the time interval within which the core statistical data targeted in this analysis task pertains. The current period time range is derived from the preset analysis period. It represents the core data boundary of this analysis and corresponds to the business runtime segments that require focused analysis.

[0093] Additionally, the comparison period time range is the time interval of the reference statistical data used for month-on-month comparisons with the current period. The comparison period time range has the same duration as the current period time range. The comparison period time range provides a benchmark for trend change analysis, and can intuitively present the fluctuation range and direction of the indicator.

[0094] Understandably, the pre-configured preset analysis cycle parameters are read to determine the time length and cycle start and end rules for a single analysis round. The start and end times of the current cycle are calculated according to the cycle rules, forming the current cycle time range. Then, shifting back one cycle of the same length, the start and end times of the reference comparison cycle are calculated, forming the comparison cycle time range.

[0095] Step S32: Based on the current period time range and the comparison period time range, extract statistical data from the daily statistical indicator data to obtain periodic statistical indicator data.

[0096] It should be noted that the periodic statistical indicator data is a multi-day, multi-dimensional statistical data set formed by summarizing the daily statistical results of the current period and the comparison period. The periodic statistical indicator data covers all indicators such as error logs, transaction volume, and response time for two complete periods, including daily multi-dimensional statistical details. This data serves as a direct data source for conducting periodic business analysis and risk identification, supporting trend judgment and month-on-month comparisons.

[0097] Understandably, the process involves using the current period's time range as the filtering condition to extract all statistical records for the corresponding date from the stored daily statistical indicator data. Then, using the comparison period's time range as the filtering condition, all daily statistical indicator records for the corresponding reference period are extracted. Finally, all daily statistical records extracted from the two periods are aggregated and integrated to form complete periodic statistical indicator data.

[0098] Step S33: Standardize the periodic statistical indicator data according to the transaction application name, function code, indicator type and transaction date to obtain standardized periodic indicator data.

[0099] It should be noted that the transaction application name is an identifier used to distinguish different transaction channels and business entities. Transaction application names include categories such as Alipay, Tenpay, other channels, and credit cards, corresponding to different fund transaction access channels. The transaction application name is one of the core business dimensions for standardized organization of periodic data, enabling the categorization of indicators by channel.

[0100] Additionally, function codes are coded identifiers used to distinguish different transaction types. Function codes correspond to different business types such as UnionPay Quick Pay, UnionPay Payment Application, and UnionPay Quick Pay Refund Transaction, and are the core basis for business dimension segmentation. Function codes enable the differentiation of indicators for different business types within the same application, supporting fine-grained business analysis.

[0101] Additionally, indicator types serve as classification identifiers to distinguish different performance statistics categories. Indicator types include four categories: error logs, transaction volume, maximum transactions per second, and response time, each corresponding to different statistical dimensions and calculation rules. Indicator types are the core classification basis for data standardization and organization, enabling the categorized presentation of different performance indicators.

[0102] Additionally, the transaction date is the calendar day on which the transaction occurred, corresponding to a single daily statistical data point. The transaction date serves as a time dimension identifier for periodic statistical data, clearly defining the temporal position of a single statistical record within the period. The transaction date provides a time benchmark for time-series analysis of trend changes, supporting the judgment of indicator trends in chronological order.

[0103] Additionally, standardized periodic indicator data consists of periodic-dimensional statistical data that has been formatted and organized in a unified manner. This data is organized systematically according to business dimensions, indicator types, and time dimensions, with a standardized format and consistent fields. Standardized periodic indicator data is compatible with the data reading requirements of large language models, improving the accuracy and efficiency of model analysis.

[0104] Understandably, the cyclical statistical indicator data is categorized and sorted according to the hierarchical order of trading application name, function code, indicator type, and trading date. The field naming and data format of various indicators are standardized, and the presentation order of data from different dimensions is regulated. After processing, a standardized cyclical indicator data dataset with a unified structure and clear hierarchy is formed.

[0105] In one implementation, when standardizing periodic statistical indicator data, statistical data within the current period and statistical data within the comparison period can be aligned using the same criteria based on the transaction application name, function code, indicator type, and transaction date, resulting in comparative indicator data for the same business object across two periods. This comparative data can record the indicator value for the current period, the indicator value for the comparison period, the direction of indicator change, and the magnitude of indicator change, generating an upward, downward, or stable indicator based on the direction of change. For response time indicators, the number of transactions between 500 milliseconds and one second, and those exceeding one second, can be separately marked as key time-consuming indicators. For error log indicators, the increase in the number of errors corresponding to return codes can be separately marked as abnormal growth information. Through this standardization process, the periodic statistical indicator data includes both original statistical values ​​and cross-period change information, facilitating subsequent structured analysis to accurately reflect the trend changes in the transaction business.

[0106] Step S34: Generate tabular indicator text and natural language indicator description based on the standardized periodic indicator data.

[0107] It should be noted that tabular indicator text presents standardized periodic indicator data in a row-and-column format. Tabular indicator text clearly corresponds to the indicator name, business category, time point, and numerical result, making the data structure intuitive and clear. Tabular indicator text allows large language models to quickly locate the specific values ​​of various indicators, improving the efficiency and accuracy of data reading.

[0108] Additionally, natural language indicator descriptions are explanatory content formed by converting core statistical data into fluent and natural textual expressions. Natural language indicator descriptions focus on presenting the overall level, extreme values, and significant fluctuation characteristics of key indicators, supplementing the textual descriptions of tabular data. Natural language indicator descriptions can help large language models quickly grasp the core characteristics of the data and guide the model to focus on changes in key indicators.

[0109] Understandably, the process involves extracting detailed information from standardized periodic indicator data and organizing it into a table format with rows and columns according to business categories and indicator types. Then, the core statistical characteristics of the data are extracted, including overall levels, peak data, and significant trends, and converted into clear natural language descriptions. Finally, both tabular numerical presentations and concise textual descriptions are generated simultaneously.

[0110] Step S35: Construct structured analysis prompt data based on the tabular indicator text, the natural language indicator description, the transaction role information, the transaction task information, the output format constraints, and the security constraints.

[0111] It should be noted that the trading role information is used to define the role and scope of capabilities of the large language model for analysis. The trading role information clearly defines the model's role as a financial trading monitoring analyst, possessing professional capabilities in trading data analysis and risk identification. This information guides the large language model to conduct analysis from a professional perspective, ensuring the professionalism and relevance of the output content.

[0112] Additionally, the transaction task information clarifies the specific analytical tasks and completion requirements of the large language model. This information includes five core analytical tasks: overall transaction situation assessment, detailed trend analysis, anomaly indicator identification, risk issue list, and improvement suggestions. The transaction task information clearly defines the model's analytical scope and output content, ensuring that the analysis results cover all required dimensions.

[0113] Additionally, output format constraints are rules that standardize the structure and format of the output content of large language models. Output format constraints limit the presentation style, content length, and organization of analysis conclusions, ensuring the consistency of the output format. Output format constraints also allow analysis results to adapt to subsequent storage and display needs, improving the usability of the results.

[0114] Additionally, security constraints are compliance requirements used to define the boundaries of large language model analysis and output rules. Security constraints explicitly require that the model conduct analysis solely based on provided objective data and must not speculate or fabricate unrepresented information. Security constraints ensure the authenticity and reliability of analytical conclusions and prevent the generation of false information.

[0115] Additionally, structured analysis prompt data is the complete instruction data used to input the large language model, formed by integrating all input elements. Structured analysis prompt data includes all elements such as data content, role settings, task requirements, formatting rules, and security rules. Structured analysis prompt data is the complete input that triggers the large language model to execute analysis tasks, directly determining the quality and compliance of the analysis output.

[0116] Understandably, the process begins by defining the trading role and task information, clarifying the model's analytical identity and required analytical tasks. Next, output format and security constraints are set to standardize the model's output format and analytical boundaries. Tabular indicator text and natural language indicator descriptions are then integrated into the aforementioned four types of rules in an orderly manner as the data context. This ultimately results in complete, structured analytical prompt data that can be directly input into a large language model.

[0117] For example, structured analysis prompts are instruction texts used to input large language models, guiding them to complete analysis tasks according to specified requirements; the corresponding English term is "Prompt." Structured analysis prompts organize their content according to fixed modules, covering five core elements: role settings, data context, task requirements, formatting rules, and security rules. Structured analysis prompts are the core input ensuring that large language models output compliant analysis results, directly determining the quality and direction of the analysis output.

[0118] Additionally, role definition clarifies the identity and corresponding professional capabilities of the AI ​​model. Role definition assigns the model the role of a financial transaction monitoring analyst, possessing professional capabilities in transaction data analysis and risk identification. Role definition guides the model to conduct analysis from a professional perspective, ensuring the professionalism and business suitability of the output.

[0119] Additionally, the data context comprises all transaction statistics provided to the large language model as the basis for analysis. Presented in structured text, the data context includes transaction statistics for each dimension from the previous week and the week-on-week changes. The data context forms the factual basis for the model's analysis, ensuring that the analysis is based on actual transaction activity.

[0120] Additionally, the analysis task instructions specify the concrete analytical tasks that the large language model needs to perform. These instructions define five core analytical tasks, covering overall transaction situation assessment, detailed trend analysis by transaction type or channel, anomaly indicator identification, a Top-5 risk issue list, and targeted improvement suggestions. The analysis task instructions guide the model to output analytical content according to specified dimensions, ensuring that the analysis results cover all necessary business perspectives.

[0121] Additionally, output format constraints are rules that standardize the presentation style and structure of the output content of a large language model. Output format constraints require the model to generate analysis conclusion text data according to a specific style, ensuring the consistency of format across different batches of output results. Output format constraints allow analysis conclusions to adapt to subsequent storage and display needs, improving the standardization of analysis results.

[0122] Additionally, security constraints are compliance requirements that limit the boundaries of large language model analysis and output rules. Security constraints require that the model conduct analysis solely based on provided objective data and must not speculate or fabricate information not reflected in the data. Security constraints ensure the authenticity and reliability of analytical conclusions and prevent the generation of unfounded speculations.

[0123] Understandably, when constructing structured analytical prompts, the first step is to define the model's role and responsibilities. Next, compiled transaction statistics are entered as the data context, providing the factual basis for the analysis. Then, five core analytical tasks are defined as the analytical task instructions, along with output format and security constraints. Finally, these five parts are systematically integrated to form a complete structured analytical prompt.

[0124] This embodiment includes an analysis example of the response time metric. The response time metric analysis example constructs specific analysis prompts for statistical data in the response time dimension, clearly defining the product scope, analysis requirements, and output examples. The response time metric analysis example intuitively demonstrates the composition logic and content format of structured analysis prompts, providing a reference for constructing analysis prompts across all dimensions.

[0125] Step S40: Perform risk analysis on the transaction business based on the structured analysis prompt data.

[0126] It should be noted that the risk analysis for trading operations is a process based on cyclical statistical indicators, identifying abnormal fluctuations, trend changes, and potential risks in trading activities. This risk analysis is automatically executed by a large-scale language model, outputting interpretable analytical conclusions and risk warnings, replacing the traditional manual review method. The risk analysis for trading operations can cover multi-dimensional trading operation indicators, uncovering potential risk patterns that are easily overlooked by manual analysis.

[0127] Understandably, the structured analysis prompts are input into the large language model, triggering its analysis task. The large language model, following the roles and task requirements defined in the prompts, conducts multi-dimensional analysis based solely on the provided objective statistical data. The large language model sequentially completes five categories of analysis: overall situation assessment, detailed trend analysis, anomaly indicator identification, risk assessment, and generation of improvement suggestions. Finally, the large language model outputs analysis conclusions in a pre-defined format, completing the risk analysis for the transaction.

[0128] This embodiment includes an analysis example of response time metrics. The response time metric analysis example covers three business types: quick payment products, refund products, and payment application products. It analyzes the distribution data of response time intervals for different card types and channels under each business type. The response time metric analysis example focuses on identifying the changes and trends in the number of extremely time-consuming transactions, and outputs analytical conclusions including explanations of interval distribution, peak values, month-on-month comparisons, and suggestions for improvement, thus clarifying the output specifications for risk analysis.

[0129] In one implementation, the structured analysis prompt data may include a role setting field, an indicator context field, a period comparison field, an analysis task field, an output format field, and a security constraint field. The role setting field is used to limit the input data processing by the preset analysis model according to the identity of a financial transaction monitoring analyst; the indicator context field is used to populate the transaction volume indicator data, success rate indicator data, error log indicator data, response time indicator data, and maximum transaction processing volume per second indicator data for the current period and the comparison period; the period comparison field is used to populate the direction and magnitude of indicator changes for the same transaction application name and the same function code in two periods; the analysis task field is used to limit the output of the preset analysis model to include the overall transaction trend, trends by transaction type, trends by channel, abnormal indicators, and a list of risk issues; the output format field is used to limit the output content to be organized according to the transaction application name, function code, indicator type, and analysis conclusion; and the security constraint field is used to limit the preset analysis model to generate analysis conclusions only based on the input periodic statistical indicator data. By splitting the structured analysis prompt data into multiple fields, the parsability of the input data can be improved, and the probability of the model output deviating from the statistical data can be reduced.

[0130] In one feasible implementation, step S40 may include steps S41 to S45: Step S41: Input the structured analysis prompt data into the preset analysis model to obtain the initial analysis conclusion data.

[0131] It should be noted that the preset analysis model is a pre-selected, large language model with natural language understanding and data analysis capabilities. Based on the input structured data, the preset analysis model can perform multi-dimensional business analysis and risk identification, outputting corresponding analysis text. The preset analysis model is the core execution vehicle for automated risk analysis, replacing traditional manual data analysis work.

[0132] Additionally, the initial analysis conclusion data consists of the raw analytical text data output by the pre-defined analytical model. This initial analysis conclusion data contains all the analytical content generated by the model based on the input data, covering multiple dimensions such as trends, anomalies, and risks. It provides the raw material for subsequent analysis and processing, forming the basis for generating the final analytical results.

[0133] Understandably, the constructed structured analysis prompt data is input into a pre-selected large language model, triggering the model to execute the analysis task. The model generates corresponding analysis text based on the rules and requirements in the prompt data and the provided statistical data. The raw analysis text output by the model is the initial analysis conclusion data.

[0134] Step S42: Analyze the index content of the initial analysis conclusion data to obtain the sub-analysis conclusion data.

[0135] It should be noted that indicator content parsing is a process of splitting and categorizing the initial analysis conclusions data. Based on different analysis dimensions and indicator types, indicator content parsing breaks down continuous analysis text into sub-items corresponding to different business functions and indicators. Indicator content parsing can decompose the original overall analysis text into structured sub-items, improving the manageability of the analysis results.

[0136] In addition, the sub-analysis conclusion data consists of a collection of sub-analysis texts obtained by parsing the indicator content and breaking it down according to business and indicator dimensions. The sub-analysis conclusion data corresponds to separate analysis conclusions for different applications, function codes, and indicator types. This sub-analysis conclusion data can support subsequent storage and display by dimension, improving the usability of the analysis results.

[0137] Understandably, the process involves reading the entire text of the initial analysis conclusion data and identifying and segmenting the content according to business categories and indicator types. Analysis content corresponding to different applications, function codes, and indicators is then extracted and categorized to form corresponding sub-items. All sub-items are then summarized to obtain the sub-analysis conclusion data.

[0138] Step S43: The sub-analysis conclusion data is formatted according to the preset output format to obtain formatted analysis conclusion data.

[0139] It should be noted that the preset output format is pre-defined, and the analysis conclusions must adhere to a unified presentation style and structural specifications. The preset output format clearly defines the way the analysis conclusions are expressed, the length of the content, and the organizational logic, ensuring the consistency of the output results. The preset output format allows the analysis conclusions to adapt to the requirements of subsequent storage and display, improving the standardization of the results.

[0140] Furthermore, formatted analysis conclusion data refers to analysis conclusion data that has been organized according to a preset output format and has a uniform presentation style. The structure, length, and organization of formatted analysis conclusion data all conform to preset specifications, and the content is clear and well-organized. Formatted analysis conclusion data is the intermediate standardized data used to generate the final risk analysis results.

[0141] Understandably, this involves reading all the sub-analysis conclusions and adjusting the content format item by item according to the preset output format requirements. This standardizes the expression logic and content length of each sub-conclusion, and regulates the text's organization and presentation order. The result is formatted analysis conclusion data that conforms to the specifications.

[0142] Step S44: Determine the transaction trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data based on the formatted analysis conclusion data.

[0143] It should be noted that trading trend analysis data reflects the overall trend of trading operations and the changing trends of specific business segments within a given period. This data covers the cyclical changes and fluctuations of core indicators such as trading volume and response time. Trading trend analysis data can intuitively present the overall direction of business operations, providing a trend-based basis for business analysis.

[0144] Additionally, anomaly indicator analysis data comprises the analytical data corresponding to indicators that deviate from normal operating levels. This data clearly identifies the relevant business segment, the abnormal behavior, and the degree of fluctuation for each anomaly indicator. Anomaly indicator analysis data can quickly pinpoint abnormal business processes, providing a clear direction for problem investigation.

[0145] Additionally, the risk issue list data is a summary list of core risk issues identified through analysis. The risk issue list data is sorted by risk level, clearly defining the specific manifestations and scope of impact of each risk issue. This data allows for a centralized presentation of core potential risks, improving the targeting and prioritization of risk monitoring.

[0146] Additionally, the improvement suggestion data contains optimization directions and handling recommendations for identified risks and anomalies. This data, combined with information on abnormal indicators, provides actionable optimization directions to support subsequent business optimization efforts. Furthermore, the improvement suggestion data connects analysis results with actual optimization actions, enhancing the practical value of the analysis findings.

[0147] Understandably, the formatted analysis conclusions data are categorized and extracted according to the analysis theme. Content related to overall and sub-business trends is extracted to form transaction trend analysis data. Content related to abnormal indicators and core risks is extracted to form abnormal indicator analysis data and risk issue list data, respectively. Content related to optimization directions is extracted to form improvement suggestion data.

[0148] In one implementation, when determining the risk issue list data, the following steps can be taken first: extract the transaction application name, function code, indicator type, current period indicator value, comparison period indicator value, and anomaly description corresponding to the abnormal indicators from the formatted analysis conclusion data. Then, determine the corresponding risk weight based on the indicator type. For example, an increase in the number of transactions exceeding one second in the response time indicator, an increase in the number of errors in the error log indicator, a decrease in the success rate indicator, and abnormal fluctuations in the transaction volume indicator can all be used as the basis for determining risk weights. Subsequently, sort the abnormal indicators according to their risk weights, the magnitude of indicator changes, and the duration of the anomalies to obtain the risk issue list data. Through this process, the risk issue list data can reflect the priority of different risk issues, facilitating operations personnel to prioritize the handling of transaction business risks with a larger impact or more obvious changing trends.

[0149] In one feasible implementation, step S44 may include steps S441 to S444: Step S441: Extract trend content based on the transaction volume change information, success rate change information, and response time change information in the formatted analysis conclusion data to obtain transaction trend analysis data.

[0150] It should be noted that transaction volume change information reflects the increase or decrease in the number of transactions for various business segments within different periods. This information includes the magnitude and direction of fluctuations in transaction volume across different business dimensions, serving as a core basis for analyzing business trends. Transaction volume change information can intuitively demonstrate the changing trends in business traffic, providing data support for assessing business operational status.

[0151] Additionally, the success rate change information reflects the changes in the percentage of successful transactions over different periods. This information is generated based on the statistical results of transaction return codes and reflects the changing trend of transaction stability. Success rate change information is an important reference for assessing the health of transaction operations and can reflect the trend of business stability.

[0152] Additionally, response time variation information reflects the changes in transaction processing time across different timeframes. This information includes changes in the proportion of transactions within each time interval and variations in the size of extremely time-consuming transactions. Response time variation information can demonstrate trends in transaction processing performance, providing a basis for performance trend analysis.

[0153] In addition, transaction trend analysis data is formed by extracting and integrating information on changes in various indicators, reflecting the overall trend of business operations within a period. Transaction trend analysis data covers changes in three core dimensions: transaction volume, success rate, and response time. It comprehensively presents the overall trend of business operations and is a core component of risk analysis results.

[0154] Understandably, the process involves traversing the entire formatted analysis conclusion data, identifying and extracting descriptions related to increases or decreases in trading volume to obtain information on changes in trading volume. Next, descriptions related to fluctuations in trading success rate are extracted to obtain information on changes in success rate. Then, descriptions related to increases or decreases in response time are extracted to obtain information on changes in response time. These three types of change information are then categorized and integrated according to business dimensions to form complete trading trend analysis data.

[0155] Step S442: Extract abnormal content based on the error log change information, response time change information, and indicator fluctuation information in the formatted analysis conclusion data to obtain abnormal indicator analysis data.

[0156] It should be noted that the error log change information reflects the changes in the number of various transaction errors over different periods. This information is generated based on statistical results of different return codes, demonstrating the trend of changes in the scale of various abnormal transactions. Error log change information is a core basis for identifying abnormal transaction operations and can pinpoint the types of errors showing abnormal growth.

[0157] Additionally, response time variation information reflects the changes in transaction processing time across different periods. This information includes changes in the proportion of transactions within each time interval and variations in the size of extremely time-consuming transactions. Response time variation information can reveal abnormal fluctuations in transaction processing performance and is an important reference for identifying performance anomalies.

[0158] Additionally, indicator fluctuation information reflects the degree to which various statistical indicators deviate from their normal operating levels. This information includes the month-on-month fluctuation range and daily extreme values, demonstrating the degree of abnormality in indicator operation. Indicator fluctuation information can quantify the degree of abnormality, providing a quantitative basis for anomaly identification.

[0159] Additionally, anomaly indicator analysis data is formed by extracting and integrating various anomaly-related information, reflecting the deviation of indicators from normal operating levels. Anomaly indicator analysis data clearly identifies the relevant business segment, the anomaly's behavior, and the degree of fluctuation. This data can quickly pinpoint abnormal business processes, providing a clear direction for problem investigation.

[0160] Understandably, the process involves traversing the entire formatted analysis conclusion data, identifying and extracting descriptions related to increases or decreases in the number of error logs to obtain error log change information. Next, descriptions related to abnormal fluctuations in response time are extracted to obtain response duration change information. Then, descriptions related to indicators deviating from normal levels are extracted to obtain indicator fluctuation information. These three types of anomaly-related information are categorized and integrated according to business dimensions to form complete anomaly indicator analysis data.

[0161] Step S443: Sort the issues according to the abnormal content and risk description content in the formatted analysis conclusion data to obtain the risk issue list data.

[0162] It should be noted that abnormal content refers to a detailed description of indicators that deviate from normal levels during trading operations. Abnormal content clearly defines the specific manifestations, timing, and scope of impact of the abnormal indicators, serving as the foundation for risk assessment. Abnormal content visually presents anomalies currently occurring, providing factual support for risk analysis.

[0163] Additionally, the risk description section analyzes and describes the potential business risks and negative impacts that abnormal indicators may cause. The risk description section extrapolates the potential business impact based on the abnormal situation, reflecting the risk level of the abnormal issue. The risk description section clarifies the severity of the abnormal issue, providing a basis for risk prioritization.

[0164] Additionally, the risk issue list data is a list of identified core risk issues prioritized by risk level. The risk issue list data arranges each risk item from highest to lowest risk severity, clearly defining the specific manifestations and potential impacts of each risk issue. This data provides a centralized view of core potential risks, helping users prioritize high-risk issues.

[0165] Understandably, this involves extracting all anomalies and their corresponding risk descriptions from the formatted analysis data, forming independent risk issue items. These risk issues are then prioritized according to their impact and severity, determining their order of priority. Finally, all the prioritized risk items are compiled and organized to create a risk issue list.

[0166] Step S444: Extract the suggested content based on the risk cause description and disposal suggestion description in the formatted analysis conclusion data to obtain improvement suggestion data.

[0167] It should be noted that the risk cause description is an analysis and description of the possible triggers and underlying logic of a risk problem. The risk cause description, by combining abnormal indicator conditions, deduces the relevant factors that led to the problem, clarifying the potential triggers of the risk. The risk cause description helps to understand the logic behind the risk's occurrence and provides a directional reference for subsequent optimization and handling.

[0168] Additionally, the recommended actions description outlines the optimization directions and remedial measures proposed for the identified risks. This description combines the risk's causes with the business scenario to provide actionable optimization directions, demonstrating its relevance and operability. Furthermore, the recommended actions description bridges risk identification with actual optimization actions, enhancing the practical value of the analysis results.

[0169] In addition, the improvement suggestion data is a collection of optimization guidance content for risk issues, formed by extracting and integrating various handling suggestions. The improvement suggestion data provides specific optimization directions for different risk issues, covering multiple dimensions such as performance and stability. This data can directly support subsequent business optimization and problem rectification work.

[0170] Understandably, the process involves iterating through the entire formatted analysis conclusion data, identifying and extracting descriptions related to the causes of risks, thus obtaining risk cause descriptions. Then, descriptions of optimization measures for each risk issue are extracted to obtain management suggestion descriptions. Finally, risk causes and corresponding management suggestions are categorized and integrated by risk item to form complete improvement suggestion data.

[0171] In this embodiment, the response time metric analysis example includes suggestions for attention and optimization regarding the issue of increased response time, which can serve as a specific reference for presenting improvement suggestions data.

[0172] Step S45: Generate transaction business risk analysis results based on the transaction trend analysis data, the abnormal indicator analysis data, the risk issue list data, and the improvement suggestion data.

[0173] It should be noted that the transaction risk analysis results are a complete weekly risk analysis outcome formed by integrating all analytical dimensions. The results cover four core categories: trends, anomalies, risks, and recommendations, comprehensively presenting the transaction operation status within the period. The transaction risk analysis results are the final output of the entire analysis process and can be directly used for business review and risk management.

[0174] In one implementation, after generating the transaction risk analysis results, these results can be linked and stored according to the data period, transaction application name, function code, indicator type, analysis conclusion, risk level, and generation time to obtain traceable analysis records. For multiple traceable analysis records generated in different analysis periods for the same transaction application name and function code, they can be sorted according to the data period to form a continuous risk analysis history. By saving traceable analysis records, subsequent queries and displays can directly locate trend changes and risk issues corresponding to a specific period, transaction application, or function code, and provide data basis for subsequent manual review.

[0175] Understandably, this involves logically integrating transaction trend analysis data, anomaly indicator analysis data, risk issue list data, and improvement suggestion data. A unified organizational framework and presentation hierarchy are established to create a complete analysis report. Ultimately, this generates a comprehensive transaction business risk analysis result.

[0176] This embodiment includes an analysis example of response time metrics. The response time metric analysis example covers three business types: quick payment products, refund products, and payment application products. It analyzes the distribution data of response time intervals for different card types and channels under each business type. The response time metric analysis example focuses on identifying the changes and trends in the number of extremely time-consuming transactions, and outputs analytical conclusions including explanations of interval distribution, peak values, month-on-month comparisons, and suggestions for improvement, clearly defining the output specifications for risk analysis results.

[0177] For example, in the process of constructing structured analysis prompt data based on the periodic statistical indicator data, response time can be used as the indicator type to be analyzed, and the response time distribution data of each application name, function code, and product within a preset analysis period can be used as periodic statistical indicator data. The response time distribution data can include the number of transactions corresponding to response time levels such as less than 50 milliseconds, 50 to 100 milliseconds, 100 to 300 milliseconds, 300 to 500 milliseconds, 500 to 1 second, and greater than 1 second. When constructing structured analysis prompt data, financial transaction monitoring analysts can be used as role information, and the main distribution range of response time for each product each day, the number of transactions between 500 milliseconds and 1 second, and the number of transactions greater than 1 second can be used. The number of transactions serves as the data context, identifying key response time ranges, determining whether transactions with extreme response times are concentrated, comparing response time changes between the current period and the comparison period, and outputting key concerns as analytical tasks. Security constraints are set, such as analyzing only based on provided data and outputting a "no data" conclusion when no data is available. When conducting risk analysis of transaction business based on the structured analysis prompts, analytical conclusions characterizing the response time changes of different products can be obtained. For example, if the response time of a certain product is mainly concentrated in the 100-millisecond to 300-millisecond range, and the number of transactions longer than 1 second increases significantly in the current period compared to the comparison period, then this product is identified as a response time risk object requiring attention, thus forming the transaction business risk analysis results.

[0178] This embodiment provides a risk analysis method for transaction business. Through a three-layer progressive processing flow of real-time data collection of the transaction chain, daily multi-dimensional indicator aggregation statistics, and weekly large-scale model structured analysis, it realizes full-cycle automated monitoring and intelligent risk analysis of the online transaction business operation status. It can automatically identify changes in transaction trends and hidden risk patterns without manual intervention, and output interpretable risk warnings and improvement suggestions.

[0179] Based on the first embodiment of this application, in the second 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, please refer to... Figure 2 Step S10 of the risk analysis method for the transaction business includes steps S11 to S14: Step S11: Collect entry collection data according to the transaction entry collection point in the preset collection points. The entry collection data includes: application name, function code, arrival timestamp, link identifier, transaction type code, request channel identifier, and requester network address.

[0180] It should be noted that the transaction entry point is a preset collection node set at the entry point of the business processing logic where the transaction request arrives. The transaction entry point is used to capture basic attribute information during the transaction initiation phase and record the initial state of the transaction entering the business processing flow. The transaction entry point is the first collection node for the entire transaction data chain, providing entry-side data support for subsequent chain integration.

[0181] Additionally, the entry-level data is collected at the transaction entry point and consists of various fields reflecting the initial state of the transaction request. This data includes basic information such as transaction identity, business attributes, and channel origin, comprehensively recording the core characteristics at the time of transaction initiation. Entry-level data serves as the initial data linking the entire transaction chain and, together with exit-level data, constitutes a complete transaction record.

[0182] Additionally, the application name serves as an identifier to distinguish different transaction channels and business entities. Application names include categories such as Alipay, Tenpay, other channels, and credit cards, corresponding to different fund transaction access channels. The application name is one of the core grouping criteria for business-level statistics, supporting channel-specific performance analysis and risk assessment.

[0183] Additionally, function codes are coded identifiers used to distinguish different transaction types. Function codes correspond to different business types such as UnionPay Quick Pay, UnionPay Payment Application, and UnionPay Quick Pay Refund Transaction, and are the core basis for detailed statistical analysis of business dimensions. Function codes enable the differentiation of different business types within the same application, supporting more granular performance analysis.

[0184] Additionally, the arrival timestamp records the time when a transaction request arrives at the business processing entry point. Accurate to the millisecond level, the arrival timestamp marks the specific point in time when a transaction enters the processing flow. It is one of the fundamental time parameters for calculating transaction processing time, providing a time benchmark for performance statistics.

[0185] Additionally, the link identifier is a unique identifier used to mark the entire process of a single transaction. The link identifier is generated along with the transaction request and runs throughout the entire processing flow from the transaction entry point to the transaction exit point. The link identifier is the core basis for connecting data at different stages of a single transaction, enabling precise matching between entry and exit data.

[0186] Additionally, transaction type codes are coded identifiers used to distinguish the major business category to which a transaction belongs. Transaction type codes correspond to different categories of fund transaction business, clearly defining the business attribute classification of the transaction. Transaction type codes can support statistical analysis by major business category, enabling coarse-grained classification of business data.

[0187] Additionally, the request channel identifier is used to mark the source channel of a transaction request. The request channel identifier can distinguish different access terminals or business entry points, clearly identifying the source path of the transaction request. The request channel identifier supports channel-specific transaction analysis, pinpointing the operational status and anomalies of different channels.

[0188] Additionally, the requester's network address is the network address information corresponding to the client that initiated the transaction request. The requester's network address identifies the source network node of the transaction request and can help locate the network environment from which the request originated. The requester's network address can be used to trace the source of abnormal transactions and assist in troubleshooting anomalies on the channel side.

[0189] Understandably, when a transaction request reaches the entry point of the business processing logic, the data collection logic at the transaction entry point is triggered. This logic sequentially extracts the application name, function code, arrival timestamp, link identifier, transaction type code, request channel identifier, and requester's network address fields for the current transaction. All extracted fields are then integrated into a single entry record to obtain the entry data.

[0190] Step S12: Collect first exit collection data according to the first transaction exit collection point in the preset collection points, wherein the first transaction exit collection point is used to indicate the exit collection point where the transaction processing is successful.

[0191] It should be noted that the first transaction exit collection point is a preset collection point set at the exit collection node where the transaction processing has successfully returned. The first transaction exit collection point is used to capture operational data during the normal completion phase of a transaction, recording performance and result information for successful transaction processing. The first transaction exit collection point is the successful exit node for the entire transaction data chain, providing data support for performance statistics and success rate calculations.

[0192] Additionally, the first exit data is collected at the first transaction exit point and consists of various fields reflecting the successful processing status of the transaction. The first exit data includes core information such as transaction result, processing time, and response time, comprehensively recording the operational status when the transaction is successfully completed. After matching the first exit data with the entry data, a complete end-to-end record of a successful transaction can be formed.

[0193] Understandably, when the business processing logic is completed and the transaction is successfully processed, the collection logic at the first transaction exit point is triggered. This collection logic extracts the application name, function code, response timestamp, processing time, return code, link identifier, transaction type code, request channel identifier, and requester network address fields for the corresponding transaction. All extracted fields are then integrated into a single exit record to obtain the first exit collection data.

[0194] Step S13: Collect second exit data according to the second transaction exit collection point in the preset collection points, wherein the second transaction exit collection point represents the exit collection point where the transaction processing is abnormal or failed.

[0195] It should be noted that the second transaction exit collection point is a preset collection point set at the exit collection node where transaction processing anomalies or failures occur. The second transaction exit collection point is used to capture operational data during the abnormal termination phase of a transaction, recording the performance and error information of the failed transaction processing. The second transaction exit collection point is the failure-side exit node for the entire transaction data chain, providing data support for error statistics and anomaly investigation.

[0196] Additionally, the second exit data is collected at the second transaction exit point and consists of various fields reflecting the transaction's anomaly or failure processing status. This second exit data includes core information such as error return codes, processing time, and response time, comprehensively recording the operational status at the time of transaction failure and termination. After matching the second exit data with the entry data, a complete end-to-end record of failed transactions can be formed, supporting error analysis and risk identification.

[0197] Understandably, when an exception occurs during the execution of business processing logic or a transaction fails, the data collection logic at the second transaction exit point is triggered. This logic extracts the application name, function code, response timestamp, processing time, return code, link identifier, transaction type code, request channel identifier, and requester's network address fields for the corresponding transaction. All extracted fields are then integrated into a single exit record to obtain the second exit data.

[0198] Step S14: Send the ingress collection data, the first egress collection data, and the second egress collection data to the message queue to obtain transaction link collection data.

[0199] It's important to note that Kafka, a message queue, is a middleware component used for asynchronous data transmission. Message queues enable asynchronous, decoupled data transmission, preventing data collection operations from impacting the execution efficiency of core transaction processes. Message queues are the core carrier for data transmission, ensuring reliable data transmission in high-concurrency scenarios.

[0200] Additionally, the transaction chain data collection is a complete set of raw transaction data obtained by collecting data from various preset collection points, transmitting it through a message queue, and then integrating and storing it. The transaction chain data collection includes entry and exit data for all transactions, covering full operational information for both successful and failed transactions. This data serves as the foundational data source for subsequent daily statistics and weekly analysis, directly impacting the accuracy of the analysis results.

[0201] Understandably, the collected entry data, first exit data, and second exit data are converted into message formats. All collected messages are asynchronously sent to a message queue, where the link storage application consumes the collected data. The link storage application integrates the entry and exit data of the same transaction based on the link identifier and stores them in the database, thus obtaining the transaction link collection data.

[0202] This embodiment provides a risk analysis method for transaction business. By using three standardized collection points—transaction entry, success exit, and failure exit—in conjunction with an asynchronous data collection scheme using message queues, it achieves non-intrusive real-time collection of transaction operation data across the entire chain. In high-concurrency transaction scenarios, it ensures the integrity and low latency of data collection without impacting the performance of core transaction processing flows.

[0203] For example, to help understand the implementation process of the risk analysis method for transaction business obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart illustrating a risk analysis method for trading operations is provided, specifically: The process is organized into three phases: online, 3 AM at the end of the day, and weekly. The online phase is used to collect technical indicators during the transaction processing. After the fund processing begins, the collected transaction data is sent to Kafka via AOP (Aspect-Oriented Programming). The consumer then retrieves the messages and stores the technical indicator data in the database, finally ending the online collection process. This phase primarily generates transaction data during fund processing. The 3 AM at the end of the day phase is used to summarize the daily technical indicators. The process begins by querying performance data and retrieving the stored transaction performance data, followed by data cleaning. The process involves several stages: 1) Aggregating and calculating daily statistical data and storing it in the database, culminating in the end-of-day processing flow. This stage primarily organizes the raw transaction data into daily statistical indicators suitable for subsequent analysis. 2) The weekly stage is used to complete periodic risk analysis. The process begins by querying daily data weekly to obtain daily statistical data within the preset analysis period. Then, data standardization is performed to convert the statistical data into structured data suitable for analysis. Subsequently, AI analysis is invoked, and a large model is used to generate transaction business trends and risk analysis content. The analysis conclusions are then saved, and the weekly analysis process ends. This stage primarily forms analytical conclusions based on periodic statistical indicators to support risk identification in the online fund transaction business.

[0204] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the risk analysis method of the transaction business of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0205] This application also provides a risk analysis device for trading operations; please refer to... Figure 4 The risk analysis device for the transaction business includes: The data acquisition module 10 is used to collect business data according to preset acquisition points to obtain transaction link acquisition data. The preset acquisition points include a transaction entry acquisition point, a first transaction exit acquisition point, and a second transaction exit acquisition point. The aggregation and statistics module 20 is used to aggregate and statistically analyze task information based on the data collected from the transaction link to obtain daily statistical indicator data. The data statistics module 30 is used to generate periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and to construct structured analysis prompt data based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints. The risk analysis module 40 is used to perform risk analysis on transaction business based on the structured analysis prompt data.

[0206] The risk analysis device for transaction business provided in this application, employing the risk analysis method for transaction business in the above embodiments, can solve the technical problems of low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in the statistical analysis of operational data and risk analysis of existing online fund transaction businesses. Compared with the prior art, the beneficial effects of the risk analysis device for transaction business provided in this application are the same as those of the risk analysis method for transaction business provided in the above embodiments, and other technical features in the risk analysis device for transaction business are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0207] In one embodiment, the aggregation and statistics module 20 is further configured to query transaction performance data from the transaction link data collected based on the preset end-of-day task time and statistical date to obtain end-of-day pending data; Based on the link identifier and link type in the end-of-day pending data, the request data and response data are integrated to obtain the integrated link data; The integrated link data is preprocessed to obtain end-of-day preprocessed data; The daily preprocessed data is aggregated and calculated according to preset statistical dimensions to obtain daily statistical indicator data.

[0208] In one embodiment, the aggregation statistics module 20 is further configured to obtain preset statistical parameters, wherein the preset statistical parameters include the business transaction date and the transaction application name; Error log statistics are performed on the end-of-day preprocessed data based on the preset statistical parameters and transaction return codes to obtain error log indicator data. Based on the transaction count statistics of the end-of-day preprocessed data, transaction volume index data is obtained; Based on the preset statistical parameters, transaction function codes, and response time levels, the response time distribution of the end-of-day preprocessed data is statistically analyzed to obtain response time index data. Daily statistical data is generated based on the error log data, the transaction volume data, and the response time data.

[0209] In one embodiment, the data statistics module 30 is further configured to determine the current period time range and the comparison period time range according to the preset analysis period; Based on the current period time range and the comparison period time range, statistical data is extracted from the daily statistical indicator data to obtain periodic statistical indicator data; The periodic statistical indicator data is standardized based on the transaction application name, function code, indicator type, and transaction date to obtain standardized periodic indicator data. Generate tabular indicator text and natural language indicator descriptions based on the standardized periodic indicator data; Structured analysis prompt data is constructed based on the tabular indicator text, the natural language indicator description, the transaction role information, the transaction task information, the output format constraints, and the security constraints.

[0210] In one embodiment, the risk analysis module 40 is further configured to input the structured analysis prompt data into a preset analysis model to obtain initial analysis conclusion data; The initial analysis conclusion data is parsed to obtain the sub-analysis conclusion data; The sub-analysis conclusion data is formatted according to the preset output format to obtain formatted analysis conclusion data; Based on the formatted analysis conclusions, determine the transaction trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data; The transaction business risk analysis results are generated based on the transaction trend analysis data, the abnormal indicator analysis data, the risk issue list data, and the improvement suggestion data.

[0211] In one embodiment, the risk analysis module 40 is further configured to extract trend content based on the transaction volume change information, success rate change information, and response time change information in the formatted analysis conclusion data to obtain transaction trend analysis data; Based on the error log change information, response time change information, and indicator fluctuation information in the formatted analysis conclusion data, abnormal content is extracted to obtain abnormal indicator analysis data. Based on the abnormal content and risk description content in the formatted analysis conclusion data, the issues are sorted to obtain a risk issue list data; Based on the risk cause description and disposal suggestion description in the formatted analysis conclusion data, the suggestion content is extracted to obtain improvement suggestion data.

[0212] In one embodiment, the data acquisition module 10 is further configured to acquire entry acquisition data based on the transaction entry acquisition point among the preset acquisition points, wherein the entry acquisition data includes: application name, function code, arrival timestamp, link identifier, transaction type code, request channel identifier, and requester network address; According to the first transaction exit collection point in the preset collection points, first exit collection data is collected, wherein the first transaction exit collection point is used to indicate the exit collection point where the transaction processing is successful and returned. According to the second transaction exit collection point in the preset collection points, collect the second exit collection data, wherein the second transaction exit collection point represents the exit collection point where the transaction processing is abnormal or failed; The ingress collection data, the first egress collection data, and the second egress collection data are sent to the message queue to obtain the transaction link collection data.

[0213] This application provides a risk analysis device for transaction business, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the risk analysis method for transaction business in the above embodiment 1.

[0214] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a risk analysis device suitable for implementing transaction services in the embodiments of this application. The risk analysis device for transaction services in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), tablets, PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The risk analysis device for transaction operations shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0215] like Figure 5As shown, the risk analysis device for trading operations 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 ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the risk analysis device for trading operations. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the risk analysis equipment for trading operations to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows risk analysis equipment for trading operations with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0216] 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.

[0217] The risk analysis device for transaction services provided in this application, employing the risk analysis method for transaction services in the above embodiments, can solve the technical problems of low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in the statistical analysis of operational data and risk analysis of existing online fund transaction services. Compared with the prior art, the beneficial effects of the risk analysis device for transaction services provided in this application are the same as those of the risk analysis method for transaction services provided in the above embodiments, and other technical features in the risk analysis device for transaction services are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0218] 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.

[0219] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0220] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to perform the risk analysis method for transaction business in the above embodiments.

[0221] 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, 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, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), 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, 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.

[0222] The aforementioned computer-readable storage medium may be included in the risk analysis equipment for the transaction business; or it may exist independently and not be assembled into the risk analysis equipment for the transaction business.

[0223] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a risk analysis device for transaction operations, the risk analysis device for transaction operations performs the following actions: collects business data based on preset collection points to obtain transaction link collection data, wherein the preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point; aggregates and statistically analyzes task information based on the transaction link collection data to obtain daily statistical indicator data; generates periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and constructs structured analysis prompt data based on the periodic statistical indicator data, wherein the structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints; and performs risk analysis of the transaction business based on the structured analysis prompt data.

[0224] 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++, as well as 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 LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0225] 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.

[0226] 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.

[0227] 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 risk analysis method for the aforementioned transaction business. This solves the technical problems of low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in existing online fund transaction business data statistics and risk analysis. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the risk analysis method for transaction business provided in the above embodiments, and will not be repeated here.

[0228] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the risk analysis method for transaction business as described above.

[0229] The computer program product provided in this application can solve the technical problems of low efficiency, limited coverage, and difficulty in timely detection of potential trend risks in the statistical analysis and risk analysis of existing online fund transaction business. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the risk analysis method for transaction business provided in the above embodiments, and will not be repeated here.

[0230] 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 risk analysis method for transaction business, characterized in that, The method includes: Business data is collected based on preset collection points to obtain transaction link collection data. The preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point. Based on the data collected from the transaction chain, task information is aggregated and statistically analyzed to obtain daily statistical indicator data; Within a preset analysis period, periodic statistical indicator data is generated based on the daily statistical indicator data, and structured analysis prompt data is constructed based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints. Risk analysis of transaction operations is performed based on the structured analysis data.

2. The method as described in claim 1, characterized in that, The step of aggregating and statistically analyzing task information based on the data collected from the transaction link to obtain daily statistical indicator data includes: Based on the preset end-of-day task time and statistical date, query the transaction performance data from the data collected in the transaction link to obtain the end-of-day pending data; Based on the link identifier and link type in the end-of-day pending data, the request data and response data are integrated to obtain the integrated link data; The integrated link data is preprocessed to obtain end-of-day preprocessed data; The daily preprocessed data is aggregated and calculated according to preset statistical dimensions to obtain daily statistical indicator data.

3. The method as described in claim 2, characterized in that, The step of aggregating and calculating the preprocessed data at the end of the day according to a preset statistical dimension to obtain daily statistical indicator data includes: Obtain preset statistical parameters, wherein the preset statistical parameters include the business transaction date and the transaction application name; Error log statistics are performed on the end-of-day preprocessed data based on the preset statistical parameters and transaction return codes to obtain error log indicator data. Based on the transaction count statistics of the end-of-day preprocessed data, transaction volume index data is obtained; Based on the preset statistical parameters, transaction function codes, and response time levels, the response time distribution of the end-of-day preprocessed data is statistically analyzed to obtain response time index data. Daily statistical data is generated based on the error log data, the transaction volume data, and the response time data.

4. The method as described in claim 1, characterized in that, The steps of generating periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and constructing structured analysis prompt data based on the periodic statistical indicator data, wherein the structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints, include: The current period time range and the comparison period time range are determined according to the preset analysis period; Based on the current period time range and the comparison period time range, statistical data is extracted from the daily statistical indicator data to obtain periodic statistical indicator data; The periodic statistical indicator data is standardized based on the transaction application name, function code, indicator type, and transaction date to obtain standardized periodic indicator data. Generate tabular indicator text and natural language indicator descriptions based on the standardized periodic indicator data; Structured analysis prompt data is constructed based on the tabular indicator text, the natural language indicator description, the transaction role information, the transaction task information, the output format constraints, and the security constraints.

5. The method as described in claim 1, characterized in that, The steps for conducting risk analysis of transaction operations based on the structured analysis data include: The structured analysis prompts are input into a preset analysis model to obtain initial analysis conclusions. The initial analysis conclusion data is parsed to obtain the sub-analysis conclusion data; The sub-analysis conclusion data is formatted according to the preset output format to obtain formatted analysis conclusion data; Based on the formatted analysis conclusions, determine the transaction trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data; The transaction business risk analysis results are generated based on the transaction trend analysis data, the abnormal indicator analysis data, the risk issue list data, and the improvement suggestion data.

6. The method as described in claim 5, characterized in that, The steps for determining the trading trend analysis data, abnormal indicator analysis data, risk issue list data, and improvement suggestion data based on the formatted analysis conclusion data include: Based on the changes in trading volume, success rate, and response time in the formatted analysis conclusion data, trend content is extracted to obtain trading trend analysis data. Based on the error log change information, response time change information, and indicator fluctuation information in the formatted analysis conclusion data, abnormal content is extracted to obtain abnormal indicator analysis data. Based on the abnormal content and risk description content in the formatted analysis conclusion data, the issues are sorted to obtain a risk issue list data; Based on the risk cause description and disposal suggestion description in the formatted analysis conclusion data, the suggestion content is extracted to obtain improvement suggestion data.

7. The method as described in claim 1, characterized in that, The step of collecting business data according to preset collection points to obtain transaction link collection data, wherein the preset collection points include a transaction entry collection point, a first transaction exit collection point, and a second transaction exit collection point, includes: Based on the transaction entry collection point in the preset collection points, entry collection data is collected, wherein the entry collection data includes: application name, function code, arrival timestamp, link identifier, transaction type code, request channel identifier, and requester network address; According to the first transaction exit collection point in the preset collection points, first exit collection data is collected, wherein the first transaction exit collection point is used to indicate the exit collection point where the transaction processing is successful and returned. According to the second transaction exit collection point in the preset collection points, collect the second exit collection data, wherein the second transaction exit collection point represents the exit collection point where the transaction processing is abnormal or failed; The ingress collection data, the first egress collection data, and the second egress collection data are sent to the message queue to obtain the transaction link collection data.

8. A risk analysis device for transaction operations, characterized in that, The device includes: The data acquisition module is used to collect business data according to preset acquisition points to obtain transaction link acquisition data. The preset acquisition points include a transaction entry acquisition point, a first transaction exit acquisition point, and a second transaction exit acquisition point. The aggregation and statistics module is used to aggregate and statistically analyze task information based on the data collected from the transaction link to obtain daily statistical indicator data. The data statistics module is used to generate periodic statistical indicator data based on the daily statistical indicator data within a preset analysis period, and to construct structured analysis prompt data based on the periodic statistical indicator data. The structured analysis prompt data includes transaction role information, transaction task information, output format constraints, and security constraints. The risk analysis module is used to perform risk analysis on transaction business based on the structured analysis prompt data.

9. A risk analysis device for trading operations, 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 risk analysis method for transaction operations 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 risk analysis method for transaction business as described in any one of claims 1 to 7.

Images