Enterprise financial risk intelligent early warning and hierarchical management and control method and system

CN122887622APending Publication Date: 2026-10-09HUANENG YANGPU THERMAL POWER CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202611004626.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-07
Publication Date
2026-10-09

AI Technical Summary

Technical Problem

[0006]本发明的目的在于,提供一种企业财务风险智能预警与分级管控方法及系统,以解决现有企业系统由于缺乏统一的数据时间基准,导致业务生成与账务落库存在时序偏差;且现有管控机制缺乏对账务处理能力的量化分析与管控干扰补偿,在面临高并发写入时,易引发账务数据积压与业务超限等问题

Benefits of technology

1.本发明通过提取数据源的本地时间戳并结合通信传输延迟计算时钟漂移量,对不同底层设备的日志进行时序补偿,该方式消除了异构设备间的时间差异,建立了全局统一的时间基准,保证了业务事件排序的准确性,为后续的配额生成与速率计算提供了可靠的数据基础。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122887622A_ABST
    Figure CN122887622A_ABST
Patent Text Reader

Abstract

The application discloses a kind of enterprise financial risk intelligent early warning and hierarchical management and control method and system, wherein the method comprises: collecting multi-source business log and performing timing calibration, to generate standard business event sequence;Parse business attribute label to generate corresponding permission token and write into memory cache pool;Theoretical generation rate and actual accounting rate are calculated based on the token quota of memory cache pool and core accounting database log respectively;Intercept compensation rate is introduced to eliminate pre-control interference, the difference between theoretical generation rate and actual accounting rate is calculated, and continuous integral calculation is carried out to obtain dynamic timing deviation value;When micro quota check is passed, according to the comparison result of the dynamic timing deviation value and the preset state threshold, the corresponding microservice hierarchical management and control action is executed and early warning is carried out.The application solves the problem of business generation and accounting time sequence deviation, effectively prevents data backlog in high-concurrency environment, and improves the stability of overall management and control.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of enterprise risk control and information processing technology, and specifically relates to an intelligent early warning and hierarchical management method and system for enterprise financial risks. Background Technology

[0002] With the development of enterprise informatization, distributed architecture has been widely used in front-end business processes and back-end financial accounting systems. In this architecture, business event generation and the storage of core accounting data are typically completed asynchronously by different system nodes. Existing enterprise systems often lack a unified data time base when handling heterogeneous data sources; local clock drift on underlying devices can cause timing discrepancies between business event sequencing and actual accounting processing.

[0003] To cope with system pressure in high-concurrency scenarios, conventional system control mechanisms are mostly deployed at the application layer and typically rely on preset static thresholds for simple access limits. This approach fails to quantitatively analyze the actual accounting rate of the backend core accounting database, resulting in a disconnect between control strategies and the underlying actual accounting processing capabilities. Furthermore, when the application layer triggers pre-emptive control actions such as request interception, suspension, or asynchronous queuing, some business requests may be delayed in being written to the database.

[0004] Existing system status assessment models do not consider the interference caused by the aforementioned non-written requests to overall traffic statistics. The system is prone to misjudgments of strategies due to statistical biases caused by pre-control, resulting in frequent switching of control status. In this situation, when the system faces a sudden surge in high-concurrency write requests, it is difficult to maintain stable scheduling and degradation processing, which may lead to risks such as backlog of core accounting data and excessive front-end business.

[0005] For example, Chinese patent CN119273487A discloses an enterprise financial management system based on financial information processing. This invention uses data collection, analysis, risk assessment, and feedback modules to work collaboratively, employs a hierarchical anomaly detection method to determine financial controllability, combines environmental data to construct an SVM model to assess risk changes, and dynamically optimizes the statistical period based on feedback. However, this invention does not incorporate the actual accounting rate of the underlying database into the quantitative analysis, and it does not consider the interference caused by requests not being written to the database in high-concurrency asynchronous processing scenarios, where business requests are intercepted, suspended, or asynchronously queued by pre-control mechanisms, thus affecting overall traffic statistics. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for intelligent early warning and hierarchical control of enterprise financial risks, in order to solve the problems of time sequence deviation between business generation and accounting entry caused by the lack of a unified data time benchmark in existing enterprise systems; and the lack of quantitative analysis and control interference compensation for accounting processing capabilities in existing control mechanisms, which can easily lead to problems such as accounting data backlog and business exceeding limits when faced with high-concurrency writes.

[0007] The technical solution of the present invention is as follows: On the one hand, this invention provides a method for intelligent early warning and hierarchical control of corporate financial risks, including the following steps: S100: Collect physical quantity logs and logical contract logs, perform timing calibration, and generate standard business event sequences; S200: Parse the business attribute tags contained in the standard business event sequence, generate corresponding physical flow permission tokens and logical contract permission tokens according to the business attribute tags, and write the physical flow permission tokens and logical contract permission tokens into the memory cache pool; S300: Based on the set observation time window, read the token quota in the memory cache pool to calculate the theoretical generation rate, and read the transaction commit log of the core accounting database to calculate the actual accounting rate. S400: Receives traffic intervention data from the previous calculation cycle, calculates the interception compensation rate, and obtains the dynamic time-series deviation value through continuous integration based on the theoretical generation rate, the actual accounting rate, and the interception compensation rate. S500: Receives a system write request message, performs micro-quota verification in the memory cache pool, and when the remaining token quota of the corresponding dimension in the memory cache pool meets the quota required for system writing, compares the dynamic time-series deviation value with the preset state threshold set, performs corresponding control actions on the corresponding microservice interface according to the comparison result, and generates financial risk warning information.

[0008] Preferably, step S100 specifically comprises: Obtain the unified time base of the system and extract the local timestamps from the physical quantity logs and logical contract logs; Calculate the local clock drift of the corresponding data source by combining the one-way transmission delay time of the communication link; The local timestamp is compensated using the local clock drift to generate a global calibration timestamp. The payload data in the physical quantity log and logical contract log are bound and encapsulated with the corresponding global calibration timestamps. The standard business event sequence is obtained by sorting the global calibration timestamps in chronological order.

[0009] Preferably, in step S200, generating the corresponding physical transfer license token and logical contract license token based on the business attribute tag specifically involves: When the business attribute tag matches the physical feature identifier set, the physical quantity payload data in the standard business event sequence is converted into a quota according to the preset physical mapping coefficient matrix to obtain the numerical quota of the physical flow license token, and a unique identifier of the physical flow license token is generated by combining the one-way hash function. When the business attribute tag matches the logical feature identifier set, the logical contract payload data in the standard business event sequence is converted into a quota according to the preset logical mapping coefficient matrix to obtain the numerical quota of the logical contract license token, and a unique identifier of the logical contract license token is generated by combining it with a one-way hash function.

[0010] Preferably, the theoretical generation rate includes the global accounts payable theoretical generation rate and the global accounts receivable theoretical generation rate, and the actual accounting rate includes the actual accounts payable accounting rate and the actual accounts receivable accounting rate. The calculation of the theoretical generation rate and the actual accounting rate includes: Within the observation time window, the sum of the numerical quotas of newly added token quotas classified according to the business direction field is divided by the time length of the observation time window to calculate the global payable theoretical generation rate and the global receivable theoretical generation rate. By monitoring and parsing the transaction commit logs through a change data capture mechanism, and performing correlation filtering, the sum of the core account values ​​belonging to the payable and receivable directions within the observation time window is calculated and divided by the time length to obtain the actual payable accounting rate and the actual receivable accounting rate.

[0011] Preferably, the interception compensation rate includes the payable interception compensation rate and the receivable interception compensation rate; The step of calculating the dynamic time-series deviation value through continuous integration based on the theoretical generation rate, the actual accounting rate, and the interception compensation rate includes: The corresponding payable interception compensation rate and receivable interception compensation rate are deducted from the global payable theoretical generation rate and the global receivable theoretical generation rate, respectively. The difference between the theoretical generation rate after deducting the interception compensation rate and the corresponding actual accounting rate are calculated respectively. The absolute value of the difference is integrated within a continuous integration time window. The dynamic time series deviation value is obtained by combining the payable deviation weight coefficient and the receivable deviation weight coefficient.

[0012] Preferably, the calculation of the interception compensation rate includes: Extract system write requests that were forcibly discarded, suspended, temporarily rejected, and allowed to retry or transferred to the asynchronous delay queue during the previous calculation cycle and are in a state of not being written to the database due to triggering control. The theoretical numerical quotas contained in the system write requests that are not yet written to the database are analyzed. The sum of the payable request quotas and the sum of the receivable request quotas that are not yet written to the database in the previous processing cycle are divided by the duration of the previous processing cycle to obtain the corresponding payable interception compensation rate and receivable interception compensation rate.

[0013] Preferably, step S500, which involves performing micro-quota verification in the memory cache pool, includes: Parse the payload classification label of the system write request message to determine the quota to be deducted for system write; Using a data structure that supports atomic operations, the corresponding quota in the memory cache pool is decremented through atomic comparison and swap operations. When the remaining token quota for the corresponding dimension in the memory cache pool is less than the quota to be deducted for system writing, it is determined that the quota is insufficient. The system write request message is discarded at the transmission control protocol layer, and a connection reset signal is returned to the sending end.

[0014] Preferably, the preset state threshold set includes a first-level deviation threshold, a second-level deviation threshold, and a third-level deviation threshold that increase sequentially. The step of comparing the dynamic time-series deviation value with a preset state threshold set and performing corresponding control actions on the corresponding microservice interface based on the comparison result includes: When the dynamic timing deviation value is less than or equal to the first-level deviation threshold, the synchronous communication mechanism of the microservice interface will route the system write request message to the core accounting database. When the dynamic timing deviation value is greater than the first-level deviation threshold and less than or equal to the second-level deviation threshold, the asynchronous message degradation mechanism is triggered, and the system write request message is temporarily stored in the bypass asynchronous message queue. When the dynamic timing deviation value is greater than the second-level deviation threshold and less than or equal to the third-level deviation threshold, write request interception, read-only routing, or database read-only permission switching operation is triggered. When the dynamic timing deviation value is greater than the third-level deviation threshold, an isolation operation is performed on the external service inbound link at the network layer to block the external service inbound traffic.

[0015] Preferably, the method further includes a cross-level handling mechanism: When the asynchronous message degradation mechanism is triggered and the bypass asynchronous message queue reaches its capacity limit, the processing status of the system write request message is upgraded to a status greater than the second-level deviation threshold and less than or equal to the third-level deviation threshold. The corresponding intervention record is generated, and the request quota, business direction, queue status, and database status are used as traffic intervention data feedback for the calculation of the interception compensation rate in the next calculation cycle.

[0016] On the other hand, the present invention provides an intelligent early warning and hierarchical control system for enterprise financial risks, including a data acquisition module, a calibration module, a token generation module, an aggregation module, a calculation module, and a scheduling module; The acquisition module is used to receive physical quantity logs and logical contract logs; A calibration module, connected to the acquisition module, is used to perform timing calibration and generate a standard business event sequence; The token generation module, connected to the calibration module, is used to generate corresponding physical flow permission tokens and logical contract permission tokens according to business attribute tags, and write the physical flow permission tokens and logical contract permission tokens into the memory cache pool; The aggregation module is connected to the token generation module and the core accounting database respectively, and is used to calculate the theoretical generation rate and the actual accounting rate. The calculation module, connected to the aggregation module, is used to receive traffic intervention data, calculate the interception compensation rate, and obtain the dynamic time-series deviation value through continuous integration calculation; The scheduling module is set in the application layer microservice communication link. It is used to receive system write request messages and perform micro-quota verification in the memory cache pool. When the quota is met, it executes control actions based on the comparison result of the dynamic time sequence deviation value and the state threshold set, and at the same time feeds back the traffic intervention data to the calculation module.

[0017] Compared with the prior art, the present invention has the following technical effects: 1. This invention extracts the local timestamp of the data source and calculates the clock drift by combining it with the communication transmission delay, and performs time-series compensation on the logs of different underlying devices. This method eliminates the time difference between heterogeneous devices, establishes a globally unified time benchmark, ensures the accuracy of business event sorting, and provides a reliable data foundation for subsequent quota generation and rate calculation.

[0018] 2. This invention obtains a dynamic time-series deviation value by calculating the integral of the difference between the theoretical front-end generation rate and the actual back-end accounting rate, and performs hierarchical control actions accordingly. This quantitative mechanism based on the difference between the front-end and back-end rates can truly reflect the processing pressure of the core accounting database, and trigger degradation or interception operations in a timely manner when the system is under high concurrency, effectively preventing the backlog of accounting data.

[0019] 3. This invention introduces an interception compensation rate when calculating dynamic timing deviation values, deducting the request quotas that were not included in the database due to control measures in the previous cycle from the theoretical rate. This mechanism eliminates the interference caused by the previous control measures on the current cycle rate statistics, avoids misjudgment of scheduling strategies and frequent switching due to statistical errors, and improves the stability of the overall control process. Attached Figure Description

[0020] Figure 1 This is an overall flowchart of the intelligent early warning and hierarchical control method for enterprise financial risks described in this invention; Figure 2 This is the overall architecture diagram of the enterprise financial risk intelligent early warning and hierarchical control system described in this invention; Figure 3 This is a timing diagram of heterogeneous data acquisition and edge clock calibration provided in an embodiment of the present invention; Figure 4 This is a flowchart of the dual-track token generation and injection process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the calculation principle of theoretical generation rate and actual accounting rate provided in this embodiment of the invention; Figure 6 This is a schematic diagram of the dynamic timing deviation calculation principle with state feedback provided in an embodiment of the present invention; Figure 7 This is a flowchart of the dual-constraint distributed scheduling control provided in an embodiment of the present invention.

[0021] Attached reference numerals: 10, Acquisition module; 20, Calibration module; 30, Token generation module; 40, Aggregation module; 50, Calculation module; 60, Scheduling module. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0023] Example 1 This embodiment provides a method for intelligent early warning and hierarchical control of enterprise financial risks. (See reference...) Figure 1 , 2 As shown, it includes the following steps: S100, the acquisition module 10 acquires physical quantity logs uploaded by the underlying devices and logical contract logs generated by the business system via the enterprise service bus. The calibration module 20 extracts local timestamps or event generation timestamps from the physical quantity logs and logical contract logs, compares them with the system network time protocol synchronization results, and obtains the corresponding time difference. The calibration module 20 calibrates the original time information based on the time difference, generates a global calibration timestamp, and outputs a standard business event sequence arranged according to the global calibration timestamp.

[0024] S200, the token generation module 30 receives a standard business event sequence and parses the business attribute tags of each business event. For business events with physical feature tags, the token generation module 30 calculates the corresponding numerical quota based on the physical mapping coefficient matrix and generates a unique identifier for the physical transfer permission token using a hash operation. For business events with logical feature tags, the token generation module 30 calculates the corresponding numerical quota based on the logical mapping coefficient matrix and generates a unique identifier for the logical contract permission token based on the rights confirmation event identifier and a hash operation. Subsequently, the token generation module 30 writes the physical transfer permission token and the logical contract permission token into the memory cache pool at the front end of the scheduling module 60.

[0025] S300, the aggregation module 40 reads token data from the memory cache pool, extracts the generated numerical quotas from the physical flow permission tokens and logical contract permission tokens, and accumulates the newly added token quotas within the set observation time window to obtain the global theoretical payable generation rate and the global theoretical receivable generation rate, respectively. The aggregation module 40 also reads the transaction commit logs of the core accounting database, and statistically analyzes the actual accounting data written by the system based on the transaction commit logs to obtain the actual payable posting rate and the actual receivable posting rate.

[0026] S400, the calculation module 50 receives the traffic intervention data generated by the scheduling module 60 in the previous calculation cycle and calculates the corresponding interception compensation rate accordingly. Based on the global theoretical payable generation rate and the global theoretical receivable generation rate, the calculation module 50 deducts the corresponding interception compensation rate and compares it with the actual payable accounting rate and the actual receivable accounting rate. Within a preset time window, the difference between the two is integrated to obtain the dynamic time-series deviation value.

[0027] S500, the scheduling module 60 receives the system write request message and parses the payload classification tag in the message. Based on the payload classification tag, the scheduling module 60 deducts the corresponding physical flow permission token quota or logical contract permission token quota from the memory cache pool. When the corresponding quota is insufficient, the scheduling module 60 discards the system write request message at the protocol layer; When the corresponding quota is sufficient, the scheduling module 60 obtains the dynamic timing deviation value output by the calculation module 50 and compares the dynamic timing deviation value with a preset set of state thresholds. Based on the comparison result, the scheduling module 60 performs synchronous routing, asynchronous message degradation, write request interception, read-only routing, database read-only permission switching, or external business link isolation operations on the corresponding microservice interface.

[0028] See attached document Figure 3 As a preferred embodiment of this invention, step S100 is implemented through the following steps: S101, the acquisition module 10 is located at the front end of the enterprise service bus and establishes a communication monitoring mechanism for the underlying devices and business systems. The acquisition module 10 communicates with the underlying devices on the field side through industrial communication protocols and communicates with the upper-layer business systems through application layer interfaces.

[0029] The underlying devices may include programmable logic controllers, industrial sensor network nodes, and edge control gateways; the upper-layer business systems may include enterprise resource planning systems, electronic contract management systems, or other business systems involved in generating accounting data.

[0030] The acquisition module 10 receives the underlying operation logs uploaded by the aforementioned data source. The underlying operation logs include physical quantity logs and logical contract logs. The physical quantity logs are used to record data with physical measurement attributes, such as material weight, current consumption, and equipment operating cycle; the logical contract logs are used to record business interaction data that does not directly depend on physical measurement values, such as electronic order generation events and contract status confirmation events.

[0031] Due to differences in startup time, crystal oscillator error, and field environment among different underlying devices, the local time used by each data source when generating logs may deviate. The acquisition module 10 parses the header fields of the underlying operation log data packets, extracts the corresponding local timestamp or event generation timestamp, and sends it to the calibration module 20 along with the payload data.

[0032] S102, the calibration module 20 acquires the system's unified time reference. The calibration module 20 has a built-in time synchronization client and establishes a time synchronization connection with the network time protocol server in the data center to obtain the current system standard time. For the specific time synchronization process of the network time protocol, those skilled in the art can use existing clock synchronization protocol frame interaction methods. Its communication frame structure and round-trip time calculation method are conventional technologies in the field and will not be described in detail here.

[0033] When the calibration module 20 receives a single underlying operation log, it records the instantaneous system standard time corresponding to the arrival of the log at the acquisition node, as a reference for subsequent time drift calculation.

[0034] S103, calibration module 20 calculates the local clock drift of the corresponding data source. Specifically, calibration module 20 reads the... Low-level runtime log Local timestamp carried in ,in This is a positive integer, and its value range is determined by the current data processing batch. The calibration module 20 also acquires the instantaneous system standard time at the time the log entry is received. It also calls the underlying network quality monitoring interface to obtain the one-way transmission delay time of the current communication link. .

[0035] When the network quality monitoring interface fails to return real-time latency data, the calibration module 20 uses the pre-stored historical statistical average latency of the communication link as... The value is chosen to avoid the calibration process being halted due to network jitter or short-term failure of the monitoring interface.

[0036] The calibration module 20 calculates the first step based on the local timestamp, the instantaneous system standard time, and the one-way transmission delay time. Local clock drift corresponding to the underlying runtime log The formula for calculating local clock drift is as follows: ; In the formula, Indicates the first The local clock drift of the data source corresponding to each underlying runtime log; This indicates the instantaneous system standard time when the system received the log; This represents the local timestamp extracted from the log; This indicates the one-way network transmission delay time from the data source to the acquisition node.

[0037] S104, Calibration module 20 generates a global calibration timestamp based on the local clock drift. Calibration module 20 compensates for the original local timestamp using the local clock drift, enabling logs generated from different data sources to be mapped to the same time base. Global calibration timestamp The calculation formula is as follows: ; In the formula, Indicates the first The global calibration timestamp corresponding to each underlying runtime log.

[0038] The calibration module 20 will process the payload data from the underlying operation log. With the corresponding global calibration timestamp The data is bound and encapsulated to obtain business event data with a unified time base. Subsequently, the calibration module 20 sorts the business event data according to the order of the global calibration timestamps, and uses the sorted queue as the standard business event sequence. .

[0039] Standard business event sequence It can be represented as: ; In the formula, This represents the payload data of each underlying runtime log; This represents the global calibration timestamp associated with the corresponding payload data. This represents the total number of logs in the current data processing batch. Calibration module 20 will use the standard business event sequence. The output is sent to the token generation module 30 for subsequent business attribute identification and permission token generation.

[0040] See attached document Figure 4 As a preferred embodiment of this invention, step S200 can be implemented through the following steps: S201, the token generation module 30 receives the standard service event sequence output by the calibration module 20. The token generation module 30 reads the payload data of each business event according to the queue order. It then parses the business attribute tags in the payload data and matches the parsing results with a pre-configured attribute mapping dictionary.

[0041] The attribute mapping dictionary includes a set of physical feature identifiers and a set of logical feature identifiers. Business attribute tags also include a business direction field, used to identify whether the corresponding business event belongs to the payable or receivable direction. For business events that do not directly carry a business direction field, the token generation module 30 determines the payable or receivable direction corresponding to the business event based on a preset business account mapping table, contract payment / receipt type, material flow direction, or business document type.

[0042] When a business attribute tag matches a physical feature identifier set, the token generation module 30 assigns the corresponding business event to the physical feature processing link; when a business attribute tag matches a logical feature identifier set, the token generation module 30 assigns the corresponding business event to the logical feature processing link. If the business attribute tag does not match either the physical feature identifier set or the logical feature identifier set, the token generation module 30 records the business event in the exception log and stops performing subsequent token generation processing for that business event.

[0043] S202, the token generation module 30 generates permission tokens for business events in the physical feature processing link and the logical feature processing link, respectively. The permission token includes a numerical quota and a unique identifier, wherein the numerical quota is used to represent the theoretical business volume corresponding to the business event, and the unique identifier is used to identify the permission token in subsequent scheduling, accounting statistics and transaction log association processes.

[0044] For service events assigned to the physical feature processing link, the token generation module 30 performs quota conversion on the underlying physical quantity payload data according to the preset physical mapping coefficient matrix to obtain the numerical quota of the physical flow permission token.

[0045] In one specific embodiment, the underlying physical quantity payload data includes material weight, current consumption, and equipment operating time. In this case, the physical mapping coefficient matrix can be set as a weight matrix corresponding to the aforementioned physical quantity fields, where each matrix element corresponds to unit material cost, unit electricity consumption cost, or unit equipment operating time cost, respectively. The token generation module 30 obtains the corresponding numerical quota through matrix operations and writes this numerical quota into the physical flow permission token.

[0046] The token generation module 30 also generates a unique identifier for the physical transfer permission token based on the physical quantity payload data and the global calibration timestamp. This unique identifier can be obtained through a one-way hash function. For the specific implementation of the one-way hash function, those skilled in the art can use existing secure hash algorithms such as SHA-256; the specific operational rules are conventional techniques in this field and will not be elaborated upon here.

[0047] The numerical quota and unique identifier of a physical transfer license token can be represented as follows: ; ; In the formula, Indicates the generated first The numerical quota of each physical circulation license token. This represents a preset physical mapping coefficient matrix, the values ​​of which are configured based on historical material unit prices or resource consumption quotas in the specific implementation scenario. This represents the underlying physical quantity payload data corresponding to the event. This represents a unique identifier for the generated physical transfer license token. Represents a one-way hash function. This indicates a data concatenation operation. This indicates the global calibration timestamp corresponding to the event.

[0048] For business events assigned to the logical feature processing link, the token generation module 30 performs quota conversion on the logical contract payload data according to the preset logical mapping coefficient matrix to obtain the numerical quota of the logical contract permission token.

[0049] In one specific embodiment, the logical contract payload data includes the contract amount, payment stage ratio, confirmation status, and performance node identifier. The logical mapping coefficient matrix is ​​used to determine the quota mapping relationship between the contract amount and the payment stage ratio, and, in conjunction with the confirmation status, to determine whether the business event meets the conditions for generating theoretical receivable or payable quotas.

[0050] The token generation module 30 also generates a unique identifier for the logical contract license token based on the logical contract payload data and the global calibration timestamp. The numerical quota and unique identifier of the logical contract license token can be represented as follows: ; ; In the formula, Indicates the generated first The numerical quota of a logical contract permission token. It is a positive integer. This represents a preset logical mapping coefficient matrix, which can be set according to the installment payment ratio in the service terms of the electronic contract management system. Indicates the first Logical contract payload data for each event. This represents a unique identifier for the generated logical contract license token. This indicates the global calibration timestamp corresponding to this logical event.

[0051] S203, the token generation module 30 encapsulates the generated physical flow permission token and logical contract permission token. The encapsulated token data includes at least the following fields: token type field, business direction field, numerical quota field, unique identifier field, generation timestamp field, lifespan field, consumption status field, business request identifier field, and associated serial number field.

[0052] Among them, the token type field is used to distinguish between physical flow permission tokens and logical contract permission tokens; the business direction field is used to distinguish between accounts payable and accounts receivable; the numerical quota field is used to record the theoretical business volume corresponding to the token; the unique identifier field is used to identify the corresponding token; the generation timestamp field is used to record the token generation time; the time to live field is used to limit the validity period of the token in the memory cache pool; the consumption status field is used to identify whether the corresponding quota has been deducted or occupied by the scheduling module 60; the business request identifier field and the associated serial number field are used by the aggregation module 40 to associate the corresponding accounting write record in the transaction commit log.

[0053] The token generation module 30 writes the encapsulated token data to the memory cache pool in front of the scheduling module 60 via an asynchronous communication interface. During the writing process, the token generation module 30 configures a time-to-live (TTL) parameter for each token. The TTL parameter limits the effective lifespan of the token in the memory cache pool.

[0054] When token data exists in the memory cache pool for longer than the corresponding lifetime parameter, the memory cache pool will reclaim the token data to prevent expired business events from continuously occupying available quotas. The lifetime parameter can be set according to the average processing cycle of the business pipeline; in some embodiments, the lifetime parameter can be configured to 12 to 72 hours.

[0055] See attached document Figure 5 As a preferred embodiment of this invention, step S300 is implemented through the following steps: S301, the aggregation module 40 establishes a read connection with the memory cache pool at the front end of the scheduling module 60, and sets the observation time window. The aggregation module 40 performs aggregation within each observation time window. Inside, read the newly added physical flow license token and the newly added logical contract license token whose timestamps fall into the window, and add the corresponding numerical quotas respectively.

[0056] In this embodiment, the business flow direction is divided into accounts payable and accounts receivable directions. The aggregation module 40 classifies and statistically analyzes the newly added token quotas based on the business direction field in the token data, and calculates the theoretical generation rate for accounts payable and accounts receivable directions respectively.

[0057] The global payables theoretical generation rate and the global receivables theoretical generation rate can be expressed as: ; ; In the formula, Indicates the current calculation time. Showing time The global coping theory generation rate, Indicates time The physical response theoretical rate, Indicates time The logical response rate of the theoretical rate; Indicates time The global theoretical rate of receivables generation. Indicates time The physical receivable rate, Indicates time The logical receivable rate.

[0058] Among them, the physical response theoretical rate Observation time window The sum of the numerical quotas of newly added physical flow permission tokens written to the memory cache pool and belonging to the coping direction, divided by the observation time window. The time length. The calculation methods for the physical receivables theoretical rate, the logical payables theoretical rate, and the logical receivables theoretical rate are the same.

[0059] For existing token quotas that have been generated in the memory cache pool but have not yet been consumed by the scheduling module 60, the aggregation module 40 records them as pending theoretical quota balances. These pending theoretical quota balances reflect the theoretical business inventory that has not yet been scheduled and are not repeatedly counted as the theoretical generation rate within the current observation time window.

[0060] Observation time window The length can be set according to system throughput, service write frequency, and allowable data fluctuation range. To balance the responsiveness and stability of rate measurement, in some embodiments, the observation time window... It can be configured to last from 1 to 10 seconds.

[0061] S302, the aggregation module 40 obtains the actual accounting data from the core accounting database. Specifically, the aggregation module 40 communicates with the core accounting database and listens to the transaction commit log through a change data capture mechanism. For the specific implementation of database change data capture, those skilled in the art can use database binary log listening, transaction log parsing, or other equivalent methods. The specific underlying communication process is conventional technology in this field and will not be described in detail here.

[0062] The aggregation module 40 parses the transaction commit log, extracts the accounting write records that have been committed and posted to disk, and reads the database system timestamp corresponding to each accounting write record. To ensure the comparability between the theoretical generation rate and the actual accounting rate, the aggregation module 40 performs correlation filtering on the accounting write records in the transaction commit log based on the business request identifier, contract number, material batch number, token unique identifier, or associated serial number, only counting accounting write records that correspond to standard business event sequences or permission token data.

[0063] S303, the aggregation module 40 follows the same observation time window as in step S301. The aggregation module 40 performs statistical analysis on the actual accounting data written. It calculates the sum of core account values ​​belonging to both accounts payable and accounts receivable within the observation time window, and then divides the sum by the observation time window value. The length of time, to obtain the time. Actual Accounts Payable Rate and actual accounts receivable posting rate .

[0064] When no transaction commit records belonging to the payable or receivable direction occur in the core accounting database within a certain observation time window, the aggregation module 40 assigns the actual accounting rate of the corresponding direction to zero to avoid null values ​​in the subsequent deviation calculation process.

[0065] The aggregation module 40 sends the calculated global payables theoretical generation rate, global receivables theoretical generation rate, actual payables accounting rate, and actual receivables accounting rate to the calculation module 50 for the calculation module 50 to perform dynamic time series deviation value calculation.

[0066] See attached document Figure 6 As a preferred embodiment of this invention, step S400 is implemented through the following steps: S401, the calculation module 50 establishes a feedback communication link with the scheduling module 60 to receive the traffic intervention results generated by the scheduling module 60 in the previous processing cycle.

[0067] During distributed scheduling, rate limiting, suspension, asynchronous degradation, or temporary rejection operations on the gateway side may prevent some system write requests that have already generated theoretical business volume from being written to the core accounting database within the current period. If this portion of business volume is still directly included in the current theoretical generation baseline, it can easily amplify the difference between the theoretical rate and the actual accounting rate, thereby causing the scheduling module 60 to continuously trigger intervention actions. To avoid this kind of feedback imbalance, the calculation module 50 performs compensatory calculations on the intervention results of the scheduling module 60.

[0068] Specifically, the calculation module 50 extracts system write requests that were forcibly discarded, suspended, temporarily rejected and allowed to retry, or redirected to the asynchronous delayed queue by the scheduling module 60 in the previous processing cycle due to triggering distributed control. The scheduling module 60 generates an intervention record for the above system write requests. The intervention record includes at least the request identifier, business direction, deducted quota, intervention type, intervention time, write status, and subsequent processing status.

[0069] The calculation module 50 calculates the interception compensation rate based on the intervention records that are not yet written to the database. When a system write request in the asynchronous delay queue is successfully written to the core accounting database in a subsequent cycle, the scheduling module 60 marks the corresponding intervention record as written to the database; the calculation module 50 will no longer include this request in the interception compensation rate in subsequent calculation cycles.

[0070] The calculation module 50 further analyzes the theoretical numerical quota contained in the system write requests and calculates compensation parameters according to the business direction. For the payable direction, the calculation module 50 divides the total quota of authorized payable requests that were not written to the database in the previous processing cycle by the duration of the previous processing cycle to obtain the payable interception compensation rate. For accounts receivable, the calculation module 50 divides the total authorized accounts receivable request quota that was not credited to the database in the previous processing cycle by the duration of the previous processing cycle to obtain the accounts receivable interception compensation rate. Interception compensation rate and accounts receivable interception compensation rate Together they constitute the negative feedback compensation parameters.

[0071] Specifically, system write requests that are deemed unauthorized or excessive due to insufficient micro-quotas are not included in the interception compensation rate; authorized system write requests that are redirected, suspended, delayed, or temporarily rejected and allowed to retry due to macro-state control are included in the interception compensation rate; system write requests that are deemed permanently rejected and will no longer enter the subsequent data storage process are no longer included in the interception compensation rate of subsequent calculation cycles.

[0072] S402, the calculation module 50 constructs a dynamic time-series deviation continuous integral model incorporating negative feedback compensation. The calculation module 50 obtains the global coping theory generation rate output by the aggregation module 40. Global accounts receivable theoretical generation rate Actual accounts payable posting rate and actual accounts receivable posting rate .

[0073] The calculation module 50 deducts the corresponding negative feedback compensation parameter from the theoretical generation rate to eliminate the impact of unrecorded business volume caused by the intervention of the scheduling module 60 itself. The theoretical generation rate after deducting the compensation parameter is used to represent the business generation benchmark that should be completed under non-intervention factors within the current calculation cycle.

[0074] Subsequently, the calculation module 50 calculates the difference between the theoretical generation benchmark and the actual accounting rate for both accounts payable and accounts receivable. To reduce the impact of instantaneous data spikes on status determination, the calculation module 50 sets a continuous integration time window. and within that continuous integration time window The difference is integrated. By introducing absolute value operations, the positive and negative deviations can be prevented from canceling each other out during the integration process.

[0075] Dynamic timing deviation The mathematical model can be expressed as: ; In the formula, Indicates time The output dynamic timing deviation value, This indicates the length of the continuous integration time window. Represents the integral variable. This represents the deviation weighting coefficient. This represents the weighting coefficient for accounts receivable deviation; Indicates time The corresponding compensation rate for interception should be paid; Indicates time The corresponding accounts receivable interception compensation rate.

[0076] In one specific embodiment, the weighting coefficient and All are real numbers greater than zero and less than or equal to one, and their specific values ​​can be set according to the company's risk sensitivity to accounts payable and accounts receivable. For example, when the risk of delayed accounts receivable is high, the value can be... Set to greater than The value is used to improve the impact of accounts receivable deviation on the overall dynamic timing deviation. The influence weight.

[0077] Continuous integration time window Covering multiple observation time windows Its length can be set according to the average dwell time of business processes, database write latency, and system throughput; In some embodiments, continuous integration time window Can be set as observation time window Ten to fifty times. With the above settings, the calculation module 50 can filter out short-cycle jitter while preserving the trend of time series changes.

[0078] S403, the calculation module 50 solves the above integral model according to the preset parameters.

[0079] The calculation module 50 will calculate the dynamic timing deviation value obtained from the solution. The output is sent to the scheduling module 60 as a macro-level status basis for subsequent microservice interface scheduling, asynchronous degradation, write request restriction, or link isolation operations.

[0080] See attached document Figure 7 As a preferred embodiment of this invention, step S500 is implemented through the following steps: S501, the scheduling module 60 is located at the application layer microservice communication gateway and is used for distributed management of write-type business requests entering the system. The scheduling module 60 receives system write request messages initiated by upper-layer application services, parses the data packet header structure of the message, and extracts the payload classification label.

[0081] The payload classification label is used to indicate the business attribute, business direction, and required quota value of the current message, and is matched with the token type field, business direction field, business request identifier field, or associated serial number field in the token data. Based on the matching result, the scheduling module 60 locates the corresponding license credential area in the memory cache pool at the front end of the scheduling module 60, and determines the quota to be deducted for the current system write request message.

[0082] The scheduling module 60 deducts the corresponding physical flow permission token quota or logical contract permission token quota from the memory cache pool. The memory cache pool uses a data structure that supports atomic operations to store the token quota. The scheduling module 60 executes the quota deduction through atomic comparison and exchange operations, distributed locks, or scripted atomic deduction instructions to avoid the same token quota being consumed repeatedly in concurrent request scenarios.

[0083] When a single system write request involves multiple business directions or multiple token types simultaneously, the scheduling module 60 reduces the relevant token quotas according to a preset deduction order or a transactional deduction mechanism. If the quota for any dimension is insufficient, the scheduling module 60 rolls back the quota deductions already completed and determines that the system write request has failed the micro-quota verification.

[0084] S502, the scheduling module 60 executes protocol layer interception based on the micro-quota verification result. When the remaining token quota for the corresponding dimension in the memory cache pool is less than the quota required by the system write request message, it is determined that the micro-quota is insufficient. At this time, the business volume corresponding to the system write request message exceeds the current license credential range.

[0085] For system write request packets that fail the micro-quota verification, the scheduling module 60 discards the system write request packet at the transport control protocol layer through the service gateway, proxy server, kernel network filtering component, virtual switch, or firewall control interface, and returns a connection reset signal to the sender. Thus, unauthorized or premature write requests are intercepted before entering the application layer business processing flow.

[0086] S503, when the remaining token quota for the corresponding dimension of the memory cache pool is greater than or equal to the quota required by the system write request message, the scheduling module 60 completes the quota deduction and enters the macro-state scheduling process. The scheduling module 60 obtains the dynamic timing deviation value output by the calculation module 50. .

[0087] The system has a pre-configured set of state thresholds. The first level of this state threshold set deviates from the threshold. Level 2 deviation threshold Deviation from the third level threshold And the thresholds at each level satisfy numerically The aforementioned thresholds can be set based on historical system load test results, database write capacity, business tolerance time windows, or accounting processing delay tolerances, and can be used to dynamically adjust time-series deviation values. It is divided into different system state intervals.

[0088] In one specific embodiment, the first-level deviation threshold The upper limit of the tolerance for normal system processing delay; the second level deviation threshold. The deviation equivalent corresponding to the maximum queuing length of the database connection pool or the safe capacity of the asynchronous queue; the third-level deviation threshold. This corresponds to a critical deviation value that may cause system write blockage, backlog of accounting data, or external abnormal traffic surges.

[0089] S504, the scheduling module 60 will dynamically adjust the timing deviation value. It is compared with the set of state thresholds, and the corresponding microservice interface scheduling operation is executed based on the comparison result.

[0090] when At that time, the system's business and financial timing matching status is determined to be normal. The scheduling module 60 maintains the synchronous communication mechanism of the microservice interface, synchronously routes the system write request message to the backend core accounting database, and the core accounting database executes the transaction commit.

[0091] when At that time, a slight timing deviation was detected in the system. The scheduling module 60 triggered the asynchronous message degradation mechanism, converting the synchronous calls of the microservice interface into asynchronous event publications, and transferring the system write request messages to a bypass asynchronous message queue for temporary storage, in order to reduce the instantaneous write pressure on the core accounting database.

[0092] When the asynchronous message queue reaches its capacity limit, the scheduling module 60 no longer treats it as a minor timing deviation, but instead escalates the situation to a severe timing deviation for cross-level handling. For system write requests that have been transferred to the asynchronous message queue but have not yet been written to the database, the scheduling module 60 generates a corresponding intervention record and feeds back the request quota, business direction, queue status, and write status to the calculation module 50 for use in calculating the interception compensation rate in the next calculation cycle. The asynchronous message queue can be implemented using a distributed message middleware; its publish-subscribe mechanism and persistence mechanism are conventional technologies in this field and will not be elaborated upon here.

[0093] when When this occurs, the system is determined to have experienced a severe timing deviation. This state indicates that there is significant congestion in the underlying accounting write process. The scheduling module 60 sends control signals to the database middleware or connection pool proxy component, triggering write request interception, read-only routing, or database read-only permission switching operations. At this time, the microservice interface only allows query requests to pass through, and new data state change requests are suspended or temporarily rejected with retry allowed, so that the system can process the backlog of accounting write tasks.

[0094] when When the system is deemed to be in a state of extreme timing instability or at risk of external abnormal traffic surges, the scheduling module 60 calls the underlying network control interface to perform isolation operations on the external service inbound links at the virtual switch or firewall level, blocking external service inbound traffic while preserving internal monitoring and management control channels.

[0095] After the system enters the business isolation protection mode, the scheduling module 60 continuously obtains status data from the core accounting database, asynchronous message queue, and computing module 50 through the internal monitoring channel. When manual intervention lifts the isolation, or when dynamic timing deviations occur... If the data falls below the preset recovery threshold for several consecutive calculation cycles, the scheduling module 60 calls the corresponding interface to release the service isolation state. The preset recovery threshold is less than or equal to the first-level deviation threshold. This is to avoid the system frequently switching between being released from isolation and being isolated again.

[0096] In a preferred embodiment of this practice, the method is further configured with an exception handling mechanism. When the calibration module 20 is unable to obtain the system network time protocol synchronization, the calibration module 20 calls a local backup time source or the most recent valid synchronization result for temporary calibration and marks the corresponding event as pending verification.

[0097] When the aggregation module 40 is unable to read the transaction commit log of the core accounting database, the aggregation module 40 maintains the previous effective actual accounting rate within the preset fault tolerance period and generates a database listening exception flag; when the exception lasts longer than the preset fault tolerance period, the aggregation module 40 marks the actual accounting rate as unavailable and triggers the scheduling module 60 to enter a protective degradation state.

[0098] When the memory cache pool experiences a connection error or insufficient capacity, the scheduling module 60 enters a protective degradation state, suspending new quota deduction requests and reporting the abnormal status to the computing module 50. Through this exception handling mechanism, the system can maintain a controllable state when the time source, database monitoring link, or cache resource is abnormal, preventing the failure of the entire early warning and control link due to the failure of a single component.

[0099] S505, the scheduling module 60 generates financial risk early warning information based on the comparison result between the dynamic time-series deviation value Dt and the state threshold set. The financial risk early warning information includes at least the early warning level, trigger time, corresponding business direction, deviation value, trigger threshold, executed control actions, and recovery conditions.

[0100] Among them, when When, the scheduling module 60 generates normal status information; when At that time, the scheduling module 60 generates a mild early warning message; when At that time, the scheduling module 60 generates a severe early warning message; when At that time, the scheduling module 60 generates an extremely critical warning message.

[0101] The scheduling module 60 writes financial risk warning information into the warning log and sends it to the financial risk monitoring terminal via message push interface, monitoring screen interface, or enterprise financial management system interface. Thus, the system can identify financial timing risks caused by accounting delays, write link congestion, or external abnormal traffic surges based on the continuous deviation between the theoretical business generation rate and the actual accounting rate, and execute corresponding hierarchical control actions according to the risk level.

[0102] To verify the effectiveness and superiority of the method provided in this embodiment, some specific examples are provided below: Taking the supplier settlement system of a certain enterprise's e-commerce platform as an example, this paper illustrates the specific numerical calculation and control process of the method described in this invention when facing high-concurrency promotional activities.

[0103] Assume the system sets both the observation time window and the continuous integration time window to be... =1 second. The preset state threshold set is as follows: the first level deviation threshold is set to 500, the second level deviation threshold is set to 1000, and the third level deviation threshold is set to 2000.

[0104] Step 1: Quota Generation and Rate Calculation to Within a 1-second time window, the front-end gateway receives a large number of physical quantity logs generated by user orders. After time-series calibration and parsing, a total of 1200 new token quotas are generated in the memory cache pool. Based on this, the theoretical generation rate for this window is calculated. .

[0105] Meanwhile, by monitoring the transaction commit logs of the core accounting database, it was determined that 800 accounts payable were actually committed to the database within that window. Based on this, the actual accounting rate was calculated. .

[0106] Step 2: Input compensation parameters into the system to extract the previous calculation cycle ( to Traffic intervention data. In the previous period, due to the triggering of the asynchronous message degradation mechanism, a total of 150 requests were diverted to the bypass asynchronous message queue and have not yet been written to the database. The interception compensation rate was calculated based on this. .

[0107] Step 3: Dynamic time series deviation value integration calculation. Within this time window, the effective theoretical generation rate after deducting compensation parameters is: 1200. 150 = 1050.

[0108] Calculate the difference between its actual accounting rate and the actual accounting rate: 1050 800 = 250, assuming If the initial cumulative deviation value at time is 350, then after continuous integration and accumulation over that second, The dynamic timing deviation value obtained at time 350 + 250 = 600.

[0109] Step 4: Status Threshold Comparison and Control Execution After receiving a new system write request message and completing the micro quota verification, the gateway reads the current dynamic timing deviation value of 600 and compares it with the preset status threshold set.

[0110] Since 500 < 600 ≤ 1000, meaning the dynamic timing deviation is greater than the first-level deviation threshold but less than or equal to the second-level deviation threshold, the system determines that there is moderate congestion in the current underlying write link and triggers the asynchronous message degradation mechanism. Subsequent system write request packets are no longer directly routed to the core accounting database, but are instead temporarily stored in a bypass asynchronous message queue. At the same time, a financial risk warning message is generated and notified to the operations and maintenance terminal.

[0111] To verify the effectiveness of the method described in this invention, a test environment was built, including a microservice gateway, a memory cache cluster, and a relational core database. The test employed a controlled variable method, injecting a step-like high-concurrency load lasting 60 seconds. The performance of existing conventional application-layer rate limiting techniques and the method of this invention was compared in terms of two indicators: backlog of accounting data and frequency of system management state switching.

[0112] Comparison of accounting data backlog indicators: The experiment set the maximum processing capacity of the system's backend core database to 1000 records per second. At the 10th second, the concurrent write requests from the frontend suddenly increased to 1800 records per second and remained thereafter.

[0113] Experimental data shows that in the control group using existing technology, because the actual underlying accounting rate cannot be perceived and only front-end fixed concurrency rate limiting is relied upon, a large number of requests queue up in the database connection pool. At the 30th second, the backlog of unprocessed accounting data in the database reached a peak of 8,500 records, and the system response latency increased significantly.

[0114] In the experimental group using the method described in this invention, during periods of sudden surge in concurrency, the dynamic timing deviation value rapidly accumulates with the integral, triggering second-level and even third-level control actions. The system promptly transfers requests to a bypass queue or intercepts them, keeping the backlog of unprocessed accounting data in the core database consistently below 1200 entries. The technical solution described in this invention effectively protects the core database and prevents downtime due to overload.

[0115] Verification of the frequency of control status switching indicator: Existing technology directly rejects requests when the application-layer queuing queue reaches full capacity, and then immediately releases the queue once it is empty, causing the system to frequently jump between normal passage and complete rejection states. Experiments showed that it experienced 24 state transitions within 60 seconds.

[0116] The method described in this invention introduces an interception compensation rate into the model ( The system pre-emptively excluded statistical biases caused by intervention actions in the previous cycle when calculating the difference. Experiments showed that the experimental group experienced only 3 smooth state upgrades and 1 state downgrade within 60 seconds. The system was able to stably maintain an asynchronous message downgrade state, avoiding misjudgments and oscillations.

[0117] Example 2 Accordingly, this embodiment provides an intelligent early warning and hierarchical control system for enterprise financial risks, used to implement the intelligent early warning and hierarchical control method for enterprise financial risks as described in any embodiment of the present invention, such as... Figure 6 As shown, it includes a data acquisition module, a calibration module, a token generation module, an aggregation module, a calculation module, and a scheduling module.

[0118] The data acquisition module 10 is located at the front end of the enterprise service bus and establishes communication connections with the underlying industrial control equipment and business management system. The data acquisition module 10 receives the underlying operation logs generated by the above data sources and uses the underlying operation logs as the data basis for subsequent timing calibration and business quota calculation.

[0119] The calibration module 20 is connected to the output of the acquisition module 10. The calibration module 20 reads the original timestamp carried in the underlying operation log, calibrates the original timestamp in conjunction with the system's unified time base, and outputs the corresponding global calibration timestamp.

[0120] The token generation module 30 is connected to the calibration module 20. The token generation module 30 includes a protocol credential generation unit and is communicatively connected to a memory cache pool located in front of the scheduling module 60. The token generation module 30 generates application-layer communication access permission credentials based on time-calibrated business event data and writes the application-layer communication access permission credentials into the memory cache pool.

[0121] The aggregation module 40 is connected to the token generation module 30 and the core accounting database. The aggregation module 40 reads the license credential quota in the memory cache pool and calculates the theoretical business generation rate; at the same time, the aggregation module 40 extracts the actual accounting data from the core accounting database to obtain the corresponding actual accounting rate.

[0122] The calculation module 50 is connected to the aggregation module 40, and the calculation module 50 is configured with a continuous time window integration algorithm model. The calculation module 50 calculates the dynamic time series deviation of the system within the continuous time window based on the business theory generation rate, the actual accounting rate, and scheduling feedback data.

[0123] The scheduling module 60 is located in the application layer microservice communication link and receives dynamic timing deviation values ​​output by the computing module 50. The scheduling module 60 performs communication traffic control through service gateways, proxy servers, kernel network filtering components, virtual switches, or firewall control interfaces, and feeds back the traffic intervention results to the computing module 50 to form a hierarchical control closed loop with feedback.

[0124] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0125] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0126] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0127] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0128] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for intelligent early warning and hierarchical control of corporate financial risks, characterized in that, Includes the following steps: S100: Collect physical quantity logs and logical contract logs, perform timing calibration, and generate standard business event sequences; S200: Parse the business attribute tags contained in the standard business event sequence, generate corresponding physical flow permission tokens and logical contract permission tokens according to the business attribute tags, and write the physical flow permission tokens and logical contract permission tokens into the memory cache pool; S300: Based on the set observation time window, read the token quota in the memory cache pool to calculate the theoretical generation rate, and read the transaction commit log of the core accounting database to calculate the actual accounting rate. S400: Receives traffic intervention data from the previous calculation cycle, calculates the interception compensation rate, and obtains the dynamic time-series deviation value through continuous integration based on the theoretical generation rate, the actual accounting rate, and the interception compensation rate. S500: Receives a system write request message, performs micro-quota verification in the memory cache pool, and when the remaining token quota of the corresponding dimension in the memory cache pool meets the quota required for system writing, compares the dynamic time-series deviation value with the preset state threshold set, performs corresponding control actions on the corresponding microservice interface according to the comparison result, and generates financial risk warning information.

2. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 1, characterized in that, The specific steps of S100 are as follows: Obtain the unified time base of the system and extract the local timestamps from the physical quantity logs and logical contract logs; Calculate the local clock drift of the corresponding data source by combining the one-way transmission delay time of the communication link; The local timestamp is compensated using the local clock drift to generate a global calibration timestamp. The payload data in the physical quantity log and logical contract log are bound and encapsulated with the corresponding global calibration timestamps. The standard business event sequence is obtained by sorting the global calibration timestamps in chronological order.

3. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 1, characterized in that, In step S200, generating the corresponding physical flow license token and logical contract license token based on the business attribute tag specifically involves: When the business attribute tag matches the physical feature identifier set, the physical quantity payload data in the standard business event sequence is converted into a quota according to the preset physical mapping coefficient matrix to obtain the numerical quota of the physical flow license token, and a unique identifier of the physical flow license token is generated by combining the one-way hash function. When the business attribute tag matches the logical feature identifier set, the logical contract payload data in the standard business event sequence is converted into a quota according to the preset logical mapping coefficient matrix to obtain the numerical quota of the logical contract license token, and a unique identifier of the logical contract license token is generated by combining it with a one-way hash function.

4. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 1, characterized in that, The theoretical generation rate includes the global payables theoretical generation rate and the global receivables theoretical generation rate, and the actual accounting rate includes the actual payables accounting rate and the actual receivables accounting rate. The calculation of the theoretical generation rate and the actual accounting rate includes: Within the observation time window, the sum of the numerical quotas of newly added token quotas classified according to the business direction field is divided by the time length of the observation time window to calculate the global payable theoretical generation rate and the global receivable theoretical generation rate. By monitoring and parsing the transaction commit logs through a change data capture mechanism, and performing correlation filtering, the sum of the core account values ​​belonging to the payable and receivable directions within the observation time window is calculated and divided by the time length to obtain the actual payable accounting rate and the actual receivable accounting rate.

5. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 4, characterized in that, The interception compensation rate includes the payable interception compensation rate and the receivable interception compensation rate; The step of calculating the dynamic time-series deviation value through continuous integration based on the theoretical generation rate, the actual accounting rate, and the interception compensation rate includes: The corresponding payable interception compensation rate and receivable interception compensation rate are deducted from the global payable theoretical generation rate and the global receivable theoretical generation rate, respectively. The difference between the theoretical generation rate after deducting the interception compensation rate and the corresponding actual accounting rate are calculated respectively. The absolute value of the difference is integrated within a continuous integration time window. The dynamic time series deviation value is obtained by combining the payable deviation weight coefficient and the receivable deviation weight coefficient.

6. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 5, characterized in that, The calculation of the interception compensation rate includes: Extract system write requests that were forcibly discarded, suspended, temporarily rejected, and allowed to retry or transferred to the asynchronous delay queue during the previous calculation cycle and are in a state of not being written to the database due to triggering control. The theoretical numerical quotas contained in the system write requests that are not yet written to the database are analyzed. The sum of the payable request quotas and the sum of the receivable request quotas that are not yet written to the database in the previous processing cycle are divided by the duration of the previous processing cycle to obtain the corresponding payable interception compensation rate and receivable interception compensation rate.

7. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 1, characterized in that, Step S500, which involves performing micro-quota verification in the memory cache pool, includes: Parse the payload classification label of the system write request message to determine the quota to be deducted for system write; Using a data structure that supports atomic operations, the corresponding quota in the memory cache pool is decremented through atomic comparison and swap operations. When the remaining token quota for the corresponding dimension in the memory cache pool is less than the quota to be deducted for system writing, it is determined that the quota is insufficient. The system write request message is discarded at the transmission control protocol layer, and a connection reset signal is returned to the sending end.

8. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 1, characterized in that, The preset state threshold set includes a first-level deviation threshold, a second-level deviation threshold, and a third-level deviation threshold that increase sequentially. The step of comparing the dynamic time-series deviation value with a preset state threshold set and performing corresponding control actions on the corresponding microservice interface based on the comparison result includes: When the dynamic timing deviation value is less than or equal to the first-level deviation threshold, the synchronous communication mechanism of the microservice interface will route the system write request message to the core accounting database. When the dynamic timing deviation value is greater than the first-level deviation threshold and less than or equal to the second-level deviation threshold, the asynchronous message degradation mechanism is triggered, and the system write request message is temporarily stored in the bypass asynchronous message queue. When the dynamic timing deviation value is greater than the second-level deviation threshold and less than or equal to the third-level deviation threshold, write request interception, read-only routing, or database read-only permission switching operation is triggered. When the dynamic timing deviation value is greater than the third-level deviation threshold, an isolation operation is performed on the external service inbound link at the network layer to block the external service inbound traffic.

9. The intelligent early warning and hierarchical control method for enterprise financial risks according to claim 8, characterized in that, The method also includes a cross-level handling mechanism: When the asynchronous message degradation mechanism is triggered and the bypass asynchronous message queue reaches its capacity limit, the processing status of the system write request message is upgraded to a status greater than the second-level deviation threshold and less than or equal to the third-level deviation threshold. The corresponding intervention record is generated, and the request quota, business direction, queue status, and database status are used as traffic intervention data feedback for the calculation of the interception compensation rate in the next calculation cycle.

10. A smart early warning and hierarchical control system for enterprise financial risks, characterized in that, The system is used to implement the enterprise financial risk intelligent early warning and hierarchical control method as described in any one of claims 1 to 9, including a data acquisition module, a calibration module, a token generation module, an aggregation module, a calculation module, and a scheduling module; The acquisition module is used to receive physical quantity logs and logical contract logs; A calibration module, connected to the acquisition module, is used to perform timing calibration and generate a standard business event sequence; The token generation module, connected to the calibration module, is used to generate corresponding physical flow permission tokens and logical contract permission tokens according to business attribute tags, and write the physical flow permission tokens and logical contract permission tokens into the memory cache pool; The aggregation module is connected to the token generation module and the core accounting database respectively, and is used to calculate the theoretical generation rate and the actual accounting rate. The calculation module, connected to the aggregation module, is used to receive traffic intervention data, calculate the interception compensation rate, and obtain the dynamic time-series deviation value through continuous integration calculation; The scheduling module is set in the application layer microservice communication link. It is used to receive system write request messages and perform micro-quota verification in the memory cache pool. When the quota is met, it executes control actions based on the comparison result of the dynamic time sequence deviation value and the state threshold set, and at the same time feeds back the traffic intervention data to the calculation module.

Citation Information

Patent Citations

  • Enterprise financial management system based on financial information processing

    CN119273487A