A method and system for trusted verification of open bank bulk tasks

Abstract

The application discloses a kind of open bank batch task trusted check method and system, belong to the field of financial technology technique.This method includes the day-end scanning and checking of independent deployment and API interface embedded check, trusted check is executed in the whole local business system.Day-end scanning and checking are checked by building control table and flow table, task execution existence, execution frequency and interval and dead task are compliance, wherein dead task determination adopts dynamic adaptive timeout threshold determined based on historical execution duration statistics.API interface embedded check executes flow pre-occupies and concurrent lock when request arrives, based on the risk level threshold dynamic adjustment of business parameter, time window check and frequency interval check, all pass and put in business execution.This application sinks trusted check capability to business system side, with local data track as only trusted basis, realizes the decentralized batch task autonomous check.

Description

Technical Field

[0001] This invention belongs to the field of financial technology, specifically relating to a trusted verification method and system for batch tasks in open banking. Background Technology

[0002] In an open banking architecture, core business systems (such as payment, clearing, and reconciliation) typically rely on a separate, company-level public scheduling platform to trigger scheduled batch tasks. The scheduling platform and the business systems belong to different database, server, and operations teams, with the business systems passively receiving scheduling instructions.

[0003] In existing technologies, to address the reliability issue of batch business scheduling, a proposed solution involves obtaining batch business scheduling requests from a bank communication server and forwarding them to a business server. The business server creates a scheduling queue and sets duration and quantity thresholds. After parsing and verifying the batch tasks, they are added to the queue. Based on the duration and quantity thresholds, batch tasks are periodically selected and sent to the batch transaction server for execution. Simultaneously, task status identifiers are set to manage execution status, and the return files are encrypted and backed up. This solution, through queue management and threshold control, alleviates the concurrency congestion problem of batch tasks to a certain extent and improves the orderly execution of the scheduling.

[0004] However, the aforementioned existing technologies still have the following drawbacks: First, there is the issue of cross-system trust gaps. This solution still follows the traditional division of labor where the scheduler is responsible for triggering and the business system is responsible for execution. The business system relies entirely on the scheduling platform's instructions and lacks the ability to independently verify the legitimacy of scheduling requests. When the scheduling platform experiences anomalies such as process freezes or network interruptions without sending requests to the business system, the business system has no means of detection and can only passively "shut down," unable to perform autonomous verification through local data traces, thus failing to guarantee business continuity.

[0005] Secondly, the ability to detect task execution anomalies is insufficient. Although this solution manages the task lifecycle through status identifiers (pending execution / in execution / success / failure), status updates rely on the interaction between the scheduling platform and the batch transaction server, which is a "scheduling-side self-verification" mode. When the scheduling platform process is alive but the logical execution is stalled (i.e., in a "frozen" state), the existing mechanism cannot detect anomalies at the business logic level, such as the task not actually executing SQL, nor can it automatically clean up zombie tasks that have been in the "in execution" state for a long time.

[0006] Third, the risk of concurrent duplicate triggering lacks effective prevention. The solution relies on a scheduling queue to manage batch tasks, but it does not provide an atomic anti-duplicate mechanism for duplicate triggering of the same task within a very short time window due to network retransmission or scheduling jitter. This poses a risk of concurrent duplicate execution in high-frequency task scenarios.

[0007] To overcome the above-mentioned technical deficiencies, this invention provides a trusted verification method and system for batch tasks in open banking.

[0008] This invention provides a trusted verification method for batch tasks in open banking, comprising independently deployed end-of-day scanning checks and API interface embedded verification; the end-of-day scanning checks serve as an offline auditing mechanism, triggered periodically by the system; the API interface embedded verification serves as a real-time risk control mechanism, triggered in response to requests from the scheduling platform; the trusted verification is executed entirely locally within the business system, without relying on status feedback from the scheduling platform.

[0009] End-of-day scanning and verification process: Construct a batch task control table, which stores task identifiers, frequency types, expected execution times, and maximum processing times.

[0010] The scanning scheduler reads the control table to obtain a list of tasks that should have been executed yesterday.

[0011] Compliance checks were performed on all tasks completed yesterday. These compliance checks included: Perform existence verification: Query the batch task flow table to check if there is an execution flow record with the corresponding task identifier yesterday. Only verify whether the scheduling platform actually triggered the task request, without distinguishing whether the final state of the flow is success or failure. Frequency and Interval Verification: For tasks with a non-interval frequency type, compare the actual number of executions yesterday with the expected number of executions. The expected number of executions is determined based on the frequency type and the expected execution time. For tasks with an interval frequency type, use the configured task start time as the starting point and the task end time as the ending point. Arrange the expected execution time points in the configured interval minutes to form a baseline execution time axis. Calculate the theoretical number of executions yesterday and compare it with the actual number of executions. At the same time, verify whether the actual execution interval meets the configured expected interval duration. Dead task verification: Scan the records in the pipeline table that are in "processing" and determine dead tasks using a dynamic adaptive timeout threshold. The dynamic adaptive timeout threshold is determined by the system before the end-of-day scan based on the normal execution time of the task over a preset number of historical days. During the statistics, abnormal samples that fail to execute, are manually terminated, or whose execution time deviates from the historical average by more than a preset multiple of the standard deviation are automatically removed. The maximum historical execution time is multiplied by a preset redundancy coefficient as the judgment threshold for the day. If there is no historical data, the maximum processing time configured in the control table is used as the initial threshold.

[0012] An alarm is triggered in response to any failure in the compliance checks.

[0013] API interface embedded verification process: In response to a request from the scheduling platform arriving at the business system API interface, a pre-validation is performed before business execution. This pre-validation includes: Pipeline pre-emption and concurrency detection: Insert a record with a status of "processing" into the batch task pipeline table, using the combination key of task identifier and execution date as a unique index, and implement a concurrent lock by utilizing the atomicity of database insertion operation; if the insertion is successful, it is considered as acquiring the lock, and subsequent verification is allowed; if a unique key conflict is triggered, it indicates that a "processing" record already exists for the same task on the same day, which is judged as a concurrent duplicate request and the current request is rejected; Business parameter parsing and dynamic threshold adjustment: Parse the business parameters carried by the current scheduling request. The business parameters include channel type and business scenario level. Determine the risk level of this request according to the preset risk level mapping rules. Apply corresponding correction coefficients to the time tolerance threshold and minimum interval threshold of this verification. Use a correction coefficient less than 1 to narrow the threshold in high-risk scenarios and a correction coefficient greater than 1 to relax the threshold in low-risk scenarios. Time window verification: A valid time window is constructed with the expected execution time point configured in the control table as the center and the time tolerance threshold dynamically adjusted by the threshold as the radius. The current request time is verified to see if it falls within the window. Frequency interval verification: Query the most recent record with a success or failure status in the current day in the transaction log table, obtain its execution start time, calculate the time difference between the current request time and that time, and verify whether the time difference falls within the minimum interval tolerance range after the threshold is dynamically adjusted; if the query is empty, it indicates that there are no executed records on that day, and the verification is based on the first expected execution time configured in the control table.

[0014] If all the above checks pass, the request is allowed and the core business logic is executed; if any check fails, the system rolls back to the state before the check and the core business logic is not executed.

[0015] After the business is completed, the task status in the transaction log is updated to success or failure based on the execution result, and the end time and error information are recorded. If the business execution times out or exits abnormally, the dead task verification in the end-of-day scan check will be used for fallback cleaning.

[0016] Accordingly, the present invention also provides a trusted verification system for batch tasks in open banking. This system is deployed on the business system side, and all verification logic is executed locally within the business system, including: The task control module is configured to store a batch task control table, which stores the task identifier, frequency type, expected execution time, and maximum processing time.

[0017] The end-of-day scanning module is configured to perform offline audit verification, including: The task acquisition unit is configured to read the control table and obtain a list of tasks to be executed yesterday; The compliance verification unit is configured to perform existence verification, frequency and interval verification, and zombie task verification on each task from yesterday. The threshold calculation unit is configured to determine the dynamic adaptive timeout threshold based on the normal execution time of the task over a preset number of historical days before the end-of-day scan. During the statistics, abnormal samples such as execution failure, manual termination, and execution time deviating from the historical average by more than a preset multiple of the standard deviation are automatically removed. The maximum historical execution time is multiplied by a preset redundancy coefficient as the judgment threshold for the day. If there is no historical data, the maximum processing time configured in the control table is used as the initial threshold. The alarm triggering unit is configured to trigger an alarm in response to any failure in the compliance verification.

[0018] The API interface verification module is configured to perform real-time risk control verification when a request from the scheduling platform arrives at the business system's API interface, including: The pipeline pre-positioning unit is configured to insert a record with a status of "processing" into the batch task pipeline table, using the combination key of task identifier and execution date as a unique index, and utilizing the atomicity of database insertion operation to implement concurrent lock; if the insertion is successful, it is considered as acquiring the lock, and subsequent verification is allowed; if a unique key conflict is triggered, it indicates that a "processing" record already exists for the same task on the same day, and it is judged as a concurrent duplicate request and the current request is rejected; The threshold dynamic adjustment unit is configured to parse the business parameters carried by the current scheduling request. The business parameters include the channel type and business scenario level. The risk level of the current request is determined according to the preset risk level mapping rule. The corresponding correction coefficients are applied to the time tolerance threshold and minimum interval threshold of the current verification. A correction coefficient of less than 1 is used to narrow the threshold in high-risk scenarios and a correction coefficient of more than 1 is used to relax the threshold in low-risk scenarios. The time window verification unit is configured to construct a legal time window with the expected execution time point configured in the control table as the center and the time tolerance threshold adjusted by the threshold dynamic adjustment unit as the radius, and to verify whether the current request time falls within the window. The frequency interval verification unit is configured to query the most recent record with a success or failure status in the current day in the flow table, obtain its execution start time, calculate the time difference between the current request time and that time, and verify whether the time difference falls within the minimum interval tolerance range adjusted by the threshold dynamic adjustment unit; if the query is empty, it indicates that there is no executed record on that day, and the verification is performed based on the first expected execution time configured in the control table. The business execution release unit is configured to release the request and trigger the execution of the core business logic in response to the passing of all checks by the flow pre-occupancy unit, time window verification unit, and frequency interval verification unit; if any check fails, it will roll back to the state before the check and will not trigger the execution of the core business logic. The status update unit is configured to update the task status in the flow table to success or failure based on the execution result after the business is completed, and record the end time and error information; if the business execution times out or exits abnormally, the dead task verification in the compliance verification unit of the end-of-day scanning module will perform fallback cleanup.

[0019] The core inventive concept of this invention lies in breaking the traditional division of labor between the scheduling platform and the business system, where "the scheduler is responsible for triggering and the business is responsible for execution," and completely sinking the trusted verification capability to the business system side to build an autonomous reverse verification architecture based solely on local data trajectories.

[0020] Compared with the prior art, this application has the following beneficial effects: 1. Decentralized verification architecture This application deploys the verification logic, status determination, request interception, and alarm triggering entirely locally on the business system, without requiring any status reporting data from the scheduling platform. In existing technologies, verification capabilities are all deployed on the scheduling side, with the business system only passively receiving requests. Status identifier updates rely entirely on feedback from the scheduling platform, which is a "scheduling-side self-verification" model. The business system itself has no active verification authority, and this cannot solve the cross-system trust issue.

[0021] 2. Time-dimensional coordination of dual verification mechanism This application employs two independent parallel mechanisms: API interface embedded verification (real-time pre-interception) and end-of-day scanning verification (T+1 offline fallback audit), forming complementary coverage in the time dimension. Existing technologies rely solely on status identifier management in the real-time request processing flow and lack offline auditing capabilities. When the scheduling platform fails to send a request due to an anomaly, the business system has no historical trajectory to trace back, making it impossible to verify "missed" events.

[0022] 3. Dynamically adaptive timeout threshold This application employs a dynamic threshold for zombie task identification. Based on the statistical distribution of historical normal execution times, it adaptively generates a daily judgment threshold. After automatically removing abnormal samples, the threshold is calculated by multiplying the historical maximum execution time by a redundancy coefficient, balancing detection rate and false alarm rate. Existing technologies use fixed duration thresholds for periodically selecting tasks from the scheduling queue, rather than for zombie task identification. In zombie scenarios, fixed thresholds cannot adapt to fluctuations in data volume for long-running tasks.

[0023] 4. Database unique index atomic lock This application uses a composite key of "task identifier + execution date + processing status" as a unique index, and leverages the atomicity of database insertion to implement concurrent locks, eliminating the need for external distributed middleware. Existing technologies control the number of concurrent threads through scheduling queues, but state reading and updating are separate operations, failing to provide atomicity and deduplication prevention guarantees.

[0024] 5. Dynamic adjustment of thresholds driven by business risk levels This application determines the risk level based on channel type and business scenario level, and applies differentiated correction coefficients to the tolerance threshold (narrowing for high risk and relaxing for low risk). In existing technologies, the threshold is statically configured, which cannot dynamically balance risk control accuracy and business availability.

[0025] 6. Precise frequency verification of the benchmark execution time axis drive This application constructs a baseline execution timeline for interval-type tasks using start time, end time, and fixed intervals, and uniformly applies it to the three verifications of time window, execution interval, and execution count. Existing technology's status identifiers only track the execution process of "queued tasks," lacking a time-dimensional expected distribution model, and cannot determine whether tasks are "missed" or "over-run," or whether the intervals are compliant.

[0026] The aforementioned technical features are closely linked through the core concept of "local data trajectory as the sole reliable basis": the dual-table linkage of the control table and the transaction table provides a unified and reliable data source for the dual verification mechanism; real-time interception and offline auditing form a dual-protection closed loop of "pre-emptive interception + post-event fallback" in the time dimension; the dynamic correction of risk levels in API verification and the historical statistical adaptive threshold in end-of-day scanning share the same statistical framework, ensuring that the logic of real-time and offline judgment standards is consistent; the benchmark execution time axis uniformly serves the three verifications, ensuring that "real-time release" and "offline judgment" are based on the exact same expected distribution model. The above synergistic effects are not a simple superposition of the individual effects of each feature, but together constitute a complete decentralized task reliable verification technical solution. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the overall process of the method described in this application. Figure 2 This is a module architecture diagram of the system in this application. Detailed Implementation

[0028] Definitions: Batch Task Control Table: This table stores the static configuration and dynamic expectations of tasks, and is used to define the scheduling rules and verification criteria for tasks, including fields such as task identifier, frequency type, expected execution time, and maximum processing time.

[0029] Batch Task Flowchart: Stores the dynamic results of each execution instance of a task, including execution status, timestamp, and error code, used for tracing the task execution trajectory and verifying compliance.

[0030] Frequency type: The cycle pattern of task execution, including daily, weekly, monthly, yearly and interval types, used to determine the expected execution frequency and time distribution of the task.

[0031] Intermittent tasks: Tasks with an interval frequency type have their execution times arranged sequentially within a single execution cycle, starting from the configured task start time and ending at the task end time, according to fixed intervals of minutes, forming a baseline execution timeline.

[0032] Benchmark execution timeline: For interval-type tasks, within a single execution cycle, the time series consists of all expected execution time points arranged sequentially at fixed intervals of minutes, with the configured task start time as the starting point and the task end time as the ending point. It serves as a unified calculation benchmark for execution count verification, time window verification, and interval compliance verification.

[0033] Time tolerance threshold: The maximum allowable deviation between the actual execution time and the expected execution time of a task, used to cope with system jitter and network latency, in minutes.

[0034] Interval time tolerance ratio: In interval-type tasks, the deviation threshold is expressed as a percentage of the interval duration and is used to dynamically adapt the verification accuracy to different interval periods.

[0035] End-of-day scan check: An offline auditing mechanism, independent of business traffic, is triggered and executed periodically by the system to verify the existence of tasks from the previous day, count the number of executions, and clean up dead tasks.

[0036] API Interface Embedded Verification: A real-time risk control mechanism that embeds verification logic into the API interface of the business system. It is triggered to execute in response to the arrival of a request from the scheduling platform, and completes pre-verification before the core business logic is executed.

[0037] Pre-emptive flow: An atomic operation in API pre-validation, which uses the atomicity of database unique indexes to implement distributed concurrent locks by inserting records in the batch task flow table with the status of "processing" to prevent concurrent duplicate calls.

[0038] Dead task: A task instance whose status in the batch task pipeline is "processing" and whose execution time exceeds the dynamic adaptive timeout threshold is judged as an abnormally stalled task instance.

[0039] Dynamic adaptive timeout threshold: The judgment threshold is determined by the system before the end-of-day scan based on the normal execution time of the task over a preset number of historical days. During the statistics, abnormal samples such as execution failure, manual termination, and execution time deviating from the historical average by more than a preset multiple of the standard deviation are automatically removed. The maximum historical execution time is multiplied by a preset redundancy coefficient as the judgment threshold for the day.

[0040] Existence verification: Query the batch task log table to check if there is an execution log record with the corresponding task identifier yesterday. Only verify whether the scheduling platform actually triggered the task request, without distinguishing whether the final state of the log is success or failure.

[0041] Example 1 like Figure 1 As shown, this embodiment provides a trusted verification method for batch tasks in open banking. All verification logic of this method is executed locally within the business system, without relying on status feedback from the scheduling platform. The method includes two parallel mechanisms: a daily end-of-day scan check and an API interface embedded verification, deployed independently. The daily end-of-day scan check, as an offline auditing mechanism, is triggered and executed daily at midnight by a timer within the business system. The API interface embedded verification, as a real-time risk control mechanism, is triggered synchronously in response to every request initiated by the scheduling platform to the business system's API interface.

[0042] I. End-of-Day Scanning and Inspection Process First, a batch task control table is pre-built in the local database of the business system. This control table uses the task identifier as the primary key, and each row records the static configuration information of a batch task. The fields of the control table include: Task Identifier, used to uniquely identify a batch task; Task Name, used to describe the business meaning of the task; Frequency Type, used to indicate the execution cycle mode of the task, with possible values ​​including daily, weekly, monthly, yearly, and interval types; Expected Execution Time, used to configure the theoretical trigger time of the task within each execution cycle; and Maximum Processing Time, used as the initial upper limit threshold for the execution time of the task. For weekly tasks, the expected execution time is specifically represented by a specific date within the week, such as every Monday or Wednesday. For monthly tasks, the expected execution time is specifically represented by a specific date within the month, such as the 1st or 15th of each month. For yearly tasks, the expected execution time is specifically represented by a specific month and day within the year, such as June 23rd of each year. For interval tasks, the expected execution time is specifically represented by a combination of the task start time, task end time, and interval minutes. The control table also includes a task activation status field, which indicates whether the task is currently active. Only active tasks are included in the validation. Taking a bank's open banking system as an example, a typical record in the batch task control table is: task identifier RCN_001, task name "End-of-Day Batch Reconciliation", frequency type "Daily", expected execution time "23:00 daily", maximum processing time "60 minutes", and task activation status "true".

[0043] A batch task log table is pre-built in the local database of the business system. Each record in this log table corresponds to one execution instance of a task. The fields of the log table include: unique log identifier, task identifier, execution date, execution start time, execution end time, task status, and error information. The task status includes three values: success, failure, and processing. A unique index is built in the log table using the combination of task identifier and execution date, and this unique index only applies to records with the status of processing. For example, when a day-end batch reconciliation task is triggered at 23:00 on a certain day, a new record will be added to the log table, with a task identifier of RCN_001, an execution date of the current day, an execution start time of 23:00:00, and a task status of processing.

[0044] The scan scheduler is triggered and executed daily at midnight. The scheduler first reads the batch task control table, filters out all task records with a true activation status, and obtains a list of task identifiers that should have been executed the previous day. Then, the scheduler iterates through this task list, performing compliance checks on each task individually. Before iterating through each task, the scheduler first applies a database row-level pessimistic lock to the row record corresponding to the current task in the batch task control table, specifically by executing a SELECT...FORUPDATE statement. During the period this row lock is held, the scheduler completes the flow check, status determination, and alarm triggering for the task, ensuring that only one scan instance processes the task at a time, avoiding duplicate alarms and status overwriting.

[0045] Compliance verification includes three sub-verifications: execution existence verification, frequency and interval verification, and zombie task verification.

[0046] The specific process of performing existence verification is as follows: The scanning scheduler performs a query operation in the batch task pipeline table using the task identifier of the current task and yesterday's date as combined query conditions. If the query result is empty, it indicates that there were no execution pipeline records corresponding to this task identifier yesterday, meaning that the scheduling platform did not send a trigger request for this task to the business system yesterday, and the existence verification is determined to have failed. If the query result is not empty, it indicates that the scheduling platform did trigger the task request, and the existence verification is determined to have passed. It should be noted that the existence verification only checks whether a pipeline record exists, and does not distinguish whether the final status of the pipeline record is success or failure. Even if the task execution fails, but a pipeline record with a failure status exists, the existence verification is still determined to have passed.

[0047] For example, if the end-of-day batch reconciliation task was not triggered at its expected execution time of 11 PM yesterday due to a network outage on the scheduling platform, then there will be no record in the transaction log with task identifier RCN_001 and execution date of yesterday. The scan scheduler will find the query result empty when performing an existence check, thus determining that the task was missed. If the task was triggered but failed due to abnormal business data, there will be a record in the transaction log with task identifier RCN_001, execution date of yesterday, and task status of failure. The existence check query result will not be empty, thus determining that the task is compliant in terms of triggering existence. The result of its execution failure will be handled separately by the business log.

[0048] The specific process for frequency and interval verification varies depending on the type of task frequency.

[0049] For tasks with non-interval frequency types, including daily, weekly, monthly, and yearly types, the scan scheduler first determines the theoretically expected number of executions for the previous day based on the task's frequency type and expected execution time. Specifically, for daily tasks, every day is an expected execution day, with an expected execution count of 1. For weekly tasks, yesterday is an expected execution day only if its weekday value matches a specific date within the configured week, with an expected execution count of 1; otherwise, yesterday is not an expected execution day, and the expected execution count is 0. For example, if a weekly task is configured to execute every Monday, and yesterday was Monday, the expected execution count is 1; if yesterday was Tuesday, the expected execution count is 0. For monthly tasks, yesterday is an expected execution day only if its date value matches a specific date within the configured month, with an expected execution count of 1; otherwise, yesterday is not an expected execution day, and the expected execution count is 0. For example, a monthly task is configured to execute on the 15th of each month. If yesterday was the 15th, the expected execution count is 1; if yesterday was the 16th, the expected execution count is 0. For annual tasks, yesterday is considered an expected execution day and the expected execution count is 1 only if yesterday's month and date values ​​match the configured average day of a specific month within the year; otherwise, yesterday was not an expected execution day, and the expected execution count is 0. After determining the expected execution count, the scheduler queries all log records corresponding to the task identifier from yesterday in the batch task log table, counts the actual execution count, and compares the actual execution count with the expected execution count. If they match, the frequency and interval verification passes; if they do not match, the frequency and interval verification fails, specifically including cases where the actual execution count is more than the expected execution count (overrunning) and cases where the actual execution count is less than the expected execution count (missed execution).

[0050] For interval-type tasks, the scan scheduler first uses the configured task start time as the starting point and the task end time as the ending point. Based on the configured interval in minutes, it sequentially arranges all expected execution time points within the time range of yesterday's calendar day, forming the baseline execution time axis for that task yesterday. The specific generation rules for the baseline execution time axis are as follows: using yesterday's calendar day 0:00:00 to yesterday's 23:59:59 as the time boundary, the configured start time is taken as the starting point and the end time as the ending point. If the configured start time is earlier than yesterday's 0:00, it is truncated to yesterday's 0:00; if the configured end time is later than yesterday's 23:59:59, it is truncated to yesterday's 23:59:59. The nth expected execution time point Tn is equal to the product of the start time plus n minus 1 and the interval in minutes, and Tn is less than or equal to the end time. The first expected execution time is fixed at the configured start time. If the last interval exceeds the end time, that time point is discarded and not included in the baseline axis. After the baseline execution timeline is generated, the scan scheduler counts the total number of expected execution time points on that timeline, which is taken as the theoretical execution count for yesterday. Subsequently, the scan scheduler queries all log records corresponding to the task identifier from yesterday in the batch task log table, counts the actual execution count, and compares the actual execution count with the theoretical execution count. If they match, the execution count verification passes; if they do not match, the verification fails. Simultaneously, the scan scheduler sorts all log records from yesterday according to their execution start time, calculates the time difference between the execution start times of adjacent records, and compares this time difference with the configured expected interval duration. If all time differences are greater than or equal to the expected interval duration, the interval compliance verification passes; if any time difference is less than the expected interval duration, the interval compliance verification fails.

[0051] For example, a payment result verification task with the task identifier QRY_005, frequency type is interval, task start time is 8:00 AM daily, task end time is 10:00 PM daily, interval is 5 minutes, and expected interval duration is 4 minutes. The scanning scheduler calculates the baseline execution timeline of this task from the previous day in the early morning of the following day, generating an expected execution time point every 5 minutes from 8:00 AM to 10:00 PM, for a total of 169 time points, meaning a theoretical execution count of 169 times. If there are actually 168 records in the transaction log, the actual number of executions is less than the expected number, the frequency verification fails, and a missed execution alarm is triggered. If there are 170 records in the transaction log, the actual number of executions is more than the expected number, triggering an over-execution alarm. If there are 169 records in the transaction log, but the time difference between two adjacent records is 3 minutes, while the expected interval duration is 4 minutes, the interval compliance verification fails, triggering an interval violation alarm.

[0052] The specific process for zombie task verification is as follows: The scan scheduler first queries the batch task pipeline table, filtering out all pipeline records where the task status is "processing" and the execution date is yesterday. For each filtered "processing" record, the scan scheduler performs a zombie determination. The basis for zombie determination is the dynamic adaptive timeout threshold, which is pre-calculated and determined by the system before the end-of-day scan execution. The calculation process of the dynamic adaptive timeout threshold is as follows: The scan scheduler extracts all execution pipeline records corresponding to the task identifier for the past 30 natural days from the batch task pipeline table, filtering out records with a successful task status as normal execution samples. Based on this, the scan scheduler further eliminates abnormal samples. Specifically, it calculates the historical mean and standard deviation of the execution time of all successful samples, and considers samples whose execution time deviates from the historical mean by more than 3 times the standard deviation as abnormal samples and eliminates them. After eliminating abnormal samples, the scan scheduler takes the maximum execution time among the remaining normal samples, multiplies this maximum value by a redundancy coefficient of 1.5, and uses the resulting product as the dynamic adaptive timeout threshold for the day. If the task is a new task, meaning there are no execution log records within the past 30 calendar days, the scan scheduler uses the maximum processing time configured in the control table as the initial judgment threshold. After determining the dynamic adaptive timeout threshold, the scan scheduler calculates the time difference between the current system time and the execution start time of the record in processing. If this time difference is greater than the dynamic adaptive timeout threshold, the task instance corresponding to the record is determined to be a zombie task. After being determined to be a zombie task, the scan scheduler again checks whether the current record status is still in processing through row locking. Only when the status is still in processing is the task status of the record updated to failure, and the error message "task execution timeout zombie" is filled in, while triggering a zombie alarm. This secondary check is used to avoid overwriting the status of tasks that have been completed normally.

[0053] For example, a batch interest settlement task at the end of a month might be identified as INT_002. The successful execution times for this task over the past 30 calendar days were 62 minutes, 68 minutes, 75 minutes, 71 minutes, 65 minutes, 73 minutes, and 110 minutes, respectively. The scheduler calculates the historical average execution time of these samples to be 75 minutes, with a standard deviation of approximately 13.3 minutes. Samples with execution times of 110 minutes deviate from the historical average by more than three times the standard deviation (more than 40.5 minutes) and are therefore identified as outliers and removed. After removal, the maximum execution time among the remaining samples is 75 minutes. Multiplying this by a redundancy factor of 1.5, the daily dynamic adaptive timeout threshold is set at 112.5 minutes. If yesterday's interest settlement task actually took 115 minutes, it exceeds this threshold and is considered a dead task. If the task is a new addition, the maximum processing time of 120 minutes configured in the control table is used as the initial threshold.

[0054] In response to any failure of the above three sub-verifications, the scan scheduler triggers the corresponding alarm. Specifically, a missed execution alarm is triggered when the existence verification fails. When the frequency and interval verification fails, an overrun alarm is triggered if the actual number of executions exceeds the expected number; a missed execution alarm is triggered if the actual number of executions is less than the expected number; and an interval violation alarm is triggered if the execution interval is shorter than the expected interval. A zombie task alarm is triggered when a zombie task is detected during the zombie task verification. All alarms are sent to operations and maintenance personnel via SMS or email.

[0055] II. API Interface Embedded Verification Process When the scheduling platform initiates a Hypertext Transfer Protocol (HTTP) request to the API interface of a business system, the API gateway of the business system first triggers an embedded verification process in the API interface before routing the request to the core business logic. This verification process is executed as the filter stage of the request processing pipeline, and all verification logic is completed locally in the business system without any interaction with the scheduling platform.

[0056] The first step in API interface embedded validation is pipeline pre-emption and concurrency detection. After receiving a scheduling request, the business system parses the task identifier and request initiation time carried in the request body, extracting the date portion of the request initiation time as the execution date. Subsequently, the business system constructs a new pipeline record. The fields of this record include: task identifier (the parsed task identifier); execution date (the date extracted from the request initiation time); execution start time (the request initiation time); and task status (processing). The business system attempts to insert this pipeline record into the batch task pipeline table. This insertion operation utilizes a pre-built unique index on the pipeline table, which is composed of the task identifier, execution date, and status fields. This unique index constraint is only effective when the status is "processing." When the database executes this insertion operation, if there is no existing record in the pipeline table with the same task identifier and execution date and a status of "processing," the insertion operation is successful. The business system considers this a successful acquisition of the concurrency lock and allows the request to proceed to subsequent validation steps. If a record with the same task identifier and execution date as the record in the log table already exists and is in the processing state, the current insert operation will trigger a database unique key conflict exception. After the business system catches the exception, it will determine that it is a concurrent duplicate request and immediately return a rejection response to the scheduling platform. The current request will be terminated and no subsequent verification or business logic will be executed.

[0057] For example, when a payment result verification task arrives at the business system API interface at 8:05:00, the transaction pre-registration unit successfully inserts a transaction record with task identifier QRY_005, execution date, and status "processing". If, due to the network retransmission mechanism, another request for the same task arrives again at 8:05:00:30, the transaction pre-registration unit attempts to insert a record with the same task identifier, execution date, and status "processing" again. At this point, a unique key conflict exception is triggered, and the duplicate request is rejected.

[0058] After the pre-emptive flow and concurrency checks pass, the system proceeds to the business parameter parsing and dynamic threshold adjustment steps. The business system parses the channel type and business scenario level fields from the scheduling request. Channel types include, but are not limited to, online banking channels, mobile banking channels, counter channels, and third-party partner channels. Business scenario levels include, but are not limited to, large-value clearing scenarios, ordinary payment scenarios, query scenarios, and data synchronization scenarios. The business system has a pre-set risk level mapping rule table, which takes the combination of channel type and business scenario level as input and the risk level as output. For example, a large-value clearing scenario with an online banking channel is mapped to a high-risk level, an ordinary payment scenario to a medium-risk level, and query and data synchronization scenarios to a low-risk level. After determining the risk level, the business system determines the time tolerance threshold correction coefficient and the minimum interval threshold correction coefficient for this verification based on the risk level. The correction coefficient is a positive number greater than 0. In high-risk scenarios, the correction coefficient is 0.6, used to narrow the tolerance threshold and improve verification accuracy. In low-risk scenarios, the correction coefficient is 1.3, used to relax the tolerance threshold and reduce the probability of false interception. In medium-risk scenarios, the correction factor is set to 1.0, keeping the original threshold unchanged.

[0059] For example, when a large disbursement request arrives through an online banking channel, the threshold dynamic adjustment unit parses the channel type as online banking and the business scenario level as large disbursement, queries the mapping table to determine it as a high-risk level, and sets the correction coefficient to 0.6. When a small disbursement request arrives through a mobile banking channel, it is determined to be a low-risk level, and the correction coefficient is set to 1.3.

[0060] The next step is the time window verification. The business system constructs a valid execution time window centered on the expected execution time configured in the batch task control table for the current task, with a dynamically adjusted time tolerance threshold as the radius. Specifically, the left boundary of this time window equals the expected execution time minus the adjusted time tolerance threshold, and the right boundary equals the expected execution time plus the adjusted time tolerance threshold. The business system obtains the initiation time of the current request and determines whether this time falls within the valid time window. If the current request time falls within the window, the time window verification passes. If the current request time is earlier than the left boundary or later than the right boundary, the time window verification fails. For interval-type tasks, the business system first determines the nearest expected execution time on the baseline execution time axis based on the current day, and then constructs a valid time window centered on this nearest expected execution time for verification.

[0061] For example, the expected execution time for a daily reconciliation task is 11 PM daily, with an initial time tolerance threshold of 5 minutes. For high-risk scenarios, the adjustment factor is 0.6, resulting in an adjusted time tolerance threshold of 3 minutes, and a valid time window from 10:57 PM to 11:03 PM. If a request arrives at 11:04 PM, it exceeds the window, and the time window validation fails. For low-risk scenarios, the adjustment factor is 1.3, resulting in an adjusted time tolerance threshold of 6.5 minutes, and a valid time window from 10:53:30 PM to 11:06:30 PM. If a request arrives at 11:04 PM, it falls within the window, and the time window validation passes.

[0062] The frequency interval verification step then begins. The business system uses the current task identifier and date as query criteria to search the batch task log table for all existing log records for the current day. It then filters out records with a success or failure status, sorts them in descending order of execution start time, and takes the first record after sorting—the most recent completed log record for the current day. If the query result is not empty, the business system retrieves the execution start time from that record, calculates the time difference between the current request initiation time and that execution start time, expressed in minutes. The business system retrieves the expected interval duration configured for the task from the control table, multiplies the configured "standard interval duration" by the aforementioned correction coefficient to obtain the adjusted expected interval duration, and constructs a tolerance range centered on this expected interval duration with a 10% baseline deviation. The left boundary of this tolerance range equals the adjusted expected interval duration minus the baseline deviation, and the right boundary equals the adjusted expected interval duration plus the baseline deviation. The business system determines whether the calculated time difference falls within this tolerance range. If it does, the frequency interval verification passes. If the time difference is less than the left boundary of the tolerance interval, it indicates that the time interval between the current request and the last execution is too short, posing a risk of duplicate triggering, and the verification fails. If the time difference is greater than the right boundary of the tolerance interval, it indicates that the time interval between the current request and the last execution is too long, potentially posing a risk of missed execution, and the verification fails. If the query result is empty, it indicates that there are no completed execution records for the day, and the current request is the first request of the day. The business system uses the expected execution time of the first request configured in the control table as a benchmark to determine whether the current request time falls within the tolerance interval near the expected execution time of the first request. If so, the frequency interval verification passes; otherwise, the verification fails.

[0063] For example, a certain interval-based verification task has an expected interval of 5 minutes and a correction factor of 1.0. The adjusted expected interval is 5 minutes, with a tolerance range of 4.5 to 5.5 minutes. If the current request time is 8:10, and the execution start time of the most recent successful record of the day is 8:05, the time difference is 5 minutes, falling within the tolerance range, and the frequency interval verification passes. If the current request time is 8:08, the time difference is 3 minutes, less than 4.5 minutes, the verification fails, and it is determined to be a duplicate trigger. If the current request time is 8:13, the time difference is 8 minutes, greater than 5.5 minutes, the verification fails. If the query result is empty, meaning there are no execution records for the day, and the current request is at 8:00, the first expected execution time is at 8:00, falling within the tolerance range, and the verification passes.

[0064] If the pre-emptive flow and concurrency detection, time window verification, and frequency interval verification all pass, the business system will allow the request and route it to the core business logic module to perform specific business processing, including but not limited to payment transaction processing, clearing and reconciliation processing, or data synchronization processing.

[0065] If any of the above checks fails, the business system performs a rollback operation. Specifically, for processing log records that have been successfully inserted during the log pre-emption and concurrency detection steps, the business system performs a database rollback operation, deleting the log record from the log table and restoring the database to its state before the check step was executed. If the time window check or frequency interval check fails, the business system does not execute any core business logic and directly returns a check failure response to the scheduling platform, terminating the current request processing flow.

[0066] After the core business logic is executed, regardless of whether the execution result is success or failure, the business system updates the task status in the pipeline table according to the execution result. If the business execution is successful, the business system updates the status of the processing record inserted in the pipeline pre-emption step to success and records the execution end time. If the business execution fails, the business system updates the status of the record to failure, records the execution end time, and records the reason for failure in the error information field. If the business execution times out or the process exits abnormally, causing the status to fail to be updated in time, the pipeline record will remain in the processing state, and the dead task verification in the aforementioned end-of-day scanning and inspection process will perform fallback identification and cleanup in the early morning of the next day.

[0067] For example, after a daily batch reconciliation task is successfully executed, the status update unit updates the task status of the transaction record from "processing" to "successful," and records the execution end time as 23:15. If the task fails due to data anomalies, the status update unit updates the task status to "failed," and the error information field records that reconciliation data is missing.

[0068] III. Transaction Consistency Guarantee All database operations in the above process are executed within the same database transaction. Specifically, the pipeline insertion and concurrency detection operations in the API pre-validation are executed within the same database transaction. If the concurrency detection determines a duplicate request or subsequent validation fails, the entire transaction is rolled back, leaving no invalid pipeline records. The status update and error message writing operations in the API post-processing are executed within the same database transaction. If an exception occurs during business execution, preventing the status from being updated, the transaction is rolled back to the state before validation. The task row locking, pipeline validation, and status update operations in the end-of-day scan are executed within the same database transaction. If an exception occurs midway, all operations are rolled back to avoid a half-updated state. The isolation level of all database transactions is uniformly set to Read Committed to ensure concurrency performance while avoiding dirty reads.

[0069] Example 2 This embodiment provides a trusted verification system for batch tasks in open banking. The system is deployed on the business system side and is used to execute the trusted verification method as described in Embodiment 1.

[0070] like Figure 2 As shown, the system includes a task control module, a day-end scanning module, and an API interface verification module. The task control module is deployed in the local database of the business system and includes a batch task control table submodule and a batch task log table submodule.

[0071] The Batch Task Control Table submodule stores the batch task control table. This control table uses the task identifier as the primary key and includes the following fields: Task Identifier (string type) uniquely identifies a batch task; Task Name (string type) describes the task's business meaning; Frequency Type (enumerated type, values ​​include day, week, month, year, and interval) indicates the task's execution cycle pattern; Expected Execution Time (time type), storing a specific time point for day, week, month, and year type tasks, and the task start time for interval type tasks; Task End Time (time type, only valid for interval type tasks, indicating the end time of the interval type task within a single execution cycle); Interval in Minutes (integer type, only valid for interval type tasks, indicating the number of minutes between two consecutive expected executions); Maximum Processing Time (integer type, in minutes), serving as the initial upper limit threshold for the task's execution duration; Weekly Frequency Date (integer type, value 1). The following fields are valid only for weekly tasks: 7. Monthly Frequency Date (integer, 1-31, valid only for monthly tasks, indicating the expected execution date within a month); Annual Frequency Month (integer, 1-12, valid only for yearly tasks, indicating the expected execution month within a year); Annual Frequency Date (integer, 1-31, valid only for yearly tasks, indicating the expected execution day within the year's frequency); Task Activation Status (Boolean, indicating whether the task is currently participating in verification); Time Tolerance Threshold (integer, in minutes, configuring the maximum allowable deviation between the actual and expected execution times); Interval Time Tolerance Ratio (floating-point, percentage, used for interval deviation thresholds in interval-type tasks); and Handling Type (indicating the handling method when verification fails, with values ​​of blocking and alarming or alarming only).

[0072] The batch task log table submodule is used to store batch task log tables. This log table contains the following fields: a unique identifier field (string type) serving as the primary key; a task identifier field (string type) associated with the task identifier in the control table; an execution date field (date type) recording the date the task was executed; an execution start time field (timestamp type) recording the time the task started execution; an execution end time field (timestamp type) recording the time the task finished execution; a task status field (enumerated type) with values ​​of success, failure, and processing; an error message field (string type) recording the error reason description when the task failed; and a request message information field recording key information from the original request message for traceability. A unique index is constructed in the log table using the combination of the task identifier, execution date, and task status fields. The application layer ensures that a record is inserted only when the task status is "processing," utilizing the atomicity of this unique index to implement concurrent locks; alternatively, the database's partial index functionality can be used to limit the constraint scope of this unique index to records with a task status of "processing."

[0073] The end-of-day scanning module is deployed on the application server of the business system and is triggered to run every morning at midnight by the system's internal timer. This module includes a task acquisition unit, a threshold calculation unit, a compliance verification unit, and an alarm triggering unit.

[0074] The task acquisition unit is configured to, after a scheduled trigger at midnight each day, first establish a connection with the local database of the business system, execute a query to read all task records in the batch task control table where the task activation status is true, extract the task identifier field value of each record from the query results, and form a list of task identifiers that should be executed yesterday. Before iterating through each task in this task list, the task acquisition unit executes a SELECT...FORUPDATE statement to apply a row-level exclusive lock to the row record of the current task in the batch task control table, ensuring that only one scan instance can process the task at a time.

[0075] The threshold calculation unit is configured to pre-calculate the dynamic adaptive timeout threshold for each task to be verified before the end-of-day scan is officially executed. For each task, the threshold calculation unit performs the following operations: It queries the batch task pipeline table for all execution pipeline records corresponding to the task identifier over the past 30 calendar days, filtering out records with a successful task status as valid samples. For each selected valid sample, the threshold calculation unit calculates its execution duration, which is equal to the execution end time minus the execution start time. The threshold calculation unit calculates the arithmetic mean and standard deviation of the execution durations of all valid samples. The threshold calculation unit iterates through all valid samples, identifying and removing samples whose execution duration deviates from the arithmetic mean by more than 3 times the standard deviation as abnormal samples. After removing abnormal samples, the threshold calculation unit takes the maximum execution duration among the remaining samples, multiplies this maximum value by a redundancy factor of 1.5, and uses the resulting product as the dynamic adaptive timeout threshold for the day. If the task has no execution pipeline records in the past 30 calendar days (i.e., the task is a new task), the threshold calculation unit uses the value of the maximum processing time segment configured in the control table as the initial judgment threshold.

[0076] The compliance verification unit is configured to perform compliance checks on all tasks from yesterday. The compliance verification unit includes an execution existence subunit, a frequency interval verification subunit, and a dead verification subunit.

[0077] When performing an existence check, the existence subunit uses the task identifier of the current task and yesterday's date as combined query conditions to perform a count query operation in the batch task log table to obtain the total number of log records corresponding to that task identifier yesterday. If the total number is equal to 0, the existence check is considered to have failed. If the total number is greater than 0, the existence check is considered to have passed.

[0078] In frequency and interval verification, the frequency interval verification subunit first reads the frequency type field value of the current task in the control table. If the frequency type is daily, weekly, monthly, or yearly, the frequency interval verification subunit determines whether yesterday was the expected execution day and the expected number of executions based on the frequency type and the configured expected execution time. If yesterday was the expected execution day, the expected number of executions is 1; if yesterday was not the expected execution day, the expected number of executions is 0. The frequency interval verification subunit then queries the transaction log table using the task identifier and yesterday's date as conditions to count the actual number of executions. It compares the actual number of executions with the expected number of executions; if they match, the verification passes; otherwise, the verification fails. If the frequency type is interval-based, the frequency interval verification subunit first generates a baseline execution timeline within the time range of yesterday's calendar day, using the configured task start time as the starting point and the task end time as the ending point, according to the configured interval in minutes. The generation rules for the baseline execution timeline are as follows: Using yesterday's 0:00:00 as the starting boundary and yesterday's 23:59:59 as the ending boundary, the larger of the configured start time and the starting boundary is taken as the actual starting point, and the smaller of the configured end time and the ending boundary is taken as the actual ending point. The nth expected execution time point Tn is equal to the actual starting point plus the product of n minus 1 and the interval in minutes, and Tn is less than or equal to the actual ending point. If the last interval exceeds the actual ending point, that time point is discarded. After generating the baseline axis, the frequency interval verification subunit counts the total number of expected execution time points on the axis as the theoretical execution count, and then counts the actual execution count of the task yesterday in the pipeline table, comparing the two. If they match, the execution count verification passes; otherwise, it fails. Meanwhile, the frequency interval verification subunit retrieves all successful or failed records of the task from the log table yesterday, sorts them in ascending order of execution start time, calculates the time difference between adjacent records, and compares all time differences with the configured expected interval duration one by one. If all time differences are greater than or equal to the expected interval duration, the interval verification passes; otherwise, it fails.

[0079] In the zombie task verification process, the zombie task verification subunit queries all records in the transaction log table whose task status is "processing" based on the task identifier and yesterday's date. For each "processing" record, the zombie task verification subunit retrieves the value of its execution start time field and calculates the difference between the current system time and the execution start time. The zombie task verification subunit then obtains the daily dynamic adaptive timeout threshold for the task from the threshold calculation unit and compares the calculated time difference with this threshold. If the time difference is greater than the threshold, the zombie task verification subunit determines that the transaction log record is a zombie task. After determining it to be a zombie task, the zombie task verification subunit executes a SELECT...FORUPDATE statement again to lock the transaction log record, rereads the value of its task status field, and only executes an update statement to update the task status of the record to "failed" if the status is still "processing," updates the error information field to "task execution timeout zombie," and records the execution end time as the current system time.

[0080] The alarm triggering unit is configured to trigger the corresponding alarm in response to any failure of a sub-verification in the compliance check. The alarm triggering unit has pre-set alarm templates for different alarm types. When the execution existence check fails, the alarm triggering unit assembles a missed execution alarm message, including the task identifier, task name, and yesterday's date. When the frequency interval check fails, the alarm triggering unit assembles an overrun alarm message or a missed execution alarm message based on the difference between the actual and expected execution counts, or assembles an interval violation alarm message when the interval check fails, including the task identifier, yesterday's date, actual execution count, and expected execution count. When a zombie task is detected, the alarm triggering unit assembles a zombie task alarm message, including the task identifier, unique log identifier, execution start time, and timeout duration. The alarm triggering unit sends the alarm message to the pre-configured communication address of the operations and maintenance personnel by calling the SMS gateway interface or email service interface.

[0081] The API interface verification module is embedded in the API gateway filter chain deployed in the business system. As a component of the request processing pipeline, it is executed before the request is routed to the core business logic. This module includes a pipeline pre-emption unit, a threshold dynamic adjustment unit, a time window verification unit, a frequency interval verification unit, a business execution release unit, and a status update unit.

[0082] The pipeline pre-positioning unit is configured to parse the task identifier field and request initiation timestamp field in the Hypertext Transfer Protocol request body after a request from the scheduling platform arrives at the API interface. It extracts the date portion from the request initiation timestamp as the execution date. The pipeline pre-positioning unit constructs a new pipeline record object, setting its task identifier field to the parsed task identifier, its execution date field to the extracted date, its execution start time field to the request initiation timestamp, and its task status field to "processing". The pipeline pre-positioning unit then calls a database insert operation to attempt to insert the pipeline record into the batch task pipeline table. The database table involved in this insert operation has a unique index constraint, which is composed of three fields: task identifier, execution date, and task status, and the constraint scope is limited to records with a task status of "processing". If the insert operation is successfully executed, the pipeline pre-positioning unit determines that it has successfully acquired a concurrent lock and transfers control to the next verification unit. If the insert operation triggers a database unique key conflict exception, the pipeline pre-positioning unit catches the exception, determines it as a concurrent duplicate request, immediately constructs a rejection response message, and returns it to the scheduling platform through the API gateway, terminating the current request processing flow.

[0083] The threshold dynamic adjustment unit is configured to parse the channel type and business scenario level fields from the Hypertext Transfer Protocol (HTTP) request body after successful pre-registration. Internally, the threshold dynamic adjustment unit stores a risk level mapping table, indexed by a combination of channel type and business scenario level, with the risk level as the value. The unit queries this mapping table using the parsed channel type and business scenario level as keys to determine the risk level of the current request. After determining the risk level, the unit determines the time tolerance threshold correction coefficient and the minimum interval threshold correction coefficient based on the risk level. The correction coefficients are set as follows: 0.6 for high risk, 1.0 for medium risk, and 1.3 for low risk. The unit reads the original time tolerance threshold and original expected interval duration configured for the current task from the control table, multiplies the original time tolerance threshold by the time tolerance threshold correction coefficient to obtain the adjusted time tolerance threshold, and multiplies the original expected interval duration by the minimum interval threshold correction coefficient to obtain the adjusted expected interval duration.

[0084] The time window verification unit is configured to read the value of the expected execution time point field configured for the current task from the control table. If the current task is an interval-type task, the time window verification unit first calls the baseline execution time axis generation function, using the current date, task start time, task end time, and interval minutes as inputs to generate the baseline execution time axis for the current day. Then, it uses the most recent expected execution time point on the baseline axis corresponding to the current request time as the verification center point. If the current task is a non-interval-type task, the time window verification unit directly uses the expected execution time point configured in the control table as the verification center point. The time window verification unit obtains the adjusted time tolerance threshold from the threshold dynamic adjustment unit, uses the verification center point minus the adjusted time tolerance threshold as the left boundary of the window, and the verification center point plus the adjusted time tolerance threshold as the right boundary of the window. The time window verification unit obtains the current request initiation time and determines whether this time is greater than or equal to the left boundary of the window and less than or equal to the right boundary of the window. If yes, the time window verification passes; otherwise, the time window verification fails.

[0085] The frequency interval verification unit is configured to perform a query operation on the batch task pipeline table using the current task identifier and the current date as query conditions. It filters out all records with task statuses of success or failure, sorts them in descending order of execution start time, and takes the first record after sorting as the most recent completed pipeline record for the current day. If the query result is not empty, the frequency interval verification unit reads the value of the execution start time field from that record, calculates the difference between the current request initiation time and the execution start time, expressed in minutes. The frequency interval verification unit obtains the adjusted expected interval duration from the threshold dynamic adjustment unit, and constructs a tolerance interval centered on this adjusted expected interval duration, with a baseline deviation of 10% of this requirement. The left boundary of this tolerance interval equals the adjusted expected interval duration minus the baseline deviation, and the right boundary equals the adjusted expected interval duration plus the baseline deviation. The frequency interval verification unit determines whether the calculated time difference falls within this tolerance interval. If it does, the frequency interval verification passes. If it does not, the frequency interval verification fails. If the query result is empty, it means that there are no completed execution records on that day. The current request is the first request of the day. The frequency interval verification unit reads the expected execution time of the first request from the control table and determines whether the current request time falls within the tolerance range near the expected execution time of the first request. If so, the verification passes; otherwise, the verification fails.

[0086] The business execution release unit is configured to release the current Hypertext Transfer Protocol (HTTP) request in response to the flow pre-reservation unit, time window verification unit, and frequency interval verification unit all returning a successful verification result. This triggers the execution of the business processing flow by invoking the entry method of the core business logic. Alternatively, the business execution release unit can be configured to not trigger the execution of the core business logic in response to any one of the flow pre-reservation unit, time window verification unit, or frequency interval verification unit returning a failed verification result. Instead, it will invoke a database rollback operation to delete the flow records already inserted in the current transaction and return a verification failure HTTP response to the scheduling platform via the API gateway.

[0087] The status update unit is configured to be triggered after the core business logic has been executed. The status update unit receives the execution result object returned by the core business logic and extracts the success / failure flag and execution end time from this object. If the execution result is successful, the status update unit constructs an update statement, using the unique identifier of the transaction log as a condition, to update the task status field of the corresponding transaction log record to success and the execution end time field to the end time returned by the business logic. If the execution result is a failure, the status update unit constructs an update statement, updating the task status field to failure, the execution end time field to the current system time, and the error information field to the failure reason description returned by the business logic. If a timeout exception or abnormal process exit occurs during business execution, preventing the status update unit from being triggered, the transaction log record remains in a processing state, and is subsequently cleaned up by the dead check subunit of the end-of-day scan module during the scan at midnight the following day.

[0088] All database operations in the task control module, end-of-day scanning module, and API interface verification module are executed within the same database transaction context. In the API interface verification module, the insert operations of the flow pre-emption unit, the query operations of the time window verification unit, and the query operations of the frequency interval verification unit are executed within the same database transaction; if any verification fails, the entire transaction is rolled back. In the API interface verification module, the update operations of the status update unit are executed in an independent database transaction, separated from the preceding verification transaction, ensuring that business execution results can be persisted independently. In the end-of-day scanning module, the row lock operations of the task acquisition unit, the query operations of the compliance verification unit, and the status update operations are executed within the same database transaction; if an exception occurs midway, all operations are rolled back. All transactions are set to the read committed isolation level.

[0089] Example 3 This embodiment takes the end-of-day batch reconciliation task in an open banking system as an example to illustrate the specific implementation process of the technical solution of the present invention in a typical financial scenario.

[0090] A bank's open banking system deploys a corporate-level public scheduling platform and independent business systems. The business systems run daily batch reconciliation tasks. The reconciliation processing logic for these tasks is executed by the business systems, while the triggering instruction is initiated by the scheduling platform at a predetermined time of 11 PM daily. The task identifier is RCN_001, the task name is "Daily Batch Reconciliation," the frequency type is daily, the expected execution time is 11 PM daily, the maximum processing time is configured to 60 minutes, and the time tolerance threshold is configured to 5 minutes.

[0091] The operations and maintenance personnel pre-enter the configuration record of the task into the batch task control table of the business system, including the task identifier RCN_001, the task name end-of-day batch reconciliation, the frequency type as daily, the expected execution time as 23:00:00, the maximum processing time as 60, the time tolerance threshold as 5, and set the task activation status to true.

[0092] On a certain calendar day, due to a network outage, the scheduling platform failed to send the reconciliation task trigger request to the business system at 11 PM. The business system did not receive any requests for the RCN_001 task at the API interface level that day; therefore, there were no transaction records corresponding to this task identifier in the batch task log table for that day.

[0093] At 1:00 AM the following day, the end-of-day scan scheduler of the business system was triggered. The scan scheduler read all task records with a true activation status from the batch task control table and obtained the task RCN_001, which should have been executed yesterday. The scan scheduler first applied a row-level pessimistic lock to the RCN_001 task. Subsequently, the scan scheduler performed an existence check, querying the batch task log table using RCN_001 and yesterday's date as conditions. The query result was empty. Based on this, the scan scheduler determined that the existence check failed, meaning that the task was not triggered by the scheduling platform yesterday. The alarm triggering unit then assembled a missed execution alarm message, including the task identifier RCN_001, the task name "End-of-Day Batch Reconciliation," and yesterday's date, and sent it to the operations personnel's mobile phone via the SMS gateway. After receiving the alarm, the operations personnel manually intervened to confirm the cause of the scheduling platform anomaly and manually triggered the reconciliation task to run again.

[0094] In this scenario, if the existing scheduling-side self-verification scheme is used, since the scheduling platform process did not crash but experienced a network-level anomaly, the scheduling platform itself may not be aware that the request was not successfully delivered, and the business system will have no way of knowing that the task should have been executed but was not triggered. The end-of-day scanning and verification mechanism of this invention, by performing an existence check and using the local pipeline trajectory of the business system as the sole basis, independently discovers the missed execution event of the task not being triggered by the scheduling platform, realizing autonomous verification under cross-system trust gaps.

[0095] Example 4 This embodiment takes a high-frequency channel verification task in an open banking system as an example to illustrate the implementation process of frequency accuracy verification and concurrent anti-duplicate measures in interval-type task scenarios.

[0096] A bank's open banking system runs a channel payment result verification task. This task needs to be executed every 5 minutes to query the payment results of upstream channels and update the local payment order status. The task identifier is QRY_005, the task name is Channel Payment Result Verification, the frequency type is interval-based, the task start time is 8:00 AM daily, the task end time is 10:00 PM daily, the interval is 5 minutes, the time tolerance threshold is configured to 1 minute, and the expected interval duration is configured to 4 minutes. Theoretically, this task can be executed 169 times per day.

[0097] The operations and maintenance personnel enter the configuration record of the task into the batch task control table. The task start time is 08:00:00, the task end time is 22:00:00, the interval in minutes is 5, the time tolerance threshold is 1, and the expected interval duration is 4.

[0098] On a specific workday, the scheduling platform sends verification requests to the business system sequentially at 8:00, 8:05, and 8:10, according to the baseline execution timeline. When the request at 8:05 arrives at the business system's API interface, the API interface's embedded verification process is triggered.

[0099] The pipeline pre-emption unit first parses the task identifier QRY_005 and the request initiation time 8:05:00 in the request. It then attempts to insert a processing record into the batch task pipeline table, with the task identifier QRY_005, the execution date being the current day, and the execution start time being 8:05:00. Since there is no processing pipeline record for this task on that day, the insertion operation succeeds, and the pipeline pre-emption unit acquires the concurrency lock.

[0100] The threshold dynamic adjustment unit parses the request and finds that the channel type is online banking, the business scenario level is ordinary payment scenario, the risk level mapping table determines it to be medium risk, the correction coefficient is 1.0, the time tolerance threshold is kept at 1 minute, and the expected interval duration is kept at 4 minutes.

[0101] The time window verification unit constructs a valid time window with a radius of 1 minute, centered on the nearest expected execution time of the interval task on the daily baseline execution timeline, which is 8:05:00. The window range is from 8:04:00 to 8:06:00. The current request time of 8:05:00 falls within this window, and the time window verification passes.

[0102] The frequency interval verification unit queries the log table for the most recent record with a successful status on that day, obtains its execution start time as 8:00:00, and calculates the time difference between the current request time 8:05:00 and 8:00:00 as 5 minutes. This time difference falls within the tolerance range of 3.6 minutes to 4.4 minutes, centered at 4 minutes and with a radius of 0.4 minutes. Therefore, the frequency interval verification passes.

[0103] After all verifications pass, the business execution release unit routes the request to the verification business logic for execution. Once the business execution is complete, the status update unit updates the status of the transaction record to success.

[0104] If, at 8:05:03, the scheduling platform sends a duplicate request for the same task to the business system again due to the network retransmission mechanism, upon arrival at the API interface, the pipeline pre-registration unit attempts to insert a pipeline record with task identifier QRY_005, execution date (today), and status "in progress." Since the pipeline record corresponding to the first request at 8:05 has not yet been updated to "successful," and the database already contains a record with task identifier QRY_005, execution date (today), and status "in progress," the current insertion operation triggers a unique key conflict exception. After capturing this exception, the pipeline pre-registration unit determines it as a concurrent duplicate request and immediately returns a rejection response to the scheduling platform. The duplicate request is intercepted, and the core business logic is not triggered. After the business execution of the first request at 8:05 is completed, the status update unit updates the pipeline status to "successful," the "in progress lock" is released, and the next normal request at 8:10 can then normally insert a new "in progress" pipeline record.

[0105] In this scenario, if existing scheduling queue solutions are used, two duplicate requests with only a 300-millisecond interval might be placed into the queue sequentially, causing two threads to execute the same verification business logic simultaneously, resulting in duplicate verification and state overwriting. This invention utilizes the atomic insertion operation of a database's unique index to complete concurrent anti-duplicate interception the moment the request arrives, without relying on distributed lock middleware. Furthermore, the interception occurs before the business logic is executed, eliminating the possibility of duplicate execution.

[0106] Example 5 This embodiment takes the month-end batch interest settlement task in an open banking system as an example to illustrate the implementation process of the present invention in the single task scenario for time window verification and dynamic adaptive threshold identification of dead tasks.

[0107] A bank's open banking system runs a month-end batch interest settlement task. This task is executed once on the last day of each month to process monthly interest for all current accounts. The task identifier is INT_002, the task name is month-end batch interest settlement, the frequency type is monthly, the expected execution time is 2:00 AM on the last day of each month, the maximum processing time is configured to be 120 minutes, and the time tolerance threshold is configured to be 10 minutes.

[0108] Since the last day of each month is not a fixed date but depends on the actual number of calendar days in the month, the expected execution time of this task cannot be expressed as a fixed date. When the operations and maintenance personnel enter the task configuration into the batch task control table, they configure the monthly frequency date as the special identifier LAST_DAY. The business system resolves this identifier to the last day of the month when matching execution dates. The time tolerance threshold for this task in the control table is configured to 10 minutes, and the maximum processing time is configured to 120 minutes.

[0109] On the 30th of a certain month (the second-to-last day of the month), due to a configuration error, the scheduling platform sent a request to the business system at 2:00 AM to trigger an interest settlement task. After the request reached the business system's API interface, the transaction pre-registration unit successfully inserted it into the processing transaction record. The time window verification unit read from the control table that the expected execution time for this task was configured as the last day of the month. However, the current date was the 30th, which was not the last day of the month. Therefore, the time window verification unit determined that the current request date was not within the expected execution date, and the time window verification failed. The business execution release unit did not trigger the interest settlement business logic, directly returned a verification failure response to the scheduling platform, and triggered an alarm. After receiving the alarm, the operations and maintenance personnel checked the scheduling platform configuration, found an error in the date configuration, and corrected it in time to avoid performing the interest settlement operation on an unexpected date.

[0110] At 2:00 AM on the correct execution date, the 31st of the month, the scheduling platform sent the interest settlement task request again. All API interface embedding verifications passed, and the core business logic began executing the interest settlement process. Due to a 30% increase in the number of accounts that month compared to usual, the interest settlement process took 105 minutes, exceeding the historical average execution time of 70 minutes for this task, but still within the dynamic adaptive timeout threshold.

[0111] The end-of-day scan was triggered in the early morning of the following day. When calculating the dynamic adaptive timeout threshold for task INT_002, the threshold calculation unit extracted successful execution records of the task from the transaction log over the past 30 calendar days, calculating the historical average execution time as 70 minutes with a standard deviation of 10 minutes. The execution times of the samples were 62 minutes, 68 minutes, 75 minutes, 71 minutes, 65 minutes, 73 minutes, and 110 minutes. The sample with a execution time of 110 minutes deviated from the historical average by more than three times the standard deviation (more than 30 minutes) and was identified as an anomaly and removed. The longest execution time among the remaining samples after removal was 75 minutes. Multiplied by a redundancy coefficient of 1.5, the dynamic adaptive timeout threshold for the day was 112.5 minutes. Yesterday's interest settlement task actually executed for 105 minutes, less than the 112.5-minute threshold. Therefore, this task was not considered a dead task, its transaction log status remained successful, and no false alarms were triggered.

[0112] If the actual execution time of the task reaches 115 minutes, exceeding the daily dynamic adaptive threshold of 112.5 minutes, the zombie verification subunit will determine the task as a zombie task, update the pipeline status to failure, trigger a zombie alarm, and notify the operation and maintenance personnel to check whether there is any performance abnormality in the task.

[0113] In this scenario, if a fixed timeout threshold scheme from existing technologies is used, such as a fixed 60-minute threshold or a fixed 120-minute threshold, a 60-minute threshold will generate a false alarm when the normal execution duration is 70 minutes, while a 120-minute threshold will fail to generate a timely alarm when the abnormal execution duration is 115 minutes. The dynamic adaptive threshold of this invention is adaptively adjusted based on the statistical distribution of historical normal execution durations, balancing the detection rate and the false alarm rate.

[0114] Example 6 This embodiment takes the batch payroll disbursement task with multiple risk levels in an open banking system as an example to illustrate the implementation process of the present invention in terms of dynamic adjustment of thresholds driven by business risk levels.

[0115] A bank's open banking system runs a batch payroll disbursement task. This task supports trigger requests from different channels and business scenarios. The task identifier is PAY_008, the task name is Batch Payroll Disbursement, the frequency type is daily, the expected execution time is 3 PM daily, the time tolerance threshold is configured to 5 minutes, and the expected interval is configured to 30 minutes.

[0116] This task accepts both large-amount disbursement requests from corporate clients via online banking and small-amount disbursement requests from individual clients via mobile banking. The bank's risk management strategy for this task is as follows: large-amount disbursement scenarios are considered high-risk scenarios, requiring higher verification accuracy and a narrower tolerance threshold; small-amount disbursement scenarios are considered low-risk scenarios, with higher priority given to business availability, and a more relaxed tolerance threshold.

[0117] When a large-amount payout request from an online banking channel arrives at the business system API at 3:06 PM, the threshold dynamic adjustment unit parses the request and identifies the channel type as online banking and the business scenario level as large-amount payout. A query of the risk level mapping table determines it to be high-risk, and the correction coefficient is set to 0.6. The time tolerance threshold is adjusted from the original 5 minutes to 3 minutes (3 minutes equals 5 minutes multiplied by 0.6). The time window verification unit constructs a valid time window centered at 3 PM with a radius of 3 minutes, ranging from 2:57 PM to 3:03 PM. The current request time of 3:06 PM exceeds this window range, the time window verification fails, the request is rejected, and an alarm is triggered. This narrowed threshold successfully intercepts high-risk requests with deviations exceeding 3 minutes, meeting the bank's strict risk control requirements for large-amount payout business.

[0118] When a small-amount payout request from a mobile banking channel arrives at the business system API at 3:07 PM, the threshold dynamic adjustment unit parses the request and identifies the channel type as mobile banking and the business scenario level as small-amount payout. A risk level mapping table is consulted to determine it as low-risk, and the correction coefficient is set to 1.3. The time tolerance threshold is adjusted from the original 5 minutes to 6.5 minutes (5 minutes multiplied by 1.3). The time window verification unit constructs a valid time window centered at 3:00 PM with a radius of 6.5 minutes, ranging from 14:53:30 to 15:06:30. The current request time of 15:07 exceeds this window range by approximately 0.5 minutes, and the time window verification fails; the request is rejected. Although the threshold for low-risk scenarios has been appropriately relaxed to reduce false interception rates, the 15:07 request still exceeds the relaxed window boundary and is therefore still deemed non-compliant. This indicates that the arrival time deviation of the request is indeed too large, and even for low-risk scenarios, it should not be allowed.

[0119] When a small-amount payout request arrives via mobile banking at 3:04 PM, the dynamic threshold adjustment unit applies a low-risk level correction coefficient of 1.3, adjusting the time tolerance threshold to 6.5 minutes, with a window range of 14:53:30 to 15:06:30. The current request time of 15:04 falls within this window, the time window verification passes, and the request is allowed to proceed. This relaxed threshold avoids mistakenly blocking a potentially executable request at 15:04, improving business availability in low-risk scenarios while ensuring basic risk control requirements.

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

[0121] The parameter values ​​involved in this invention, including but not limited to the preset historical number of 30 natural days, the preset standard deviation multiple of 3 times, the preset redundancy coefficient of 1.5, the high-risk correction coefficient of 0.5 to 0.8, the low-risk correction coefficient of 1.2 to 1.5, and the specific division method of the risk level mapping rule, are all preferred embodiments of this invention. Those skilled in the art can make adaptive adjustments to these parameters according to the needs of actual application scenarios. These adjustments do not depart from the core concept of this invention and still fall within the protection scope claimed by the claims of this invention.

Claims

1. A trusted verification method for batch tasks in open banking, characterized in that, This includes independently deployed end-of-day scan checks and API interface embedded verification; the end-of-day scan checks are executed periodically by the system internally for offline auditing. API interface embedded validation is triggered when a request arrives from the scheduling platform; The entire trusted verification process is performed locally within the business system. End-of-day scan checks include: constructing a batch task control table; scanning the scheduler to read the control table and obtain the list of tasks to be executed yesterday; performing compliance checks on each task from yesterday, including: execution existence check, querying the batch task log table to check if there are any execution log records from yesterday; frequency and interval check, comparing the actual number of executions with the expected number of executions for non-interval tasks, and constructing a baseline execution timeline based on the configured start time, end time, and interval minutes for interval tasks and comparing the actual number of executions with the theoretical number of executions, while also checking whether the actual execution interval meets the expected interval duration; dead task check, using a dynamic adaptive timeout threshold to determine the status of records in the log table as being processed, the dynamic adaptive timeout threshold is determined based on the statistical analysis of the normal execution duration of the past preset number of days, and after removing abnormal samples, the maximum historical execution duration multiplied by the redundancy coefficient is used as the judgment threshold for the day; and triggering alarms in response to any failures in the compliance checks. API interface embedded validation includes: pre-emptive flow and concurrency detection, inserting records in the flow table with a status of "processing" and implementing concurrency locks using a combination key of task identifier and execution date as a unique index; business parameter parsing and dynamic threshold adjustment, parsing the business parameters carried in the request and determining the correction coefficient; time window validation, constructing a valid time window centered on the expected execution time in the control table and with the adjusted time tolerance threshold as the radius; frequency interval validation, querying the most recent record in the flow table with a status of success or failure on the current day and verifying whether the time difference falls within the adjusted minimum interval tolerance range; if all validations pass, the request is allowed and the core business logic is executed; otherwise, it is rolled back; after the business is completed, the task status in the flow table is updated, and if execution times out or abnormal exit occurs, a day-end scan check is used for cleanup; among them, the minimum interval tolerance range is constructed centered on the adjusted expected interval duration and with a preset percentage of the adjusted expected interval duration as the deviation.

2. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, Frequency types include daily, weekly, monthly, yearly, and interval types. For weekly tasks, the expected execution time is a specific date within the week. For monthly tasks, the expected execution time is a specific date within the month. For yearly tasks, the expected execution time is a specific month and day within the year. For interval tasks, the expected execution time is a combination of the task start time, task end time, and interval in minutes.

3. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, The transaction log table uses a unique index constructed from a combination of three fields: task identifier, execution date, and task status. The scope of this unique index is limited to records where the task status is "processing". Insert operations in transaction log pre-registration and concurrency detection utilize this unique index to implement concurrency locks.

4. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, The rules for determining the value of the correction coefficient are as follows: a correction coefficient less than 1 is used for high-risk scenarios to narrow the threshold, a correction coefficient greater than 1 is used for low-risk scenarios to widen the threshold, and a correction coefficient equal to 1 is used for medium-risk scenarios.

5. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, In time window validation, for interval tasks, the nearest expected execution time on the baseline execution time axis of the current request time is first determined based on the baseline execution time axis of the current day. Then, a valid time window is constructed with the nearest expected execution time point as the center for judgment.

6. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, During the zombie task verification, after a task is identified as a zombie task, the current record status is checked again through row lock to see if it is still in processing. Only if the status is still in processing is the task status of the record updated to failure and filled with error information, and a zombie alarm is triggered at the same time.

7. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, During the end-of-day scan check, before traversing each task in the task list, the scan scheduler applies a row-level exclusive lock to the row record of the current task in the control table to ensure that only one scan instance processes the task at a time.

8. The trusted verification method for batch tasks in open banking according to claim 1, characterized in that, In the API interface embedded validation, the insertion operation in the flow pre-occupancy and concurrency detection, the query operation in the time window validation, and the query operation in the frequency interval validation are all executed in the same database transaction. If any validation fails, the entire transaction is rolled back. After the business process is completed, the status update operation of the transaction table is performed in an independent database transaction, separate from the pre-validation transaction.

9. A trusted verification system for batch tasks in open banking, characterized in that, The system is deployed on the business system side, and all verification logic is executed locally on the business system, including: The task control module is configured to store a batch task control table and a batch task flow table. The control table is used to store task identifier, frequency type, expected execution time, and maximum processing time. The end-of-day scanning module is configured to perform offline audit verification, including: The task acquisition unit is configured to read the control table and retrieve the list of tasks that should be executed yesterday. The threshold calculation unit is configured to determine a dynamic adaptive timeout threshold based on the normal execution time of the task over a preset number of historical days before the end-of-day scan. During the statistics, abnormal samples such as execution failures, manual terminations, and execution times deviating from the historical average by more than a preset multiple of the standard deviation are automatically removed. The maximum historical execution time is multiplied by a preset redundancy coefficient as the judgment threshold for the day. If there is no historical data, the maximum processing time configured in the control table is used as the initial threshold. The compliance verification unit is configured to perform existence verification, frequency and interval verification, and dead task verification for each task executed yesterday. Specifically, the existence verification checks the batch task log table to see if any execution log records exist from yesterday. The frequency and interval verification compares the actual number of executions with the expected number of executions for non-interval tasks, and for interval tasks, it constructs a baseline execution timeline using the configured start time, end time, and interval minutes, comparing the actual number of executions with the theoretical number of executions, while also verifying whether the actual execution interval matches the expected interval duration. The dead task verification uses a dynamic adaptive timeout threshold to determine the status of records in the log table as being in progress. The dynamic adaptive timeout threshold is determined based on the statistical analysis of normal execution times over a preset historical number of days. After removing abnormal samples, the maximum historical execution time multiplied by a redundancy coefficient is used as the daily judgment threshold. The alarm triggering unit is configured to trigger an alarm in response to any failure in the compliance verification. The API interface verification module is configured to perform real-time risk control verification when a request from the scheduling platform arrives at the business system's API interface, including: The pipeline pre-positioning unit is configured to insert a record with a status of "processing" into the batch task pipeline table, using the combination key of task identifier and execution date as a unique index, and utilizing the atomicity of database insertion operations to implement concurrent locks; if the insertion is successful, it is considered to have acquired the lock, and subsequent verification is allowed; if a unique key conflict is triggered, it is determined to be a concurrent duplicate request and the current request is rejected. The threshold dynamic adjustment unit is configured to parse the business parameters carried by the current scheduling request. The business parameters include the channel type and business scenario level. It determines the risk level of the current request according to the preset risk level mapping rules and applies the corresponding correction coefficients to the time tolerance threshold and minimum interval threshold of the current verification. The time window verification unit is configured to construct a valid time window with the expected execution time point configured in the control table as the center and the time tolerance threshold adjusted by the threshold dynamic adjustment unit as the radius, and to verify whether the current request time falls within the window. The frequency interval verification unit is configured to query the most recent record in the transaction log table that has a status of success or failure, obtain its execution start time, calculate the time difference between the current request time and that time, and verify whether the time difference falls within the minimum interval tolerance range adjusted by the threshold dynamic adjustment unit. If the query is empty, the verification is based on the first expected execution time configured in the control table. The minimum interval tolerance range is constructed with the adjusted expected interval duration as the center and a preset percentage of the adjusted expected interval duration as the deviation. The business execution release unit is configured to release the request and trigger the execution of the core business logic in response to the passing of all checks by the flow pre-occupancy unit, time window verification unit, and frequency interval verification unit; if any check fails, it will roll back to the state before the check and will not trigger the execution of the core business logic. The status update unit is configured to update the task status in the flow table to success or failure after the business execution is completed, and record the end time and error information; if the business execution times out or exits abnormally, the dead task verification in the compliance verification unit of the end-of-day scanning module will be used for fallback cleanup.

Images