Financial monitoring system based on real-time data processing and intelligent analysis

Abstract

The invention discloses a financial monitoring system based on real-time data processing and intelligent analysis, and relates to the technical field of financial information, and the system comprises a bill collection module which employs a configuration API interface, carries high-concurrency data streams through a distributed message queue, carries out the real-time connection of an upstream business system and a financial system, and receives bill detail data; and the analysis and check task arrangement module manages the task dependency relationship based on a directed acyclic graph model, and arranges a data pulling task, a bill general task and a bill check task according to a preset rule. According to the financial monitoring system provided by the invention, the automation and intelligence level of financial management is remarkably improved by integrating real-time data processing and intelligent analysis technologies, the system adopts a configured API interface and a distributed message queue, efficient butt joint with an upstream business system and a financial system is realized, and the financial management efficiency is improved. The real-time performance and accuracy of data receiving are ensured, and the data processing flow is more flexible and controllable.

Description

Technical Field

[0001] This invention relates to the field of financial information technology, specifically to a financial monitoring system based on real-time data processing and intelligent analysis. Background Technology

[0002] In the field of corporate financial management, the accuracy, timeliness, and completeness of financial data are directly related to the scientific nature and compliance of business decisions. With the expansion of business scale and the diversification of business models, financial data is experiencing explosive growth, and data sources are becoming increasingly complex, encompassing multiple channels such as upstream business systems and financial systems. This places higher demands on the real-time nature of data processing and the intelligence of analysis. Traditional financial monitoring methods, relying on basic data collection and manual verification processes, are gradually showing insufficient adaptability in areas such as data integration, task scheduling, and anomaly warning. They are unable to meet the actual needs of modern enterprises for refined financial management and proactive risk prevention, necessitating technological innovation to improve the automation and intelligence level of financial monitoring.

[0003] Currently, existing financial monitoring methods have many shortcomings in practical applications: the data collection stage lacks flexible configurable interfaces, resulting in high integration costs when adding new business systems; data format compatibility is limited, easily leading to data delays or incompleteness; data processing relies excessively on manual operation and traditional tools, making it difficult to efficiently process large-scale data, and the flexibility of custom analysis rules is insufficient, easily leading to result deviations due to human factors; the analysis process lacks comprehensive task orchestration and real-time monitoring mechanisms, task dependency management is complex, and anomalies are difficult to detect and respond to in a timely manner; at the same time, the data traceability and security assurance mechanisms are imperfect, posing difficulties for financial compliance and risk assessment. To address these issues, we propose a financial monitoring system based on real-time data processing and intelligent analysis. Summary of the Invention

[0004] To address the aforementioned technical issues, a financial monitoring system based on real-time data processing and intelligent analysis is provided. This technical solution resolves the problems of insufficient flexibility in data acquisition interface configuration, high integration costs for new systems and limited format compatibility; over-reliance on manual labor and traditional tools, making it difficult to efficiently process large-scale data, insufficient flexibility in custom analysis rules; lack of comprehensive task orchestration and real-time monitoring, resulting in delayed anomaly response; and the need for improved data traceability and security mechanisms.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A financial monitoring system based on real-time data processing and intelligent analysis includes: a bill collection module, an analysis and verification task scheduling module, a verification result query and processing module, a configuration management module, and a monitoring and alarm module; The bill collection module is used to connect to the upstream business system in real time, and to receive bill details data by accepting high-concurrency data streams through a distributed message queue. The analysis and verification task scheduling module is electrically connected to the bill collection module. The analysis and verification task scheduling module is used to schedule data retrieval tasks, total bill tasks and bill verification tasks according to preset rules, automatically process various types of data and generate task result data. The verification result query and processing module is electrically connected to the analysis and verification task scheduling module. The verification result query and processing module is used to provide bill data query and processing functions, and expenditure finance specialists can view the monitoring results and respond to issues in real time. The configuration management module is used to centrally manage and flexibly configure data collection elements and task orchestration configuration information through a visual configuration interface. The monitoring and alarm module is used to monitor the system's operating status in real time. It adopts a multi-level alarm strategy to notify relevant personnel through multiple communication channels when data anomalies occur.

[0006] Preferably, the bill collection module includes a configurable data collection interface; The configurable data collection interface allows for flexible configuration of the billing data structure through a unified data structure definition mechanism; Administrators use a visual interface to predefine data structure templates, which include: field names, data types, constraints, and data mapping rules. The bill collection module automatically generates a data receiving adapter based on the template. When an enterprise adds an upstream business system, the administrator enters the data source type, connection parameters, and data format specifications of the new system in the configuration interface, and the bill collection module dynamically loads the configuration to complete the integration. The configurable data collection interface supports three data formats: JSON, XML, and CSV, and converts data into standard formats through a built-in parser. During the data reception process, the interface performs real-time data verification, checking field integrity, data type matching, and constraint compliance, and filtering out invalid or abnormal data.

[0007] Preferably, the bill collection module uses a unified collection interface to receive bill detail data reported by the upstream system, and internally uses a distributed message queue to asynchronously smooth out high-concurrency data streams. The specific implementation method is as follows: Upstream business systems report detailed bill data by calling a unified bill collection interface; After receiving the data, the bill collection module uses RocketMQ message queues internally for asynchronous peak shaving to support high concurrency scenarios. RocketMQ is deployed in a cluster environment and uses a topic and tag mechanism to classify and route the data. The bill collection module acts as a consumer instance, asynchronously pulling data from the queue and using a partitioning mechanism to achieve parallel processing. The bill collection module is configured with multiple consumer groups, each responsible for a specific data partition, and the data is evenly distributed through a load balancing algorithm. The queue mechanism implements a backpressure control strategy. When the data processing speed is lower than the data inflow rate, it automatically reduces the frequency of consumer fetching and dynamically increases the number of consumer instances. After receiving the data, the module performs preliminary cleaning and formatting, and outputs it to the analysis and verification task scheduling module.

[0008] Preferably, the analysis and verification task orchestration module includes an intelligent task orchestration engine; The intelligent task orchestration engine is used to perform personalized configurations for different bill reconciliation businesses. The functional components of the intelligent task orchestration engine include: a task dependency relationship construction submodule, a task scheduling and execution submodule, a state management and storage submodule, a subsequent task triggering submodule, and a rule configuration and adaptation submodule. The task dependency construction submodule is used to parse the logical relationships between tasks, generate a directed acyclic graph, clarify the execution order and dependency conditions of tasks, and ensure that tasks proceed in an orderly manner according to preset logic. The tasks include: data retrieval, analysis and summarization, and verification. The task scheduling and execution submodule is used to send the initial task to the execution queue, trigger the task to run in the adapted environment, monitor the task progress and resource usage in real time, trigger an alarm immediately if data error or execution failure occurs, and manage shared resources through a resource lock mechanism. The status management and storage submodule is used to record the execution status, execution time and output results of each task, forming a traceable task execution log, which provides data support for subsequent queries and troubleshooting. The subsequent task triggering module is used to intelligently determine whether to trigger subsequent tasks based on task dependencies and the execution results of previous tasks. At the same time, it plans the execution order of subsequent tasks by taking into account task priority and system resource availability. The execution modes supported include parallel and serial. The rule configuration and adaptation module allows users to customize task orchestration rules and logic according to the needs of different billing verification businesses, and quickly build personalized task processes through a visual configuration interface.

[0009] Preferably, the intelligent task orchestration engine performs personalized configuration in the following manner: Through the visual configuration interface provided by the rule configuration and adaptation submodule, the task flow rules defined by the user for a specific type of bill reconciliation business are received. The task flow rules include the execution logic of one or more task nodes, the dependencies between nodes, and the branching conditions after a node succeeds or fails. The task dependency construction submodule automatically generates a concrete directed acyclic graph based on the task flow rules. This directed acyclic graph clearly defines the execution order and triggering conditions between the data retrieval task, the bill summary task, and the bill verification task.

[0010] Preferably, the specific process by which the task scheduling and execution submodule manages shared resources using a resource lock mechanism includes: When allocating shared data resources for a task to access, the system first attempts to acquire the mutex lock corresponding to the resource. If the acquisition is successful, the task is triggered to execute. During the task execution, access to the resource is locked until the task is completed or the timeout occurs, at which point the lock is released. If the acquisition fails, the task is placed in a waiting queue and scheduled in a queue to avoid race conditions for the same shared data resource when multiple tasks are executed concurrently.

[0011] Preferably, the process by which the state management and storage submodule records the task execution state is as follows: When the task scheduling and execution submodule triggers a task node to start execution, a status record is created in the database and marked as "in execution", and the start timestamp is recorded at the same time; After the task is completed, update the status record to "success" or "failure", and record the end timestamp, output result summary or error log; The status record is associated with a unique identifier for the task node.

[0012] Preferably, the specific logic of the subsequent task triggering submodule intelligently triggering subsequent tasks based on task dependencies and execution results is as follows: Listen for status update events of its predecessor tasks; when a predecessor task's status is updated to "success", check the directed acyclic graph to identify all subsequent tasks that have that task as a direct predecessor. For each eligible subsequent task, further verification is performed to confirm whether all other prerequisites have been met. If all prerequisites are met, the subsequent task is submitted to the execution queue of the task scheduling and execution submodule for scheduling and execution, taking into account the current system load and the preset task priority.

[0013] Preferably, the verification result query processing module adopts a scripted query processing mechanism to realize a unified query processing function; The scripted query processing mechanism is configured as follows: for different bill types, customized settings are pre-defined in the configuration management module using scripting, defining the data query logic and result processing rules for that type of bill; When a finance specialist initiates a query request, the verification result query processing module automatically identifies the bill type and calls the corresponding preset script. By executing the query logic defined in the script, it efficiently retrieves the target data from the repository and encapsulates and responds to the data according to the result processing rules defined in the script.

[0014] Preferably, in the monitoring and alarm module, the multi-level alarm strategy specifically includes: Different levels of abnormal events and their corresponding alarm levels are predefined; the abnormal events include data reception delay, task execution failure, and verification result deviation exceeding the threshold. When an abnormal event is detected, the notification channel and recipients are determined according to its alarm level. For low-level warnings, in-system messages or emails are used for notification. For high-level alarms, SMS or instant messaging APIs are used to trigger strong reminder notifications and escalate them to higher-level management personnel to ensure that alarm information can be responded to in a timely manner.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: The financial monitoring system proposed in this invention significantly improves the automation and intelligence of financial management by integrating real-time data processing and intelligent analysis technologies. The system employs configurable API interfaces and distributed message queues to achieve efficient integration with upstream business and financial systems, ensuring the real-time and accurate reception of data. Its task orchestration mechanism, based on a directed acyclic graph model, makes the data processing flow more flexible and controllable, automatically adapting to the analysis needs of different business scenarios. The built-in rule engine and predefined verification rule library support hot loading and version management of rules, enhancing the flexibility and maintainability of analysis rules. A comprehensive monitoring and alarm module ensures real-time monitoring of system status and timely response to anomalies, effectively reducing financial risks. Attached Figure Description

[0016] Figure 1 This is a diagram showing the module connection architecture of the financial monitoring system of the present invention; Figure 2 This is a diagram showing the overall architecture of the financial monitoring system of the present invention. Detailed Implementation

[0017] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0018] Reference Figure 1 and Figure 2As shown, a financial monitoring system based on real-time data processing and intelligent analysis includes a bill collection module. This module uses a unified, configurable API interface and a RocketMQ distributed message queue to handle high-concurrency data streams, connecting in real-time with upstream business and financial systems to receive detailed bill data. RocketMQ is deployed in a cluster environment and uses a topic and tag mechanism to classify and route bill data from different sources and types, ensuring the accuracy of data flow.

[0019] The implementation of the configurable API interface relies on the dual support of a visual configuration interface and configuration files. System administrators can intuitively define data structures by dragging and dropping fields and selecting mapping relationships in the visual interface. Field mapping supports one-to-one, many-to-one, and conversion mapping (such as format conversion and unit conversion). Configuration files use YAML or JSON format, which facilitates version control and batch deployment.

[0020] When adding a new upstream business system, the administrator does not need to develop code. They only need to configure the connection protocol (such as JDBC, HTTP, FTP) and authentication information (such as account password and API key) of the data source in the interface. The data table structure mapping tool automatically identifies the differences between the source table and the target table fields and generates mapping suggestions. Then, the administrator configures the data filtering, cleaning and other processing logic (such as removing test data and filling in the default values ​​of missing fields). After data cleaning and formatting, the data is output to the analysis and verification task orchestration module, which can achieve rapid integration.

[0021] This interface is compatible with various data formats and protocols, including JSON, XML, direct database connections, and standard API calls. It has built-in parsers for different data formats to ensure that the data is correctly converted into the system's unified format.

[0022] The built-in data verification mechanism of the interface starts in real time during the data reception process, including field non-empty verification (checking whether key fields such as transaction amount and order number exist), data type verification (ensuring that the date format and numerical range meet the definition), and business rule verification (such as income and expenditure type matching and correct positive and negative logic of amount). For the identified abnormal data, the occurrence time, data source, error type and original data content are recorded in detail, and an alarm process is immediately triggered to notify relevant personnel for handling.

[0023] The distributed message queue adopts a high-throughput, low-latency publish-subscribe pattern. This pattern was chosen to support multiple downstream processing nodes consuming data simultaneously, improving concurrent processing capabilities. Internally, it achieves load balancing through a partitioning mechanism, with each partition corresponding to an independent consumption queue. The system is also configured with multiple consumer groups, each responsible for a specific data partition. Data is evenly distributed through a load balancing algorithm, ensuring orderly data processing and preventing duplicate consumption. In addition, the queue mechanism has a built-in backpressure control strategy: when the data processing speed is lower than the data inflow rate, the system automatically reduces the consumer pull frequency and dynamically increases the number of consumer instances to balance the data production and consumption rates. At the same time, persistent message storage ensures that data is not lost after system failure, meeting the reliability requirements of financial data.

[0024] The task orchestration module manages task dependencies based on a directed acyclic graph (DAG) model. It orchestrates data retrieval tasks, total billing tasks, and billing verification tasks according to preset rules, automatically processing various data types and generating task results. This module includes a rule configuration and adaptation sub-module, providing configuration functionality for task verification logic through a visual interface. The interface integrates a drag-and-drop flowchart designer, allowing users to select components such as data retrieval, field mapping, summary calculation, and verification from a component library. After dragging and dropping components onto the canvas, the execution order is set by connecting lines. Component parameters are configured via forms (e.g., summary field selection, verification threshold setting). For complex logic, script-based definition is supported, providing a script editor with syntax highlighting and auto-completion, and built-in commonly used function libraries (e.g., date calculation and amount summary functions). The rules engine integrates a predefined verification rule library, covering common financial verification scenarios (such as income and expenditure balance verification, invoice amount and order amount matching, and tax calculation verification). Hot loading of rules is achieved through dynamic loading of rule files via a class loader, taking effect without requiring a system restart. Version management records the creation and modification history of rules, supporting rollback to previous versions for easy rule iteration and issue tracing. Task dependency management based on a directed acyclic graph model ensures tasks are executed sequentially, monitoring the execution status, resource usage, and error messages of each task node in real time. When a task fails, it automatically retryes according to a preset strategy. The number of retries and the interval are configurable (e.g., a maximum of 3 retries with a 5-minute interval). If a retry fails, an alarm mechanism is triggered.

[0025] The task orchestration analysis and verification module includes a task dependency construction submodule. This module parses the dependencies between tasks based on the user-configured task logic, generating a directed acyclic graph that clearly defines the task execution order and dependency constraints. Dependency types include sequential dependencies (task B must be executed after task A is completed), data dependencies (task B must use the output data of task A), and conditional dependencies (task B is executed when the result of task A meets a specific condition). Users can design task flows by dragging and dropping task nodes and drawing connections using a visual editor. When adding nodes, users can configure names, types, and execution parameters, and when modifying dependency edges, they can set dependency condition expressions. During dependency construction, cycle detection is implemented using a depth-first search algorithm. When traversing nodes, the access path is recorded. If a node already in the path is encountered, it is determined to be a circular dependency, and the system automatically marks it and prompts the user to adjust. The conflict resolution mechanism automatically adjusts the dependency based on task priority or user-preset conflict resolution rules when a dependency conflict is detected (such as the same task being set to depend on two mutually exclusive tasks simultaneously), or pauses the construction and prompts the administrator for manual intervention. The generated dependency data is persistently stored in the database in a structured format. Each record contains information such as task ID, dependent task ID, dependency type, and creation time. Version management is supported to track historical changes, and the dependency structure at any point in time can be viewed through the historical backtracking function, providing data support for process optimization.

[0026] The task orchestration module for analysis and verification includes a task scheduling and execution submodule. This module dynamically schedules task execution based on task priority, resource availability, and dependencies. During scheduling decisions, it first checks whether task dependencies are met, then allocates execution resources based on task priority (e.g., core bill verification tasks have higher priority than statistics tasks) and current system resource status (e.g., idle CPU and memory capacity), and pushes task instances to the corresponding execution queue. The execution environment supports containerized deployment and Serverless functions. Containerized deployment uses Docker containers to encapsulate the task execution environment and orchestrates it using Kubernetes, achieving dynamic scaling of resources and task isolation to avoid resource contention between tasks. Serverless functions are suitable for short-cycle, low-frequency tasks, supporting on-demand invocation and reducing resource idle costs. The task execution process is monitored in real time, collecting metrics such as start time, end time, CPU utilization, and memory usage through data collection. When task execution failure (e.g., throwing an exception) or timeout (exceeding the preset execution duration) is detected, a retry mechanism is automatically triggered. The number of retries is configured according to task importance. If a retry fails, failover is initiated, and the task is assigned to a backup node for execution. For tasks involving database shared resource operations, a pessimistic locking mechanism is adopted. The target record is locked before a write operation to prevent data inconsistency caused by concurrent modifications. The lock is released after the task completes normally or during timeout rollback, ensuring data integrity. The task scheduling and execution status (e.g., queuing, running, success, failure) is reported to the monitoring and alarm module in real time for global monitoring.

[0027] The task orchestration module for analysis and verification includes a state management and storage submodule. This module tracks the execution status of task instances in real time, including waiting (dependencies not satisfied), executing (resources allocated), successful (execution completed without errors), and failed (execution exception). It records detailed execution duration, output result data ID, error messages, and stack traces. State data storage employs a hybrid strategy: structured data (such as task IDs, status codes, and timestamps) is stored in a relational database, supporting complex queries and transaction consistency; unstructured data (such as detailed error logs) is stored in a NoSQL database to meet high write performance requirements. To support high-concurrency read and write operations, the system uses a database connection pool to manage connection resources and adopts a read-write separation architecture, distributing query requests to slave databases to reduce pressure on the master database. The module provides a standardized state query API, supporting queries by task ID, time range, status type, and other conditions. It also visualizes key indicators such as task status distribution and execution efficiency through a real-time dashboard. An event notification mechanism is triggered when a state changes, notifying relevant modules to update the status of dependent tasks via an event bus. For example, after a preceding task succeeds, subsequent tasks are notified to enter the executable state. Status data uses the LZ4 compression algorithm to reduce storage usage, and the archiving strategy migrates historical data that has exceeded the retention period to cold storage according to time periods to ensure system storage efficiency.

[0028] The task orchestration module for analysis and verification includes a subsequent task triggering submodule. This module automatically triggers subsequent tasks based on sequence dependencies, data dependencies, and the execution result of the current task. The triggering logic is based on predefined rules and conditional expressions. The conditional expressions are converted into executable logic by an ANTLR parser. For example, a subsequent audit task is triggered when "all preceding tasks are successfully completed and the total amount is greater than 10,000 yuan". Multiple triggering modes are supported: serial execution starts tasks sequentially in a single queue to ensure task execution order; parallel execution starts multiple independent tasks simultaneously using multiple threads or distributed nodes to improve processing efficiency; conditional branching selects tasks to execute based on the expression calculation result, such as triggering an exception handling task when the amount is abnormal, and triggering an archiving task when it is normal. Triggering decisions comprehensively consider the real-time system load. Monitoring modules obtain metrics such as CPU utilization, memory usage, and queue length. When the system load exceeds a preset threshold, the triggering of low-priority tasks is delayed, prioritizing the execution of core tasks. Triggering actions are asynchronously notified via message queues or event buses to ensure the reliability of task triggering. Even if a submodule temporarily fails, the message is persistently stored and reprocessed after recovery. All trigger history records (including trigger time, trigger conditions, task ID, and execution results) are persistently stored in the database, supporting audit traceability and trigger logic optimization.

[0029] The verification result query processing module adopts a script-based configuration approach, supporting multiple scripting language interpreters, including a Python script interpreter. Users can customize data filtering, sorting, aggregation, and calculation rules based on invoice type through the script editor, generating customized query views and analysis reports. The Python script interpreter is implemented by embedding a CPython interpreter, supporting calls to the system's built-in financial analysis function library (such as depreciation calculation and tax calculation functions) and user-uploaded custom modules. The script execution environment is isolated, ensuring that different user scripts do not interfere with each other. The module provides a unified query processing interface, encapsulating the underlying data access logic, and standardizing the data acquisition and real-time response for different types of invoices (such as purchase invoices and sales invoices), masking differences in data storage. Query results can be exported to structured data formats such as Excel and CSV, or directly pushed to decision support tools (such as BI systems) via API, meeting diverse analysis needs. The scripting mechanism includes query caching and index management. The query cache uses Redis to store results from frequently accessed queries, and the cache expiration time is dynamically adjusted based on the data update frequency. For example, frequently updated real-time bills are cached for 10 minutes, while static historical bills are cached for 24 hours. Index management automatically identifies commonly used query fields (such as bill date and supplier ID) and periodically creates or optimizes database indexes based on query log analysis to improve query efficiency. All query operations are logged in detail, including the user, query time, script content, execution duration, and result data volume. This supports operation auditing and query performance analysis, facilitating the optimization of slow queries.

[0030] The configuration management module centrally manages system configuration information through a web-based management interface. This includes field definitions, data source connection parameters, and authentication mechanisms for data collection billing details, as well as task types, execution frequencies, dependencies, verification rules, and global system parameters for billing analysis and reconciliation task orchestration. The web interface is developed using the React framework, featuring a front-end / back-end separation architecture. It provides a responsive design supporting multi-terminal access, and interface interactions are implemented intuitively through drag-and-drop and form filling, reducing configuration complexity. Configuration changes are submitted to the back-end via a RESTful API, with a real-time effect mechanism implemented through an event-driven architecture. After configuration modification, an event notification is triggered, and relevant modules listen for the event and dynamically reload the configuration, applying the new configuration without requiring a system restart. Batch configuration updates are supported; users can import and export configuration information using Excel templates, which include preset validation rules to ensure correct data format. Configuration validation automatically checks parameter validity through a built-in rule library, such as whether the connection address format is correct, whether numerical parameters are within a valid range, and whether dependencies are closed loops. If validation fails, the specific error location and reason are displayed. All configuration change records are logged in an audit log, including information such as the operator, timestamp, content before and after the change, and reason for the change. The log is tamper-proof and supports querying by time, operator, configuration type, and other criteria. The module provides comprehensive configuration backup and recovery functions, performing full backups on a regular basis while recording incremental configuration change logs. Backup data is stored encrypted, and recovery supports precise point-in-time restoration, ensuring the security and reliability of configuration data.

[0031] The monitoring and alarm module provides comprehensive monitoring of data collection, task execution, and verification results. Monitoring metrics include data inflow, processing latency, error rate, system resource utilization, and data lineage tracing. Metric collection is achieved by embedding tracking programs at key process nodes. Data inflow is calculated by statistically analyzing message queue consumption frequency. Processing latency records the time difference between data reception and processing completion. Error rate is calculated by the percentage of failures per task type. System resource utilization is monitored in real-time using operating system commands to obtain data such as CPU, memory, and disk I / O. Data lineage is traced by recording the data flow path (e.g., source system, processing task, storage location). Anomaly detection utilizes a rule engine to analyze monitoring data in real-time. The rule engine loads user-configured anomaly rules (e.g., a 50% drop in data inflow, processing latency exceeding 30 minutes, error rate exceeding 5%) and compares monitoring metrics with rule thresholds in real-time to identify anomalies such as data flow interruptions, task execution timeouts, and verification result deviations. The multi-level alerting strategy dynamically selects alert channels based on the severity of the anomaly. Severe anomalies (such as core data interruption) trigger SMS, instant message, and telephone alerts simultaneously; important anomalies (such as batch task failures) trigger SMS and email alerts; and general anomalies (such as individual data errors) trigger only email alerts. Alert information includes the anomaly occurrence time, specific indicator values, impact scope, troubleshooting suggestions, and associated tracing IDs, facilitating rapid problem location. Historical alert data is persistently stored in a time-series database, supporting queries, statistics, and trend analysis by time range, anomaly type, severity, and other dimensions. By generating alert frequency reports and indicator change curves, it assists administrators in identifying and optimizing potential system problems.

[0032] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A financial monitoring system based on real-time data processing and intelligent analysis, characterized in that, include: The system includes a bill collection module, an analysis and verification task scheduling module, a verification result query and processing module, a configuration management module, and a monitoring and alarm module. The bill collection module is used to connect to the upstream business system in real time, and to receive bill details data by accepting high-concurrency data streams through a distributed message queue. The analysis and verification task scheduling module is electrically connected to the bill collection module. The analysis and verification task scheduling module is used to schedule data retrieval tasks, total bill tasks and bill verification tasks according to preset rules, automatically process various types of data and generate task result data. The verification result query and processing module is electrically connected to the analysis and verification task scheduling module. The verification result query and processing module is used to provide bill data query and processing functions, and expenditure finance specialists can view the monitoring results and respond to issues in real time. The configuration management module is used to centrally manage and flexibly configure data collection elements and task orchestration configuration information through a visual configuration interface. The monitoring and alarm module is used to monitor the system's operating status in real time. It adopts a multi-level alarm strategy to notify relevant personnel through multiple communication channels when data anomalies occur.

2. The financial monitoring system based on real-time data processing and intelligent analysis according to claim 1, characterized in that, The bill collection module includes a configurable data collection interface; The configurable data collection interface allows for flexible configuration of the billing data structure through a unified data structure definition mechanism; Administrators use a visual interface to predefine data structure templates, which include: field names, data types, constraints, and data mapping rules. The bill collection module automatically generates a data receiving adapter based on the template. When an enterprise adds an upstream business system, the administrator enters the data source type, connection parameters, and data format specifications of the new system in the configuration interface, and the bill collection module dynamically loads the configuration to complete the integration. The configurable data collection interface supports three data formats: JSON, XML, and CSV, and converts data into standard formats through a built-in parser. During the data reception process, the interface performs real-time data verification, checking field integrity, data type matching, and constraint compliance, and filtering out invalid or abnormal data.

3. The financial monitoring system based on real-time data processing and intelligent analysis according to claim 1, characterized in that, The bill collection module uses a unified collection interface to receive bill detail data reported by the upstream system, and internally uses a distributed message queue to asynchronously smooth out high-concurrency data streams. The specific implementation method is as follows: Upstream business systems report detailed bill data by calling a unified bill collection interface; After receiving the data, the bill collection module uses RocketMQ message queues internally for asynchronous peak shaving to support high concurrency scenarios. RocketMQ is deployed in a cluster environment and uses a topic and tag mechanism to classify and route the data. The bill collection module acts as a consumer instance, asynchronously pulling data from the queue and using a partitioning mechanism to achieve parallel processing. The bill collection module is configured with multiple consumer groups, each responsible for a specific data partition, and the data is evenly distributed through a load balancing algorithm. The queue mechanism implements a backpressure control strategy. When the data processing speed is lower than the data inflow rate, it automatically reduces the frequency of consumer fetching and dynamically increases the number of consumer instances. After receiving the data, the module performs preliminary cleaning and formatting, and outputs it to the analysis and verification task scheduling module.

4. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 1, characterized in that, The analysis and verification task orchestration module includes an intelligent task orchestration engine; The intelligent task orchestration engine is used to perform personalized configurations for different bill reconciliation businesses. The functional components of the intelligent task orchestration engine include: a task dependency relationship construction submodule, a task scheduling and execution submodule, a state management and storage submodule, a subsequent task triggering submodule, and a rule configuration and adaptation submodule. The task dependency construction submodule is used to parse the logical relationships between tasks, generate a directed acyclic graph, clarify the execution order and dependency conditions of tasks, and ensure that tasks proceed in an orderly manner according to preset logic. The tasks include: data retrieval, analysis and summarization, and verification. The task scheduling and execution submodule is used to send the initial task to the execution queue, trigger the task to run in the adapted environment, monitor the task progress and resource usage in real time, trigger an alarm immediately if data error or execution failure occurs, and manage shared resources through a resource lock mechanism. The status management and storage submodule is used to record the execution status, execution time and output results of each task, forming a traceable task execution log, which provides data support for subsequent queries and troubleshooting. The subsequent task triggering module is used to intelligently determine whether to trigger subsequent tasks based on task dependencies and the execution results of previous tasks. At the same time, it plans the execution order of subsequent tasks by taking into account task priority and system resource availability. The execution modes supported include parallel and serial. The rule configuration and adaptation module allows users to customize task orchestration rules and logic according to the needs of different billing verification businesses, and quickly build personalized task processes through a visual configuration interface.

5. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 4, characterized in that, The intelligent task orchestration engine performs personalized configuration in the following ways: Through the visual configuration interface provided by the rule configuration and adaptation submodule, the task flow rules defined by the user for a specific type of bill reconciliation business are received. The task flow rules include the execution logic of one or more task nodes, the dependencies between nodes, and the branching conditions after a node succeeds or fails. The task dependency construction submodule automatically generates a concrete directed acyclic graph based on the task flow rules. This directed acyclic graph clearly defines the execution order and triggering conditions between the data retrieval task, the bill summary task, and the bill verification task.

6. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 4, characterized in that, The specific process by which the task scheduling and execution submodule manages shared resources using a resource lock mechanism includes: When allocating shared data resources for a task to access, the system first attempts to acquire the mutex lock corresponding to the resource. If the acquisition is successful, the task is triggered to execute. During the task execution, access to the resource is locked until the task is completed or the timeout occurs, at which point the lock is released. If the acquisition fails, the task is placed in a waiting queue and scheduled in a queue to avoid race conditions for the same shared data resource when multiple tasks are executed concurrently.

7. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 4, characterized in that, The process by which the state management and storage submodule records the task execution state is as follows: When the task scheduling and execution submodule triggers a task node to start execution, a status record is created in the database and marked as "in execution", and the start timestamp is recorded at the same time; After the task is completed, update the status record to "success" or "failure", and record the end timestamp, output result summary or error log; The status record is associated with a unique identifier for the task node.

8. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 4, characterized in that, The specific logic of the subsequent task triggering submodule, which intelligently triggers subsequent tasks based on task dependencies and execution results, is as follows: Listen for status update events of its predecessor tasks; when a predecessor task's status is updated to "success", check the directed acyclic graph to identify all subsequent tasks that have that task as a direct predecessor. For each eligible subsequent task, further verification is performed to confirm whether all other prerequisites have been met. If all prerequisites are met, the subsequent task is submitted to the execution queue of the task scheduling and execution submodule for scheduling and execution, taking into account the current system load and the preset task priority.

9. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 1, characterized in that, The verification result query processing module adopts a scripted query processing mechanism to realize a unified query processing function; The scripted query processing mechanism is configured as follows: for different bill types, customized settings are pre-defined in the configuration management module using scripting, defining the data query logic and result processing rules for that type of bill; When a finance specialist initiates a query request, the verification result query processing module automatically identifies the bill type and calls the corresponding preset script. By executing the query logic defined in the script, it efficiently retrieves the target data from the repository and encapsulates and responds to the data according to the result processing rules defined in the script.

10. A financial monitoring system based on real-time data processing and intelligent analysis according to claim 1, characterized in that, In the monitoring and alarm module, the multi-level alarm strategy is specifically as follows: Different levels of abnormal events and their corresponding alarm levels are predefined; the abnormal events include data reception delay, task execution failure, and verification result deviation exceeding the threshold. When an abnormal event is detected, the notification channel and recipient are determined according to its alarm level; for low-level warnings, in-system messages or email notifications are used. For advanced alerts, additional strong notifications are triggered via SMS or instant messaging API and escalated to higher-level administrators to ensure timely response to alert information.

Images