A service data checking method and device

Abstract

The application discloses a business data checking method and device, realizes automatic perception of failed allocation flow checking, automatic compensation, that is, re-performs allocation flow checking, that is, the checking failure is automatically perceived and automatically compensated, and manual operation and maintenance pressure is reduced. Further, in the embodiment of the application, the re-checking of the failed allocation flow is not re-checked for the whole batch of data, and waste of resources is avoided.

Description

Technical Field

[0001] This application relates to, but is not limited to, information processing technology, and in particular to a business data verification method and device. Background Technology

[0002] To verify the integrity of credit line transfers, fund allocation reconciliation is required to check business data balance. However, reconciliation may fail due to network fluctuations or malfunctions, counterparty database failures, application failures, or other reasons.

[0003] If the transfer transaction verification fails due to network jitter, application failure, or database failure, an alarm will be issued by the relevant technical department after the verification database confirms the failure. Manual intervention is required to determine the cause of the failure, which affects the efficiency of the transfer transaction verification. Summary of the Invention

[0004] This application provides a business data verification method and device that can automatically detect verification failures and automatically compensate for them, thereby reducing the manual operation and maintenance pressure.

[0005] This invention provides a business data verification method, including:

[0006] When the first triggering condition is met, determine whether there is an allocation flow with a status of verification failure in the verification failure record information;

[0007] The target allocation flow is pushed to the counterparty database corresponding to the target allocation flow, so that the counterparty database can verify the target allocation flow; wherein, the target allocation flow is any allocation flow in the allocation flow whose status is the verification failure.

[0008] Based on the verification results, determine whether to change the status of the target allocation flow.

[0009] In one exemplary instance, it also includes:

[0010] When the second triggering condition is met, the current batch of transfer flow is determined, and the current batch of transfer flow is pushed to at least one counterparty database corresponding to the current batch of transfer flow to realize the verification of the transfer flow; the verification failure record information of the transfer flow that fails to verify is recorded.

[0011] In one exemplary instance, it also includes:

[0012] The failed transfer transactions are pushed to the corresponding counterparty database so that the counterparty database can re-verify the failed transfer transactions; if the re-verification meets the re-verification failure conditions, the step of recording the verification failure record information of the failed transfer transactions is executed.

[0013] In one exemplary instance, the verification failure record information includes batch information of the failed transfer flow, first-party account information, and second-party account information.

[0014] In one exemplary instance, pushing the target allocation flow to the counterparty database corresponding to the target allocation flow includes:

[0015] Based on the verification failure record information of the target transfer flow, determine the second-party account information corresponding to the target transfer flow, and read the corresponding target transfer flow record;

[0016] The counterparty pool is determined based on the second-party account information;

[0017] The target transfer transaction record is sent to the counterparty database so that the counterparty database corresponding to the second party account information can verify the target transfer transaction record.

[0018] In one exemplary instance, before pushing the target allocation flow to the counterparty database corresponding to the target allocation flow, the method further includes:

[0019] Change the information indicating the status of the transfer flow in the verification failure record to "in progress".

[0020] In one exemplary instance, determining whether to change the target allocation flow that failed the current verification based on the verification result includes at least one of the following:

[0021] If the verification result is successful, the status of the target transfer flow will be changed to successful verification.

[0022] If the verification result is a verification failure, the status of the target allocation flow remains unchanged;

[0023] If the verification result is not received within the preset time period, the status of the target allocation flow remains unchanged.

[0024] In one exemplary instance, determining the current batch allocation flow and pushing the current batch allocation flow to at least one counterparty database corresponding to the current batch allocation flow includes:

[0025] Based on the verified batch information, determine the current batch information that needs to be verified in the transfer flow;

[0026] Read the allocation flow from the current batch information;

[0027] Based on the second-party account information, the read transfer flow is pushed to the counterparty database corresponding to the transfer flow.

[0028] In one exemplary instance, the verification failure record information of the transfer flow that failed to verify includes:

[0029] If the verification result is a verification failure, or if the verification result is not received within a preset time period, the verification failure record information is stored.

[0030] The verification failure record information includes batch information, first-party account information, and second-party account information of the failed transfer transactions.

[0031] In one exemplary instance, the verification failure record information further includes: information indicating the status of the transfer flow that failed the verification;

[0032] The states include: a pending verification state that needs to be re-verified, a successful verification state that has been successfully verified, or a verification process in progress that is being re-verified.

[0033] The verification failure record information also includes:

[0034] Set the status of the relevant information entered into the table to "pending verification".

[0035] In one exemplary instance, satisfying the first triggering condition includes satisfying at least one of the following:

[0036] The preset periodic trigger time has been reached;

[0037] The number of failed transfer transactions has reached a preset threshold.

[0038] When the statistics of failed transfer transactions reach the preset time limit;

[0039] A trigger request was received from a pre-set command key.

[0040] This application also provides a computer-readable storage medium storing computer-executable instructions, which are used to execute the business data verification database method described in any of the above claims.

[0041] This application embodiment also discloses an apparatus for implementing business data verification, including a memory and a processor, wherein the memory stores the following instructions executable by the processor: for performing the steps of the business data verification method described in any of the above claims.

[0042] This application embodiment further provides a business data verification method, including:

[0043] Based on the current batch information, the current batch transfer flow in the current batch is pushed to at least one counterparty database corresponding to the current batch transfer flow to realize the verification of the transfer flow;

[0044] If there are failed transfer transactions in the current batch, push the failed transfer transactions to the corresponding counterparty database so that the counterparty database can re-verify the failed transfer transactions.

[0045] When the conditions for re-verification failure are met, record the verification failure information for the transfer flow that failed to verify.

[0046] This application embodiment also provides a business data verification device, including: a compensation module and a recording module; wherein,

[0047] The compensation module is configured to, when a first trigger condition is met, query the record module to determine whether there is an allocation flow with a status of verification failure; push the target allocation flow to the counterparty database corresponding to the target allocation flow so that the counterparty database can verify the target allocation flow, wherein the target allocation flow is any allocation flow with a status of verification failure; and determine whether to change the status of the currently failed target allocation flow based on the verification result.

[0048] The recording module is configured to store the verification failure records of transfer transactions that failed to be verified.

[0049] The business data verification method provided in this application embodiment realizes automatic detection and automatic compensation for failed transfer flow verification, i.e., re-verification of transfer flow. In other words, it automatically detects verification failures and automatically compensates for them, reducing the manual operation and maintenance pressure.

[0050] Furthermore, the compensation information for the failed transfer transactions includes batch information, the account information of the party verifying the transaction, and the account information of the other party verifying the transaction. In other words, in this embodiment, the re-verification of the failed transfer transactions is not a re-verification of the entire batch of data, but rather excludes the data that has been successfully verified in the current batch and only re-verifies the transfer transactions that failed in the current batch, thus avoiding waste of resources.

[0051] Furthermore, in this embodiment of the application, during the process of verifying the transfer flow, the transfer flow compensation information of the transfer flow that fails to be verified is recorded. In this way, the foundation is laid for the transfer flow that fails to be verified to be re-verified, and preparation is also made for automatically sensing the verification failure and automatically compensating.

[0052] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0053] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0054] Figure 1 A schematic diagram of the data business processing architecture for entering and exiting the vault in related technologies;

[0055] Figure 2 This is a flowchart illustrating a business data verification method according to an embodiment of this application;

[0056] Figure 3 This is a flowchart illustrating another business data verification method in an embodiment of this application;

[0057] Figure 4 This is a schematic diagram of the architecture of the reserve fund system for implementing business data verification in an embodiment of this application.

[0058] Figure 5 This is a schematic diagram of the composition of the business data verification device in the embodiments of this application. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be arbitrarily combined with each other.

[0060] In a typical configuration of this application, the computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0061] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0062] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0063] The steps illustrated in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases the steps shown or described may be performed in a different order than that presented here.

[0064] In the process of processing business data for entering and leaving the vault, such as Figure 1 As shown, taking a single data center as an example, the amount deposited into the vault needs to be aggregated (e.g., ...). Figure 1 The credit limit is collected from the account and deposited into the Internet Data Center (IDC) database. The account credit limit in the IDC database needs to be allocated (e.g., ...). Figure 1 The allocated quota is transferred to the withdrawal vault for withdrawal transactions. The operation of deducting / increasing the quota and recording the transfer flow is a database transaction.

[0065] When credit limits are transferred, the credit limit is typically deducted and the transaction record is kept first in database A, where the transfer originates. Then, the credit limit is added to database B (the counterparty database), which corresponds to database A and the transfer originates from (referred to as the counterparty database), and the transaction record is kept. It is easily understood by those skilled in the art that database A is also the counterparty database of database B. Since credit limit transfers are usually cross-database operations, uncontrollable factors such as network failures can lead to data write-in failures.

[0066] In a single transfer transaction reconciliation task, the system first retrieves transfer transaction records for the same batch and the same account from all databases in the current data center, including the deposit vault, withdrawal vault, and IDC database. Then, it distinguishes between two different types of transactions based on the loan identifiers in the transfer transaction records: transfer transactions from the deposit vault and transfer transactions from the withdrawal vault. Finally, it compares these transaction information in memory to check whether the loan balance is maintained.

[0067] To reduce human intervention and achieve automatic system compensation and verification, thereby reducing operational and maintenance pressure and avoiding resource waste, this application provides a business data verification method, such as... Figure 2 As shown, it includes:

[0068] Step 200: When the first triggering condition is met, determine whether there is an allocation flow with a status of verification failure in the verification failure record information.

[0069] In one exemplary instance, the first trigger condition is used to trigger the process of re-verifying the recorded transfer transactions that failed to be verified. The first trigger condition may include, but is not limited to, the following: triggering according to a pre-set cycle to periodically check for the existence of transfer transactions that failed to be verified; or triggering the check for the existence of transfer transactions that failed to be verified when the number of transfer transactions that failed to be verified reaches a preset threshold; or triggering the check for the existence of transfer transactions that failed to be verified when the statistics of transfer transactions that failed to be verified reach a preset duration; or receiving a trigger from an external source, such as adding a command key to the periodic check to facilitate manual triggering of the process of checking for the existence of transfer transactions that failed to be verified when needed; or triggering the process manually according to demand, etc.

[0070] In one exemplary instance, satisfying the first triggering condition in step 200 includes satisfying at least one of the following: reaching a preset periodic triggering time; the number of failed transfer transactions reaching a preset quantity threshold; the statistics of failed transfer transactions reaching a preset duration; receiving a trigger request from a preset command key, etc.

[0071] In one exemplary instance, determining whether there are failed transfer records may include:

[0072] Check the verification failure record information. If there is a record of a failed transfer transaction in the verification failure record information, then it is confirmed that a failed transfer transaction exists; if there is no record of a failed transfer transaction in the verification failure record information, then it is confirmed that no failed transfer transaction exists.

[0073] In one exemplary instance, the verification failure record information can be manually recorded during normal transfer flow verification, or it can be as described in this application. Figure 3The example shown was automatically generated.

[0074] In one exemplary instance, the verification failure record information includes batch information, first-party account information, and second-party account information of the failed transfer transaction. Furthermore, the verification failure record information also includes information indicating the status of the transfer transaction.

[0075] In one exemplary instance, the verification failure record information can be stored in a table used to record relevant information for failed transfer transactions. Each record in the table represents a piece of information related to a failed transfer transaction, where the relevant information indicates the batch information, first-party account information, and second-party account information of the failed transfer transaction. Furthermore, the relevant information for failed transfer transactions may also include information indicating the status of the transfer transaction, such as: status "Pending Verification," indicating that verification is required; status "Verification Processing," indicating that verification is underway; status "Verification Successful," indicating that verification has been successful, etc.

[0076] It should be noted that when there are multiple records of failed transfer transactions, those skilled in the art can easily understand that they can scan and process each record one by one according to the order in which they were recorded and the first-in-first-out principle.

[0077] Step 201: Push the target allocation flow to the counterparty database corresponding to the target allocation flow so that the counterparty database can verify the target allocation flow; wherein, the target allocation flow is any allocation flow in the allocation flow whose status is verification failure.

[0078] In one exemplary instance, the target transfer flow that currently failed to reconcile is the transfer flow that is currently being processed among the multiple transfer flows that have failed to reconcile.

[0079] In one exemplary instance, step 201 may include:

[0080] Based on the verification failure record information, the target transfer flow that failed the verification is pushed to the corresponding counterparty database, so that the counterparty database can verify the target transfer flow. In this application, this process is also referred to as compensation.

[0081] In one exemplary instance, based on the verification failure record information, pushing the target transfer flow that failed the verification to the counterparty database corresponding to the target transfer flow may include:

[0082] Based on the verification failure record information of the target allocation flow, determine the second-party account information corresponding to the target allocation flow, and read the corresponding target allocation flow record;

[0083] Determine the counterparty pool based on second-party account information;

[0084] The target transfer transaction record is sent to the counterparty database so that the counterparty database corresponding to the second-party account information can verify the target transfer transaction.

[0085] In one exemplary instance, where the verification failure record information is stored in a table used to record relevant information of the failed transfer flow, pushing the target transfer flow that failed the verification to the counterparty database corresponding to the target transfer flow may include:

[0086] Based on the relevant information of the target allocation flow in the verification failure record information, obtain the batch information, first-party account information and second-party account information corresponding to the target allocation flow;

[0087] Based on the batch information, first-party account information, and second-party account information of the target transfer flow that failed to be verified, read the corresponding transfer flow record;

[0088] The read transfer records are pushed to the counterparty database corresponding to the second-party account information, so that the counterparty database corresponding to the second-party account information can verify the target transfer records.

[0089] In one exemplary instance, before pushing the target allocation flow to the counterparty database corresponding to the target allocation flow, the process may further include:

[0090] Change the status information of the target allocation flow to: "Verification in progress" in the relevant information of the allocation flow.

[0091] In one exemplary instance, step 201 may further include: determining that the adversary database is online. If the adversary database is offline, the process can end.

[0092] Step 202: Determine whether to change the status of the target transfer flow that failed the verification based on the verification results.

[0093] In one exemplary instance, this step may also include:

[0094] If the verification result is successful, the status of the target allocation flow will be changed to successful; if the verification result is unsuccessful, the status of the target allocation flow will remain unchanged and will remain pending verification; if the verification result is not received within a preset time, the status of the target allocation flow will remain unchanged and will remain pending verification.

[0095] pass Figure 2 The business data verification method shown realizes automatic detection and automatic compensation for failed transfer flow verification, that is, re-verification of transfer flow. In other words, it automatically detects verification failures and automatically compensates for them, reducing the manual operation and maintenance pressure.

[0096] Furthermore, since the relevant information of the failed transfer transactions includes batch information, first-party account information, and second-party account information, in this embodiment, the re-verification of the failed transfer transactions is not a re-verification of the entire batch of data, but rather excludes the successfully verified data in the current batch and only re-verifies the failed transfer transactions in the current batch, thus avoiding waste of resources.

[0097] In one exemplary instance, this application may further include:

[0098] Step 300: When the second triggering condition is met, determine the current batch transfer flow and push the current batch transfer flow to at least one counterparty database corresponding to the current batch transfer flow to realize the verification of the transfer flow.

[0099] In one exemplary instance, the second triggering condition is used to trigger the process of verifying the transfer flow. The second triggering condition may include, but is not limited to, the following: triggering according to a pre-set cycle to perform timed verification of the transfer flow; or, adding a command key on the basis of timed verification or to facilitate manual triggering of the process of verifying the transfer flow when needed; or; or manual triggering according to demand.

[0100] In one exemplary instance, satisfying the second triggering condition in step 300 includes satisfying at least one of the following: reaching a preset periodic triggering time; receiving a trigger request from a preset command key, etc.

[0101] In one exemplary instance, the step of pushing the current batch allocation flow to at least one counterparty database corresponding to the current batch allocation flow may include:

[0102] Based on the verified batch information, determine the current batch information that needs to be verified in the transfer flow;

[0103] Read the transfer flow information from the current batch information that needs to be checked;

[0104] Based on the second-party account information, the read transfer flow is pushed to the counterparty database corresponding to the transfer flow.

[0105] Step 301: Record the verification failure information for the failed transfer transactions.

[0106] In one exemplary instance, if the verification result from the counterparty database is successful, it indicates that the current transfer flow has successfully completed the verification; if the verification result from the counterparty database is unsuccessful, the verification failure record information of the unsuccessful transfer flow is recorded; if no verification result is received within a preset time period, the verification failure record information of the unsuccessful transfer flow is recorded.

[0107] In one exemplary instance, if a table is used to store information related to failed transfer transactions, step 301 may include:

[0108] If the verification result from the counterparty database is successful, it indicates that the current transfer transaction has been successfully verified. If the verification result from the counterparty database is unsuccessful, or if no verification result is received within a preset time period, the relevant information of the unverified transfer transaction is entered as a record into the table used to store the relevant information of the unverified transfer transaction. Furthermore, the relevant information of the unverified transfer transaction may also include information indicating the status of the unverified transfer transaction. For example, when the relevant information of the unverified transfer transaction is first recorded in the table, its status is set to: pending verification.

[0109] In one exemplary instance, information related to a failed transfer transaction may include: batch information, first-party account information, and second-party account information. Furthermore, information related to a failed transfer transaction may also include: information indicating the status of the transfer transaction, such as: status "pending verification," indicating a need for re-verification; status "verification successful," indicating successful verification; status "verification in progress," indicating ongoing re-verification.

[0110] In this embodiment of the application, during the process of verifying the transfer flow, the information of the transfer flow that fails to be verified, namely the relevant information of the transfer flow, is recorded. This lays the foundation for re-verifying the transfer flow that fails to be verified, and also prepares for automatically detecting verification failures and automatically compensating for them.

[0111] This application also provides a computer-readable storage medium storing computer-executable instructions, the computer-executable instructions being used to perform the above-described... Figure 2 and Figure 3 The business data verification method for any item.

[0112] This application further provides an apparatus for implementing business data verification, including a memory and a processor, wherein the memory stores the following instructions executable by the processor: for performing the above... Figure 2 and Figure 3 The steps of any of the business data verification methods described herein.

[0113] This application Figure 2 and Figure 3The illustrated embodiment can be performed by two tasks: one task for the initial verification and another for the compensation verification. The initial verification task performs the verification of transfer transactions batch by batch, checking each batch individually. For batches where verification fails, the relevant information of the failed transfer transactions within that batch is stored in a table. The compensation verification task retrieves the transfer transactions with a pending verification status from the table storing the information of the failed transfer transactions and initiates a re-verification process for those transactions.

[0114] Another embodiment of this application also provides a business data verification method, including:

[0115] Based on the current batch information, push the current batch transfer flow in the current batch to at least one counterparty database corresponding to the current batch transfer flow for verification;

[0116] If there are failed transfer transactions in the current batch, push the failed transfer transactions to the corresponding counterparty database so that the counterparty database can re-verify the failed transfer transactions.

[0117] In the business data verification method of this embodiment, the transfer flow that fails to be verified will be re-verified until the re-verification is successful before the verification of the next batch of transfer flow will continue.

[0118] In another embodiment of this application, during a normal verification task of transfer records, if a transfer record verification fails, the verification task can be automatically paused on the faulty batch. Then, the verification task will attempt to re-verify the transfer records that failed in the faulty batch until the faulty batch is verified, and then the verification of subsequent batches will be performed. This method eliminates the need to record a compensation record table.

[0119] In another embodiment of the present application described above, it may further include: when the re-verification failure condition is met, recording the verification failure record information of the transfer flow that failed to be verified.

[0120] In another embodiment of this application described above, during the process of re-verifying the transfer transactions that failed verification in the faulty batch, if the re-verification of a single failed transfer transaction in the current verification batch meets the re-verification failure conditions, such as the re-verification duration reaching a preset first threshold or the number of re-verifications exceeding a preset first threshold, then the verification failure record information of the failed transfer transaction can be added to the table used to record compensation information for failed transfer transactions, and proceed to the verification of subsequent batches. Thus, in... Figure 2 When the first trigger condition is met, the failed transfer flow can be re-verified based on the added verification failure record information.

[0121] In another embodiment of this application described above, during the process of re-verifying the transfer transactions that failed verification in the faulty batch, if the re-verification of the failed transfer transactions in the current verification batch meets the re-verification failure conditions, such as the re-verification duration reaching a preset second threshold, then the verification failure record information of the transfer transactions that have not yet been successfully re-verified can be added to the table used to record compensation information for failed transfer transactions, and the verification of subsequent batches can proceed. Thus, in... Figure 2 When the first trigger condition is met, the failed transfer flow can be re-verified based on the added verification failure record information.

[0122] The following describes the specific implementation of the business data verification method in this application, taking into account the application scenario.

[0123] Taking the reserve fund system of a clearing institution as an example, the business data verification method provided in any of the above embodiments of this application should be able to be used to process the transfer of quotas between multi-level accounts (such as three-level accounts) within the reserve fund system. Figure 4 This is a schematic diagram of the architecture of the reserve fund system for implementing business data verification in this application embodiment, as shown below. Figure 4 As shown, the reserve fund system is a distributed architecture with multiple locations and multiple centers (e.g., 3 locations and 6 centers). Typically, payment institutions open multiple accounts in the reserve fund system, and these accounts may be distributed across different databases in different data centers. Therefore, the transfer of funds usually involves cross-database operations. To avoid data transfer failures caused by cross-database operations, the clearing institution's reserve fund system uses the business data verification method provided in this application to verify the transfer transaction records. This enables automatic detection and compensation for failed transfer transaction verifications, i.e., re-verifying the transfer transaction records.

[0124] Transfer transactions represent the transfer of credit limits between accounts. This means that for every reduction in credit limit in one account, a corresponding increase must be made in the other. Cross-account verification prevents one-sided increases or decreases. For example... Figure 4 As shown, this embodiment takes account A01 in database A of data center 1 (e.g., deposit 00 database), account A02 in database A of data center 1 (e.g., deposit 00 database), account B01 in database B of data center 2 (e.g., IDC database), and account C02 in database C of data center 3 (e.g., IDC database) as examples.

[0125] The deposit and transfer records (partial fields) of the City 1 Data Center's 00 deposit vault are shown in Table 1:

[0126]

[0127]

[0128] Table 1

[0129] In this embodiment, in order to ensure the uniqueness of the transfer transaction records between accounts, each transfer transaction in Table 1 has a unique tracking number, which ensures the uniqueness of each transaction.

[0130] The batch transfer log is used to record the batches currently being checked, as shown in Table 2:

[0131] 1 202104131600

[0132] Table 2 shows the IDC database of City 2, and the transfer transaction records (partial fields) are shown in Table 3:

[0133] 1 202104131601 B01 A01 1000 111111111 2 202104131601 B01 A01 2000 555555555 3 202104131602 B01 A01 5000 333333333

[0134] Table 3 shows the IDC databases of City 3, and the transfer transaction records (partial fields) are shown in Table 4:

[0135] 1 202104131601 C02 A02 1000 222222222 2 202104131603 C02 A02 6000 444444444

[0136] Table 4

[0137] In a scheduled task, City 1 data center periodically triggers a transfer transaction verification. In this embodiment, according to Table 2, the transfer transaction verification batch table, it can be seen that the batch 202104131600 of the deposit 00 vault has been verified. Therefore, the data verification of batch 202104131601 will automatically begin. City 1 data center reads the data of batch 202104131601 from the transfer transaction table of the deposit 00 vault shown in Table 1. Then, based on the counterparty account information B01 and C02, it pushes the transfer transaction to the application's data center for verification. That is, the transfer transaction of counterparty account information B01 is pushed to City 2 data center, and the transfer transaction of counterparty account information C02 is pushed to City 3 data center.

[0138] In this embodiment, it is assumed that when the transfer transaction of account B01 is pushed to the city 2 data center, due to network interruption, application downtime in the city 2 data center receiving the request, or IDC database failure in the city 2 data center, the city 1 data center does not receive a response or receives a verification failure response within a preset time period. At this time, in the table (which can be called the compensation record table in this embodiment) used to store relevant information of the failed transfer transaction in the deposit 00 database of the city 1 data center, a record to be compensated for verification is recorded, that is, the relevant information of the failed transfer transaction to account B01, as shown in Table 5:

[0139] 1 202104131601 A01 B01 Compensation

[0140] Table 5

[0141] If the transfer transaction record verification from deposit 00 to account B01 is successfully completed (i.e., no system anomaly occurs), then this batch is considered to have been executed successfully, and the verification batch shown in Table 2 is updated to 202104131601. The updated transfer transaction record verification batch table is shown in Table 6:

[0142] 1 202104131601

[0143] Table 6

[0144] By recording the relevant information of the failed transfer transactions during the transfer transaction verification process described in this embodiment, in another scheduled task, the City 1 Data Center can re-verify the failed transfer transactions according to the compensation record table shown in Table 5, which stores the relevant information of the failed transfer transactions. The implementation process may include:

[0145] The City 1 data center periodically scans the compensation record table. If it finds a record with a status of "pending compensation," it will retrieve the corresponding transfer record from the City 1 data center's deposit / transfer record table based on the information recorded in the compensation record table, according to batch information, account information (i.e., first-party account information), and counterparty account information (i.e., second-party account information). In this embodiment, for example... Figure 1 As shown, the transfer record with ID 2 is re-pushed to the data center in city 2 where the counterparty account B01 is located for re-verification of the transfer record. If the verification is successful, the status in the transfer compensation information corresponding to the transfer record in the compensation record table is changed to successful; if the verification fails, the status in the transfer compensation information corresponding to the transfer record remains unchanged so that it can be re-verified when the next scheduled task arrives.

[0146] Figure 5 This is a schematic diagram of the composition structure of the business data verification device in the embodiments of this application, such as... Figure 5 As shown, it includes at least: a compensation module and a recording module; wherein,

[0147] The compensation module is configured to, when the first trigger condition is met, query the record module to determine whether there is an allocation flow with a status of verification failure; push the target allocation flow to the counterparty database corresponding to the target allocation flow so that the counterparty database can verify the target allocation flow, wherein the target allocation flow is any allocation flow with a status of verification failure; and determine whether to change the status of the currently verified target allocation flow based on the verification result.

[0148] The recording module is configured to store the verification failure records of transfer transactions that failed to be verified.

[0149] In one exemplary instance, the recording module may be a table for storing information related to failed transfer transactions, with each record in the table being information related to a failed transfer transaction.

[0150] In one exemplary instance, the compensation module's function of pushing the target allocation flow to the corresponding counterparty database is configured as follows:

[0151] Based on the relevant information of the target allocation flow, obtain the batch information, first-party account information and second-party account information of the target allocation flow; according to the batch information, first-party account information and second-party account information of the target allocation flow, read the corresponding allocation flow record; push the read allocation flow record to the counterparty database corresponding to the second-party account information so that the counterparty database corresponding to the second-party account information can verify the target allocation flow.

[0152] In one exemplary instance, the compensation module is further configured to change the status of the relevant information of the target allocation flow to: verification in progress.

[0153] In one exemplary instance, the compensation module's setting for determining whether to change the status of the target allocation flow that failed the verification based on the verification result is as follows:

[0154] If the verification result is successful, the status of the relevant information corresponding to the target allocation flow will be changed to successful verification; if the verification result is unsuccessful, the status of the target allocation flow will remain unchanged and will remain pending verification; if the verification result is not received within a preset time, the status of the target allocation flow will remain unchanged and will remain pending verification.

[0155] The compensation module in the business data verification equipment of this application enables automatic detection and compensation for failed transfer flow verifications, i.e., re-verification of transfer flow. In other words, it automatically detects and compensates for verification failures, reducing the manual maintenance burden.

[0156] Furthermore, the compensation information for the transfer transactions that failed to be verified includes batch information, first-party account information, and second-party account information. In other words, in this embodiment, the re-verification of the transfer transactions that failed to be verified is not a re-verification of the entire batch of data, but rather excludes the data that has been successfully verified in the current batch and only re-verifies the transfer transactions that failed to be verified in the current batch, thus avoiding waste of resources.

[0157] In one exemplary example, the business data verification device of this application may further include: a verification module, configured to: when the second triggering condition is met, determine the current batch transfer flow and push the current batch transfer flow to at least one counterparty database corresponding to the current batch transfer flow for verification; and record the verification failure record information of the transfer flow that failed to be verified to the recording module.

[0158] In one exemplary example, the information of failed reconciliation transfers in the verification module is recorded in the recording module, configured as follows:

[0159] If the verification result from the counterparty database is successful, it indicates that the current transfer flow has successfully completed the verification; if the verification result from the counterparty database is unsuccessful, the verification failure record information for the unsuccessful transfer flow is recorded; if no verification result is received within a preset time period, the verification failure record information for the unsuccessful transfer flow is recorded. Furthermore, it can be set to: set the status of the relevant information for the unsuccessful transfer flow to "Pending Verification".

[0160] In one exemplary instance, information related to a failed transfer transaction may include: batch information, first-party account information, and second-party account information. Furthermore, information related to a failed transfer transaction may also include: information indicating the status of the transfer transaction, such as: status "pending verification," indicating a need for re-verification; status "verification successful," indicating successful verification; status "verification in progress," indicating ongoing re-verification.

[0161] In this embodiment of the application, the verification module in the business data verification device records the information of the failed transfer transactions during the verification process. This lays the foundation for re-verifying the failed transfer transactions and prepares for automatically detecting and compensating for verification failures.

[0162] Although the embodiments disclosed in this application are as described above, the content described is merely for the purpose of understanding this application and is not intended to limit this application. Any person skilled in the art to which this application pertains may make any modifications and changes in the form and details of the implementation without departing from the spirit and scope disclosed in this application; however, the scope of patent protection of this application shall still be determined by the scope defined in the appended claims.

Claims

1. A method for verifying business data, comprising: When the first triggering condition is met, it is determined whether there is a transfer transaction with a status of verification failure in the verification failure record information; wherein, the verification failure record information is recorded for the transfer transaction that failed to be verified when verifying the transfer transaction of historical batches, and the verification failure record information includes the batch information, first party account information, and second party account information of the transfer transaction that failed to be verified. The target transfer transaction is pushed to the counterparty database corresponding to the target transfer transaction, so that the counterparty database can verify the target transfer transaction; wherein, the target transfer transaction is any transfer transaction among the transfer transactions that failed to be verified; the transfer transaction means that during the credit limit transfer process, one account deducts credit limit and records the transaction, and another account increases credit limit and records the transaction; the counterparty database is a database that has a lending relationship with the current database in the credit limit transfer; the verification includes: determining the second-party account information corresponding to the target transfer transaction based on the verification failure record information of the target transfer transaction, and reading the corresponding target transfer transaction record; determining the counterparty database based on the second-party account information; and sending the target transfer transaction record to the counterparty database, so that the counterparty database corresponding to the second-party account information can verify the target transfer transaction; Based on the verification results, determine whether to change the status of the target allocation flow.

2. The business data verification method according to claim 1 further includes: When the second triggering condition is met, the current batch of transfer flow is determined, and the current batch of transfer flow is pushed to at least one counterparty database corresponding to the current batch of transfer flow to realize the verification of the transfer flow; the verification failure record information of the transfer flow that fails to verify is recorded.

3. The business data verification method according to claim 2 further includes: The failed transfer records are pushed to the corresponding counterparty database so that the counterparty database can re-verify the failed transfer records. If the re-verification meets the re-verification failure condition, the step of recording the re-verification failure information of the transfer flow that failed the re-verification is executed.

4. The business data verification method according to claim 1, 2, or 3, further comprising, before pushing the target transfer flow to the counterparty database corresponding to the target transfer flow: Change the information indicating the status of the transfer flow in the verification failure record to "in progress".

5. The business data verification method according to claim 4, wherein, The step of determining whether to change the target allocation flow that failed the verification based on the verification results includes at least one of the following: If the verification result is successful, the status of the target transfer flow will be changed to successful verification. If the verification result is a verification failure, the status of the target allocation flow remains unchanged; If the verification result is not received within the preset time period, the status of the target allocation flow remains unchanged.

6. The business data verification method according to claim 2 or 3, wherein, The step of determining the current batch allocation flow and pushing the current batch allocation flow to at least one counterparty database corresponding to the current batch allocation flow includes: Based on the verified batch information, determine the current batch information that needs to be verified in the transfer flow; Read the allocation flow from the current batch information; Based on the second-party account information, the read transfer flow is pushed to the counterparty database corresponding to the transfer flow.

7. The business data verification method according to claim 2 or 3, wherein, The verification failure record information for the transfer flow that failed to be verified includes: If the verification result is a verification failure, or if the verification result is not received within a preset time period, the verification failure record information is stored.

8. The business data verification method according to claim 7, wherein the verification failure record information further includes: Information indicating the status of the failed transfer flow; The states include: a pending verification state that needs to be re-verified, a successful verification state that has been successfully verified, or a verification process in progress that is being re-verified. The verification failure record information also includes: Set the status of the relevant information entered in the form to "pending verification".

9. The business data verification method according to any one of claims 1 to 3, wherein, The satisfaction of the first triggering condition includes satisfying at least one of the following: The preset periodic trigger time has been reached; The number of failed transfer transactions has reached a preset threshold. When the statistics of failed transfer transactions reach the preset time limit; A trigger request was received from a pre-set command key.

10. A computer-readable storage medium storing computer-executable instructions for performing the business data verification method according to any one of claims 1 to 9.

11. An apparatus for performing business data verification, comprising a memory and a processor, wherein, The memory stores the following instructions that can be executed by a processor: steps for performing the business data verification method according to any one of claims 1 to 9.

12. A business data verification method, comprising: Based on the current batch information, the current batch transfer flow in the current batch is pushed to at least one counterparty database corresponding to the current batch transfer flow to realize the verification of the transfer flow; If there are failed transfer transactions in the current batch, push the failed transfer transactions to the corresponding counterparty database so that the counterparty database can re-verify the failed transfer transactions. When the conditions for re-verification failure are met, record the verification failure information for the failed transfer transaction. The transfer flow refers to the process in which one account deducts credit limit and records the flow, while the other account increases credit limit and records the flow. The counterparty database is the database that has a lending relationship with the current database in the credit limit transfer. The verification includes: determining the second-party account information corresponding to the target transfer flow based on the verification failure record information of the target transfer flow, and reading the corresponding target transfer flow record; determining the counterparty database based on the second-party account information; and sending the target transfer flow record to the counterparty database so that the counterparty database corresponding to the second-party account information can verify the target transfer flow.

13. A business data verification device, comprising: Compensation module, recording module; among which, The compensation module is configured to, when a first trigger condition is met, query the record module to determine if there is a transfer transaction with a status of "verification failed"; push the target transfer transaction to the counterparty database corresponding to the target transfer transaction so that the counterparty database can verify the target transfer transaction, wherein the target transfer transaction is any transfer transaction among the transfer transactions that failed verification; determine whether to change the status of the current target transfer transaction that failed verification based on the verification result; wherein the transfer transaction represents that during the credit limit transfer process, one account deducts credit limit and records the transaction, and another account increases credit limit and records the transaction, and the counterparty database is a database that has a lending relationship with the current database in the credit limit transfer; the verification includes: determining the second-party account information corresponding to the target transfer transaction based on the verification failure record information of the target transfer transaction, and reading the corresponding target transfer transaction record; determining the counterparty database based on the second-party account information; and sending the target transfer transaction record to the counterparty database so that the counterparty database corresponding to the second-party account information can verify the target transfer transaction; The recording module is configured to store the verification failure records of transfer transactions that failed to be verified.

Images