Data transfer amount checking method and device, storage medium and terminal

Abstract

The embodiment of the specification discloses a data transfer quota checking method and device, a storage medium and a terminal. In response to a transfer quota checking request for a target data transfer task, a plurality of resource transfer data corresponding to the target data transfer task are collected. A target transfer quota checking strategy is determined according to the total number of all resource transfer data. The target transfer quota checking strategy is used to calculate each resource transfer data, and a transfer quota difference value between inflow data and outflow data in each resource transfer data is obtained. The transfer quota difference value is used to determine a transfer quota checking result of the target data transfer task. The related resource transfer data is collected with the data transfer task as an anchor point, the quota checking is avoided from the perspective of the main body, and the abnormal positioning accuracy is improved. The dynamic selection of the calculation mode based on the transfer quota checking strategy can adapt to data transfer tasks of different sizes and avoid the performance bottleneck caused by the fixed strategy.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and terminal for verifying data transfer quotas. Background Technology

[0002] In numerous technological fields, from information technology to resource management, there are widespread scenarios involving the transfer of resource data between different entities or systems. Ensuring the accuracy of transfer amounts is crucial in these complex resource flows to avoid resource waste, system overload, or security risks. Existing methods for verifying resource data transfer amounts often focus on the perspective of the transferring entity and rely on end-of-day or periodic batch processing. While these methods can detect deviations at the macro level, they still suffer from technical problems such as coarse verification granularity and high troubleshooting costs. Summary of the Invention

[0003] This specification provides a method, apparatus, storage medium, and terminal for verifying data transfer quotas, which can solve the technical problems of coarse verification granularity and high troubleshooting costs in related technologies.

[0004] Firstly, embodiments of this specification provide a method for verifying data transfer limits, the method comprising: In response to the transfer quota verification request for the target data transfer task, collect multiple resource transfer data corresponding to the target data transfer task. The corresponding target transfer amount verification strategy is determined based on the total amount of all resource transfer data. Based on the above target transfer amount verification strategy, the transfer amount difference between the inflow data and the outflow data in each resource transfer data is calculated. The transfer amount verification result of the above target data transfer task is determined based on the above transfer amount difference.

[0005] In one possible implementation, the above-mentioned collection of multiple resource transfer data corresponding to the target data transfer task includes: determining the database corresponding to each resource transfer data in the target data transfer task, each database being used to record information of the corresponding resource transfer data during the data transfer process; and collecting resource transfer data for the target data transfer task in each database through a preset streaming computing engine.

[0006] In one possible implementation, the above-mentioned collection of resource transfer data for the target data transfer task through a preset streaming computing engine includes: collecting resource transfer data organized in chronological order through the latency processing mechanism corresponding to the streaming computing engine.

[0007] In one possible implementation, the above-mentioned determination of the corresponding target transfer quota verification strategy based on the total amount of all resource transfer data includes: when the total amount of all resource transfer data is less than a preset threshold, determining the target transfer quota verification strategy as a non-summary verification strategy; when the total amount of all resource transfer data is greater than or equal to the preset threshold, determining the target transfer quota verification strategy as a summary verification strategy.

[0008] In one possible implementation, when the target transfer quota verification strategy is the non-summary verification strategy, the calculation of each resource transfer data based on the target transfer quota verification strategy includes: loading each resource transfer data into the memory object of the current working thread, and accumulating the inflow quota or outflow quota corresponding to each resource transfer data through a single traversal; or, distributing each resource transfer data to multiple parallel working threads, accumulating the inflow quota or outflow quota corresponding to each resource transfer data in each parallel working thread, and aggregating the processing results of each parallel working thread.

[0009] In one possible implementation, when the target transfer quota verification strategy is the above-mentioned summary verification strategy, the calculation of each resource transfer data based on the target transfer quota verification strategy includes: dividing each resource transfer data into a preset number of ordered sub-batches, calculating each resource transfer data in each sub-batchlet sequentially based on the sequence number of each sub-batchlet and a preset time isolation time, and during the calculation process, accumulating the inflow quota or outflow quota corresponding to each resource transfer data in each sub-batchlet to obtain the transfer quota difference corresponding to each sub-batchlet; and after the calculation of all sub-batches is completed, accumulating the transfer quota difference corresponding to each sub-batchlet.

[0010] In one possible implementation, the above-mentioned division of each resource transfer data into a preset number of ordered sub-batches includes: calculating the sequence hash value corresponding to the sequence identifier of each resource transfer data, and dividing each resource transfer data into multiple ordered sub-batches based on each sequence hash value.

[0011] In one possible implementation, determining the transfer limit verification result of the target data transfer task based on the transfer limit difference includes: if the transfer limit difference meets a preset difference condition, determining that the transfer limit verification of the target data transfer task is successful; if the transfer limit difference does not meet the preset difference condition, inputting the feature information of each resource transfer data and the corresponding associated data into a preset rule engine, determining the anomaly type of the current verification result through the rule engine, and processing the corresponding resource transfer data based on the anomaly type, wherein the associated data is other resource transfer data that conforms to a preset association relationship with each resource transfer data.

[0012] In one possible implementation, the above-mentioned method of determining the anomaly type of the current verification result through the rule engine and processing the corresponding resource transfer data based on the anomaly type includes: determining whether there is target associated data in the associated data that meets the preset matching conditions with the feature information of the target resource transfer data; if not, determining that the anomaly type is a special anomaly and stopping the verification of the transfer amount of the target data transfer task; if it exists, determining that the anomaly type is a repairable anomaly, establishing a first mapping relationship between the target associated data and the target data transfer task, and verifying the transfer amount of the target data transfer task based on the first mapping relationship.

[0013] In one possible implementation, the method further includes: collecting transaction detail data associated with each resource transfer data, wherein each transaction detail data is used to characterize the transaction occurrence information corresponding to each resource transfer data; and establishing a second mapping relationship between each resource transfer data and the corresponding transaction detail data, so as to index each resource transfer data based on the second mapping relationship.

[0014] Secondly, embodiments of this specification provide a data transfer quota verification device, the device comprising: The data acquisition module is used to collect multiple resource transfer data corresponding to the target data transfer task in response to the transfer quota verification request for the target data transfer task. The classification calculation module is used to determine the corresponding target transfer amount verification strategy based on the total amount of all resource transfer data. Based on the above target transfer amount verification strategy, the module calculates the transfer amount difference between the inflow data and the outflow data in each resource transfer data. The quota verification module is used to determine the transfer quota verification result of the target data transfer task based on the above transfer quota difference.

[0015] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0016] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0017] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the method described above.

[0018] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides a method for verifying data transfer quotas. In response to a transfer quota verification request for a target data transfer task, multiple resource transfer data corresponding to the target data transfer task are collected. A corresponding target transfer quota verification strategy is determined based on the total number of all resource transfer data. The transfer quota difference between inflow and outflow data in each resource transfer data is calculated based on the target transfer quota verification strategy. The transfer quota verification result of the target data transfer task is determined based on the transfer quota difference. First, by identifying specific target data transfer tasks, the system proactively collects multiple resource transfer data strongly correlated with them, constructing a logically self-consistent micro-data loop. This allows the system to reconstruct the full picture of a single business event, ensuring data integrity and contextual relevance regardless of whether the task involves simple point-to-point transmission or complex multi-source aggregation or multi-path distribution. Furthermore, this step is triggered by a "verification request," meaning that verification no longer relies on fixed long-cycle time slices but can be embedded in any key node of the task lifecycle (e.g., triggered immediately upon task completion). This event-driven collection mechanism improves the timeliness of data acquisition, enabling the system to immediately perceive the data status after resource transfer occurs, compressing the risk exposure period from anomaly occurrence to detection, and providing a time basis for subsequent real-time intervention. Next, a dynamic adaptive calculation mechanism based on data characteristics is introduced. Depending on the total data volume, the system can automatically select or adjust the most suitable verification strategy, ensuring efficient and accurate completion of verification tasks across various data scales. By calculating the transfer amount difference between inflow and outflow data, the system can intuitively reflect the balance state during the data transfer process, providing a strong basis for subsequent verification result judgment. Finally, the final output of the verification process is directly related to the validity and compliance of the data transfer task. By determining the verification result based on the difference in the transfer amount, the system can clearly determine whether the data transfer task meets the expected amount requirements, thereby promptly preventing non-compliant data transfer behavior and protecting the integrity and security of data resources. At the same time, this step also provides an important reference for the subsequent processing of the data transfer task, such as adjusting the transfer amount, supplementing missing data, or correcting errors. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 An exemplary system architecture diagram for a data transfer quota verification method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a data transfer quota verification method provided in an embodiment of this specification; Figure 3 A flowchart illustrating a data transfer quota verification method provided in an embodiment of this specification; Figure 4 A flowchart illustrating a data transfer quota verification method provided in an embodiment of this specification; Figure 5 A structural block diagram of a data transfer quota verification device provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0021] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0022] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments in this specification as detailed in the appended claims. Furthermore, in the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments in this specification, "multiple" refers to two or more.

[0023] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0024] In numerous technological fields, there are widespread scenarios where resource data needs to be transferred between different entities or systems. For example, in smart grids, power load data needs to flow in real time between power generation and consumption to maintain supply and demand balance; in the inventory management of large e-commerce platforms, product inventory data needs to be frequently transferred between central warehouses and regional distribution centers; in the financial sector, funds, as a core resource, frequently need to flow between different accounts or financial platforms to support various financial activities such as daily transactions and investment. In these complex resource transfer processes, ensuring the accuracy of the transfer amount is crucial. That is, throughout the entire lifecycle of a resource flowing from its source to its destination, it is essential to rigorously verify whether the inflow and outflow volumes maintain logical conservation and balance. This is to prevent resources from "disappearing out of thin air" or "creating out of nothing" due to data transmission packet loss, system concurrency conflicts, state synchronization delays, or logical processing anomalies, which could lead to inconsistent system states, service interruptions, or even serious business incidents.

[0025] Existing methods for verifying resource data transfer quotas typically employ a periodic aggregation and verification model based on the subject dimension. Specifically, existing solutions often use a macro-level management subject as the verification unit, and at a fixed time window (such as the "day-end" after the end of daily transactions), all resource transfer records occurring under that subject are fully aggregated. The difference between the total inflow value and the total outflow value within that time window is used to determine whether the overall data transfer is balanced.

[0026] While this method can detect deviations at the macro level, its inherent technical flaws are becoming increasingly apparent. First, its verification granularity is too coarse, burying massive amounts of micro-level transfer tasks within the aggregated data of the macro-level entity. Once an anomaly is detected, the lack of independent indexes for specific transfer tasks makes it difficult for technicians to quickly locate the specific data transfer event or fault chain that caused the anomaly in hundreds of millions of historical data points, resulting in extremely high troubleshooting costs and long processing times. Second, its verification mechanism has significant lag, relying on long-term fixed-time slices, which cannot achieve real-time monitoring of the resource transfer process. This leads to excessively long time from the occurrence of an anomaly to its detection, during which erroneous resource scheduling decisions may continue to be made, causing irreversible losses. Finally, facing increasingly complex non-linear resource aggregation scenarios such as many-to-one and one-to-many relationships, traditional entity-level verification often lacks fine-grained business context information, making it unable to reconstruct the true resource flow logic and easily leading to misjudgments or omissions.

[0027] Therefore, this specification provides a method for verifying data transfer quotas to solve the technical problems of existing resource data transfer quota verification methods, such as coarse verification granularity and high troubleshooting costs.

[0028] Please see Figure 1 , Figure 1This is an exemplary system architecture diagram of a data transfer quota verification method provided in the embodiments of this specification.

[0029] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0030] Terminal 101 can interact with server 103 via network 102 to receive or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. For example, terminal 101 can act as a client device for a user to initiate a data transfer task and verification request, while server 103 acts as a backend processing center with data transfer quota verification logic deployed. When a user triggers verification for a specific data transfer task through terminal 101, terminal 101 generates a transfer quota verification request containing the unique identifier of the task and sends it to server 103 via network 102. After receiving the request, server 103 performs a series of operations, including data collection, policy determination, and difference calculation, ultimately generating a transfer quota verification result. This result is then fed back to terminal 101 via network 102 for visualization, allowing the user to promptly understand the quota verification status of the data transfer task.

[0031] Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the electronic devices listed above, and it can be implemented as multiple software programs or software modules (e.g., to provide distributed services), or it can be implemented as a single software program or software module, without specific limitations.

[0032] In the embodiments of this specification, terminal 101 first responds to the transfer quota verification request for the target data transfer task by collecting multiple resource transfer data corresponding to the target data transfer task; then, it determines the corresponding target transfer quota verification strategy based on the total number of all resource transfer data, calculates the transfer quota difference between the inflow and outflow data in each resource transfer data based on the target transfer quota verification strategy; and finally, it determines the transfer quota verification result of the target data transfer task based on the transfer quota difference.

[0033] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0034] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0035] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0036] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data transfer limit verification method provided in an embodiment of this specification. The execution entity in this embodiment can be a terminal performing data transfer limit verification, a processor within the terminal performing the data transfer limit verification method, or a data transfer limit verification service within the terminal performing the data transfer limit verification method. For ease of description, the following example uses a processor within the terminal as the execution entity to illustrate the specific execution process of the data transfer limit verification method.

[0037] like Figure 2 As shown, the verification methods for data transfer limits can include at least: S202. In response to the transfer quota verification request for the target data transfer task, collect multiple resource transfer data corresponding to the target data transfer task.

[0038] Optionally, embodiments of this specification provide a method for verifying data transfer quotas, aiming to solve the problem of data inconsistency caused by link anomalies, concurrent conflicts, or state synchronization delays during the transfer of resource data from the source to the destination in complex network environments. The core logic of this method lies in breaking away from the traditional coarse-grained verification mode based on macro-level subjects or fixed time windows, and instead establishing a micro-closed-loop mechanism with the data transfer task as the smallest verification unit.

[0039] Specifically, when the system receives a transfer limit verification request for a specific target data transfer task, this request is typically triggered automatically by the upstream business system after the task is completed, or manually initiated by operations and maintenance personnel via terminal devices. In response to this verification request, the system first performs a data collection step, which involves accurately retrieving and collecting all resource transfer data directly related to the target data transfer task based on its unique identifier. This data represents all data changes involved in the task execution process, including not only the specific values ​​of the data transfers but also implicit directional information about the data transfers, i.e., inflows and outflows, thus providing the necessary conditions for subsequent calculation of the transfer limit difference.

[0040] It should be noted that the data transfer limit verification method proposed in the embodiments of this specification can be widely applied in various scenarios such as distributed data processing systems, cloud computing resource scheduling platforms, large-scale logistics information management systems, and financial accounting systems, to effectively address various data inconsistency risks that may be encountered during resource data transfer in complex network environments. To facilitate in-depth explanation and specific examples, and to enable those skilled in the art to more intuitively and concretely understand the implementation details and logical flow of this solution, subsequent examples will use financial accounting as a typical application scenario for illustration.

[0041] For example, in a specific application scenario of financial fund accounting, when the core accounting system or risk control monitoring platform receives a fund reconciliation request for a specific business document, the system immediately responds and initiates a data collection program. Based on the globally unique serial number of the business document, it accurately extracts all accounting transaction records associated with the document from the distributed financial database or transaction log. These collected accounting transaction records detail every fund change during the transaction process, including details of fund outflows on the debit side and fund inflows on the credit side, thereby constructing a complete and continuous view of fund changes under the business document. This ensures that the underlying data relied upon for subsequent debit and credit balance verification has sufficient integrity and contextual consistency.

[0042] S204. Determine the corresponding target transfer amount verification strategy based on the total amount of all resource transfer data, and calculate the transfer amount difference between the inflow data and the outflow data in each resource transfer data based on the target transfer amount verification strategy.

[0043] Optionally, after determining the multiple resource transfer data corresponding to the target data transfer task, the embodiments of this specification enter the core strategy adaptive matching and difference calculation stage. The key to this stage is that the system no longer uses a single fixed verification logic, but first performs statistics on all collected resource transfer data to obtain its total quantity, and dynamically decides on the target transfer amount verification strategy that is suitable for the current task based on the data scale characteristics represented by the total quantity.

[0044] Specifically, the system has a pre-set judgment logic based on a quantity threshold. When the total amount of resource transfer data is small and does not reach the preset threshold, it indicates that the data structure of the target data transfer task is relatively simple and the processing load is low. The system will automatically select a more direct target transfer amount verification strategy, such as checking the transfer amount of each piece of data one by one. Conversely, when the total amount of resource transfer data is large and exceeds the preset threshold, it indicates that the task involves the complex flow of massive amounts of data. At this time, the system will automatically switch the transfer amount verification strategy and reasonably group or batch process the data, thereby improving the processing speed while ensuring the verification accuracy and adapting to the verification needs of large-scale data.

[0045] For example, in a specific application scenario of financial fund accounting, the system first counts the total number of accounting transaction details associated with the business document to be verified. If the number of details is small (e.g., only a few simple loan records), it indicates that the fund flow of the business is clear and the computational load is low, and the system will directly adopt the verification method of calculating each transaction. Conversely, if the number of accounting transaction details attached to the business document is extremely large (e.g., involving hundreds or thousands of split accounts, settlements, or high-frequency transaction records), it indicates that the data volume of the business is huge. At this time, the system will intelligently switch to group or batch processing mode to reasonably divide the accounting transaction records, thereby greatly improving processing efficiency while maintaining verification accuracy.

[0046] S206. Determine the transfer amount verification result of the target data transfer task based on the transfer amount difference.

[0047] Optionally, after obtaining the transfer amount difference between the inflow and outflow data in each resource transfer data, the embodiments of this specification enter the final verification result determination stage, and compare and analyze the calculated transfer amount difference with the preset difference conditions, thereby quantitatively evaluating the consistency of the target data transfer task.

[0048] Specifically, the system has pre-set balancing standards for different types of data transfer tasks. If the calculated difference in transfer amount is equal to zero, or if the absolute value of the difference falls within the preset error tolerance range, it is determined that the resource transfer data in the target data transfer task has achieved numerical self-balancing, indicating that all inflow and outflow resource amounts are statistically perfectly matched, and no data loss, duplication, or anomaly has occurred. In this way, a transfer amount verification result indicating that the verification has passed is generated. Conversely, if the difference in transfer amount exceeds the preset tolerance threshold, whether it is a positive or negative deviation, it means that there is a significant numerical imbalance in the resource flow under this task. The system then determines that the verification has failed, generates a transfer amount verification result indicating that the verification has failed, and marks the task as an abnormal state in order to trigger the subsequent error investigation mechanism.

[0049] Furthermore, to enhance the guiding significance of the verification results, the embodiments in this specification can also perform tiered judgments based on the specific numerical characteristics of the transfer amount difference when determining the verification result. For example, when the transfer amount difference is small but exceeds the tolerance range, the system can generate a suggestive verification result, recommending a second review or manual intervention; while when the transfer amount difference is huge, the system directly generates a blocking verification result, immediately freezing the subsequent process of the target data transfer task to prevent the further spread of erroneous data.

[0050] In the embodiments of this specification, a method for verifying data transfer quota is provided. First, by locking onto a specific target data transfer task, multiple resource transfer data strongly associated with it are actively collected, constructing a logically self-consistent micro-data closed loop. This enables the system to reconstruct the full picture of a single business event, ensuring data integrity and contextual relevance regardless of whether the task involves simple point-to-point transmission or complex multi-source aggregation or multi-path distribution. Furthermore, this step is triggered by a "verification request," meaning that the verification behavior no longer depends on fixed long-cycle time slices, but can be embedded into any key node in the task lifecycle (such as triggering immediately after the task is completed). This event-driven collection mechanism improves the timeliness of data acquisition, enabling the system to immediately perceive the data status after a resource transfer occurs, compressing the risk exposure period from the occurrence of an anomaly to its discovery, and providing a time basis for subsequent real-time intervention. Then, a dynamic adaptive calculation mechanism based on data characteristics is introduced. Depending on the total amount of data, the system can automatically select or adjust the most suitable verification strategy, ensuring efficient and accurate completion of verification tasks across various data scales. By calculating the transfer amount difference between inflow and outflow data, the system can intuitively reflect the balance during the data transfer process, providing a strong basis for subsequent verification result judgment. Finally, the final output of the verification process is directly related to the validity and compliance of the data transfer task. By determining the verification result based on the transfer amount difference, the system can clearly determine whether the data transfer task meets the expected amount requirements, thereby promptly preventing non-compliant data transfer behavior and protecting the integrity and security of data resources. Simultaneously, this step also provides important reference for subsequent processing of the data transfer task, such as adjusting the transfer amount, supplementing missing data, or correcting errors.

[0051] Please see Figure 3 , Figure 3 This is a flowchart illustrating a data transfer quota verification method provided in an embodiment of this specification.

[0052] like Figure 3 As shown, the verification methods for data transfer limits can include at least: S302. In response to the transfer quota verification request for the target data transfer task, determine the database corresponding to each resource transfer data in the target data transfer task. Each database is used to record information of the corresponding resource transfer data during the data transfer process.

[0053] Optionally, when collecting multiple resource transfer data corresponding to the target data transfer task, the embodiments of this specification first perform database positioning and mapping operations. That is, the system automatically parses and determines the source database storing each resource transfer data under the task based on the unique identifier of the target data transfer task. These databases are distributed across different business nodes to support high-concurrency writing. They record detailed information of the corresponding resource transfer data during the data transfer process, including but not limited to key data such as transfer time, transfer direction, and transfer amount.

[0054] For example, in a specific application scenario of financial fund accounting, the above database positioning process is manifested as follows: when the system receives a fund verification request for a specific business document, it first automatically parses and locks the upstream accounting database storing all the accounting transactions under that business document based on the unique number of that business document; these upstream accounting databases are usually distributed across different core transaction nodes to support high-concurrency accounting, and they fully record the detailed information of each accounting transaction under that business document in the process of fund transfer, including but not limited to key elements such as the transaction time, the direction of fund lending (inflow or outflow), and the specific transaction amount, thereby laying a solid source foundation for the subsequent accurate collection of accounting transaction data.

[0055] S304. In each database, resource transfer data for the target data transfer task is collected through a preset streaming computing engine.

[0056] Optionally, after determining the databases corresponding to the resource transfer data in the target data transfer task, the embodiments of this specification further execute efficient and real-time data acquisition jobs in each database through a preset streaming computing engine. In specific implementation, the system deploys a streaming computing cluster based on the Flink architecture. This cluster serves as the core acquisition component, directly connecting to the database log interface corresponding to each resource transfer data to establish a continuous data acquisition channel.

[0057] Furthermore, to address the potential time lag issues that may arise during database master-slave synchronization in a distributed environment, and to prevent verification deviations caused by reading incompletely committed transaction data, this embodiment of the specification also introduces a delayed processing mechanism from the Flink architecture into the data acquisition process. This mechanism, by configuring a reasonable time window, allows the streaming computing engine to delay processing database change events after they are captured for a preset period, ensuring that the transaction state of the upstream database has completely stabilized before formally incorporating the corresponding resource transfer data into the computation process. This ensures the consistency of the acquired data in terms of timing.

[0058] Optionally, to address the risk of duplicate collection of the same resource transfer data due to network jitter or system retries, this specification implements an idempotent control strategy based on sequence number standardization. First, the streaming engine cleans and formats the unique identifier field in the collected raw resource transfer data, performing sequence number standardization to eliminate encoding format inconsistencies caused by differences in the source system, generating globally unique standardized key-value pairs. Then, upsert semantics are used for data write control. When the streaming engine detects that the standardized key-value pair of the currently flowing resource transfer data already exists in the state storage, it automatically performs an update operation to overwrite the old version of the data; if the key-value pair does not exist, an insertion operation is performed. This mechanism ensures that regardless of how many times the underlying database resends the logs, the resource transfer data set maintained in memory always remains up-to-date and unique, effectively avoiding inflated transfer quota calculations or logical errors caused by data duplication.

[0059] Optionally, to gain a more comprehensive understanding and analysis of the context of resource transfer data, the system also synchronously monitors the transaction details associated with each resource transfer data through a streaming computing engine. These transaction details, serving as supplementary information to the resource transfer data, record detailed transaction information corresponding to each resource transfer data, including but not limited to key fields such as transaction type, occurrence time, participants, and operation details, providing rich contextual support for subsequent data analysis and verification. Based on this, a second mapping relationship is established between the two. This mapping relationship is based on the inherent logical connection between the data. By extracting common identifiers or related fields from the resource transfer data and transaction details, the system can automatically identify and match corresponding data records, thereby constructing a complete data association network. Based on the constructed second mapping relationship, the embodiments in this specification implement refined indexing and rapid retrieval capabilities for each resource transfer data. When subsequent verification processes need to trace the source of a resource transfer data or verify its business background, there is no need to perform a full database scan or complex join queries. Instead, the system directly utilizes this second mapping relationship to instantly lock the associated transaction details data through the identifier of the resource transfer data. Furthermore, this mapping relationship supports bidirectional traceability. It can find the corresponding transaction details through resource transfer data, and in specific scenarios, it can also reverse index the specific resource transfer data through transaction characteristics, thus forming a complete data loop and providing strong technical support for the accurate location of abnormal data.

[0060] For example, in a specific application scenario of financial fund accounting, when the system collects accounting records under business documents through a streaming computing engine, it simultaneously monitors and obtains the associated detailed business records. These detailed business records record the specific business background of each fund change, such as payment channels, counterparties, and business summaries. Subsequently, the system automatically establishes a second mapping relationship between the accounting records and the detailed business records based on the unique business identifiers shared by them. Based on this mapping relationship, when it is necessary to trace and verify the source of an accounting record, there is no need to perform a full table scan or complex multi-table join queries on massive historical data. The system can instantly locate the corresponding detailed business record simply by using the identifier of the accounting record, and then directly parse out the associated order number associated with the accounting record. This not only enables rapid location of the source of each accounting record, but also provides efficient and accurate data support for subsequent investigation of fund discrepancies and reconstruction of the full business picture.

[0061] S306. When the total amount of all resource transfer data is less than the preset threshold, the target transfer amount verification strategy is determined to be a non-summary verification strategy.

[0062] Optionally, after determining all resource transfer data covered by the target data transfer task, the embodiments of this specification dynamically adapt the optimal target transfer quota verification strategy based on the total amount of resource transfer data to solve the balance problem between verification efficiency and resource consumption under different data scales. In specific implementation, the system presets a threshold determined based on historical performance tests to delineate the boundaries of data processing modes. When the total amount of all resource transfer data under the current target data transfer task is less than the preset threshold, the system determines that the target transfer quota verification strategy is a non-summary verification strategy. Under this strategy mode, the system treats all resource transfer data as a whole set, directly extracts the transfer quota value from each resource transfer data, and assigns corresponding positive or negative signs according to its data flow attribute (e.g., inflow is recorded as positive, outflow as negative). Then, it performs a one-time summation operation on all signed transfer quotas in the set.

[0063] S308. When the total amount of all resource transfer data is greater than or equal to the preset threshold, the target transfer amount verification strategy is determined to be the summary verification strategy.

[0064] Optionally, when the total number of all resource transfer data obtained from the statistics is greater than or equal to a preset threshold, it indicates that the data scale is huge. If a single global accumulation method is used, it may cause memory overflow or processing delay due to the excessive weight of a single calculation task, and it is not conducive to parallel processing. At this time, the system determines the target transfer amount verification strategy as a summary verification strategy. Under this strategy mode, the system first divides the massive resource transfer data into several independent data subgroups according to preset grouping rules (such as time slice, data type, or hash sharding). Subsequently, the system independently executes the above-mentioned summary verification logic for each data subgroup, that is, it performs signed accumulation and summation of the transfer amounts of each resource transfer data in the subgroup in parallel.

[0065] S310. Calculate the transfer amount difference between inflow and outflow data in each resource transfer data based on the target transfer amount verification strategy.

[0066] Optionally, for details regarding step S310, please refer to step S202, which will not be repeated here.

[0067] S312. If the difference in the transfer amount meets the preset difference condition, the transfer amount verification of the target data transfer task is confirmed to be successful.

[0068] Optionally, after calculating the transfer amount difference for the target data transfer task, the embodiments of this specification first execute an automated judgment process based on preset difference conditions to establish the final transfer amount verification result. Specifically, the system has preset flexible difference condition logic, which not only includes strict zero-value matching, but can also be configured to allow small fluctuations within a certain precision range (e.g., extremely small differences caused by floating-point calculation errors or specific business rounding rules). If the calculated transfer amount difference falls within the preset difference condition range, the system directly determines that the transfer amount verification of the target data transfer task is successful, generates a corresponding success status flag, and triggers subsequent data archiving or status synchronization operations without any additional intervention.

[0069] S314. If the difference in the transfer amount does not meet the preset difference condition, the feature information of each resource transfer data and the corresponding associated data is input into the preset rule engine. The rule engine determines the anomaly type of the current verification result and processes the corresponding resource transfer data based on the anomaly type. The associated data is other resource transfer data that conforms to the preset association relationship with each resource transfer data.

[0070] Optionally, when the transfer limit difference does not meet the preset difference condition, considering that in a complex data transfer environment, factors such as timing differences between different data sources, transmission delays, or temporary record interruptions may lead to a temporary limit imbalance, this temporary imbalance may not necessarily represent a substantial data error. Directly determining that the limit verification has failed may result in a large number of false alarms or unnecessary interruptions. Therefore, in this case, the embodiments of this specification do not immediately determine that the target data transfer task verification has failed, but instead regard the current imbalance state as an intermediate state to be diagnosed, and activate an intelligent decision-making mechanism to distinguish between a permanent anomaly and a recoverable temporary fluctuation.

[0071] Optionally, at this stage, the system inputs the feature information of each resource transfer data and its corresponding associated data into a preset rule engine. Here, associated data refers to other resource transfer data already existing in each database that conforms to a preset logical relationship with each resource transfer data; these constitute the context for judging the current data status. Based on the input multi-dimensional feature information, the rule engine performs in-depth analysis and identification of the anomaly type presented by the current verification result. This analysis aims to determine, beyond the surface difference in the amount, whether the anomaly is a deterministic error that cannot be corrected by conventional means, or a temporary data loss or misalignment caused by external factors. According to its built-in decision logic, the rule engine outputs a classification result for the current anomaly type, which will serve as the basis for decisions in subsequent processing steps.

[0072] This specification provides a method for verifying data transfer quotas. By clearly defining the databases corresponding to each resource transfer data in the target data transfer task and utilizing a preset streaming computing engine for data collection, real-time and accurate capture of information during the data transfer process is achieved. This not only improves the efficiency and reliability of data collection but also ensures the integrity and consistency of data during the transfer process, providing a data foundation for subsequent data transfer quota verification. The streaming computing engine's built-in delay processing mechanism is used to collect resource transfer data organized in chronological order, effectively solving the technical challenge of out-of-order data arrival in a distributed environment. This avoids false quota imbalance alarms caused by data time sequence errors, improving the accuracy of the verification logic. The target transfer quota verification strategy is dynamically selected based on the total amount of resource transfer data. Specifically, a non-summarization verification strategy is used when the data volume is small, while a summary verification strategy is used when the data volume is large. This flexible strategy selection method ensures verification accuracy with small data volumes while improving verification efficiency with large data volumes, enabling the system to automatically adjust the verification method according to the actual situation, thus better adapting to data transfer tasks of different scales and complexities. When the transfer amount difference does not meet preset conditions, a rule engine is introduced to conduct in-depth analysis of the anomaly type based on the characteristics of the associated data. This distinguishes between a substantial error and a recoverable temporary fluctuation, effectively identifying and automatically repairing false imbalances caused by temporary data link breaks, reducing false alarm rates and manual intervention costs. By collecting transaction detail data that represents transaction occurrence information and establishing a second mapping relationship between it and resource transfer data, an efficient bidirectional indexing mechanism is constructed. This tightly associates the amount value with the specific transaction context, enabling the system to achieve accurate positioning and rapid retrieval based on the mapping relationship when it needs to trace or verify specific resource transfer data. This not only improves the efficiency of fault diagnosis and data auditing but also provides support for data correlation analysis in complex scenarios, enhancing the interpretability and maintainability of the entire verification system.

[0073] Please see Figure 4 , Figure 4 This is a flowchart illustrating a data transfer quota verification method provided in an embodiment of this specification.

[0074] like Figure 4 As shown, the verification methods for data transfer limits can include at least: S402. In response to the transfer quota verification request for the target data transfer task, collect multiple resource transfer data corresponding to the target data transfer task.

[0075] Optionally, for details regarding step S402, please refer to the description in step S202, which will not be repeated here.

[0076] S404. When the total amount of all resource transfer data is less than the preset threshold, the target transfer amount verification strategy is determined to be a non-summary verification strategy; when the total amount of all resource transfer data is greater than or equal to the preset threshold, the target transfer amount verification strategy is determined to be a summary verification strategy.

[0077] Optionally, for details regarding step S404, please refer to steps S306-S308, which will not be repeated here.

[0078] S406. When the target transfer quota verification strategy is a non-summary verification strategy, load each resource transfer data into the memory object of the current worker thread, and accumulate the inflow quota or outflow quota corresponding to each resource transfer data through a single traversal; or, distribute each resource transfer data to multiple parallel worker threads, accumulate the inflow quota or outflow quota corresponding to each resource transfer data in each parallel worker thread, and aggregate the processing results of each parallel worker thread.

[0079] Optionally, in scenarios where the target transfer quota verification strategy is determined to be a non-summary verification strategy, it usually means that the total amount of resource transfer data involved in the current target data transfer task is relatively small, below a preset threshold, and falls within the scope of lightweight data processing. For such scenarios, the embodiments in this specification provide two computation execution modes to adapt to different system loads and hardware environments.

[0080] Optionally, the first mode is suitable for scenarios with extremely small data volumes and extremely high real-time requirements. The system directly loads the transfer data of each resource into the memory object of the current worker thread, constructing a temporary in-memory dataset. Subsequently, through a single traversal, the inflow or outflow amount corresponding to each resource transfer data is linearly accumulated directly in memory. Since the data resides entirely in high-speed memory and no complex context switching is required, this processing method can complete the difference calculation of the amount with extremely low latency, quickly obtaining the transfer amount difference, thereby achieving instant verification of small-scale data transfer tasks.

[0081] Optionally, the second mode addresses situations where the total amount of resource transfer data, while not reaching the threshold for aggregation and verification, exceeds the optimal range for single-threaded processing. In this mode, a multi-threaded parallel computing architecture is employed. The system dynamically allocates each piece of resource transfer data to multiple parallel worker threads according to a preset allocation algorithm. Each parallel worker thread independently performs local accumulation of the inflow or outflow amount corresponding to its allocated resource transfer data within its local context, generating intermediate calculation results. After all parallel worker threads have completed their respective local calculations, the main thread performs a final aggregation operation on the processing results output by each parallel worker thread, thereby obtaining the global transfer amount difference. This parallel processing mechanism fully utilizes the computing power of multi-core processors, shortens the computation time for medium-sized data volumes, and avoids performance bottlenecks caused by single-threaded blocking.

[0082] S408. When the target transfer quota verification strategy is the summary verification strategy, each resource transfer data is divided into a preset number of ordered sub-batches. Based on the sequence number of each sub-batch and the preset time isolation time, each resource transfer data in each sub-batch is calculated sequentially. During the calculation process, the inflow quota or outflow quota corresponding to each resource transfer data in each sub-batch is accumulated to obtain the transfer quota difference corresponding to each sub-batch. After the calculation of all sub-batches is completed, the transfer quota difference corresponding to each sub-batch is accumulated.

[0083] Optionally, when the target transfer quota verification strategy is determined to be the summary verification strategy, it usually means that the total amount of resource transfer data involved in the current target data transfer task is extremely large, reaching or exceeding the preset threshold, and falls into the category of massive data processing. For such scenarios, the embodiments in this specification adopt an ordered sub-batch accumulation mechanism based on time-series isolation. Specifically, the system first divides the massive amount of resource transfer data into a preset number of ordered sub-batches, and each sub-batch is assigned a unique sequence number to identify its processing order. During the calculation and execution phase, the system strictly follows the sequence number order of the sub-batches and introduces a preset time-series isolation mechanism, that is, after the previous sub-batch is calculated and resources are released, the system waits for a set time interval (such as a second-level delay) before starting the calculation task of the next sub-batch.

[0084] Optionally, during the specific calculation process of each sub-batch, the system iterates through the resource transfer data contained in the currently active sub-batch, locally accumulating the corresponding inflow or outflow quota to independently calculate the transfer quota difference corresponding to that sub-batch. To prevent duplicate batch calculations caused by network jitter, task retries, or distributed scheduling anomalies, this embodiment introduces an optimistic locking mechanism based on state flags in the accumulation operation. After reading the sub-batch status, the system only executes the accumulation logic when the status meets the "not calculated" condition, and verifies the status version when writing the result to ensure that any ordered sub-batch is accumulated only once during the entire calculation lifecycle. After all the preset number of ordered sub-batches have completed their calculations and generated their respective transfer quota differences, the system executes the final aggregation step, globally accumulating the transfer quota differences corresponding to all sub-batches to obtain the final transfer quota difference for the entire target data transfer task.

[0085] In one possible implementation, during the specific process of dividing each resource transfer data into a preset number of ordered sub-batches, the embodiments of this specification employ a hash sharding strategy based on sequence identifiers to achieve a uniform distribution of massive amounts of data. First, the system extracts a sequence identifier from each resource transfer data to uniquely identify its generation order or source; this sequence identifier serves as a key value for data differentiation. Then, a preset hash algorithm is invoked to calculate each sequence identifier, generating a corresponding sequence hash value. Based on this, the system maps and aggregates all resource transfer data into multiple different logical buckets according to the numerical range of the sequence hash values; each logical bucket constitutes an ordered sub-batch. In this way, the massive amount of resource transfer data is broken down and reorganized into multiple ordered sub-batches with controllable granularity and balanced load, thus laying the data foundation for subsequent batch accumulation calculations.

[0086] S410. If the difference in the transfer amount meets the preset difference condition, the transfer amount verification of the target data transfer task is confirmed to be successful.

[0087] Optionally, for details regarding step S410, please refer to step S312, which will not be repeated here.

[0088] S412. If the difference in the transfer amount does not meet the preset difference condition, input the feature information of each resource transfer data and the corresponding associated data into the preset rule engine to determine whether there is target associated data in the associated data that meets the preset matching condition with the feature information of the target resource transfer data.

[0089] Optionally, in specific implementation scenarios where the transfer amount difference does not meet the preset difference conditions, thereby triggering an exception handling process, the embodiments of this specification use a preset rule engine to diagnose and intelligently decide the root cause of the verification failure. When the rule engine receives the feature information of each resource transfer data and its corresponding associated data, it first searches the vast associated data pool to see if there is any target associated data whose feature information (such as data generation timestamp, data source identifier, transfer amount value, business type label, etc.) matches the preset matching conditions of the target resource transfer data currently causing the imbalance. This process aims to confirm whether the current amount difference is a false anomaly caused by a temporary break or delayed arrival in the data link, or a permanent anomaly caused by data loss or logical errors. By comparing the similarity and correlation of feature information, the rule engine accurately identifies whether there are one or more other resource transfer data that should belong to the current target data transfer task but are stuck in other queues or database partitions due to differences in synchronization timing between systems.

[0090] S414. If not, determine the exception type as a special exception and stop verifying the transfer amount of the target data transfer task.

[0091] Optionally, if, after a comprehensive search, the rule engine determines that no target related data matches the characteristic information of the target resource transfer data in the associated data, the system will classify the current anomaly as a special anomaly. This situation typically corresponds to a relatively extreme and clearly unrelated scenario, meaning that the resource transfer data may have originated from an unknown error source, or irreversible data corruption may have occurred. For such special anomalies, the system immediately stops the subsequent verification process for the transfer amount of the current target data transfer task, generates a high-priority anomaly alarm, and marks the task as requiring manual intervention or entering a separate special processing channel.

[0092] S416. If it exists, determine that the anomaly type is a repairable anomaly, establish a first mapping relationship between the target associated data and the target data transfer task, and verify the transfer amount of the target data transfer task based on the first mapping relationship.

[0093] Optionally, if the rule engine successfully retrieves target-related data that matches the feature information of the target resource transfer data, the current anomaly type is determined to be a repairable anomaly. This indicates that the current quota imbalance is only a temporary phenomenon caused by transmission delays or asynchronous batch processing between different processing nodes, and the data is actually complete and loop-safe. In this case, the system will automatically establish a first mapping relationship between the target-related data and the target data transfer task, logically binding the originally scattered resource transfer data to the same task, and based on the established first mapping relationship, include the target-related data in the calculation scope and re-verify the transfer quota of the target data transfer task.

[0094] For example, in a specific financial accounting scenario, suppose a transaction involves multiple payers and payees, with funds flowing through different payment channels and ultimately being deposited into the payee's account. During transaction execution, factors such as network latency and differences in system processing speed may cause some fund transfer data (i.e., accounting records) to fail to be synchronized to the accounting system in a timely manner, resulting in an imbalance in transfer amounts. When the accounting system detects that the transfer amount difference of a data transfer task does not meet the preset difference condition, it immediately triggers an exception handling process. The feature information of each accounting record and its corresponding related data under the task is input into a preset rule engine, and the rule engine searches for whether there is target related data that matches the feature information of the target resource transfer data causing the current imbalance.

[0095] Furthermore, if the rules engine detects a fund transfer that should have been received but is not displayed in the accounting system, and its transaction time, account information of both parties, and transaction amount all highly match the target resource transfer data, but are temporarily stuck in the cache queue of other payment channels due to differences in system synchronization timing, the rules engine determines this anomaly to be repairable and automatically establishes a first mapping relationship between the target related data and the target data transfer task. Based on this mapping relationship, the system includes the stuck fund transfer data in the calculation scope and re-verifies the transfer amount of the target data transfer task. Conversely, if the rules engine does not find any target related data that matches the target resource transfer data in the related data, it determines this anomaly to be a special anomaly, immediately stops the subsequent verification process of the transfer amount of the current target data transfer task, and generates a high-priority anomaly alarm to notify relevant personnel to intervene in a timely manner to avoid potential financial risks.

[0096] This specification provides a method for verifying data transfer quotas. For non-summary verification scenarios with a small total amount of transferred data or a light computational load, it offers a flexible and efficient in-memory computing mechanism. By supporting loading data into a single-threaded memory object for single-pass traversal, or utilizing multi-threaded parallel processing before aggregating the results, it can dynamically adapt computing resources according to the actual data scale. This avoids the additional overhead caused by introducing complex batching logic when the data volume is small, and fully utilizes multi-core processing capabilities to significantly shorten verification time when the data volume is moderate, ensuring the timeliness and accuracy of quota verification for routine data transfer tasks. In summary verification scenarios involving massive amounts of transferred data, an ordered sub-batch accumulation mechanism based on time-sequence isolation is introduced. This divides the large dataset into multiple ordered sub-batches and forces them to be executed sequentially at intervals, effectively smoothing the instantaneous system load and solving the memory overflow, computation timeout, and hot key conflict problems that are prone to occur in traditional full aggregation methods when facing high-volume data. Simultaneously, combined with a time-sequence waiting strategy between batches, it ensures the computational independence between each sub-batch in a distributed environment, avoiding data competition and conflicts, and guaranteeing the accuracy of the verification results. By using the hash value of the sequence identifier as the basis for data sharding, the discrete nature of the hash algorithm effectively eliminates the risk of data skew caused by uneven data temporal distribution, ensuring a balanced data load for each sub-batch and preventing individual batches from becoming performance bottlenecks due to excessive size. Simultaneously, this hash-based sharding method preserves logical order while dispersing data, facilitating subsequent time-series isolation calculations and ensuring the computational order and independence between sub-batches. Through a rule engine, precise matching of feature information identifies the existence of correlated target data. The system can automatically distinguish between recoverable anomalies caused by data synchronization delays and special anomalies caused by data loss. For recoverable anomalies, a mapping relationship is automatically established and re-verified, effectively eliminating cross-system data transmission noise and reducing false alarm rates and manual intervention costs. For special anomalies, the system decisively stops and issues alarms to prevent error propagation. This intelligent noise reduction and decision-making mechanism improves the final consistency and verification pass rate of data transfer tasks in complex heterogeneous environments.

[0097] Please see Figure 5 , Figure 5 This is a structural block diagram of a data transfer quota verification device provided in an embodiment of this specification. Figure 5 As shown, the data transfer limit verification device 500 includes: The data acquisition module 510 is used to collect multiple resource transfer data corresponding to the target data transfer task in response to the transfer quota verification request for the target data transfer task. The classification calculation module 520 is used to determine the corresponding target transfer amount verification strategy based on the total amount of all resource transfer data, and to calculate the transfer amount difference between the inflow data and the outflow data in each resource transfer data based on the target transfer amount verification strategy. The quota verification module 530 is used to determine the transfer quota verification result of the target data transfer task based on the transfer quota difference.

[0098] Optionally, the data acquisition module 510 is also used to determine the database corresponding to each resource transfer data in the target data transfer task. Each database is used to record information of the corresponding resource transfer data during the data transfer process. In each database, resource transfer data for the target data transfer task is collected through a preset streaming computing engine.

[0099] Optionally, the data acquisition module 510 is also used to acquire resource transfer data organized in chronological order through the delay processing mechanism corresponding to the streaming computing engine.

[0100] Optionally, the classification calculation module 520 is also used to determine the target transfer amount verification strategy as a non-summary verification strategy when the total amount of all resource transfer data is less than a preset threshold; and to determine the target transfer amount verification strategy as a summary verification strategy when the total amount of all resource transfer data is greater than or equal to the preset threshold.

[0101] Optionally, when the target transfer quota verification strategy is a non-summary verification strategy, the classification calculation module 520 is also used to load each resource transfer data into the memory object of the current working thread, and accumulate the inflow quota or outflow quota corresponding to each resource transfer data through a single traversal; or, allocate each resource transfer data to multiple parallel working threads, accumulate the inflow quota or outflow quota corresponding to each resource transfer data in each parallel working thread, and aggregate the processing results of each parallel working thread.

[0102] Optionally, when the target transfer quota verification strategy is a summary verification strategy, the classification calculation module 520 is also used to divide each resource transfer data into a preset number of ordered sub-batches, and calculate each resource transfer data in each sub-batch based on the sequence number of each sub-batch and the preset time isolation time. During the calculation process, the inflow quota or outflow quota corresponding to each resource transfer data in each sub-batch is accumulated to obtain the transfer quota difference corresponding to each sub-batch; after the calculation of all sub-batches is completed, the transfer quota difference corresponding to each sub-batch is accumulated.

[0103] Optionally, the classification calculation module 520 is also used to calculate the sequence hash value corresponding to the sequence identifier of each resource transfer data, and divide each resource transfer data into multiple ordered sub-batches based on each sequence hash value.

[0104] Optionally, the quota verification module 530 is further configured to determine that the transfer quota verification of the target data transfer task is successful if the transfer quota difference meets the preset difference conditions; if the transfer quota difference does not meet the preset difference conditions, input the feature information of each resource transfer data and the corresponding associated data into the preset rule engine, determine the abnormal type of the current verification result through the rule engine, process the corresponding resource transfer data based on the abnormal type, and the associated data is other resource transfer data that meets the preset association relationship with each resource transfer data.

[0105] Optionally, the quota verification module 530 is further used to determine whether there is target associated data in the associated data that meets the preset matching conditions with the feature information of the target resource transfer data; if not, the exception type is determined to be a special exception, and the verification of the transfer quota of the target data transfer task is stopped; if it exists, the exception type is determined to be a repairable exception, a first mapping relationship is established between the target associated data and the target data transfer task, and the transfer quota of the target data transfer task is verified based on the first mapping relationship.

[0106] Optionally, the data transfer quota verification device 500 further includes: a transaction data acquisition module, used to collect transaction detail data associated with each resource transfer data, wherein each transaction detail data is used to characterize the transaction occurrence information corresponding to each resource transfer data; and to establish a second mapping relationship between each resource transfer data and the corresponding transaction detail data, so as to index each resource transfer data based on the second mapping relationship.

[0107] In this embodiment of the specification, a data transfer quota verification device is provided, wherein a data acquisition module is used to collect multiple resource transfer data corresponding to the target data transfer task in response to a transfer quota verification request for the target data transfer task; a classification calculation module is used to determine a corresponding target transfer quota verification strategy based on the total number of all resource transfer data, and calculate the transfer quota difference between inflow data and outflow data in each resource transfer data based on the target transfer quota verification strategy; and a quota verification module is used to determine the transfer quota verification result of the target data transfer task based on the transfer quota difference. First, the data acquisition module identifies specific target data transfer tasks and proactively collects multiple resource transfer data strongly correlated with them, constructing a logically self-consistent micro-data closed loop. This allows the system to reconstruct the full picture of a single business event, ensuring data integrity and contextual relevance regardless of whether the task involves simple point-to-point transmission or complex multi-source aggregation or multi-path distribution. Furthermore, this step is triggered by a "verification request," meaning that verification behavior no longer relies on fixed long-cycle time slices but can be embedded in any key node of the task lifecycle (such as triggering immediately after the task is completed). This event-driven acquisition mechanism improves the timeliness of data acquisition, enabling the system to immediately perceive the data status after a resource transfer occurs, compressing the risk exposure period from anomaly occurrence to discovery, and providing a time basis for subsequent real-time intervention. Then, the classification calculation module introduces a dynamic adaptive calculation mechanism based on data characteristics. Depending on the total amount of data, the system can automatically select or adjust the most suitable verification strategy, ensuring efficient and accurate completion of verification tasks across various data scales. By calculating the transfer amount difference between inflow and outflow data, the system can intuitively reflect the balance during the data transfer process, providing a strong basis for subsequent verification result judgment. Finally, the final output of the verification process is directly related to the validity and compliance of the data transfer task. The quota verification module determines the verification result based on the transfer amount difference. The system can clearly determine whether the data transfer task meets the expected quota requirements, thereby promptly preventing non-compliant data transfer behavior and protecting the integrity and security of data resources. Simultaneously, this step also provides important reference for subsequent processing of the data transfer task, such as adjusting the transfer quota, supplementing missing data, or correcting errors.

[0108] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0109] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0110] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 6 As shown, terminal 600 may include: at least one terminal processor 601, at least one network interface 604, user interface 603, memory 605, and at least one communication bus 602.

[0111] The communication bus 602 is used to enable communication between these components.

[0112] The user interface 603 may include a display screen and a camera. Optionally, the user interface 603 may also include a standard wired interface and a wireless interface.

[0113] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0114] The terminal processor 601 may include one or more processing cores. The terminal processor 601 connects to various parts within the terminal 600 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the terminal processor 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The terminal processor 601 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the terminal processor 601 and may be implemented as a separate chip.

[0115] The memory 605 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned terminal processor 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a data transfer limit verification program.

[0116] exist Figure 6 In the terminal 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 601 can be used to call the data transfer quota verification program stored in the memory 605 and specifically perform the following operations: In response to a transfer limit verification request for the target data transfer task, collect multiple resource transfer data corresponding to the target data transfer task; The corresponding target transfer amount verification strategy is determined based on the total amount of all resource transfer data. The transfer amount difference between the inflow and outflow data in each resource transfer data is calculated based on the target transfer amount verification strategy. The transfer amount verification result of the target data transfer task is determined based on the transfer amount difference.

[0117] In some embodiments, when the terminal processor 601 executes the following steps when collecting multiple resource transfer data corresponding to the target data transfer task: determining the database corresponding to each resource transfer data in the target data transfer task, each database being used to record information of the corresponding resource transfer data during the data transfer process; and collecting resource transfer data for the target data transfer task in each database through a preset streaming computing engine.

[0118] In some embodiments, when the terminal processor 601 executes the following steps when collecting resource transfer data for a target data transfer task through a preset streaming computing engine: collecting each resource transfer data organized in chronological order through the delay processing mechanism corresponding to the streaming computing engine.

[0119] In some embodiments, when the terminal processor 601 executes the following steps to determine the corresponding target transfer quota verification strategy based on the total amount of all resource transfer data: when the total amount of all resource transfer data is less than a preset threshold, the target transfer quota verification strategy is determined to be a non-summary verification strategy; when the total amount of all resource transfer data is greater than or equal to the preset threshold, the target transfer quota verification strategy is determined to be a summary verification strategy.

[0120] In some embodiments, when the target transfer quota verification strategy is a non-summary verification strategy, the terminal processor 601 performs the following steps when calculating each resource transfer data based on the target transfer quota verification strategy: loading each resource transfer data into the memory object of the current working thread, accumulating the inflow quota or outflow quota corresponding to each resource transfer data through a single traversal; or, distributing each resource transfer data to multiple parallel working threads, accumulating the inflow quota or outflow quota corresponding to each resource transfer data in each parallel working thread, and aggregating the processing results of each parallel working thread.

[0121] In some embodiments, when the target transfer quota verification strategy is a summary verification strategy, the terminal processor 601 performs the following steps when calculating each resource transfer data based on the target transfer quota verification strategy: dividing each resource transfer data into a preset number of ordered sub-batches, calculating each resource transfer data in each sub-batchlet sequentially based on the sequence number of each sub-batchlet and a preset time isolation time, accumulating the inflow quota or outflow quota corresponding to each resource transfer data in each sub-batchlet during the calculation process to obtain the transfer quota difference corresponding to each sub-batchlet; and accumulating the transfer quota difference corresponding to each sub-batchlet after the calculation of all sub-batches is completed.

[0122] In some embodiments, when the terminal processor 601 divides each resource transfer data into a preset number of ordered sub-batches, it specifically performs the following steps: calculating the sequence hash value corresponding to the sequence identifier of each resource transfer data, and dividing each resource transfer data into multiple ordered sub-batches based on each sequence hash value.

[0123] In some embodiments, when the terminal processor 601 executes the transfer amount verification result of the target data transfer task based on the transfer amount difference, it specifically performs the following steps: if the transfer amount difference meets the preset difference condition, it determines that the transfer amount verification of the target data transfer task is successful; if the transfer amount difference does not meet the preset difference condition, it inputs the feature information of each resource transfer data and the corresponding associated data into the preset rule engine, judges the anomaly type of the current verification result through the rule engine, processes the corresponding resource transfer data based on the anomaly type, and the associated data is other resource transfer data that meets the preset association relationship with each resource transfer data.

[0124] In some embodiments, when the terminal processor 601 executes the following steps when determining the anomaly type of the current verification result through the rule engine and processing the corresponding resource transfer data based on the anomaly type: determining whether there is target associated data in the associated data that meets the preset matching conditions with the feature information of the target resource transfer data; if not, determining that the anomaly type is a special anomaly and stopping the verification of the transfer amount of the target data transfer task; if it exists, determining that the anomaly type is a repairable anomaly, establishing a first mapping relationship between the target associated data and the target data transfer task, and verifying the transfer amount of the target data transfer task based on the first mapping relationship.

[0125] In some embodiments, the terminal processor 601 further performs the following steps: collecting transaction detail data associated with each resource transfer data, wherein each transaction detail data is used to characterize the transaction occurrence information corresponding to each resource transfer data; and establishing a second mapping relationship between each resource transfer data and the corresponding transaction detail data, so that each resource transfer data can be indexed based on the second mapping relationship.

[0126] In the several embodiments provided in this specification, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0127] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0128] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0129] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0130] Furthermore, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the data transfer tasks and resource transfer data involved in this specification were obtained under full authorization.

[0131] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0132] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0133] The above is a description of a data transfer quota verification method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. A method for verifying data transfer limits, the method comprising: In response to a transfer quota verification request for a target data transfer task, multiple resource transfer data corresponding to the target data transfer task are collected. The corresponding target transfer amount verification strategy is determined based on the total amount of all resource transfer data. The transfer amount difference between the inflow data and the outflow data in each resource transfer data is calculated based on the target transfer amount verification strategy. The transfer limit verification result of the target data transfer task is determined based on the transfer limit difference.

2. The method according to claim 1, wherein collecting multiple resource transfer data corresponding to the target data transfer task includes: Determine the database corresponding to each resource transfer data in the target data transfer task. Each database is used to record information about the corresponding resource transfer data during the data transfer process. In each database, resource transfer data for the target data transfer task is collected through a preset streaming computing engine.

3. The method according to claim 2, wherein collecting resource transfer data for the target data transfer task through a preset streaming computing engine includes: The streaming computing engine uses a latency processing mechanism to collect resource transfer data organized in chronological order.

4. The method according to claim 1, wherein determining the corresponding target transfer quota verification strategy based on the total amount of all resource transfer data includes: When the total amount of all resource transfer data is less than the preset threshold, the target transfer amount verification strategy is determined to be a non-summary verification strategy. When the total amount of all resource transfer data is greater than or equal to the preset threshold, the target transfer amount verification strategy is determined to be the summary verification strategy.

5. The method according to claim 4, wherein when the target transfer quota verification strategy is the non-aggregation verification strategy, the calculation of each resource transfer data based on the target transfer quota verification strategy includes: Load the data of each resource transfer into the memory object of the current worker thread, and accumulate the inflow or outflow amount corresponding to each resource transfer data through a single traversal; Alternatively, the resource transfer data can be distributed to multiple parallel worker threads, the inflow or outflow amount corresponding to each resource transfer data in each parallel worker thread can be accumulated, and the processing results of each parallel worker thread can be aggregated.

6. The method according to claim 4, wherein when the target transfer quota verification strategy is the summary verification strategy, the step of calculating each resource transfer data based on the target transfer quota verification strategy includes: The resource transfer data is divided into a preset number of ordered sub-batches. Based on the sequence number of each sub-batch and the preset time isolation time, the resource transfer data in each sub-batch are calculated sequentially. During the calculation process, the inflow or outflow amount corresponding to each resource transfer data in each sub-batch is accumulated to obtain the transfer amount difference corresponding to each sub-batch. After all sub-batch calculations are completed, the transfer amount differences corresponding to each sub-batch are summed up.

7. The method according to claim 6, wherein dividing the resource transfer data into a preset number of ordered sub-batches includes: Calculate the sequence hash value corresponding to the sequence identifier of each resource transfer data, and divide each resource transfer data into multiple ordered sub-batches based on each sequence hash value.

8. The method according to claim 1, wherein determining the transfer limit verification result of the target data transfer task based on the transfer limit difference includes: If the difference in the transfer amount meets the preset difference condition, the transfer amount verification of the target data transfer task is determined to be successful; If the difference in the transfer amount does not meet the preset difference condition, the feature information of each resource transfer data and the corresponding associated data is input into the preset rule engine. The rule engine determines the anomaly type of the current verification result, and the corresponding resource transfer data is processed based on the anomaly type. The associated data is other resource transfer data that conforms to the preset association relationship with each resource transfer data.

9. The method according to claim 8, wherein determining the anomaly type of the current verification result through the rule engine and processing the corresponding resource transfer data based on the anomaly type includes: Determine whether there is any target associated data in the associated data that matches the feature information of the target resource transfer data according to a preset matching condition; If it does not exist, determine that the anomaly type is a special anomaly, and stop verifying the transfer amount of the target data transfer task; If it exists, determine that the anomaly type is a repairable anomaly, establish a first mapping relationship between the target associated data and the target data transfer task, and verify the transfer amount of the target data transfer task based on the first mapping relationship.

10. The method according to claim 2, further comprising: Collect transaction details associated with each resource transfer data. Each transaction details data is used to characterize the transaction occurrence information corresponding to each resource transfer data. Establish a second mapping relationship between each resource transfer data and the corresponding transaction details data, so that each resource transfer data can be indexed based on the second mapping relationship.

11. A data transfer quota verification device, the device comprising: The data acquisition module is used to collect multiple resource transfer data corresponding to the target data transfer task in response to the transfer quota verification request for the target data transfer task; The classification calculation module is used to determine the corresponding target transfer amount verification strategy based on the total amount of all resource transfer data, and to calculate the transfer amount difference between the inflow data and the outflow data in each resource transfer data based on the target transfer amount verification strategy. The quota verification module is used to determine the transfer quota verification result of the target data transfer task based on the transfer quota difference.

12. A computer program product comprising instructions that, when run on a computer or processor, causes the computer or processor to perform the steps of the method as claimed in any one of claims 1 to 10.

13. A computer storage medium storing a plurality of instructions adapted for loading by a processor and performing the steps of the method as claimed in any one of claims 1 to 10.

14. A terminal comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as claimed in any one of claims 1 to 10.

Images